We get one question more than any other now, usually from someone who just watched Claude Code produce a working screen in a language they don't know how to use.
Why not just have your agent build two fully native apps?
Teams like Shopify, that famously went all-in on React Native a few years ago, are doing just that and moving to building two separate, fully native apps. Again.
Here's the thing: Writing the code was never the expensive part of building cross-platform mobile apps.
The really expensive part comes immediately after v1 has shipped to both stores. And it's got nothing to do with which agent or models you're using, and everything to do with cost.
Teams, Time and Tokens#
Teams#
This is a wild sentence: Today, it's entirely possible for an individual developer to build native apps for each platform.
If you scale up to teams, you don't even need the traditional "iOS" team and "Android" team anymore; you largely only need skilled developers who can steer and leverage AI to its fullest.
Conway's Law infers that, if you have a single team building the same thing, they will ultimately reach for that product to mimic their structure. Or the team will split into two again, Android and iOS.
As an organization, you have to decide how you want to operate: do you want your code to follow your org chart, or do you want your org chart to be governed by your code?
Whichever way you cut it, two codebases will drift the moment they exist unless you've got a single person keep a tight leash on them. Staying on top of that costs you more.
Time#
Two codebases immediately means double the time and effort. It's going to stretch the amount of time required for the entire software development lifecycle: analyzing, scoping, building, testing, QA, publishing, support, and marketing.
But we're saving so much time using AI! We can afford to throw some away on duplication.
That's only true while you're a first mover. When the rest of the industry catches up, your advantage will collapse and that wasted time will come back to haunt you, with your processes and team now entrenched a way of working that is going to be much harder to unpick.
Tokens#
While the true cost of AI compute may be subsidized today, that could change tomorrow. But even if it doesn't, your team are still spending at least double the tokens they need to.
That translates to usage they can't spend elsewhere. Or viewed from another angle, more water and fossil fuels used to power and cool all those AI server farms.
So the right move is the boring one: Keep one source of truth for state and logic, but let each platform's real toolkit render it.
The incumbents#
Every single cross-platform framework built prior to 2025 is built for human developers. They're patches on patches over 10+ years of cruft: switching from Java to Kotlin, Objective-C to Swift, this rendering engine then that rendering engine.
They are dependency hell, where every feature you want to add is tech debt from Day 1. And they're often incapable of leveraging new platform features immediately.
Builds are slow and buggy, and your deployment pipeline breaks every week because some minor package bump now depends on a Gradle version your developers can't use yet.
This translates to poor performance on every side: for your teams and for your users.
Why SuperNative is different#
We started to build SuperNative right as the AI storm began to rage. We're evolving the framework faster and we're adapting every day to how developers are using the emerging tools to move faster and more efficiently.
There's only one way to move faster than building completely separate native codebases: build one codebase that translates to multiple native apps in a single move.
The end result is two completely native apps, but how you get there is via a single codebase.
And it's not by cross-compiling or transpiling from one language to another. By running the actual code you wrote directly on each platform, you can get full platform-native UI and performance without ever having to think about Android vs iOS.
But when you need to, you can dip out directly to Swift or Kotlin with Plugins. No translation layer, no intermediates, everything in one place working beautifully together.
You can have one team—or one person!—build one codebase and end up with gorgeous native apps for any target.
What we built#
SuperNative is the architecture behind NativePHP for Mobile v4. This is the short version. The long version is in the architecture docs: the renderer, render, publish and mount, subtree reuse, the threading model and the embedded runtime, plus a glossary.
Eww! PHP!?
Ignore the language. Your agents don't care that it's written in PHP. What you should care about is the outcome. You get fully native apps, built explicitly for each platform, leveraging each manufacturers' blessed toolchains, giving you fully native performance.
If you've ever thought PHP can't do this or shouldn't do this, think again! It can and it's awesome at it.
And we're a very small team! It's been built by two long-time PHP developers, backed by a growing, profitable org—Bifrost Technology, LLC—, supported by an epic crew of helpers and contributors, and a lot of Claude.
Time to first build#
The final boss for your agent is to get your apps onto the stores. Don't waste your tokens building pipelines or having it browser-use its way through the individual app store flows.
Just use Bifrost.
Bifrost is the build service for SuperNative apps. Once you've got your agent connected to our MCP server, it can set everything else up for you. Have it set up your service accounts and API keys in Bifrost and you'll be deploying to the stores in no time.
Never worry about certificates, keystores, or provisioning profiles ever again. Just ask your agent to do it in no time through Bifrost.
It's the fastest way to build apps with AI, with industry-leading build times.
It was Bifrost's first birthday yesterday, and we added a whole bunch of cool features to celebrate.
Write once, run everywhere#
Even if you have your agents writing two apps, what happens when your business needs shift and you need to support web and desktop? Or TV? What happens when you're asked to make headcount reductions? How do you keep on supporting the users on platforms that don't bring in enough revenue to justify the investment?
SuperNative is the answer and we're driving fast towards true multiplatform support. Install nativephp/mobile today to see where we're heading and how we're getting there. Connect your repo to Bifrost and make your first build.
All that's left for you to do is... Make. Ship. Happen.
