Most business apps do not need to be written twice.
An app has to exist twice. Android and iOS are separate platforms with different languages, different release rules and different review queues. Paying for the same screens twice is the largest avoidable cost in mobile work.
Cross-platform means writing the app once and building both from it. For the app a business actually needs, a job card, a dealer order screen, a booking, that is nearly always the right trade.
A cross-platform app is written once, in one codebase, and then built into an Android app and an iPhone app. The screens, the logic and the connection to your system are shared. Only the handful of places where the two platforms genuinely differ, such as device permissions and push notifications, get separate treatment.
Where it earns its place.
What is actually shared
- Every screen, and how the app moves between them
- The business rules, so an Android and an iPhone behave alike
- The connection to your backend and its permissions
- Offline storage for staff working where the signal drops
- One bug fixed once, reaching both platforms
What still happens twice
Cross-platform is not the same as free. These stay separate whichever tool you pick.
- Two developer accounts, Google Play and Apple
- Two review queues, with Apple the slower of the pair
- Push notification set-up on each platform
- Device permissions for camera, location and storage
- Testing on real Android handsets as well as an iPhone
The apps we build this way
React Native with Expo is our usual choice, and Flutter where a client already runs it.
- Field staff and technician apps
- Dealer and distributor ordering apps
- Customer booking and appointment apps
- Delivery and logistics apps
- Doctor and nurse apps for rounds
- Approval apps for owners who are travelling
How a release actually goes
- Build
- Internal test
- Store review
- Staged rollout
- Over-the-air fix
- A test build on your own devices before anything reaches a store
- Store listings, screenshots and privacy answers, which take longer than people expect
- A rollout to a few people first, so a bad release stops there
- Crash reports coming back with the screen and the device
Over-the-air updates cover most fixes without a store review. Anything touching the native part still waits in Apple’s queue like everybody else.
When native is the better answer
- The app is built around the camera, sensors or Bluetooth hardware
- A game, or anything where the animation is the product
- Deep use of a platform feature that arrived this year
- You already run a native app and a team who maintains it
We say so when we see it. Forcing a shared codebase onto an app that fights it costs more than writing two would have.
When this is the right choice.
- Staff or customers need the app on whichever phone they already carry
- The app is mostly screens, forms, lists and a link to your system
- One small team will maintain it for years
- Android matters most, but a few people on the team carry an iPhone
- You want a fix to reach both platforms from a single change
When it is not.
- An app whose value is a platform feature, such as advanced camera work or a watch companion
- A job a mobile website would do, where an app only adds two store reviews to every change
- A working native app, unless keeping two codebases in step has become the problem
- An internal tool ten people open at a desk, where a web portal is less work for everybody
Questions we are asked about it.
Is React Native or Flutter better?
Both are good, and the choice rarely decides a project. We use React Native because the same TypeScript and the same people cover the web application and the app. If your team already writes Dart, Flutter is the sensible answer.
Will it feel like a real app?
Yes, for the kind of app most businesses need. The screens are real native components, not a website in a wrapper. Where an app lives on animation or hardware, the difference does start to show.
Can it work without internet?
It can, if that is designed in from the start. Field staff in a basement or on a village road need the app to hold the job card and send it when the signal returns. Adding that later is expensive.
Do we need our own Apple developer account?
Yes, in your company name, and a Google Play account too. We set both up with you rather than publishing under ours, because the app should stay yours if we ever part ways.
How do updates reach people?
Most arrive over the air, without anybody visiting a store. Changes to the native part need a fresh build and Apple’s review, which takes as long as it takes and cannot be hurried by us.
Can you work on an app somebody else built?
Usually. We read the code first and tell you whether adding to it or restarting is the cheaper path. Both answers happen, and the code decides it rather than our preference.
Services that use it.
What it sits with.
Not sure Cross-platform apps 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