Expo is the difference between a release and a week of somebody’s life.
The code is the easy half of a mobile app. The other half is the keystore nobody can find and the provisioning profile that expired last month. Somewhere there is a Mac that is the only machine in the office able to produce an iOS build.
Expo takes most of that away. It also lets you push a JavaScript fix to phones that already have the app, without waiting for a store review, and that is the part teams notice first.
Expo is the tooling around React Native. It builds your Android and iOS apps on its own servers rather than on a developer’s machine, and handles the signing and the store upload. Camera, push notifications, location and biometrics come through one set of libraries. React Native is the app. Everything between that code and a phone in somebody’s hand is Expo.
Where it earns its place.
What Expo actually removes
- Builds on Expo’s servers, so no Mac has to live in your office
- Certificates, keystores and provisioning handled rather than remembered
- Camera, GPS, notifications and biometrics without native code on each platform
- Over-the-air updates for JavaScript changes
- The app running on a real phone over Wi-Fi while it is still being written
Over-the-air updates, and their limits
A JavaScript fix can reach installed phones the same evening. Anything native still needs a new build and a trip through the stores.
- Screens, text, logic and styling can be pushed
- A new native library cannot
- Store rules still apply, and an update may not change what the app is for
- People stay on the old build until they reopen the app
- The server has to keep answering both versions for a while
Useful for a wrong label on the payment screen at 7pm on a Friday. Not a way around review.
Where we use it
- Customer apps for booking, ordering and tracking
- Field staff apps using the camera, GPS and lists that work without signal
- Dealer and distributor ordering apps
- Internal apps for staff, through the stores or internal distribution
- First versions, where getting into a tester’s hands quickly matters
When the bare React Native setup is the better call
Expo covers most device features, and moving off it later is real work. So it is worth knowing where the edge sits before you start.
- A native SDK nobody has wrapped, such as a particular card terminal or biometric device
- Hard limits on app size, where every megabyte is argued over
- Background behaviour the platform only grants to native code
- An existing bare app that already builds and ships without complaint
A development build lets you add your own native code and keep the rest of Expo, which settles most of these without a full move.
The bits teams forget until review day
- Store accounts
- Build
- Listing
- Review
- Release
- Updates
- Play Console and App Store accounts in your business name, not a developer’s
- An Apple developer account somebody renews each year
- A privacy policy page that exists before the app is submitted
- A test login the reviewer can use, or the app comes straight back
- Icons, screenshots and a description that a person has to write
When this is the right choice.
- One codebase for Android and iOS, kept alive by a small team
- Standard device features: camera, location, notifications, files
- A team with no Mac and nobody who enjoys Xcode
- An app that will need frequent small fixes after launch
- A first version where reaching the store matters more than native polish
When it is not.
- An app built around a native SDK nobody has wrapped for React Native
- A bare React Native app that already builds and releases without trouble
- Games, or anything drawing its own interface frame by frame
- A product where the platform itself is the point, and Kotlin or Swift is the honest answer
Questions we are asked about it.
Is Expo only for simple apps?
That was fair once and is repeated long after it stopped being true. Development builds let you add native code and keep the tooling. The apps that outgrow it are the ones with unusual hardware or strict size limits.
Can we publish under our own developer account?
Yes, and you should. The Play Console and App Store accounts belong to your business, with your name as owner. We are added as a developer and can be removed later without the app going anywhere.
What about people who never update apps?
The app checks for an update when it opens and applies it on the next launch. Somebody who leaves it open for days stays on old code, so we keep the API answering both versions rather than assuming everyone moved.
Do we still have to submit to the app stores?
Yes, for the first release and for any change that touches native code. Review times vary and are in nobody’s control, which is why we plan around them instead of promising a launch date.
Can an Expo app work without internet?
Partly, and it takes deliberate work. We cache the lists a field engineer needs, queue what they type in, and sync when a signal comes back. The rest waits, and the screen says so rather than spinning.
What does it cost to run?
There is a free tier that covers a small team, with paid plans for more builds and updates. Apple and Google bill the store accounts separately. We set out the recurring charges before you commit to the approach.
Services that use it.
What it sits with.
Not sure Expo is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private