SwiftUI, UIKit, or both?

01

Ask four questions before choosing

These questions make a framework discussion concrete. A new settings screen and a complex editor may have different needs, even in the same app. My recommendation is to assess the feature rather than assume one choice must govern every screen.

• What is the oldest iOS version the product must support?
• Which screens already work well, and which need to change?
• Are there specific controls or interactions the new feature depends on?
• Which approach can the team implement, review, and maintain confidently?

02

Use integration as an option

Apple supports SwiftUI views inside UIKit through hosting controllers, and UIKit views or view controllers inside SwiftUI through representable wrappers. This allows an existing interface to adopt another approach in a focused area.

03

Choose a small feature to evaluate

Pick a real screen with a clear acceptance criterion. Review layout, navigation, accessibility, and behavior when content is missing or unusually long. Include the supported device sizes and OS versions in the evaluation.

For a hybrid screen, also review where data is owned and how events cross the boundary. A working visual prototype is useful, but it should answer those questions before you treat the approach as settled. This is a planning recommendation, not a benchmark comparing the frameworks.

04

Treat deployment targets as part of the decision

For example, SwiftUI’s support for the Observation framework starts with iOS 17 and macOS 14. A learning example using it needs a compatible deployment target; an app supporting older versions needs a suitable alternative.

05

Make the decision reviewable

Write down the chosen approach, the specific feature it applies to, the constraints you checked, and what would make you revisit it. That gives both the developer and the product team a useful reference as the app evolves.