Mobile development is the craft of shipping software onto the two operating systems people actually carry, and the platforms keep moving the ground under it. Android 16 shipped on 10 June 2025, the earliest major Android release in years, and Google ran two API releases in 2025, the Q4 one a minor release with no app-impacting behaviour changes. Apple's cadence runs the other way: one annual operating system cycle, with Swift 6.2 arriving at WWDC25, its concurrency model defaulting to single-threaded execution until a developer asks for parallelism, and Embedded Swift now running on iPhone coprocessors. Hiring for mobile development means staffing both calendars at once, because every candidate has lived inside exactly one of them.
Challenges in Mobile Development Recruiting
Android and iOS now release on different calendars
The two platforms stopped being rhythmically comparable, and the difference shapes the engineers each one produces. Google compressed its year: Android 16 was the earliest major launch in years, the only 2025 release with planned app-impacting behaviour changes, and a Q4 minor release followed, with quarterly updates in between. Apple keeps the annual clock, and the Swift language tracks it, so an iOS engineer's year has one migration season and eleven quiet months. The hiring consequence is tempo. Android engineers live inside continuous platform churn and target SDK deadlines; iOS engineers live inside one June-to-September compatibility window. That tempo shows in habits: Android candidates quote release numbers and deprecation warnings, iOS candidates quote WWDC sessions and migration seasons. A hiring manager who assumes both populations work the same way will read an Android candidate's constant adaptation as chaos and an iOS candidate's measured cadence as slowness, and pass on both.
Cross-platform development picks a bridge and lives with it
Cross-platform development always means a bridge: Flutter's engine, React Native's JavaScript-to-native bindings, Kotlin Multiplatform's shared code with native UIs. Google announced official support for Kotlin Multiplatform for sharing business logic across Android and iOS at I/O 2024, and production teams have shipped it since, which moved the bridge from experiment to strategy. Compose Multiplatform is now stable for Android, iOS and desktop, with the web target still in beta on WebAssembly. The hiring question is whether the candidate has maintained a bridge across a platform update, because that is the job: when Android or iOS changes an API the bridge wraps, somebody debugs the abstraction while the calendar runs. Candidates who have only written shared code in a greenfield app have not yet met the hard half of cross-platform development, and their interview should say so out loud.
Mobile architecture where offline is the default state
Mobile architecture is designed for the moment the network is not there, which makes it a different discipline from server work wearing a small screen. State has to live on the device, the write queue has to survive an app kill, the sync has to reconcile on reconnect, and the user must never see the gap. That stack has a shape: local database, outbox or pending-write queue, cache invalidation, conflict resolution, and a background scheduler that each platform restricts differently. Candidates who have carried that stack talk about it in loss stories: the offline queue that drained backwards after a flight, the merge conflict on a shared grocery list. Candidates who have only called APIs talk about endpoints, and the endpoint talk is how you know the loss story is missing. The same split shows in their state vocabulary: a real owner distinguishes persisted state, cached state and derived state, because conflating the three is how offline apps lose data quietly. The brief should name the offline posture of the product, because an engineer hired for always-online assumptions will design mobile applications that empty their state the moment a tunnel swallows the signal.
Mobile performance is a battery and jank budget
The performance conversation on mobile is not throughput; it is a budget of battery, memory and main-thread milliseconds, and the platforms now legislate parts of it. Apps targeting Android 16's SDK 36 must support all orientations and be resizable, which forces the layout work that janky apps skipped; the same release pushes adaptive layouts and desktop windowing on large screens. The interview must therefore go after the traces: the frozen frame on a low-end device, the ANR caused by main-thread JSON parsing, the memory warning that killed the background service, the battery drain traced to a wakelock nobody removed, the startup time regressed by a new splash dependency. Mobile performance experience sounds like profiler output, not like a checklist, and it is the least transferable of the mobile skills: an excellent web engineer has never once thought about a doze bucket, a thermal throttle, or the difference between a frozen frame and a slow network call on a two-year-old device.
Mobile UI/UX that the platform guidelines adjudicate
Mobile UI/UX is designed under two courts with different rules. Apple's Human Interface Guidelines and Google's Material conventions decide navigation, gesture, density and accessibility, and the stores enforce the sharpest edges of both. Adaptive work is now the centre of it: orientation independence and resizability are requirements for apps targeting Android 16, and Google's I/O guidance pushes apps toward windowing across phones, tablets and foldables. A designer's screen is one viewport; a mobile engineer's is a matrix of devices, densities and input modes. Screening for mobile UI/UX means asking which convention a candidate fought and lost, which platform gesture they rebuilt instead of reusing, and what their app does on a foldable. Candidates who have shipped to both stores answer with case law, not principles, and they can name the exact guideline that forced the last change.
App store release trains expose inflated mobile applications claims
Mobile CVs inflate more easily than any other software CV because the nouns are public: everyone lists iOS, Android, Kotlin, Swift, Flutter. Verification has to walk the release train, which is the honest audit trail of mobile work. Which release did you own? What changed in it, what regressed in the one after, and what did the crash-free rate do across the rollout? Who triaged the store rejection, and what was the fix when the review board pushed back? These questions fail candidates fast because release history is falsifiable and they know it. The cost of skipping the audit is likewise concrete: a weak mobile hire lands a crash spike in the store reviews, stalls the release train through two review cycles, and leaves a bridge or module the next engineer refuses to touch. Mobile mistakes ship to devices that cannot be patched the same day, so the error window is measured in release trains, and assessment has to be as strict as the store that will adjudicate the outcome.
References
- Android 16 is here — Android Developers Blog. (accessed 2026-09-28)
- Top 3 updates for building excellent, adaptive apps at Google I/O '25 — Android Developers Blog. (accessed 2026-09-28)
- What's new in Swift — WWDC25 — Apple Developer. (accessed 2026-09-28)
- Kotlin Multiplatform Development Roadmap for 2025 — JetBrains. (accessed 2026-09-28)
- Kotlin Multiplatform FAQ — Kotlin Documentation. (accessed 2026-09-28)