iOS and Android app development
This is the page for the decision before the framework decision. Native or cross-platform, one codebase or two, and what that choice costs you in year three rather than in month two.
01Capabilities
Four mobile jobs, and what each does to the platform choice
Mobile work reaches us in a few recognisable shapes, and the platform answer is different in each. Read these as four different pressures on the same decision rather than as a menu.
- Field
Field and operations apps
Apps used by drivers, technicians and warehouse staff, often offline-first, as in our logistics and transportation work. Sync conflict resolution is the real engineering problem here, not the screens.
- Companion
Companion apps for an existing platform
A mobile surface onto a system that already exists on the web. The interesting decisions are about the API contract and what the app is allowed to do while disconnected.
- Rebuilds
App rebuilds and rescues
Apps that shipped, gathered users, and became unmaintainable or unstable. Store review history and crash data usually tell us more in an hour than a week of meetings. Where the answer is repair rather than restart, it runs as ordinary mobile app development against the existing codebase.
- Hardware
Device and hardware integration
Bluetooth peripherals, NFC and RFID, cameras and location. This is where cross-platform frameworks stop being free and the native layer stops being optional.
02Case studies
Two mobile systems we took to both stores
Two published builds, in logistics and in building security, each shipping an iOS app and an Android app.
See all case studies- LogisticsA freight-management platform and mobile apps for a US logistics startup (Mover Technologies)
- SecurityiOS and Android apps for a building-security software companyunicrew contributed to the iOS and Android apps of a security software company, built on its existing web client, through to the production release.
03Fit
Native, cross-platform, or not an app at all
Getting this wrong is expensive in both directions. Unnecessary native work doubles the build; the wrong cross-platform bet forces a rewrite the month a hardware requirement arrives. Five of the six rows below send you off this page, three of them to a framework and two of them away from a mobile build entirely.
| Your situation | What we recommend |
|---|---|
| Heavy device integration: Bluetooth peripherals, camera pipelines, background location | Go nativeSwift and Kotlin. The bridge overhead and the plugin gaps will cost you more than the second codebase does. |
| Mostly forms, lists and API calls, wanted on both platforms, built by one team | Cross-platformEither Flutter or React Native. Which one follows the skills you already employ, not a benchmark. |
| You already run a strong React and TypeScript team on the web | Different pageOur React Native page. Shared language and shared people usually beat a marginally better rendering model. |
| A bespoke interface that must look identical on both platforms | Different pageOur Flutter page. It draws its own widgets, which is what you want when platform convention is not the goal. |
| One platform carries almost all of your users today | Build one onlyBuild that one natively and well. A cross-platform framework is a poor trade when the second platform is not yet a real audience. |
| What the users actually need is the same thing, on a phone screen | Not an appWe will say so. Plenty of "we need an app" conversations end at a good mobile web experience, and yours might be one. |
Scope
What we own is the platform decision and what it costs you later. That covers the second codebase, the store releases, and the maintenance nobody puts in the first budget. unicrew has been building software since 2012, with 100+ senior in-house engineers across six countries. The work runs under an ISO 27001:2022 certified information-security management system. We will not pick the framework we most want to staff and then reason backwards from it.
The expensive question in mobile is not which framework. It is what you do on the second platform, because the second one is where you find out whether your decisions were about the product or about one operating system. Teams that treat both from the start ship slower for a quarter and faster forever afterwards. We would still not recommend it for everyone.
Andrii BurdaSenior Engineering Manager, unicrew04Delivery
How the second platform actually arrives
Most mobile work that reaches us is already live on one platform, or live and unwell on both. These four steps are what we do before we agree to write anything.
- Read the crash data and the reviewsCrash-free rate by version and device, plus what users actually complain about in the stores. This is the cheapest and most honest source of truth about an app's real condition.
- Map the API contractMobile problems are frequently backend problems presented on a small screen. Chatty endpoints and missing pagination show up as a slow app that no amount of client work will fix.
- Decide rebuild versus repair, in writingWith the reasoning stated, because this is the decision you will have to justify internally. Often the answer is repair the worst fifth of it rather than start again.
- Ship through both stores earlyA real release through both review processes as soon as there is anything to release. Store review, signing and device fragmentation are where mobile timelines actually go wrong, which is why they meet our QA and test automation practice first.
05Client voices
Two clients on the mobile work
I’m consistently humbled by Artelogic’s performance. Projects of this caliber are hard to outsource. Teams come and go, and this type of work almost never gets done. They’ve kept their priorities straight as they’ve grown and always deliver.
The project led to the release of our production apps and a prototype showcasing new features. They were reliable, responsive, and consistently addressed our needs very well. We were impressed by their strong technical and interpersonal skills and how smoothly they adapted to our team, processes, and product.
06Stack
The five routes out of this decision
Wherever the decision lands, it lands on one of these, and each has a page of its own.
07Questions
Questions about running two platforms
Answered the way we would answer them on a call. If yours is not here, it is a good first message.
You can bring our mobile engineers onto your team. What we will not do is supply developers and leave the native-versus-cross-platform decision unowned, because that decision sets your cost for years. Design review comes from an architect outside the delivery team, under the same QA and test automation practice as our own projects. Team extension is managed teams; handing over the outcome is mobile app development.
Two when the app depends on device capabilities, background behaviour or performance that differs between the platforms. One when the app is largely forms, lists and network calls, which honestly describes a great many business apps. The question is not which is better in general. It is which is cheaper across the whole life of your app, including the maintenance nobody budgets for.
Yes, including the parts that go wrong: signing and provisioning, privacy declarations, data-collection disclosures and review rejections. We would rather own the first submission than hand you a build and a wiki page. Where you already have store accounts and a release process, we work inside them rather than replacing them.
Usually fix, and we will show you the data behind that. Instability tends to concentrate in a few screens and a handful of device or OS combinations, so the crash-free rate by version tells you quickly whether this is structural. A rebuild is justified when the architecture prevents the fix, not when the app merely feels bad.
A scoping call with an engineer. For an existing app we ask for the crash reporting and the repository beforehand, because the crash-free rate by version answers questions no meeting will. You get back a written recommendation on native versus cross-platform, or on rebuild versus repair, with the reasoning. Most engagements start within two to four weeks.
Three shapes, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based and quoted per project, offered once the first read is done. Team extension is billed monthly per engineer. The rate depends on the seniority mix the work needs, so it is quoted rather than listed.
Deciding the platforms, or fixing an app that shipped?
Tell us who uses the app and what it touches on the device. You will get a straight recommendation on native versus cross-platform, including the version where you build less.