Mobile developers
Mobile developers build applications that run on hardware belonging to somebody else, under an operating system that may suspend them without warning, in a version the user chose to install and may never replace. Those three facts shape the whole discipline. This guide covers what the work involves on iOS and Android, how to think about the native and cross-platform decision, and what to look for in a candidate.
What does a mobile developer do?
A mobile developer builds and releases applications for iOS, Android or both — the screens and navigation, the local data storage that lets the app work without a connection, the integration with device capabilities such as camera, location, biometrics and notifications, and the release process that carries a build through store review and out to users. The role is also accountable for how the application behaves on constrained hardware: startup time, memory, battery consumption and responsiveness on devices considerably older than the one it was written on.
The structural difference from web engineering is that you do not control the running version. A web fix reaches everyone on the next request; a mobile fix must be built, signed, submitted, reviewed, approved, released and then installed by someone who may decline to update for months. Users therefore run many versions at once, and every server change has to stay compatible with clients written long before it. That single constraint is why mobile teams are careful in ways web teams need not be, and it is what is most often underestimated when a web team is asked to ship an app.
The second difference is the device. The operating system may suspend or terminate the process to reclaim memory, background execution is restricted and differs by platform, connectivity is intermittent rather than binary, and everything the app does is charged to a battery the user is watching. An application that assumes a network, assumes it keeps running when backgrounded, or assumes it will be relaunched in the state it was left in works perfectly in development and behaves strangely for real users.
Finally, the two platforms have genuinely different conventions — navigation and back behaviour, permission models, typography and layout norms, lifecycle, review policy and release tooling. Cross-platform frameworks reduce duplicated code but do not remove the need to understand both, because where the abstraction stops is exactly where users notice: gestures, keyboard handling, notifications, deep links, accessibility and anything touching hardware.
When teams need this capability
Mobile work is frequently assigned to whoever is closest to the front end, on the assumption that an app is a website with a different shell. These are the situations where that assumption becomes costly.
A web team has been asked to produce an app
Capable engineers can usually get something onto a device. What they tend not to have is release engineering, store policy, platform navigation conventions, background execution limits and the habit of designing for an installed base running several versions at once. The first submission rejection is normally where this becomes visible.
The product has to work without a connection
Field work, logistics, retail floors, warehouses, travel, patchy mobile coverage. Local persistence, queued actions, conflict resolution and an honest representation of sync state are a design problem as much as an engineering one, and they cannot be added convincingly after the fact.
Device capability is the product
Camera and scanning, precise or background location, Bluetooth peripherals, biometric authentication, health or sensor data. These sit behind permission models that differ by platform and change between operating system versions, and they are where a generic cross-platform layer most often runs out.
Release quality has started costing something
Crashes concentrated on particular devices or operating system versions, a declining store rating, or a defect that shipped and could not be withdrawn quickly. Mobile has no equivalent of a fast rollback for users who have already updated, so quality has to be enforced before release rather than repaired after it.
Performance on real devices has become a complaint
Slow cold start, scrolling that stutters, the app being terminated in the background, or noticeable battery drain. These are diagnosed with platform profiling tools on representative hardware, and they rarely reproduce on a recent flagship device attached to a debugger.
Core capabilities
Platform fluency
Knowing how each platform expects an application to behave — navigation and back-stack semantics, activity and view controller lifecycle, permission prompts, system typography and layout conventions. Applications that ignore these are usually described by users as feeling wrong before anyone can say why.
Native and cross-platform judgement
Understanding what a shared codebase actually saves, where the abstraction leaks, and what it costs to drop to native code when it does. The decision turns on how much of the product is device-integrated, how differently the two platforms need to behave, and who will maintain it.
Offline behaviour and local data
Choosing a local store, deciding what is cached and for how long, queueing actions taken while disconnected, resolving conflicts when they reach the server, and showing the user a truthful state rather than an optimistic one. Sync is where mobile applications accumulate their most difficult defects.
Performance on constrained hardware
Cold start time, frame rendering during scroll and animation, memory pressure and the terminations it causes, image decoding, and the background activity that drains a battery. The relevant measurements come from older mid-range devices, not from the newest phone in the office.
Release engineering
Signing and provisioning, build variants, versioning, beta distribution, phased rollout, store metadata, and the ability to force an upgrade when a client version must be retired. Much of the operational risk in mobile lives here rather than in the application code.
Store review and policy
Working within the rules each store enforces — privacy disclosure, payment and subscription policy, permission justification, content requirements, account deletion — and designing so that a review outcome is predictable rather than a recurring surprise in the delivery plan.
Notifications and background work
Push delivery through each platform’s service, token lifecycle, permission and opt-in, deep linking into the right screen from a cold start, and background tasks written to survive an operating system that will delay, batch or cancel them.
Mobile accessibility
Screen reader support with VoiceOver and TalkBack, meaningful labels and grouping, respect for the user’s text size and reduced-motion settings, adequate touch target sizes and sensible focus order. Mobile accessibility has its own conventions and testing tools; web knowledge partly transfers but does not cover it.
Device and version fragmentation
Deciding which operating system versions and screen classes are supported, testing across a representative range rather than a convenient one, and handling capability differences without a maze of conditional branches.
Technology ecosystem
Common technologies in mobile engineering are listed below. This describes the landscape of the discipline as it is practised, not a claim about any particular engineer’s toolkit. The more informative question here is which platforms a candidate has released and maintained on, since store, release and lifecycle knowledge is platform-bound in a way that language knowledge is not.
iOS
- Swift
- SwiftUI
- UIKit
- Xcode
- Swift Concurrency
- Combine
Android
- Kotlin
- Jetpack Compose
- Android SDK
- Android Studio
- Coroutines
Cross-platform
- React Native
- Flutter
- Expo
- Kotlin Multiplatform
- .NET MAUI
Local data and sync
- SQLite
- Room
- Core Data
- SwiftData
- Realm
- WatermelonDB
Device services
- APNs
- Firebase Cloud Messaging
- Crashlytics
- Sentry
- RevenueCat
Testing
- XCTest
- Espresso
- Maestro
- Detox
- Appium
- Firebase Test Lab
Build and distribution
- Fastlane
- Xcode Cloud
- Bitrise
- TestFlight
- App Store Connect
- Google Play Console
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Product
- Business priorities
- Roadmap
- Architecture
- Sprint priorities
- Engineering standards
- Day-to-day technical collaboration
Talent.ID handles
- Employment relationship
- Payroll
- Employee benefits
- Talent administration
- Ongoing employee relationship
What to look for when hiring
A published application is better evidence than most disciplines offer, but it is evidence of the surface only. What it does not show is how the release was managed, how the app behaves on weak hardware, or what happens when the connection drops. Probe those instead.
Release history rather than build history
Ask what they have taken through submission and maintained afterwards. Building an application and operating one across many releases are different experiences, and only the second teaches versioning, rollout discipline and compatibility with clients already in the field.
- Has managed signing, provisioning and store metadata rather than only inheriting them
- Uses phased rollout and watches crash-free sessions before widening it
- Can describe a rejection, why it happened and how they resolved it
- Has a considered position on when to force an upgrade and how to warn users first
Platform depth behind the framework
Cross-platform experience is valuable but it can conceal an absent understanding of the platform underneath. Ask what they did when the framework did not cover a case — the answer separates people who have shipped seriously from people who have stayed inside the abstraction.
- Has written or read platform code when the shared layer was insufficient
- Can explain lifecycle and background restrictions on at least one platform
- Knows where the two platforms genuinely need to behave differently
Offline and synchronisation thinking
Ask what their most recent application does with no connectivity. Weak answers describe an error message. Strong answers describe queued work, a local source of truth, and what the user is told while things are pending.
- Distinguishes cached reads from queued writes
- Has a stated approach to conflicts rather than assuming they will not occur
- Represents pending and failed states honestly in the interface
Performance on the devices users own
Ask how they measure startup and scrolling, and on what hardware. Engineers who profile only on current flagship devices will consistently miss the problems their actual audience experiences.
- Uses platform profiling tools rather than impressions
- Tests on older mid-range hardware deliberately
- Can name a specific cause of dropped frames or memory pressure they fixed
- Treats battery consumption as something to measure rather than assume
Crash triage in production
Mobile faults arrive as stack traces from strangers on devices you cannot inspect. Ask how they work from a crash report to a cause, and how they prioritise across a report list.
- Prioritises by affected users and severity rather than by raw count
- Adds breadcrumbs or logging in response to something unreproducible
- Has diagnosed a fault confined to one operating system version or manufacturer
Accessibility on mobile terms
Ask what happens when a screen reader is enabled, or when a user sets a much larger text size. This is a straightforward question that a large proportion of candidates have never considered, and it is a reasonable proxy for craft.
- Has actually navigated their own app with VoiceOver or TalkBack
- Handles large text sizes without truncation or broken layout
- Provides labels for icon-only controls and respects reduced-motion preferences
Reasoning about the architecture choice
Ask when they would choose native over a shared codebase and what would change their mind. You are looking for conditions and tradeoffs, not allegiance to the framework on their CV.
- Ties the choice to device integration, team composition and maintenance horizon
- Can argue the case against the approach they personally prefer
- Recognises that the decision constrains hiring as much as engineering
Interview questions worth asking
Questions chosen to expose how a candidate thinks about releases, devices and users they cannot reach. Use them in your own interview process — you decide who joins your team, on your own assessment.
A defect ships and reaches users. Walk me through what you actually do, from the first report to the fix being in people’s hands.
What a strong answer shows
Whether the irreversibility of a mobile release is understood. Strong answers cover halting or narrowing a rollout, any server-side mitigation available, the submission timeline, and the reality that some users will stay on the broken version regardless.
How would you decide between native and a cross-platform framework for a new application?
What a strong answer shows
Conditional reasoning. Look for weight given to device integration, how far the two platforms must diverge, the team that will maintain it, and the cost of dropping to native occasionally — rather than a general preference presented as a conclusion.
Describe what your app does when the user has no connection, and what it does when the connection returns midway through something.
What a strong answer shows
Genuine offline design. The interesting part is the reconnection: queued actions replayed safely, duplicate submissions prevented, conflicts resolved by a stated rule, and the user shown what is still pending rather than a spinner.
Your server team wants to change an API response shape. Clients in the field are on several older versions. What do you tell them?
What a strong answer shows
Compatibility discipline, which is the habit that most distinguishes mobile engineers from web engineers. Look for additive change, versioned contracts, tolerant parsing, and a plan for retiring old clients that involves warning them first.
Cold start has become noticeably slow as the app has grown. How do you find out why?
What a strong answer shows
Measurement before intervention. Strong answers reach for platform tracing, separate the phases of launch, look at work performed eagerly at startup that could be deferred, and verify the improvement on representative hardware rather than the newest device available.
A crash affects a small proportion of users, concentrated on one operating system version. You cannot reproduce it. What now?
What a strong answer shows
Diagnosis at a distance. Look for reading the trace properly, segmenting by device, version and locale, adding instrumentation deliberately, and forming a hypothesis that can be confirmed by data rather than shipping a speculative fix and waiting.
What happens if I turn on the screen reader and increase the text size on the last app you shipped?
What a strong answer shows
Whether accessibility was practised or assumed. Someone who has done it describes specific fixes — labels for icon controls, layouts that reflow, focus order through a modal. Someone who has not will answer that the framework handles it.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- A team maintains an application on both platforms alongside a roadmap of new features. Crash reports are concentrating on older devices, the offline behaviour needs rework, and each release consumes time the team would rather spend on the product.
- Approach
- Additional mobile capacity works within the team’s established practice — their chosen architecture, their branching and review conventions, their testing approach and their release cadence on each store. Feature priorities and platform decisions continue to be made by the team that owns the application.
- What this adds to the team
- Maintenance and platform work can proceed alongside feature delivery instead of competing with it. What the app becomes, and how it is built, stays under the direction of the people accountable for it.
Related disciplines
Frequently asked questions
- Should we build native or cross-platform?
- It depends on how much of the product is the device. Applications built mostly from forms, lists and content are well served by a shared codebase, and the saving on a second implementation is real. Applications built around cameras, sensors, background location, Bluetooth peripherals or demanding graphics spend that saving on bridging code and platform-specific exceptions. Two non-technical factors decide more cases than the technical ones: who will maintain it, and whether the platforms need to feel meaningfully different. One engineer with a broad feature list generally points to shared; platform specialists with a device-heavy product generally point to native.
- Can a web developer build a mobile app with React Native?
- They can make progress quickly, because the component model and language carry over. What does not carry over is the part that causes trouble: signing and store submission, permission models, lifecycle and background limits, offline behaviour, push delivery and testing across devices. That is where a web engineer working alone loses the time the familiar syntax appeared to save, so combining web familiarity with someone who has released and maintained a mobile application is more reliable than expecting the framework to close the gap.
- Do we need separate iOS and Android engineers?
- If you are building natively, generally yes — the toolchains, languages, conventions and release processes are different enough that genuine depth in both is uncommon. If you are building on a shared codebase, one engineer can cover both, provided someone understands each platform well enough to handle the cases the framework does not. Either way, treat the two platforms as needing separate testing and separate release attention rather than assuming parity because the code is shared.
- How does app store review affect delivery planning?
- It puts a variable delay between finishing a change and users receiving it, and that delay is outside your control. Teams that plan around it release on a predictable cadence, keep something in review while the next version is being built, and use remote configuration or server-side switches so that behaviour can be adjusted without another submission. Teams that ignore it discover the constraint during an incident, which is the worst moment to learn it.
- Does a mobile app need dedicated backend work?
- Almost always, and usually more than expected. The client cannot be updated on demand, so the API has to be versioned and tolerant of old callers; notifications need a service that stores tokens and handles delivery; offline sync needs endpoints designed for reconciliation rather than simple reads and writes. A mobile engineer will have opinions about all of this and can often implement it, but it is server-side work and should be planned as such.
- How should we measure whether a mobile app is healthy?
- Crash-free sessions, cold start time on representative hardware, adoption of recent versions, and the proportion of users who have granted notification and other permissions. Store ratings are a lagging and noisy signal, useful for direction rather than diagnosis. The measure teams most often overlook is version adoption, because it determines how long any given defect stays in the field and how quickly an old client can safely be retired.
- How do mobile developers work with an existing engineering team?
- They work to your direction: your roadmap, your platform decisions, your review process and your release schedule. Technical ownership does not move, and staff augmentation is not an outsourced delivery model. What Talent.ID holds is the employment relationship: payroll, employee benefits, talent administration and the ongoing relationship with the employee.
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.