SwiftUI or UIKit for a New iOS App? A Requirements Checklist

For a new iOS app, start by testing whether SwiftUI covers the product's hardest interaction. It is a reasonable first candidate for a state-driven interface, but a framework preference should not override a required capability or a team's ability to ship and maintain it.

This checklist is for a product with no existing UI to preserve. For measurement and bridging details, read the SwiftUI–UIKit performance and integration comparison. If you already maintain an app, use the modernization decision guide.

1. Establish the deployment target

List the OS versions and devices the product must support. Check the availability of each API your proposed architecture depends on. A framework being available on an older OS does not mean its newer navigation, observation, or layout APIs are available there.

For example, Observation support in SwiftUI starts with iOS 17. Supporting an older OS may require another observation approach or availability-specific implementation. That is a design constraint to price explicitly, not a reason to pretend the compatibility work is free.

2. Prototype the hardest interaction

A login screen rarely answers the framework question. Instead, prototype the feature most likely to expose a gap: rich text editing, a custom timeline, a camera overlay, a complex collection layout, or a third-party SDK's view controller.

Use representative data and include larger text, VoiceOver, keyboard interaction, and navigation restoration. Decide whether a UIKit component inside SwiftUI would contain the complexity or spread it throughout the application.

Apple documents embedding UIKit in SwiftUI and SwiftUI in UIKit. A hybrid implementation is an available design choice, with explicit lifecycle and state-ownership costs.

3. Choose one owner for state

Observation tracks dependencies; it does not decide where your application's truth lives. Define which object owns the document, account session, or editable draft, and how changes reach persistence.

Avoid keeping separate mutable copies in the view, view model, and repository unless the distinction is deliberate. An editing draft may be separate from a saved record, for example, but it needs explicit save and discard behavior.

Apple's Observation migration guide describes the framework mechanics. Use your own state-transition tests to validate application behavior.

4. Keep persistence independent of the UI decision

SwiftUI does not require SwiftData, and UIKit does not require Core Data. Choose storage based on migrations, synchronization, account identity, data volume, and recovery requirements.

A new app with collaboration requirements needs an explicit sharing design. Do not infer that a persistence framework supports your entire sharing workflow because it supports private iCloud synchronization. The iOS tech-stack decision guide connects these choices to three concrete product shapes.

5. Assess the team's maintenance cost

Include experience with debugging, accessibility, testing, and release support. A short spike can reveal where the team needs training; it cannot establish a universal productivity percentage.

A team experienced in UIKit may ship a complex UIKit-heavy feature more predictably. A team using SwiftUI across several Apple platforms may benefit from shared composition. In both cases, preserve platform-specific behavior instead of treating a shared view as a finished experience everywhere.

6. Record the outcome before expanding scope

The decision should fit into a short record:

• Required OS versions and the workflow used for evaluation.
• Evidence that the interaction, accessibility, and performance criteria pass.
• Any UIKit wrappers or external UI dependencies and their owners.
• State, navigation, and persistence boundaries.
• The main unresolved risk and a test that would resolve it.

If the prototype exposes a problem, reduce the uncertainty before building the remaining screens. If it passes, proceed with one complete user journey, including errors and restoration. The best framework choice is the one supported by that evidence and a maintainable implementation plan.