Which mobile stack do AI coding agents ship best on?

Quick answer

The best mobile stack for AI coding agents is the one your agent can build, run and verify on your app's hardest feature. Swift and Kotlin give agents first-party tooling in Xcode and Android Studio. React Native with Expo gives them one TypeScript codebase for iOS and Android, while Flutter and Kotlin Multiplatform share code in other ways. Test one real feature on your shortlist before you commit.

Does the mobile stack matter for AI coding agents?

By 2 p.m. your agent had built the same login screen twice, once in Flutter and once in React Native. Both looked fine, so you picked the one with nicer spacing. A week later the company's identity provider still won't hand the user back to the Android app after sign-in. The afternoon measured how well an agent draws a screen; your product needed sign-in that works on two operating systems.

The mobile stack matters for AI coding agents because it decides how much code the agent writes and how it checks its own work. On a native project the agent writes Swift for iOS and Kotlin for Android, so each feature exists twice. On React Native, Flutter or .NET MAUI it writes most features once and drops into platform code for the rest. Kotlin Multiplatform shares Kotlin logic and lets the UI stay native or be shared.

Language familiarity is the other argument. GitHub's Octoverse report found TypeScript became the most used language on GitHub by monthly contributors in August 2025, and linked the shift, as a correlation, to typed languages that make agent-assisted coding more reliable. React Native apps are written in TypeScript and React. Public code volume describes what models have seen, though, not how often an agent finishes your feature correctly.

Tooling around the language makes up the rest of the difference. Apple's Xcode supports coding models and agents from Anthropic, Google and OpenAI and can be extended over the Model Context Protocol (MCP). Android Studio has Gemini Agent Mode for multi-step tasks.

Why did Shopify move from React Native to native?

Shopify announced on September 10, 2026 that it is moving its mobile apps from React Native to Swift and Kotlin, and coding agents are the reason it gives. Shopify had chosen React Native in 2020 partly to stop building the same features twice. In Native is now the future of mobile at Shopify, the team writes that "LLMs changed one of the core assumptions behind our 2020 decision." Agents now do enough of the implementation, translation, testing and review work that building a feature in both Swift and Kotlin no longer costs what it used to.

The Shop app went first, rebuilt natively in 12 weeks, and the main Shopify app, with more than 300 screens, is next. Shopify chose a full rebuild over a gradual migration and built Helix, an internal system that moves agent work through small checkpoints, each gated by tests, visual review, two adversarial code reviews and human approval. The post also says native keeps Shopify "closer to platform capabilities and first-party tooling," and thanks the React Native team at Meta for being "excellent stewards of the framework."

Shopify's post is worth reading in full. If you are weighing the same move, price the harness next to the rewrite, because checkpoints, reviews and agent-friendly test tooling are a large part of Shopify's account.

How do the main mobile stacks compare for agent-driven work?

The stacks below are in alphabetical order. "Best for" describes the team and product each one suits, not a measured agent score.

Flutter's architecture includes native interoperability. Kotlin Multiplatform supports different degrees of sharing, and Compose Multiplatform is listed as stable on iOS if you want to share the UI too. Capacitor is a native runtime for web apps, and .NET MAUI builds native mobile and desktop apps from C# and XAML. None of these architecture facts tells you how a particular agent will do on your repository.

Some cases have a clear winner. Swift and SwiftUI win when iOS is the whole product, or when a feature depends on an Apple API the week it ships; Kotlin and Jetpack Compose win the same way on Android. Kotlin Multiplatform wins when you already have strong iOS and Android teams and only the business logic is duplicated. Capacitor wins when your web app already is the product.

What does a coding agent need from a mobile stack?

A coding agent needs a loop it can run without you: find the installed version of an API, build from a clean checkout, launch the app, see what happened and rerun the check. Without that loop, the agent edits text and waits for a human to open the simulator.

Separate the agent from the toolchain when a run fails. "Agent called an API that doesn't exist" and "runner lacked a signing certificate" need different fixes, so log them differently.

React Native's testing overview explains why tests at different levels catch different problems. Type checks catch invented APIs, component tests catch broken state, and only a run on a simulator or device catches the sign-in redirect that never comes back.

