App Development

Native iOS in 2026: SwiftUI or UIKit, and when native wins

7 min readBy Davinder Kumar Meen

A desktop computer, a laptop, a phone and a watch with an orange strap on a desk

Native iOS development in 2026 means Swift, with SwiftUI for most new screens and UIKit where you need fine control or already have a large UIKit codebase; the two work together in one app. Choose native when the iPhone is your main platform, when the app depends on Apple features such as widgets, App Intents, Live Activities, on-device Apple Intelligence or Apple Watch, or when performance and platform feel are the product. Choose cross-platform when you need iOS and Android at the same time with one team and the app is mostly forms, lists and content.

Key takeaways

  • Swift is Apple's language for all its platforms; swift.org lists Swift 6.4.1 as the latest release as of 29 October 2026.
  • Swift 6 added an opt-in language mode that "extends Swift's safety guarantees to prevent data races"; move existing code to it module by module.
  • SwiftUI is the default for new interfaces and is required for widgets, Live Activities and controls; UIKit remains fully supported and the two mix in the same app.
  • Many of Apple's newest features (App Intents, WidgetKit, Foundation Models, Liquid Glass) are Swift APIs first. Cross-platform apps can use them, but through native extensions someone still writes in Swift.
  • Swift 6.3 shipped the first official Swift SDK for Android (March 2026), which lets teams share Swift business logic with Android; it is not a shared UI framework.

What does "native iOS" mean today?

An app written in Swift against Apple's own frameworks, built in Xcode, using SwiftUI or UIKit for the interface. When this post was first written in 2019 it celebrated ten years of the App Store; the choice then was between Objective-C and a young Swift, and between native and "hybrid" web-view apps. Today the comparison is with mature cross-platform frameworks (React Native, Flutter, Kotlin Multiplatform), which we compare in cross-platform or native in 2026. This article is about the native side: which choices you make inside it, and when it is worth it.

Should you use SwiftUI, UIKit or both?

Usually both, with SwiftUI as the default. Apple describes SwiftUI as a declarative framework that works alongside UIKit and AppKit, so you can adopt it screen by screen.

Situation Suggested approach
New app SwiftUI for screens and navigation; drop to UIKit for the odd component SwiftUI does not cover well
Existing UIKit app Keep UIKit; build new screens in SwiftUI and host them in UIKit
Widgets, Live Activities, controls SwiftUI (WidgetKit uses SwiftUI views)
Complex custom text editing, collection layouts with heavy customisation, precise gesture handling UIKit is often easier; wrap it for SwiftUI
Apple Watch, Apple Vision Pro, Mac from the same code SwiftUI shares the most across platforms

Two more decisions sit underneath the UI choice. For local data, Apple's SwiftData (iOS 17 and later) combines, in Apple's words, "Core Data's proven persistence technology and Swift's modern concurrency features"; Core Data itself, plain files or SQLite remain valid choices. For architecture, keep business logic out of views so it can be tested and, if you later want, shared. Our getting started with iOS development guide covers Xcode, simulators and publishing requirements.

What does Swift 6 change for a project?

It moves concurrency bugs from runtime to compile time, if you opt in. The Swift 6 announcement (September 2024) introduced a "new, opt-in language mode" that extends Swift's safety guarantees to prevent data races in concurrent code. Data races are the intermittent, hard-to-reproduce crashes and corrupted state that appear when two threads touch the same data.

For a new app, start in the Swift 6 language mode; the compiler warnings are cheaper than the bugs. For an existing app, follow the migration guide on swift.org and move one module or target at a time, starting with code that has few dependencies. Plan the work: older third-party libraries may not be ready, and some fixes change how your code is structured.

Which Apple features push you toward native?

Features that live outside the main app screen, and features that arrive first as Swift APIs:

  • App Intents make your actions available to Siri, Spotlight, the Shortcuts app, the Action button, widgets and controls, and discoverable by Apple Intelligence. We cover them in iPhone app productivity features: Shortcuts, widgets and Siri.
  • WidgetKit powers widgets, Live Activities and controls, built in a widget extension with SwiftUI.
  • The Foundation Models framework (iOS 26 and later) gives apps the on-device model behind Apple Intelligence, with guided generation into Swift types and tool calling. It needs a device that supports Apple Intelligence.
  • Liquid Glass, the design Apple introduced in June 2025, comes with updated SwiftUI, UIKit and AppKit APIs. Native apps pick up the system look by adopting them.
  • Apple Watch and Apple Vision Pro apps are built with Apple's frameworks.

Cross-platform apps can still offer these, but not in their shared code. Flutter's own documentation, for example, has you add iOS app extensions as native Xcode targets, with Xcode generating the widget code, and it warns that extensions have limited memory. Live Activities need ActivityKit and, for remote updates, ActivityKit push notifications from your server. If an app's value depends on several of these surfaces, a growing share of the code is native anyway, and native from the start is often simpler.

When does native beat cross-platform?

When at least one of these is true:

  1. iPhone is the main market and Android can wait or will be a separate team.
  2. The app lives on system surfaces: widgets, Live Activities, controls, Siri, Apple Watch.
  3. Performance or feel is the product: camera, audio, real-time graphics, large lists, heavy animation, offline data.
  4. You want on-device AI through Apple's frameworks with as little bridging as possible.
  5. The app has a long life and you want to adopt Apple's yearly changes on day one, without waiting for a framework or plugin update.

And cross-platform is usually the better fit when you need both stores at once with one team, the app is mostly forms, lists and content, and the budget favours one codebase. Our Flutter app development page describes that route.

There is a middle path: keep two native interfaces but share logic. Kotlin Multiplatform has offered this for some time, sharing Kotlin code with an iOS app. Since March 2026, Swift 6.3 includes "the first official release of the Swift SDK for Android," which swift.org says lets you build Swift packages for Android and bring Swift code into existing Kotlin or Java apps. It is new, so check library support for your needs before relying on it.

How do you decide for your app?

Write down, for the first two years:

Question Points toward native Points toward cross-platform
Which platforms at launch? iOS first iOS and Android together
How much happens outside the app (widgets, Siri, Watch)? A lot Little
Performance-critical features? Yes No
Team skills Swift developers available JavaScript/TypeScript or Dart team
How fast must you adopt new iOS features? Day one Can wait

Then build a small prototype of the riskiest screen or integration in the approach you favour. Our iOS development team builds native Swift apps and can review a feature list against these questions.

FAQ

Is UIKit deprecated?

No. Apple continues to update UIKit; in 2025 it received the same Liquid Glass design APIs as SwiftUI. Use it where it serves you and mix it with SwiftUI.

Should a new iOS app use SwiftUI?

In most cases, yes, as the default for screens, with UIKit for components that need more control. Widgets, Live Activities and controls require SwiftUI.

Do I need to adopt the Swift 6 language mode now?

For new code, it is worth starting there. For existing apps, migrate gradually, module by module, using the swift.org migration guide.

Can a React Native or Flutter app have widgets and Siri support?

Yes, but those parts are written natively in Swift as app extensions or modules, and the shared code talks to them through bridges and shared storage.

Can Swift code run on Android now?

Swift 6.3 includes an official Swift SDK for Android, so you can build Swift packages for Android and call Swift from Kotlin or Java apps. The Android interface is still built with Android tools.

Sources (13 links)
Share this article