What "fully native" means
The previous lesson covered the four ways to put an app on a phone. This lesson looks closely at the hardest one: writing a separate native app for each platform. An AI coding agent makes this option more realistic than it used to be.
Native means you write the app in the language and tools that the phone's maker provides. No extra layer sits in between.
- iOS (iPhone and iPad): you write the code in Swift. You build the screens with SwiftUI, Apple's toolkit for describing a screen in code. The work happens in Xcode, Apple's development app, which runs only on a Mac. Xcode 26 needs macOS Sequoia 15.6 or later. Since 28 April 2026, every app uploaded to the App Store must be built with Xcode 26 or later and the iOS 26 SDK (checked October 2026).
- Android: you write the code in Kotlin. You build the screens with Jetpack Compose, and the work happens in Android Studio, which runs on Windows, macOS, Linux and ChromeOS. Google has recommended Kotlin since 2019. Java is the older Android language, and you will still see it in existing projects.
Think of it like publishing a book in two languages. React Native is like writing once and printing with a translation layer. Native is like writing two original editions.
Why teams avoided native
Going native meant:
- Two codebases. Every feature had to be built twice.
- Two languages. The team needed Swift skills and Kotlin skills, which usually meant two different people.
- Two sets of bugs. Each app broke in its own way.
That cost is why cross-platform tools such as React Native won. One JavaScript codebase could ship to both stores.
What an AI coding agent changes
This shift is recent, so be clear about how good the evidence is.
- Translating a feature. You can give the agent a finished SwiftUI screen and ask for the same screen in Compose.
- Working in an unfamiliar language. The agent writes the Kotlin, and you ask it to explain each part.
- Keeping two apps in step. Agents can compare the two codebases and list where they differ.
How good is the evidence? The benefits above come mostly from practitioner experience, meaning developers' own reports. They have not yet been measured in careful studies. Where productivity has been measured, the results are mixed. In a 2025 randomised controlled trial, METR studied experienced open-source developers using early-2025 AI tools. They took 19% longer to finish their tasks, even though they believed the tools had made them faster. Treat "AI makes native cheap" as something to test for yourself, not a proven fact.
What native gives you over React Native
Each advantage is real, but each has limits:
- New platform features on day one. Apple and Google release new features for their own toolkits first. Cross-platform libraries catch up later.
- Performance. There is no JavaScript layer. The gap is small for simple screens and matters most for heavy animation or graphics.
- Smaller apps. You do not ship a JavaScript engine inside the app.
- Full use of system features. This advantage is smaller than it was. Expo's
expo-widgetslibrary now builds home-screen widgets for both Android and iOS in React, though it needs a development build. Apple Watch apps and the newest system features are still easiest in Swift. - Fewer framework upgrades. You avoid the regular React Native and Expo version upgrades. You still have to keep up with yearly Xcode and SDK requirements.
What AI does not remove
- Two apps to test and release. You need two store submissions and two review queues.
- Feature drift. A fix made on iOS gets forgotten on Android.
- A Mac and Xcode for iOS. There is no way around this for the full toolchain.
- No over-the-air updates. React Native with EAS Update can push JavaScript fixes to users within minutes, as long as the app store rules allow the change. A native fix needs a full store release.
- Harder reviewing. A later lesson covers when to get human help. Checking AI code in two languages you cannot read is harder still.
Simple rule: go native only when your app's main value depends on a platform feature, and you can test and release two apps. Otherwise, choose a cross-platform route.
Do this: build one screen twice
The example screen is a Streak counter: a title, a number, a "Done today" button that adds 1, and a "Reset" button.
- Write one spec. Put the screen's text, buttons and behaviour in a plain text file. Both apps get built from this file.
- iOS (Mac only): In Xcode, choose File > New > Project > iOS > App and set the interface to SwiftUI. Paste in your spec and ask the agent: "Write ContentView.swift in SwiftUI to match this spec. Explain each line." Pick an iPhone simulator and press Run.
- Android (any computer): In Android Studio, create a project from the Empty Activity template, which uses Compose. Ask the agent: "Write the same screen in Jetpack Compose in MainActivity.kt to match this spec." Create a virtual device in Device Manager, then press Run.
- Check for drift. Go through the spec line by line on both screens. Then ask the agent to compare the two files and list any differences.
- Commit both to GitHub with a message that names the spec.
No Mac? Do the Android part in full. For iOS, use Swift Playgrounds on an iPad to build a SwiftUI app; it cannot do in-app purchases. Another option is to read the agent's Swift code with its explanation, without running it.
Key takeaways
- Native means Swift and SwiftUI in Xcode (Mac only) for iOS, and Kotlin and Compose in Android Studio for Android. Java is the older Android language.
- AI agents lower the cost of two codebases. The evidence is mostly practitioner reports, and measured results are mixed.
- Native's advantages are real but smaller than they were. Expo now handles widgets.
- You still have two releases, a risk of drift, the need for a Mac, no over-the-air fixes, and code in two languages to review.
- Go native only when a platform feature is central to your app and you can run two apps.