Check the native escape path. Every shared framework can call platform code, but someone on your team has to maintain that bridge. During the trial, ask the agent to write one small native module and see who on the team can review it.

Check upgrades as well. Ask the agent which dependency versions it chose and how the project will get compatible updates, because your app will outlive the model that wrote its first version.

How do you compare mobile stacks with your own coding agent?

Pick a feature that hits your real constraints

Choose a feature that pushes the agent into your product's awkward corners. For a field-service app that might be: capture a photo, attach it to a job record, and upload it when the connection comes back. Point the app at a test service with controlled responses, including a rejected upload and a session that expires while the app is in the background.

Give every stack the same written brief. Record the agent and model version, the documentation it may read and the tools it can use. If one environment needs an hour of setup before the agent can start, count that hour.

Ask for an installable build and a follow-up change

Ask the agent for an installable build on each platform you ship, plus proof that the feature works. Then change the requirement: an unsent photo must survive the app being killed. The second change shows whether the first implementation has a structure your team can work with.

A sheet like this keeps the runs comparable:

Tick a box only when you actually exercised that path. When a run fails, write down the cause before you rerun it, and keep the failed run in the record.

Score outcomes before speed

Score correct behavior and a reproducible build first. A stack that misses a required capability needs a plan before it competes on convenience.

For the stacks that pass, count hands-on correction time more than elapsed time. An agent can work for hours without interrupting anyone, while a ten-minute signing failure can eat an engineer's afternoon. Keep generation time apart from native compile time, or a busy shared runner will quietly pick your winner.

Have a maintainer review the code for the project's conventions and for tests that would catch a plausible regression. Show the raw outcomes before any weighted score.

A decision might read: "Both stacks passed the upload scenario. Our native team fixed failures with less help in Swift and Kotlin, so we will stay native and improve the agent's project instructions." Another team could reach the opposite conclusion with the same frameworks.

Should you switch an existing app's stack to get better AI output?

Improve the agent's setup in your current stack before you switch. Give it project instructions, docs for the versions you run, and a way to build and screenshot the app. A migration has to pay for itself in product and maintenance terms, and a nicer first screen doesn't count.

Set a reconsideration trigger tied to a concrete change, such as a new platform requirement, instead of rerunning the comparison every time a new model ships.

Where Expo fits

Expo belongs on the shortlist when your team has React and TypeScript skills and wants one codebase for iOS and Android. Expo's view is that coding agents ship well on React Native with Expo, and the mechanism is concrete: the agent edits one TypeScript project, so a feature is written and reviewed once for both platforms (you still run it on each). create-expo-app writes an AGENTS.md file that points Claude Code, Codex and Cursor to the docs for your SDK version, per Expo's AI agents guide.

Development builds run the native runtime your app needs instead of the fixed one in Expo Go. EAS Build compiles iOS and Android builds on hosted machines, and EAS Submit uploads them to the stores. An upload is not an approval; App Review and Google Play still make that call.

For the agent itself, Expo Skills are instruction files for Claude Code, Codex, Cursor and other agents (npx skills add expo/skills installs them). The Expo MCP Server lets an agent read current Expo docs, install compatible package versions with npx expo install and trigger EAS builds. With the expo-mcp package on SDK 54 or later, it can also take simulator screenshots and tap views by testID.

Expo is the wrong pick when iOS is the whole product, or when your roadmap depends on new Apple APIs the week they ship; Swift with Xcode's agents is the direct route there. A native team that ships well today shouldn't switch because an agent's default answer names React Native. Expo also leaves you the work of choosing native dependencies and testing hardware-specific behavior.

Limitations

Your result belongs to the workload, agent and model version you tested. A model update can change coding behavior, and a new product requirement can expose a capability the trial never touched. The Expo MCP Server's local iOS capabilities work with simulators only, not physical devices, and only on macOS hosts. Its documentation search tool requires a paid EAS plan, and starting an EAS build from it requires a GitHub repository connected to the project.

Next step

Start one stack from the React Native environment guide, which recommends a framework such as Expo for new apps, then run the same written feature brief against the other stack you are seriously considering.

Verified on 12 September 2026.