Native iOS — Swift + SwiftUI
An iOS app with SwiftUI screens and Swift services around Apple SDKs, for teams whose device integration matters more than sharing one UI across platforms.
Sources verified Sep 2026
Circumstances — when to use it
- iOS is the first platform being implemented
- Bluetooth, camera, AR, or other device APIs are central to the product
- The team can maintain Apple-specific code and test on physical devices
- A separate Android implementation is acceptable if it is needed later
Synergy — how the pieces fit
SwiftUI renders state-driven screens; Swift services own device connections, networking, and persistence. Keep permissions and lifecycle handling outside view bodies, and bridge to UIKit when a control or SDK needs it. Use the platform API appropriate to the task rather than treating a background task as an always-running process: iOS decides when many kinds of background work can run. Prototype the riskiest hardware integration on a real device before building the rest of the interface. Plan for Xcode on macOS and Apple's signing and distribution workflow.
The tech and its role
Architectural examples
Each example links to a public source — no claims about private internals.
Ice Cubes
The Mastodon client's public repository describes a SwiftUI app for Apple platforms, with device-side notifications and account credentials in the keychain. SwiftUI app example; not evidence of Bluetooth or AR functionality.
sourceFruta
Apple's sample demonstrates a feature-rich SwiftUI app and App Clip. A learning sample, not a commercial product or a template for unrestricted background execution.
sourceSkip if
Skip if Android is the first target, or one shared UI implementation across iOS and Android is a hard requirement.