Mobile app engineering
Six pages sit under this one and they disagree with each other on purpose. This page is the map. It says which page owns which argument, and where the honest answer is not a mobile app at all.
01Capabilities
Four kinds of mobile project, and the choice inside each one
Each shape has a different first decision, and in none of them is that decision the technology. The pages linked below carry the full argument.
A new app, with the platform question still open
You know you need an app. Whether that is one set of code or two is not settled, and that choice sets your cost for years. The argument lives on iOS and Android, where we make it with you before anyone names a framework, meaning the toolkit the app is written in.
One build that runs on both platforms
That is what cross-platform means: one team, one set of code, two app stores. Flutter and React Native both ship serious products. Each page argues its own case and argues against itself, because the deciding factor is usually your own team rather than a benchmark.
Native depth on one platform
When the app has to do something the phone itself does, you end up native. That means Swift on iOS and Kotlin on Android, written straight against the phone's own system. Sensors, scanners, camera work and background jobs are the usual reasons, as in warehouse and logistics work.
An app in the store that has to stay there
Store review rules change, phone makers withdraw features apps depend on, and privacy declarations get stricter. Objective-C covers the older iPhone end of that. Keeping it going afterwards is maintenance and support.
02Stack
Which of these six pages is yours
One row per page, with the one-line reason to open it. Each row leads to exactly one place, so the whole row is the link.
| Technology | What that page settles |
|---|---|
| iOS & Android | Start hereThe decision before the technology: one set of code or two, and what that costs you in year three rather than in month two.iOS and AndroidOr book a meeting |
| Swift | Native iOSWhere you land once the app has to reach the phone's own hardware, and a cross-platform layer sits between you and it.Swift iOS developmentOr book a meeting |
| Kotlin | Native AndroidAndroid's hard part is the range of handsets, the battery rules each maker adds, and background work that quietly stops. Native gets you control of all three.Kotlin Android developmentOr book a meeting |
| React Native | If you already run ReactThe real advantage is people, not rendering: the engineers who ship your web product can ship the app, and you hire from one pool.React NativeOr book a meeting |
| Flutter | One look, both platformsRight when the design is custom, has to look identical on both platforms, and you want one mobile team rather than two.FlutterOr book a meeting |
| Objective-C | Inherited apps onlyNobody starts here now. Plenty of apps that still earn money did, and the question is whether to keep it running, move it onto Swift, or replace it.Objective-C modernizationOr book a meeting |
03Fit
What we would tell you, including when the answer is not an app
The one call we will not leave to preference is native or cross-platform, and it is made on iOS and Android rather than here. That page carries the full table and the reasoning. This one is the routing above it, including the routes that lead out of mobile entirely.
| Your situation | What we recommend |
|---|---|
| Both platforms, and nobody has settled whether you are funding one app or two | Start on iOS and AndroidThat is where the native-versus-cross-platform call gets made, with the reasoning written down, because it is the decision you will have to defend internally later. It is on iOS and Android. |
| Both platforms, one team, and an app that is mostly screens over data from a server | Cross-platformReact Native if you already write React and TypeScript, because shared people beat a better rendering model. Flutter if the design is custom and has to look identical on each platform. |
| Sensors or scanners over Bluetooth, camera work, or jobs that must keep running while the app is closed | NativeSwift on iOS, Kotlin on Android. Every cross-platform route to these ends in native code anyway, and then you maintain the join as well. |
| What you actually need is a website that works well on a phone | Not an appMobile web has no store review, no signing and no second set of code, and a fair number of app conversations honestly end there. That is web development, not this cluster. |
| The app feels slow, and the server it talks to is chatty | Not a mobile problemFix the server side first: what each request returns, how large it is, and how results are paged. No amount of work inside the app compensates for it. |
| An app already in the store that nobody can change safely | Assess before you chooseAn assessment before a technology choice, and usually repair rather than rebuild. On older iPhone estates that starts at Objective-C, and more broadly at legacy modernization. A rewrite trades known bugs for unknown ones, and your store rating absorbs the difference. |
Scope
What we own is the recommendation and everything after it: how many apps you are funding, the path to release, and whether your own engineers can keep changing the app once we step back. Two of the six rows above send you out of mobile entirely, and a third tells you to assess before choosing anything. That is deliberate. Getting the shape wrong at the start is the most expensive mistake available here, and the cheapest one to avoid. Where the fix turns out to be on the server rather than on the phone, that is custom software development. We work to ISO 27001:2022 and ISO 9001:2015, audited by Quay Audit UK.
You learn what your architecture decisions actually were when you build the second platform. Everything you assumed about navigation, state and what the phone is doing in the background comes back with a bill attached. So decide up front whether the second platform is coming, and be honest, because 'maybe later' is how a codebase ends up shaped for one platform and paying for two.
Andrii BurdaSenior Engineering Manager, unicrew04Delivery
Four answers, taken in this order, and the stack picks itself
The order matters more than the technology. Taken this way, the framework question mostly answers itself.
- Name the hardest thing the app must do on the phoneNot the feature list. The one requirement closest to the hardware: a scanner, a camera pipeline, location tracking that runs for hours, or a stretch offline. That single answer rules out more options than everything else put together.
- Decide how many apps you are fundingTwo native builds means two release calendars, two backlogs and two versions of every bug, for as long as the product lives. That is a budget decision with a technical input, not the reverse, so make it openly rather than inherit it from whoever started coding.
- Exercise the release path before there is much to releaseSigning, the store paperwork, privacy declarations and a real submission through both review processes. Store review and the sheer range of handsets are where mobile timelines actually slip, and the first submission is the cheapest place to find that out.
- Decide who maintains this in year twoYour team, ours, or nobody, answered before the technology is fixed. A stack your engineers cannot read or upgrade is a cost that arrives long after launch, and it never appears in the original estimate.
05Case studies
Three apps we shipped, and what each one had to solve
- 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.
SportSports app development for Triathlon associationunicrew engineers modernized the sports website and built a mobile app for better membership management and race planning.
06Client voices
Two reviews, both about iOS and Android 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.
07Questions
Straight answers on frameworks, hiring and whether you need an app
Yes, and plenty of work starts that way. What we will not do is supply people and leave the platform decision unowned, because that decision sets your cost for years. So an architect outside the delivery team reviews the design, and the work goes through the same QA practice as our own. Team extension is managed teams; handing over the outcome is mobile app development.
None, and a partner with a default here is telling you about their staffing rather than about your product. Two answers decide it: what the app must do on the phone, and what your engineers already write. Once those are on the table the choice is usually obvious and occasionally unwelcome. The full argument is on iOS and Android, and the Flutter and React Native pages each make the case against the other.
Sometimes not, and it is worth asking before you commit to a store presence. Mobile web costs you notifications that behave consistently, reliable background work, deep access to the phone's hardware, and the install itself as a habit. If none of those are load-bearing, a responsive web build gets you there with one set of code and no review process.
Yes, and often that is the shape. For a building-security software company we built the iOS and Android apps on top of the web product they already had, working inside their own team and processes, and helped them release their production apps. What we ask for first is an honest account of what is broken, not a rewrite proposal.
A scoping call with an engineer, not an account manager. For an existing app we ask for the repository and the crash reporting beforehand, because crash-free rate by version and device tells us more in an hour than a week of description. For a new build we want the hardest thing it has to do on the phone. Work usually starts two to four weeks after we agree scope.
Services we deliver in Mobile Apps
All servicesBuilding a mobile app, or keeping one alive?
Tell us what the app has to do, who uses it and what your team already writes. You get a straight read on native versus cross-platform, including the version where you build less.