The platform is the API.
Swift and Kotlin reach platform frameworks without a cross-platform adapter. That matters when background work, audio, camera, accessibility, app extensions, or OS-specific UI is the product. Direct does not mean automatic.
AI-First Mobile Engineering
Native development for AI-first mobile apps is back
Native is back. AI changed the cost curve. The platforms still get the last word. AI can accelerate Swift and Kotlin in parallel. It cannot turn iOS and Android into one product for free. Native wins when direct platform control is worth owning two real codebases.
Two codebases are not a failure of abstraction when platform behaviour is the feature.
Why native earns the decision again
On-device AI starts closer to the source.
Native code reaches Core ML on Apple platforms and ML Kit, Gemini Nano, or LiteRT on Android directly. Cross-platform plugins can expose the same APIs. Native removes one compatibility layer when model support and device variation are already hard enough.
The debugger sees the real app.
Instruments and Android Studio Profiler show platform threads, memory, network work, rendering, and energy without a framework layer in between. Fewer layers do not prevent bugs. They make ownership harder to dodge.
Current on-device AI entry points, checked 2 September 2026: Apple Core ML (opens in a new tab) and Android ML Kit, Gemini Nano, and LiteRT overview (opens in a new tab).
The AI-first prerequisite
Two codebases. One behavioural contract. Zero copy-paste optimism.
AI can duplicate a feature quickly. It can duplicate a wrong assumption even faster. Keep the product contract and failure corpus shared while each platform owns its implementation.
Testing references: Apple testing in Xcode (opens in a new tab) and Android testing fundamentals (opens in a new tab).
Choose native with the invoice visible
Choose native when
The platform behaviour is product value.
- On-device AI, camera, audio, Bluetooth, background work, accessibility, or OS integration sits at the centre of the product.
- Performance and memory need separate tuning on representative Apple and Android devices.
- An existing native codebase or platform team already makes direct ownership the lower-risk path.
- Your organisation can fund two implementations, two test paths, and two release trains after launch.
Do not choose native when
The budget only contains one app wearing two costumes.
- The product is mostly shared screens and data flows, with little platform-specific value.
- A proven Flutter or React Native path covers the hardest requirement with materially less ownership cost.
- The plan calls two AI-generated codebases “free” and leaves nobody accountable for keeping them aligned.
The compact native engineering stack
Tools evolve. The jobs stay put: catch mistakes, prove behaviour, see reality, and harden the release on both platforms. These examples are current, not canonical.
Catch
Make generated shortcuts fail early.
iOS
Let the Swift compiler catch type failures. Add SwiftLint for the project rules the compiler does not own.
Android
Let the Kotlin compiler catch type failures. Run Android Lint and detekt for platform and code-quality rules.
Prove
Test logic fast and platform behaviour for real.
iOS
Use Swift Testing for unit and integration work, with XCTest UI tests for the journeys only the running app can prove.
Swift Testing + XCTest
Android
Use JUnit and Robolectric for fast feedback, then instrumented Compose or View tests where Android behaviour matters.
JUnit + Robolectric + Android UI tests
See
Inspect the failure at platform depth.
iOS
Use the Xcode debugger and Instruments. Add Pulse or the HTTP Traffic instrument when request and streaming visibility shortens triage.
Instruments
Android
Use the Android Studio debugger and Profiler. Add debug-only Chucker and LeakCanary when network or memory faults hide in normal logs.
Android Studio Profiler
Harden
Raise the extraction cost. Keep provider keys off-device.
iOS
Store session tokens in Keychain, verify App Attest signals on the server, strip release symbols, and treat string-literal obfuscation as friction, not secrecy.
Android
Encrypt session tokens with an Android Keystore key before persisting them, verify Play Integrity signals on the server, and test R8 against release builds. Deeper hardening follows the threat model.
Provider keys do not belong in either binary. Obfuscation and hardening can raise extraction cost. They cannot turn a shipped secret or model into an unextractable asset.
Different stack. Same standard.
Tooling and security references: Apple performance and Instruments (opens in a new tab), Apple HTTP Traffic instrument (opens in a new tab), Android Studio profiling (opens in a new tab), App Attest (opens in a new tab), Play Integrity (opens in a new tab), and R8 app optimisation (opens in a new tab).
An opinion paid for in platform work
Daniel Melter brings recent hands-on native and Flutter development, backed by around ten years of traditional native work. Around three years with React Native apps, plus recent analysis of React Native app binaries with Claude Code, sharpen the view of where shared abstractions save time and where the platforms still collect their debt.
Native is not the premium answer by default. It is the honest answer when the hardest requirement already lives inside iOS or Android.
See why Flutter starts in pole position, read when React Native can beat it, or compare the complete decision at the mobile technology hub.