Hire a freelance mobile app developer

The first real decision is native or cross-platform, and it is a budget decision disguised as a technical one. Native means Swift and SwiftUI or UIKit on iOS, and Kotlin with Jetpack Compose on Android: two codebases, two sets of platform conventions, and the best possible access to hardware, background execution and anything new a platform ships. Cross-platform means one codebase — React Native, which suits a team already fluent in React and TypeScript, or Flutter, which gives tighter control of rendering and a consistent look across both platforms. For most line-of-business apps a cross-platform codebase is the right answer; for an app whose whole value is in a camera pipeline, a Bluetooth stack or background location, native usually wins. An engineer who asks what the app has to do before naming a framework is doing this properly.

Offline-first is the requirement that separates apps for work from apps for consumers, and it is almost always under-specified. A technician in a basement, a surveyor on a rural site, an engineer inside a steel building: no signal, and the job still has to be recorded. That means a real local database, a queue of pending changes, sync that resumes after a crash rather than starting again, conflict rules that someone has actually decided — last write wins, or the server wins, or the user is asked — and an interface that makes it obvious what has been saved locally and what has reached the server. Retrofitting any of this is close to a rewrite, which is why it belongs in the first conversation and in the job post.

Then the hardware and the device itself. Apps for work tend to use the parts of a phone that are awkward: the camera for photographs attached to a record and for barcode and QR scanning, GPS and background location, Bluetooth Low Energy to pair with an instrument or configure a device, NFC, file and document handling, printing to a label printer. Each of those carries platform permissions, battery implications and background-execution limits that differ between iOS and Android and change with every OS release. "It works on my phone" is not a status report.

Release is a project in itself and is routinely left out of estimates. Apple and Google both review submissions, both reject for reasons that are not always predictable, and both require things that have nothing to do with code: a developer account in the client’s own name, signing certificates and provisioning profiles, app icons and store screenshots at several sizes, a privacy policy, data-collection disclosures, and a test build distributed through TestFlight or Play Console internal testing before anyone outside the project sees it. Agree early whose accounts the app is published under — it should be the client’s — because moving an app between developer accounts after release is considerably harder than setting it up correctly first.

After that it is maintenance, which never stops. Both platforms ship a major OS version every year, both periodically raise the minimum SDK a store will accept, and an app that is not touched for eighteen months is an app that eventually cannot be updated at all. Crash reporting, analytics on the handful of things worth measuring, and a plan for who does the yearly compatibility pass are part of buying an app, not extras.