Vom SwiftUI-Konzept zum App Store in wenigen Wochen

There is a specific kind of delay that affects iOS projects: the feature that was supposed to ship “in a few weeks” that is still in development three months later because the scope kept expanding and the submission process turned out to have more steps than expected. In reality, shipping a SwiftUI app quickly is not a question of velocity – it is a question of deciding early what the app is not going to do, and then not second-guessing that decision when the temptation to add one more feature appears.

We have shipped several SwiftUI apps on short timelines. The process is repeatable, but it requires discipline about scope, a clear understanding of the Apple submission pipeline, and a willingness to release something that is good but not complete. Here is what that looks like in practice.

Die Umfangsentscheidung erfolgt vor dem ersten Commit

The most important work in a fast iOS release cycle happens before any code is written. The question is not “what should this app do” but “what is the one problem this app solves for the user in version one.” Every feature that is not directly connected to that problem is version two material.

This is harder than it sounds because nearly everything feels relevant when you are designing from first principles. Notifications feel important. Social features feel important. Detailed analytics dashboards feel important. But in reality, users cannot evaluate any of those features until they have used the core function of the app and found it valuable. An app that does one thing well and ships in four weeks generates more useful feedback than an app that does six things acceptably and ships in four months.

The practical tool for this is a two-column list written before development starts: what is in the MVP, and what is explicitly deferred. The deferred list is not a backlog – it is a forcing mechanism. Every feature that gets added to a project in flight should be measured against whether it should go on the deferred list rather than the current sprint. Most of them should.

Die ersten zwei Wochen: Nur Kernbildschirme

A SwiftUI app with a clear single purpose typically needs three to five screens to function: an onboarding flow, one or two primary interaction screens, and a settings or account screen. In the first two weeks, those screens should reach functional completeness – they do the thing they need to do, with real data, in the correct order. They do not need to be polished. Animations can be system defaults. Typography can be whatever the system provides. Error states can be simple text alerts.

The architectural decisions that matter in this phase are the ones that are hard to change later: the navigation model (NavigationStack vs. TabView vs. a custom coordinator), the state management approach (whether to use @Observable from the Observation framework, or stick with ObservableObject), and the data persistence strategy (SwiftData, Core Data, UserDefaults for simple state). Making these decisions explicitly and early – rather than letting them accumulate organically – avoids the situation in week three where half the app uses one navigation model and half uses another.

For apps integrating a Supabase backend, the authentication flow deserves particular attention in this phase. Apple’s App Review guidelines require apps with accounts to offer either Sign in with Apple or a way to delete the account. If your app uses email/password authentication via Supabase, both the Sign in with Apple integration and the account deletion flow need to be in the MVP – not because users will use them on day one, but because App Review will reject the app without them.

Wochen drei und vier: Politur und TestFlight

The third week is when the app starts looking like a real product. This is where you address loading states (not just “show a spinner” but “show a spinner that makes the wait feel appropriate”), empty states (what the app shows when there is no data yet), and error states (what happens when a network call fails). These are not polish – they are the experience for new users, who arrive with no data and occasionally have network problems.

TestFlight distribution should begin in week three, not week four. The reason is that the first build you upload will have build issues you did not anticipate. App Store Connect validates the binary before making it available for testing, and it catches problems – missing entitlements, incorrect provisioning profile combinations, Info.plist keys that are required but absent – that Xcode’s local build does not surface. Encountering these in week three gives you time to fix them before the real submission. Encountering them the night before you want to launch does not.

TestFlight feedback at this stage is most useful for identifying navigational confusion and missing affordances, not for feature requests. Ask testers: “Was there anything you tried to do that you could not figure out how to do?” rather than “What features would you like to see?” The latter question will generate a list that would add months to the timeline.

Der App Store-Einreichungsprozess

The App Store submission process has more steps than first-time submitters expect, and each step has the potential to block the release. Working through them in advance – rather than starting them when the app is code-complete – prevents the final week from becoming a scramble.

Screenshots are required before submission and they must exactly match the required device sizes. Apple currently requires screenshots for 6.9-inch displays (iPhone 16 Pro Max), 6.5-inch displays (iPhone 14 Plus), and iPad Pro 13-inch (6th generation) if the app supports iPad. Generating these in the Simulator is straightforward but time-consuming if you leave it to the last day. A simple Fastlane snapshot configuration can automate this.

The App Privacy details section in App Store Connect requires you to declare every type of data your app collects, what it is used for, and whether it is linked to the user’s identity. This is not optional metadata – submission fails if it is incomplete. If your app uses Supabase with authentication, you collect at minimum email addresses and user identifiers, both of which require disclosure. Third-party SDKs and analytics tools add to this list. Mapping your data collection accurately before submission avoids having to update these details after launch.

App Review typically takes one to three business days for a standard review, faster for apps with expedited review requests (available for genuine time-sensitive circumstances). The review is a human reading the app against Apple’s guidelines, not an automated process. The most common first-submission rejection reasons are: missing account functionality (Sign in with Apple, account deletion), demo account credentials not provided for apps with login, and crashes in edge cases that testers did not encounter but reviewers did.

Was zu kürzen ist und wie

The hardest part of a fast release cycle is making the cuts feel intentional rather than rushed. Users can tell the difference between an app that is deliberately simple and an app that is unfinished. The difference is mostly in the completeness of what is present – every screen that exists should be complete – rather than the number of screens that exist.

Practical cuts that rarely hurt a first release: push notifications (complex to set up correctly, and users need to trust the app before notifications are welcome), social features (following, sharing, leaderboards – useful at scale, distracting at launch), advanced customization settings (most users never change defaults), and any feature that requires significant backend infrastructure that the MVP does not already need.

Practical cuts that do hurt a first release: error handling (an app that crashes on a network timeout frustrates users permanently), loading states (an app that freezes with no visual feedback looks broken), and account management basics (users need to be able to reset their password and delete their account, even in the MVP).

Nach dem Launch: Die ersten zwei Wochen sind am wichtigsten

The first two weeks after launch are the period when App Store ratings are most fragile. An early cluster of one-star reviews because of a crash that did not appear in testing is disproportionately damaging to an app’s long-term rating. Instruments and Xcode’s crash organizer should be checked daily in the first week. A hotfix release addressing any critical crashes should be submitted within 24 hours of identification – App Review offers an expedited path for crash fixes.

The impulse to ship the deferred features immediately after launch is worth resisting for at least two weeks. Understanding how users actually interact with the core experience before adding complexity is more valuable than showing momentum. The version two features on the deferred list will be better designed after two weeks of observing real usage patterns than they would have been if built in parallel with the launch.