Before every app stands the same reflexive question: native or cross-platform? And it is mostly answered too early and too fundamentally.
My core thesis from practice: for most apps, Expo is enough — faster, cheaper, one codebase. On top comes a point that tends to be overlooked: Expo brings notifications and OTA updates along. That is infrastructure which normally does not just exist and would otherwise create additional technical overhead — overhead you only see once you have to build it yourself.
Why Expo — and for whom
It was not an ideology call, it was team reality. There were one or two developers, and the knowledge leaned toward React Native. With that, effectively one developer could build the app and cover iOS and Android at once. The Expo documentation covers the iOS and Android cases well, which kept development relatively simple.
That is exactly the selection logic for small teams: not "what is technically purest" but "who can carry this". One codebase a single person can maintain across both platforms beats two native stacks the team is not staffed for.
What Expo delivered
The concrete gain: one codebase plus EAS Build and Submit. That simplified time-to-store considerably — build and ship to both stores from one pipeline instead of maintaining two native toolchains.
The biggest practical lever was the build infrastructure itself. With EAS you push the code and it gets built — a build environment you do not have to operate yourself. The trade-off: the build then runs at Expo, and the code sits there. Whoever does not want that can build locally and submit the finished builds — that path stays open. But the convenience of serving both stores from one configuration is exactly the point that lowers time-to-store.
At its core that is one file:
// eas.json
{
"cli": { "version": ">= 5.0.0" },
"build": {
"preview": {
"distribution": "internal",
"ios": { "simulator": true }
},
"production": {
"autoIncrement": true,
"channel": "production"
}
},
"submit": {
"production": {}
}
}The hype still has to be put in its place. Web works with Expo but was not used — and I would not recommend it here either: users quickly latch onto "this is all the same thing", and that perception costs. We did not use OTA updates either, because the data comes from the backend API anyway and the benefit was thin. The lesson: you take the parts of Expo that fit — not all of it, just because it is included.
Where it hurt
The first expensive surprise is libraries. A library that is excellent on the web is not automatically a good native library. You hit limitations quickly, and you should plan for that from the start. Sometimes the right answer is a licensed library — Mapbox is the classic: solid, but a real cost driver you have to price in early.
The second is the platform difference. iOS and Android diverge faster than "write once" suggests. Concrete example: SQLite concurrency — Android limits simultaneous connections, iOS does not. Same code, different behavior; you find that under load and the hard way. App Store review, by contrast, went entirely smoothly — but only because the app needed no logins and no payments. Nobody should generalize that to their own case.
When it has to be native after all
The clear boundary: native when platform-specific surface comes into play — widgets, App Clips, deeper iOS- or Android-specific features. Native too when the app should be active in the background a lot, or when memory and battery consumption truly have first priority.
Expo now comes astonishingly close in many of these respects. But "close" is not "there" when exactly those things are the product.
Conclusion
For a small team building a normal product app for both stores, Expo is mostly the right choice: one codebase, one person can carry it, and notification as well as OTA infrastructure come along instead of becoming projects of their own. Native is the deliberate exception for OS-deep or resource-critical apps — not the default.
If an app is on your table and you want to weigh whether cross-platform carries it or it has to be native: that very assessment — and the app development after it — is part of my work in Technical Consulting.