Core engineering
Hire Mobile Engineers
Engineers who ship apps that feel native, work offline, and get through app review without drama.
A mobile engineer builds iOS and Android applications, natively or with React Native, including offline data sync, performance budgets and release engineering. Hire one when mobile is a primary surface rather than an afterthought. Expect $60 to $140 per hour by seniority.
What this role actually does
Mobile engineering carries constraints that web engineers rarely face. Releases are gated by app review, so a bad build can take days to correct rather than minutes. Devices vary enormously in capability. Connectivity is unreliable, which makes offline-first data synchronisation a core requirement rather than a nice extra. Battery and memory budgets are real and enforced by the platform.
The native versus cross-platform decision is usually less dramatic than it is made to sound. React Native covers most product applications well; native becomes clearly correct when you need deep platform integration, sustained high-performance graphics, or platform features on the day they ship.
Core skills to look for
- React Native with TypeScript, or native Swift and Kotlin
- Offline-first data synchronisation and conflict resolution
- Mobile performance: cold start, frame timing, memory and battery
- Release engineering: signing, staged rollout, crash monitoring
- Push notifications and background processing within platform limits
- App Store and Play Store review requirements, including privacy disclosures
- Mobile-specific accessibility on both platforms
When you need to hire this role
- Mobile is a primary product surface rather than a companion to the web app
- Users work in poor connectivity and need reliable offline behaviour
- Crash rates or store ratings have become a business problem
- Release cycles are slow and risky
- You need platform features your current cross-platform setup cannot reach
How to assess candidates for this role
Ask about offline sync
Have them describe a conflict resolution strategy they shipped. This is where mobile engineering gets genuinely hard and it is difficult to fake.
Probe release discipline
Ask how they handle a critical bug discovered after release. Look for staged rollout, remote configuration and rollback planning.
Test performance knowledge
Ask how they would diagnose a slow cold start. Expect profiling and startup path analysis, not guesses.
Check the platform decision
Ask when they would choose native over React Native. A specific, requirement-driven answer indicates real experience with both.
Typical rate bands
| Level | Experience | Typical rate | What they own |
|---|---|---|---|
| Mid-level | 3-5 years | $60-90/hr | Ships features within an existing app architecture |
| Senior | 6-9 years | $90-120/hr | Owns app architecture, performance and release process |
| Staff / Principal | 10+ years | $120-140/hr | Owns multi-app platform strategy and shared infrastructure |
Frequently asked questions
Should we build native or cross-platform?
React Native handles most product applications well and costs less to maintain across two platforms. Native is the right choice for deep platform integration, sustained high-performance graphics, or immediate access to newly released platform features.
What does offline-first actually require?
A local source of truth, a synchronisation protocol, and an explicit conflict resolution policy. The last part is where most implementations fail, because the correct policy depends on the product and cannot be borrowed from a library.
How much does a mobile engineer cost?
Typical vetted contract rates are $60 to $90 per hour at mid-level, $90 to $120 at senior and $120 to $140 for staff and principal, varying with region and whether both platforms are in scope.
How do we evaluate mobile candidates?
Ask about a shipped app: crash rate, cold start time, release cadence and a specific production incident. Published apps also give you something concrete to inspect before the interview.
Can one engineer cover both iOS and Android?
With React Native, usually yes for product work. With native development, one engineer can cover both but rarely at equal depth, so expect slower delivery on the weaker platform.