India is a mobile-first market. Companies like PhonePe, Swiggy, CRED, and Razorpay have world-class mobile engineering teams. Mobile app developer interviews cover platform-specific knowledge (Kotlin/Compose for Android, Swift/SwiftUI for iOS), cross-platform frameworks (React Native, Flutter), and mobile system design. This guide covers what to expect at Indian product companies in 2026.
Mobile app developer salary in India 2026
Mobile app developer salary in India (2024-25):
Junior Android/iOS developer (0-2 years): 6-16 LPA at product companies; 3-7 LPA at agencies. Mid-level mobile engineer (3-5 years): 18-40 LPA at product companies. Senior mobile engineer (5-8 years): 35-70 LPA.
Companies with high demand for mobile engineers in India:
- PhonePe (payments app: 500 million users; Kotlin Android and Swift iOS teams)
- Swiggy (food delivery: complex real-time location and map UX)
- CRED (known for iOS and Android craft; design-obsessed mobile apps)
- Razorpay (payment SDK that embeds into other apps)
- Zepto and Blinkit (quick commerce: complex inventory and delivery UX)
- Ola (both driver and rider apps; Android-first)
Android vs iOS demand in India: Android is significantly more in demand (India is an Android-dominant market; most Indian product companies prioritise Android). iOS roles are rarer but pay comparably due to lower supply of iOS engineers.
React Native: widely used at startups and IT services; pays slightly less than native but opens more roles because one engineer can cover both platforms.
Android interview questions: Activity lifecycle, ViewModel, Compose
Android interview questions for Indian product companies:
1. Activity lifecycle: onCreate: initialise UI and data (called once when activity is created). onStart: activity becomes visible but not yet in foreground. onResume: activity has focus; user can interact. onPause: another activity takes partial focus; stop animations; do NOT do heavy work here. onStop: activity no longer visible; save data. onDestroy: activity being destroyed; release resources.
Common mistake: doing heavy work in onResume (called on every resume from background); do heavy initialisation in onCreate and use ViewModel to survive orientation changes.
2. ViewModel and LiveData: ViewModel: survives configuration changes (device rotation); holds UI-related data; lifecycle-aware (scoped to the Activity or Fragment). LiveData: observable data holder; updates observers automatically when data changes; lifecycle-aware (only updates active observers, preventing memory leaks). StateFlow (modern alternative to LiveData): Kotlin coroutines-based; recommended for new code with Compose.
3. Jetpack Compose: Declarative UI toolkit for Android (similar to React's component model). UI is described in Kotlin @Composable functions. State changes trigger automatic recomposition of only the affected composables. Key concepts: remember and mutableStateOf for local state; ViewModel for state that survives recomposition; LaunchedEffect for side effects (API calls, coroutines).
4. When to use Service vs WorkManager: Service: for tasks that need to run while the user is in the app (music playback, real-time location tracking). WorkManager: for guaranteed background work that must complete even if the app exits or the device restarts (uploading analytics, syncing data). WorkManager is the recommended approach for all deferrable background work in Android.
iOS and Swift interview questions
iOS interview questions:
1. Swift optionals and nil safety: Optionals (Type?): a variable that may or may not contain a value. Swift forces you to handle the nil case explicitly, preventing null pointer exceptions. Unwrapping options: optional binding (if let x = optionalX { ... }), guard let (for early exit), optional chaining (optionalX?.property), and nil coalescing (optionalX ?? defaultValue). Avoid force unwrapping (optionalX!) except when you are certain the value exists.
2. UIViewController lifecycle: viewDidLoad: called once after the view is loaded into memory; set up UI and initial data here. viewWillAppear: called each time before the view becomes visible; use for data that may have changed while the view was off-screen. viewDidAppear: called after the view is visible; start animations or load resources that require the view to be visible. viewWillDisappear / viewDidDisappear: called when the view is being removed; stop animations, save state.
3. Swift concurrency (async/await, actors): async/await: introduced in Swift 5.5; marks functions as asynchronous and allows await to pause execution without blocking the thread. Task: creates a concurrent unit of work. Use Task.detached for fire-and-forget work. MainActor: marks a class or function as running on the main thread (@MainActor annotation); replaces DispatchQueue.main.async for UI updates. actor: a reference type that serialises access to its state, preventing data races.
4. SwiftUI vs UIKit: SwiftUI: declarative, state-driven; newer; fewer APIs than UIKit; used for new features at most companies. UIKit: imperative, delegate-based; mature; still the foundation of most large iOS apps. For interviews: know both; be ready to explain when you would use UIKit (complex animations, custom UI that UIKit handles better, existing UIKit codebases) vs SwiftUI.
Practise mobile engineering interview questions with HireStepX's AI voice interviewer. Get scored feedback on your technical explanations and how clearly you reason through mobile architecture decisions. First 2 sessions free.
Practice freeReact Native and mobile system design
React Native and mobile system design questions:
React Native: 1. What is the React Native bridge? React Native uses a bridge to communicate between JavaScript and native code (Objective-C/Swift for iOS, Java/Kotlin for Android). JavaScript runs in a separate thread; UI updates are sent as serialised messages across the bridge. The new architecture (Fabric + JSI) replaces the bridge with synchronous native bindings, reducing latency.
2. When to use React Native vs Flutter vs native? React Native: best when your team has strong JavaScript/React expertise and you want to share code across iOS and Android (and optionally web). Large library ecosystem. Flutter: best for pixel-perfect custom UIs and when performance consistency matters (Flutter uses its own rendering engine, not native components). Dart learning curve is smaller than many expect. Native (Kotlin/Swift): best when you need access to bleeding-edge platform APIs, maximum performance, or the most platform-idiomatic UX. Highest cost (separate codebases).
Mobile system design questions asked at senior roles:
- 'Design the Twitter feed for mobile (infinite scroll, offline support, and pagination)': discuss local database (Room for Android, Core Data for iOS), pagination strategy (cursor-based), offline-first architecture, background sync, and image caching (Glide for Android, Kingfisher for iOS, or FastImage for React Native).
- 'How do you handle state management in a large mobile app?': Redux (React Native), ViewModel + StateFlow (Android), TCA - The Composable Architecture (iOS). Discuss the trade-offs: global state vs local state, when to use each, and how to avoid unnecessary redraws.
Frequently asked questions
Explore more