The startup brought me in after their second mobile engineer left in eighteen months. Both had been "senior mobile developers" on paper. Both had been expensive failures in practice.
The first was a React Native specialist hired to build their iOS app. Within months, they discovered he'd never written a line of Swift. When they needed native integrations—the camera functionality their product required—he was stuck. The app launched six months late with compromises nobody wanted.
The second was a strong iOS engineer hired to also handle Android. She could theoretically write Kotlin, but her Android work was clearly second-class. The Android app crashed constantly, lagged behind iOS on features, and generated half their support tickets. She was frustrated; they were frustrated; users were frustrated.
Neither hiring was stupid. Both made sense given incomplete information. But in both cases, the company had hired "a mobile engineer" when they needed a specific type of mobile engineer—and the mismatch proved expensive.
Mobile engineering has fragmented into distinct specialties with different skills, different tools, and different career paths. Understanding this landscape before you hire is essential[^1].
The Mobile Landscape Has Changed
When the App Store launched in 2008, "mobile developer" was a coherent category. You learned Objective-C, maybe some early Android, and you built apps. The tools were limited, the patterns were emerging, and one person could reasonably understand the whole space.
That world is gone. Today's mobile ecosystem includes iOS native development (Swift, SwiftUI, UIKit), Android native development (Kotlin, Jetpack Compose), React Native (JavaScript/TypeScript with React patterns), Flutter (Dart with its own widget system), and Kotlin Multiplatform (shared Kotlin code with native UIs). Each represents a distinct skill set with its own learning curve, community, and job market.
This matters because hiring managers often underestimate how different these specialties are. A React Native expert and an iOS native expert both "build mobile apps," but they use different languages, different patterns, different tools, and different mental models. Asking a React Native developer to write native iOS code is like asking a frontend developer to write backend Rust—technically both are "programming," but the skills barely overlap.
When I work with companies on mobile hiring, I start by making them articulate exactly what they need. Not "mobile developer" but "iOS engineer who can work with SwiftUI" or "React Native developer who understands native module bridging." The specificity forces clarity that prevents mismatches.
Native Versus Cross-Platform: The Real Tradeoffs
Every company with mobile ambitions eventually faces this question: do we build native apps for each platform, or do we use a cross-platform framework?
| Platform | Key Skills to Assess | Red Flags | Interview Focus |
|---|---|---|---|
| iOS (Swift) | Memory management, SwiftUI/UIKit, App lifecycle | Only knows tutorials | System design for offline-first |
| iOS (Objective-C) | Legacy codebases, bridging | Refuses Swift | Migration strategy |
| Android (Kotlin) | Jetpack Compose, coroutines, lifecycle | Only Java experience | Architecture patterns |
| React Native | Native bridges, performance profiling | "It's just React" | Native module debugging |
| Flutter | Dart, widget trees, platform channels | Only built demos | Production deployment experience |
The honest answer is that both approaches have legitimate uses, and anyone who tells you one is universally better is selling something.
Native development means writing separate codebases for iOS and Android. You get maximum performance, complete access to platform APIs, UI that feels genuinely native, and the ability to adopt new platform features immediately. The tradeoff is cost—you need iOS engineers AND Android engineers, and you build everything twice.
Cross-platform development means sharing code across iOS and Android. React Native and Flutter are the dominant options, with Kotlin Multiplatform gaining ground. You need fewer engineers, ship features to both platforms simultaneously, and maintain one codebase (mostly). The tradeoff is limitations—some native functionality requires workarounds or isn't available, performance can lag native in demanding scenarios, and "native feel" is harder to achieve.
In my experience, the decision often comes down to two questions: What does your app actually do? And what's your team composition?
If your app is content-focused—feeds, forms, standard UI patterns—cross-platform works beautifully. Most B2B apps, content apps, and utility apps fall in this category. The development speed advantage is real, and the limitations rarely matter.
If your app is performance-intensive—games, AR, video processing, complex animations—native is usually necessary. The performance overhead of cross-platform frameworks matters when you're pushing hardware limits.
If your app needs deep platform integration—widgets, watch apps, system extensions, background processing—native makes those integrations much easier. Cross-platform frameworks often have gaps or delays in supporting new platform features.
As for team composition: if you have strong web developers who know React, React Native provides an easier path than hiring from scratch. If you have a dedicated mobile team, native development lets them use their strongest skills.
The worst decision is treating this as an ideology rather than a tradeoff. I've seen companies insist on native for simple apps (wasting money) and companies insist on cross-platform for complex apps (creating technical debt). Match the approach to your actual needs.
What To Look For In iOS Engineers
iOS engineering has evolved dramatically in recent years. The shift from UIKit to SwiftUI represents a fundamental change in how iOS UIs are built, and engineers are distributed across this transition.
Strong iOS engineers today should be fluent in Swift—not just syntactically but conceptually. They should understand Swift's type system, its memory management model, and its concurrency features (async/await, actors). Objective-C still matters for legacy code, but new iOS development is overwhelmingly Swift.
For UI development, the landscape is split. SwiftUI is Apple's declarative framework, released in 2019 and now mature enough for production use. UIKit is the imperative framework that powered iOS apps for over a decade. Most production codebases involve both—SwiftUI for new features, UIKit for existing functionality or cases where SwiftUI has limitations.
What distinguishes senior iOS engineers from junior ones isn't just coding ability but architectural judgment. Senior engineers understand when to use Core Data versus SwiftData versus a third-party solution. They can design apps that handle offline scenarios gracefully. They know how to profile and optimize performance using Instruments. They understand the app lifecycle, memory management, and the constraints of mobile computing.
When interviewing iOS engineers, I probe for this architectural understanding. It's easy to find engineers who can write SwiftUI views; it's harder to find engineers who can design entire apps well. Questions like "Walk me through how you'd architect an offline-first app" or "How would you handle syncing local data with a backend?" reveal whether someone has worked through real problems or just followed tutorials.
The iOS job market is competitive. Strong senior engineers typically earn $180K-$230K in major markets, with staff-level engineers commanding $220K-$280K or more. Demand exceeds supply, especially for engineers with SwiftUI expertise combined with production experience.
What To Look For In Android Engineers
Android engineering has undergone similar evolution. The shift from Java to Kotlin is essentially complete for new development, and the recent transition to Jetpack Compose parallels iOS's move to SwiftUI.
Strong Android engineers should be deeply fluent in Kotlin—its coroutines, flows, and extension functions. They should understand Android's unique lifecycle challenges, which are more complex than iOS due to the activity/fragment system and Android's aggressive memory management.
The UI landscape mirrors iOS's transition. Jetpack Compose is Android's modern declarative framework, now production-ready and preferred for new development. The traditional View system (XML layouts) still runs most existing apps. Engineers need familiarity with both.
Architecture patterns matter heavily in Android. The Android community has converged on MVVM with the Architecture Components (ViewModel, LiveData/StateFlow, Room). Senior engineers should have strong opinions about these patterns and know when to deviate from standard approaches.
Testing is an area where Android engineers vary significantly. Some have deep experience with automated testing—unit tests with JUnit, integration tests with Espresso, UI tests with Compose testing. Others have worked in environments where testing was minimal. Given Android's device fragmentation, testing expertise is particularly valuable.
A revealing interview question for Android engineers: "How do you handle configuration changes without losing state?" This touches lifecycle understanding, state management, and architectural patterns—all critical for Android development. Engineers who struggle with this question may lack depth.
Android compensation roughly parallels iOS, though iOS engineers sometimes command a slight premium due to more constrained supply. Senior Android engineers typically earn $175K-$225K in major markets.
What To Look For In Cross-Platform Engineers
Cross-platform engineering—primarily React Native and Flutter—requires a different evaluation approach than native development.
React Native engineers should have strong JavaScript/TypeScript and React fundamentals. The framework is essentially React with a different rendering target, so engineers coming from web React can ramp up relatively quickly. However, I've seen many React Native hires struggle because they don't understand the native layer beneath the JavaScript.
The key differentiator for strong React Native engineers is native module experience. When the JavaScript layer can't do something—accessing a specific native API, implementing a performance-critical feature—engineers need to drop into native code. React Native engineers who can write native modules (Swift for iOS, Kotlin for Android) are dramatically more valuable than those who can only work in JavaScript.
Flutter engineers work in Dart, which most engineers need to learn specifically for Flutter. The language is approachable if you know Java or JavaScript, but Flutter has its own learning curve. Flutter engineers should understand widgets, state management (Provider, Riverpod, or Bloc), and how to work with platform channels for native integration.
For both React Native and Flutter, I probe for understanding of the bridge/channel between cross-platform code and native code. Questions like "What happens when you call a native module from React Native?" or "How do platform channels work in Flutter?" reveal whether someone understands the architecture or is just writing code on top of it.
Cross-platform engineers often come from web backgrounds, which creates both opportunities and risks. The opportunity is that they bring web development velocity and patterns. The risk is that mobile has constraints—memory, battery, network—that web developers sometimes underestimate. I look for evidence that cross-platform engineers have internalized these mobile constraints.
The Interview Process
Mobile engineering interviews should assess both coding ability and platform-specific knowledge.
For the technical screen, I recommend a conversation rather than a quiz. Instead of "What's the difference between frames and bounds in UIKit?" ask candidates to walk through how they'd build a specific feature. Listen for their thought process, the tradeoffs they consider, and how deeply they understand the platform.
For the practical exercise, have candidates build something representative of real work. A small feature with networking, UI, and state management reveals more than abstract algorithm problems. Mobile development is largely about integration—connecting APIs, managing state, rendering UI—and your exercise should reflect that.
For senior candidates, include a system design component specific to mobile. "Design an offline-first messaging app" or "Architect a photo editing app with undo/redo" reveal architectural thinking that pure coding exercises miss. Listen for how they handle networking, persistence, state management, and the unique constraints of mobile.
Pay attention to how candidates discuss their past work. Strong mobile engineers should be able to articulate technical decisions they made, challenges they faced, and what they'd do differently. If someone can only describe features they built but not how they built them, their experience may be shallower than their resume suggests.
Building a Mobile Team
Team composition depends on your needs and budget, but some patterns work better than others.
If you're hiring a single mobile engineer, they should be senior—ideally someone with experience across both platforms or deep expertise in your primary platform. Solo mobile engineers don't have anyone to learn from or review their code, so they need to be self-sufficient and opinionated about quality.
If you're hiring for both platforms, you need to decide between specialists and generalists. Platform specialists (dedicated iOS engineers, dedicated Android engineers) produce higher-quality platform-specific work but require coordination to keep platforms in sync. Generalists (engineers who work on both platforms) reduce coordination overhead but may produce lower quality on their weaker platform.
If you're using cross-platform, ensure at least one person genuinely understands the native layer. When something goes wrong deep in the bridge, or when you need a native module, you need someone who can actually write native code. An entirely JavaScript/Dart team building React Native/Flutter apps will eventually hit walls they can't climb.
The startup I mentioned at the beginning eventually got mobile hiring right. They stopped posting for "mobile developer" and instead posted for exactly what they needed: a senior iOS engineer with SwiftUI experience for their primary platform, plus a React Native contractor to maintain their secondary Android app while they validated that market.
Two years later, that iOS engineer is now their mobile lead, they've hired a junior iOS engineer she mentors, and they've brought the React Native work in-house as the Android market proved worthwhile. The path wasn't perfectly efficient, but they never again made a hire that fundamentally mismatched the role.
Mobile engineering is fragmented. Embrace the fragmentation by getting specific about what you need.
References
[^1]: SmithSpektrum mobile engineering placement data, 100+ hires, 2020-2026. [^2]: Stack Overflow Developer Survey, 2025. [^3]: Levels.fyi, mobile engineering compensation data, 2026. [^4]: JetBrains, State of Mobile Development, 2025.
Hiring mobile engineers? Contact SmithSpektrum for sourcing support and interview design.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum