Question 1

A user fills out a multi-step checkout form, switches to the camera to take a photo of their ID, and returns to find the form completely reset. How do you distinguish between standard backgrounding and system-initiated process death, and what architectural pattern would you implement to restore transient UI state versus persistent drafts?

Accepted Answer

You can't ask the OS directly whether your process was killed — you infer it. If the process survives backgrounding, your Activity/ViewModel objects are the exact same instances when you return. If the process was killed and recreated, Android calls onCreate(savedInstanceState) with a non-null bundle, and any ViewModel is rebuilt from scratch, restoring only what was written into its SavedStateHandle before death. On iOS, scene/state restoration hands you a small serialized snapshot instead of live objects — same idea.

The fix is to split state into two tiers with different lifetimes. Transient UI state (current step index, scroll offset, which field has focus) belongs in SavedStateHandle — small, cheap, fine to lose on a force-quit. Persistent drafts (the actual values the user typed) should not depend on that mechanism at all, because the save-state bundle has a size limit and isn't guaranteed on every kill path (some OEM 'swipe to kill' flows skip it entirely). Those belong in local disk storage — Room/SQLite or CoreData — written continuously, independent of the OS lifecycle.

Concretely: a CheckoutViewModel debounces each field edit 300ms and upserts it into a checkout_drafts table keyed by a session id stored in SavedStateHandle. On relaunch, the ViewModel first checks SavedStateHandle for the session id (same-process resume is instant), and if that's missing (fresh process), it still has a 'last open draft' pointer persisted separately that it uses to reload the row from disk — so either path gets the user back to where they left off.

Question 2

During an orientation change or entry into split-screen mode, an ongoing network request gets cancelled and re-executed from scratch. How do you decouple async operation lifecycles from view-controller lifecycles to ensure in-flight work survives configuration changes?

Accepted Answer

The bug pattern is launching the coroutine/task directly off the Activity or Fragment's own lifecycleScope, so when the view is torn down and recreated on rotation, that scope is cancelled and the request dies with it — the new Activity instance then kicks off the same call again from zero.

The fix is to own the async work at a layer that survives configuration changes: a ViewModel (which Android explicitly keeps alive across rotation via the same ViewModelStore) launching work in viewModelScope, or a repository-level scope tied to application/process lifetime rather than the screen. The UI layer only observes a stream (StateFlow/LiveData, or a Combine publisher on iOS) exposed by that ViewModel; when the view is recreated, it just resubscribes to the current value instead of re-triggering the request.

For example, in Compose/ViewModel terms:
class ProductViewModel(private val repo: ProductRepo) : ViewModel() {
 val product = MutableStateFlow<Product?>(null)
 init {
 viewModelScope.launch {
 product.value = repo.fetchProduct(id) // survives rotation
 }
 }
}
The Activity is destroyed and recreated on rotation, but the ViewModel instance (and its viewModelScope) is retained by the framework, so the network call keeps running and the new UI just reads the same product StateFlow when it resubscribes.

Question 3

Your app is granted a limited execution window (such as 30 seconds) upon entering the background to flush an analytics queue and upload pending telemetry. How do you handle OS background expiration handlers to ensure requests terminate gracefully without the app getting killed by the watchdog?

Accepted Answer

Both platforms give you a background task handle plus an expiration callback, and the failure mode to avoid is doing unbounded work and letting the OS kill you mid-write, which can corrupt whatever you were flushing. On iOS you call beginBackgroundTask(expirationHandler:) which gives you the roughly-30-second window and, critically, a closure the OS calls a few seconds before time runs out so you can abort cleanly. On Android there's no equivalent grace-period callback for a plain background app, so this pattern is usually implemented via a short-lived foreground service or WorkManager's expedited work, which itself gets an onStopped()/execution-timeout callback to cancel in-flight work.

The pattern is: start the task, race the actual upload against a timer slightly shorter than the OS deadline, and in the expiration handler, cancel the network call and immediately call endBackgroundTask so the OS doesn't treat you as unresponsive. Whatever wasn't flushed stays in the local queue for the next opportunity — you never want to leave the queue in a state where you don't know if an item was sent or not, so writes should be idempotent (each event has an id, dedup'd server-side).

Example (iOS-style pseudocode):
var bgTask: UIBackgroundTaskIdentifier = .invalid
bgTask = UIApplication.shared.beginBackgroundTask { 
 uploadTask?.cancel()
 UIApplication.shared.endBackgroundTask(bgTask)
}
uploadTask = queue.flush { 
 UIApplication.shared.endBackgroundTask(bgTask)
}
If the flush finishes first, you end the task normally; if the expiration fires first, you cancel outstanding work and still end the task — never let the OS have to force-kill you for taking too long, since that can affect future background execution privileges.

Question 4

A user taps a push notification containing a deep link to an order detail screen while the app is in a cold state. How do you construct a synthetic navigation backstack so that pressing the hardware or system back button navigates up to the order history list rather than exiting the application?

Accepted Answer

When the app is launched fresh from a notification, there is no real backstack — the user never actually navigated from Home to Orders to this specific order, so if you just push the OrderDetail screen alone, back exits the app straight to the home screen, which feels broken.

The fix is to synthesize the backstack the user would have had if they'd navigated there normally, before pushing the deep-linked destination. On Android this is TaskStackBuilder: you add the intents for the parent screens (e.g. MainActivity, then OrdersListActivity/fragment) and then the OrderDetail intent on top, so the real Android backstack now has three entries even though only the last one was ever actually shown. On iOS with UINavigationController, you build the same thing manually with setViewControllers([home, ordersList, orderDetail], animated: false) so the nav stack already contains the parents.

Concretely, on Android:
TaskStackBuilder.create(context)
 .addNextIntentWithParentStack(orderDetailIntent)
 .startActivities()
where orderDetailIntent's activity declares parentActivityName=OrdersListActivity in the manifest (or you add each parent intent explicitly). The result: tapping the notification opens OrderDetail directly, but pressing back takes the user to Orders (which itself back-navigates to Home), matching the mental model of 'I came from my order history' even though that screen was never actually rendered along the way.

Question 5

Design the background processing strategy for a continuous delivery-tracking feature that must collect GPS updates reliably for hours without getting suspended by aggressive OS battery optimization modes (e.g., Doze mode or low-power state throttling).

Accepted Answer

Continuous background location is one of the few cases where the platforms deliberately make your life hard, because it's the single biggest battery-drain complaint category, so the design has to work with the OS's exemption mechanisms rather than around them.

On Android, plain background location requests get throttled hard under Doze and App Standby. The correct approach is a foreground service with a persistent notification (which exempts you from most background execution limits, and is legally required by Play policy to be visible so the user knows tracking is active), requesting the ACCESS_BACKGROUND_LOCATION permission, and using FusedLocationProviderClient with a priority tuned to the use case (PRIORITY_BALANCED_POWER_ACCURACY once moving, HIGH_ACCURACY only during active delivery windows) rather than the tightest possible interval at all times. On iOS, you request 'Always' location authorization and use CLLocationManager's significant-location-change or region-monitoring APIs plus allowsBackgroundLocationUpdates, and enable the 'location' background mode capability; iOS will still throttle standard continuous updates unless you're an app the user has explicitly granted Always access to for exactly this purpose.

Practically: batch and locally buffer GPS fixes (e.g. every 30s) and upload in batches every few minutes rather than streaming each point individually — this cuts both battery and network cost, and if a batch upload fails you just retry the whole buffer next cycle instead of losing individual points. The foreground service notification should show live ETA/status so it earns its place as user-visible functionality rather than a workaround.

Question 6

In a modern fragmented or composable architecture, an asynchronous flow emits UI events after the user has navigated away and the view is detached, but the view model remains alive. How do you prevent stale view references and crashes caused by emissions to destroyed view hierarchies?

Accepted Answer

The ViewModel legitimately outlives any single Fragment/View instance (that's the whole point of it surviving rotation and being shared across re-created views), so if a Flow keeps emitting and a stale Fragment reference is still directly updating its own views from that emission, you get a crash or a leak the moment the Fragment is destroyed but the subscription isn't cancelled with it.

The fix is to scope the collection to the view's lifecycle specifically, not the ViewModel's. On Android, that's repeatOnLifecycle(Lifecycle.State.STARTED) inside viewLifecycleOwner.lifecycleScope.launch { ... } — this automatically cancels and restarts the collector as the view starts/stops, and stops it permanently when the view is destroyed, while the ViewModel and its underlying Flow keep running untouched. On SwiftUI/Combine, .onReceive combined with the view's own lifetime (or Combine's .cancel() in deinit for UIKit) achieves the same isolation.

Example:
viewLifecycleOwner.lifecycleScope.launch {
 viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
 viewModel.uiEvents.collect { event -> handleEvent(event) }
 }
}
With this, navigating away stops collection immediately (no crash on a destroyed view), and navigating back re-subscribes cleanly — the ViewModel's flow itself is untouched and continues emitting to whoever's currently listening.

Question 7

A banking app must obscure account balances and sensitive data with a privacy overlay whenever the app switcher / task manager is invoked, while instantly restoring visibility on resume. What lifecycle transitions do you hook into, and how do you ensure no unmasked frames are captured by the OS snapshot?

Accepted Answer

The risk isn't just someone shoulder-surfing the app switcher — it's that both OSes take an actual screenshot of your last-rendered frame to show in the switcher/preview, and that image can be cached on disk. If you only blur the UI after the transition starts, the OS may have already captured the unmasked frame a moment earlier.

On Android, the clean solution is the FLAG_SECURE window flag, which tells the OS to render a black rectangle in the recents thumbnail and to block screenshots/screen recording entirely — set once on the sensitive Activity's window rather than trying to hook onPause timing. On iOS there's no equivalent flag, so you hook applicationWillResignActive (fires the instant the app is about to lose foreground, before the snapshot is taken) to snap an opaque privacy view over the whole window synchronously, and remove it in applicationDidBecomeActive; this is also the correct hook for the incoming-call/Control-Center interruption case, not just the app switcher.

Concretely on Android: getWindow().addFlags(WindowManager.LayoutParams.FLAG_SECURE) on the Activity showing balances. On iOS: in willResignActive, add a UIImageView with your logo (or a blur view) as a subview covering the key window at maximum z-index, synchronously, so it's guaranteed to be in place before the system's snapshot is generated; remove it in didBecomeActive. Test by backgrounding and checking the actual multitasking preview, not just eyeballing the transition.

Question 8

A user rapidly types into a search field, triggering debounced API calls. If the search query changes while a network request is mid-flight, how do you propagate structured cancellation down to the underlying HTTP client to avoid wasting bandwidth and CPU?

Accepted Answer

Debouncing alone only delays when you fire the next request — it doesn't stop an in-flight one that's already outdated by the time it would resolve. You need actual cancellation to propagate all the way down through the coroutine/Task chain into the HTTP client's own cancellation mechanism (its underlying socket/call), not just have your code ignore the result when it arrives.

Structured concurrency makes this straightforward if you set it up right: each new search launches its coroutine as a child of a scope you control, and before launching the next one you cancel the previous Job. As long as your HTTP client (OkHttp, URLSession, etc.) is cooperative — checks isActive / responds to Task cancellation — that cancellation actually tears down the socket instead of just abandoning a reference and letting the response arrive uselessly. On iOS, Swift's structured concurrency does the same with Task cancellation propagating into URLSession's async APIs.

Example with Kotlin Flow's built-in operator (the idiomatic way, since it does exactly this):
searchQueryFlow
 .debounce(300)
 .distinctUntilChanged()
 .flatMapLatest { query -> api.search(query) } // cancels prior in-flight call automatically
 .collect { results -> render(results) }
flatMapLatest cancels the coroutine (and therefore the underlying OkHttp call) for the previous query the instant a new one arrives — no manual Job bookkeeping needed, and no wasted bandwidth parsing a response nobody wants anymore.

Question 9

Your application runs heavy cryptographic operations on background threads while simultaneously trying to read cached records from disk. How do you partition thread pools and dispatchers to prevent compute-heavy tasks from starving high-priority disk I/O and UI rendering pipelines?

Accepted Answer

The failure mode is using one shared, unbounded thread pool for everything: CPU-bound crypto work saturates all cores, and a disk-read task queued behind it has to wait its turn even though it's mostly waiting on I/O, not CPU — and if that pool is also backing anything that touches the main thread's dependencies, you get jank too.

The fix is to give different workload types their own bounded pools sized to their actual resource profile. CPU-bound work (crypto, image processing, compression) should run on a pool sized to roughly the number of CPU cores (Kotlin's Dispatchers.Default does this), because more threads than cores just adds context-switch overhead without more throughput. I/O-bound work (disk, network) should run on a pool that can have far more threads than cores, since those threads spend most of their time blocked waiting rather than executing (Dispatchers.IO is backed by a much larger, elastic pool for exactly this reason). The UI/main thread stays reserved for rendering and short work only.

Concretely in Kotlin:
val cryptoResult = withContext(Dispatchers.Default) { encrypt(payload) }
val cachedRecord = withContext(Dispatchers.IO) { db.query(id) }
Because these run on separate pools, a burst of encryption work maxing out Default's core-bound threads has no effect on IO's ability to service the disk read promptly, and neither can block the main thread since both are dispatched off it. On iOS, the equivalent is choosing appropriate DispatchQueue QoS classes (.userInitiated vs .utility vs .background) rather than dumping everything on a single global concurrent queue.

Question 10

A real-time financial ticker WebSocket emits stock price updates at 120Hz, but your UI chart component can only render at 60Hz without dropping frames. How would you design a backpressure or conflation strategy to handle the emission rate mismatch without causing an out-of-memory error?

Accepted Answer

If you naively buffer every incoming tick waiting for the UI to consume them, the queue grows unbounded because the producer (120Hz) is permanently faster than the consumer (60Hz) — that's a slow, guaranteed OOM, not a one-off spike. The fix isn't to make the UI faster (it's capped by the display refresh rate), it's to accept that some intermediate values are disposable and only the latest matters for rendering.

This is exactly what conflation is for: instead of a queue that holds every value, you hold a single 'latest value' slot that gets overwritten by newer ticks, and the consumer reads whatever is currently there whenever it's ready. You lose intermediate ticks, but for a price chart that's usually fine — the user needs to see the current price, not every micro-update that happened between frames. If you do need every tick for something else (e.g. computing volume-weighted average in the background), that consumer should have its own independent, unbounded-appropriate path rather than sharing the UI's conflated one.

In Kotlin Flow, this is literally the conflate() operator:
webSocketFlow
 .conflate() // drop intermediate ticks if collector is slower
 .collect { latestPrice -> chart.update(latestPrice) }
conflate() lets the producer keep emitting freely while the collector only ever processes the most recent value once it's ready for the next one — no unbounded buffer, no backpressure signal needed back to the producer, and no dropped frames from the UI trying to catch up on a stale backlog.

Question 11

A user triggers a 'Refresh Feed' action followed immediately by an 'Apply Filter' action. Due to network latency, the 'Refresh Feed' payload returns after the 'Apply Filter' payload. How do you architect your state layer to prevent stale responses from overwriting newer user intent?

Accepted Answer

This is a classic race condition: two requests are in flight, the newer one (Apply Filter) happens to resolve first, and then the older one (Refresh Feed) lands afterward and blindly overwrites the state with a now-stale result — the user sees the filter applied for a split second and then sees it silently reverted.

The general fix is to make every request carry a version/sequence number (or the request's own generation id) and only accept a response into state if it's still the latest one you asked for; any older response is simply discarded on arrival. This is the same underlying idea as flatMapLatest cancellation, but explicit versioning is useful when you can't just cancel the older request outright (e.g. it's a fire-and-forget write, or cancellation isn't cheap) and instead need to tolerate it completing but ignore its result.

Example:
var latestRequestId = 0
fun refreshFeed() {
 val requestId = ++latestRequestId
 api.fetchFeed { result ->
 if (requestId == latestRequestId) state.update(result) // else: stale, drop it
 }
}
Every new user action (refresh or filter) increments the same counter and captures its own snapshot of it; when a response arrives, it only applies if no newer action has started since. This guarantees the state layer always converges to whatever the user asked for last, regardless of which network response happens to land first.

Question 12

You are building an in-memory image and data cache that will be accessed and mutated concurrently by multiple worker threads. How do you implement thread safety using modern language primitives (e.g., actors, read-write locks, atomic references) while avoiding lock contention and priority inversion?

Accepted Answer

A plain synchronized/mutex-guarded HashMap works but serializes every access — readers block behind writers and other readers even though most cache traffic is reads. The two modern approaches that reduce contention meaningfully are read-write locks (many concurrent readers, exclusive writer) and actors (single-threaded-confinement instead of locking at all, so there's no lock to contend over or invert priority on).

Swift's actor model is a clean fit here: an actor serializes access to its own mutable state automatically, and every access from outside is an async call, so the compiler enforces you can't accidentally read/write without going through the actor's isolation — you get correctness without manually reasoning about lock ordering. On the JVM/Kotlin side, a ReentrantReadWriteLock (or Java's ConcurrentHashMap for a simpler map-shaped cache, which uses fine-grained internal striping instead of one global lock) gives you concurrent reads with exclusive writes, which suits a cache that's read far more often than it's written.

Example (Swift actor):
actor ImageCache {
 private var storage: [String: UIImage] = [:]
 func get(_ key: String) -> UIImage? { storage[key] }
 func set(_ key: String, _ image: UIImage) { storage[key] = image }
}
Because the actor serializes its own reentrant calls, two threads calling get() and set() concurrently never race on storage directly — the runtime queues the actor's own method bodies, which avoids both explicit lock management and the classic priority-inversion trap of a low-priority thread holding a lock a high-priority thread is waiting on.

Question 13

Implement the core logic for polling an asynchronous document-generation endpoint, incorporating exponential backoff, randomized full jitter, and a hard circuit-breaker timeout.

Accepted Answer

The three pieces work together: exponential backoff spaces out retries so you're not hammering a slow endpoint every second; full jitter randomizes each wait so many clients polling the same backend don't all retry in synchronized bursts (the 'thundering herd' problem); and a hard overall timeout guarantees the poll gives up and surfaces an error instead of looping forever if the document generation genuinely never finishes.

Full jitter specifically means picking a random delay between 0 and the exponential cap, not just adding a small random offset to a fixed exponential value — that's what actually breaks up synchronized retry storms across many clients.

suspend fun pollDocumentStatus(jobId: String): DocumentResult {
 val startTime = System.currentTimeMillis()
 val hardTimeoutMs = 60_000L
 var attempt = 0
 while (System.currentTimeMillis() - startTime < hardTimeoutMs) {
 val status = api.checkStatus(jobId)
 if (status.isReady) return status.result
 val cap = minOf(30_000L, 1000L * (1 shl attempt)) // exponential, capped at 30s
 val jitteredDelay = Random.nextLong(0, cap) // full jitter
 delay(jitteredDelay)
 attempt++
 }
 throw TimeoutException("Document generation exceeded $hardTimeoutMs ms")
}
This backs off from 1s toward a 30s cap as attempts increase, randomizes each actual wait within that cap, and unconditionally throws once the 60-second hard budget is exhausted — so a caller never hangs indefinitely on a stuck job, and the backend never sees a fixed, predictable retry cadence from every client at once.

Question 14

When passing long-lived callback closures across architectural boundaries to perform asynchronous network handling, how do capture lists and weak reference semantics prevent memory leaks and retain cycles?

Accepted Answer

A retain cycle happens when object A holds a strong reference to a closure, and that closure itself strongly captures A (directly, or through self) — neither can ever be deallocated because each is keeping the other alive, even after the screen that owns them is dismissed. This is especially easy to trigger with a long-lived callback (a network completion handler stored on a singleton service, a delegate closure held past the view's lifetime) because the closure genuinely does outlive the immediate call site.

Swift's capture list lets you specify how a closure captures external variables, and weak self is the standard fix: the closure holds a weak (or unowned, if you're certain self can never be nil when it fires) reference to self instead of a strong one, breaking the cycle. Inside the closure you then have to unwrap that optional weak reference before using it, since self may legitimately have been deallocated by the time the closure runs (e.g. the user navigated away before the network call finished) — which is also exactly the behavior you want, since it stops a completed callback from firing dead work into a gone screen.

Example:
class ProfileLoader {
 func loadProfile(completion: @escaping (Profile) -> Void) {
 networkService.fetch { [weak self] result in
 guard let self = self else { return } // self was deallocated, bail cleanly
 self.cache(result)
 completion(result)
 }
 }
}
Without [weak self], networkService's stored closure would keep self alive indefinitely (a leak) even if the user closed the profile screen; with it, self can be deallocated normally, and the guard makes the callback a safe no-op if that already happened.

Question 15

A feed containing heterogeneous list items experiences significant frame drops (jank) during rapid scrolling on mid-tier hardware. Walk through your profiling methodology to isolate whether the bottleneck is view inflation overhead, layout pass recalculations, or expensive payload binding.

Accepted Answer

You don't guess — you profile in a specific order because each layer's symptom looks slightly different in the tooling. Start with Android Studio's Profiler / Perfetto systrace (or Instruments' Time Profiler + Core Animation on iOS) while scrolling the actual jank-prone feed, and look at where each frame's 16ms/8ms budget is actually being spent: inflate/layout/draw/bind are each their own trace sections.

If the time is dominated by inflate calls repeating for view types that should be recycled, that points to the RecyclerView/UICollectionView not reusing view holders correctly (e.g. too many distinct viewType values fragmenting the recycle pool, or DiffUtil forcing full rebinds). If it's dominated by layout/measure passes, that usually means nested ViewGroups doing redundant measure passes (a LinearLayout inside a ConstraintLayout inside a CardView, each re-measuring children) — flattening the hierarchy or switching to ConstraintLayout/single-pass layout fixes this. If it's bind, you look at onBindViewHolder/cellForRowAt itself — common culprits are synchronous image decode, date formatting, or business-logic computation happening on the main thread during bind instead of being precomputed or cached.

Concretely: enable GPU rendering profile bars (or Perfetto's frame timeline) and scroll; a spike in the 'measure/layout' colored segment vs the 'bind' segment tells you which of the two to attack first, rather than reflexively reaching for view holder caching when the real cost is layout nesting, or vice versa.

Question 16

In a declarative UI framework (Jetpack Compose or SwiftUI), updating a single toggle inside a complex dashboard causes full-screen tree re-evaluation and recomposition. How do you diagnose unstable parameter types and restructure state hoisting to enforce granular recomposition scopes?

Accepted Answer

Compose (and SwiftUI similarly) only skips recomposing a composable if it can prove none of its inputs changed, and that proof relies on the compiler treating the parameter types as stable. A parameter type that isn't stable (a plain mutable class, a List which is an interface Compose can't guarantee immutability for, a lambda that's recreated fresh on every parent recomposition) forces Compose to assume it might have changed and recompose the child anyway — which cascades outward and looks like the whole screen re-evaluating from one toggle.

The diagnostic tool is the Compose compiler's stability report (or the Layout Inspector's recomposition counts overlay), which flags exactly which parameters are marked unstable and why. Common fixes: replace List<T> with an immutable wrapper (kotlinx.collections.immutable's ImmutableList) or annotate a data class @Immutable/@Stable if you can genuinely guarantee it; hoist state so each composable only reads the specific slice of state it actually renders (e.g. via derivedStateOf or splitting one big UiState into per-section states) instead of one god-object passed down that changes on every toggle.

Example of the fix pattern:
// before: whole DashboardState passed down, any field change recomposes everyone
@Composable fun Dashboard(state: DashboardState) { ... }
// after: each section reads only its own slice
@Composable fun ToggleSection(enabled: Boolean, onToggle: () -> Unit) { ... }
By passing enabled: Boolean (a stable primitive) instead of the whole state object, Compose can correctly skip recomposing every other section of the dashboard that doesn't depend on that boolean, and only the toggle's own composable and its direct consumers re-run.

Question 17

An app crashes with OutOfMemory errors when users scroll through an uncurated gallery of 48MP camera photos. Design a decoding pipeline that inspects image header metadata and downsamples the bitmap directly in memory to match the exact target view dimensions before allocation.

Accepted Answer

A 48MP photo decoded at full resolution (say 8000x6000) into an ARGB_8888 bitmap is roughly 8000*6000*4 bytes = ~192MB per image — for a single thumbnail in a grid that might render at 200x200px, that's catastrophic overallocation, and doing that for even a handful of images concurrently blows past typical per-app heap limits.

The fix is to never fully decode the image just to find out its size. BitmapFactory.Options has an inJustDecodeBounds flag that reads only the image header (dimensions) without allocating any pixel data at all. You use that to compute a downsampling factor (inSampleSize, which must be a power of two) that gets the decoded bitmap close to your actual target view size, then do the real decode with that sample size set — the decoder itself downsamples during decode, so you never allocate the full-resolution bitmap in the first place. On iOS, the equivalent is CGImageSourceCreateThumbnailAtIndex with kCGImageSourceThumbnailMaxPixelSize, which does the same header-only-then-downsample dance natively.

Example:
val options = BitmapFactory.Options().apply { inJustDecodeBounds = true }
BitmapFactory.decodeFile(path, options) // no pixel allocation yet
options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight)
options.inJustDecodeBounds = false
val bitmap = BitmapFactory.decodeFile(path, options) // decodes already-downsampled
where calculateInSampleSize finds the largest power-of-two divisor such that width/inSampleSize and height/inSampleSize still comfortably cover reqWidth/reqHeight — turning that 192MB allocation into something like a 300KB one for a 200x200 target.

Question 18

Cold app startup time is exceeding SLA thresholds due to hidden disk I/O on the main thread. How do you leverage runtime enforcement tools (such as StrictMode or custom tracing traces) to detect synchronous file reads and measure Time to Initial Display (TTID)?

Accepted Answer

The dangerous thing about accidental main-thread disk I/O is that it's often invisible in normal testing — a SharedPreferences.getString() call, an unguarded file read in a library's init, or a synchronous Room query during Application.onCreate() all look instant on a fast dev device but add real, measurable latency to cold start on average hardware, directly pushing out TTID (the moment the first frame of actual content, not just a blank window, is displayed).

Android's StrictMode is built exactly for catching this class of bug: enabling detectDiskReads()/detectDiskWrites() with penaltyLog() (or penaltyDeath() in debug builds to force it to surface immediately) logs a full stack trace the instant disk I/O happens on the main thread, which pinpoints the exact call site rather than just telling you startup is slow. For measuring TTID itself, Android's own reportFullyDrawn() API combined with adb shell am start -W gives you a precise breakdown of launch time phases, and Perfetto/systrace traces around Application.onCreate() through the first frame show exactly where the time goes.

Example setup in Application.onCreate() (debug builds only):
StrictMode.setThreadPolicy(
 StrictMode.ThreadPolicy.Builder()
 .detectDiskReads().detectDiskWrites().detectNetwork()
 .penaltyLog()
 .build()
)
Running a cold start with this enabled and grepping logcat for StrictMode violations immediately surfaces things like a library reading a config file synchronously during init — the fix is almost always moving that read off the main thread or deferring it past first frame, then re-measuring TTID with reportFullyDrawn() to confirm the SLA is met.

Question 19

You need to implement a complex gesture-driven swipe-to-dismiss card stack animation running strictly at 120fps. How do you offload animation calculations to the RenderThread/GPU pipeline to bypass main-thread execution completely during touch tracking?

Accepted Answer

At 120fps you have roughly 8.3ms per frame, and if any part of that time is spent on the main/UI thread doing Kotlin/Swift object allocation, layout, or business logic per touch event, you'll drop frames the instant that thread is busy with anything else (a network callback landing, a GC pause, a recomposition elsewhere) — the animation has to be resilient to the main thread being briefly unavailable.

On Android, the technique is RenderNode / RenderThread-driven animations: properties like translationX, alpha, and scale on a View can be animated via the RenderThread directly (this is what ViewPropertyAnimator and Compose's graphicsLayer{} modifier use under the hood) once they're set up, meaning the actual per-frame interpolation happens off the main thread in native code talking straight to the GPU, and touch-tracking updates to those same properties can be applied without triggering a full measure/layout/draw pass — only a cheap property update and re-composite. On iOS, Core Animation's CALayer properties (position, transform, opacity) are inherently GPU-composited and animatable off the main thread via the render server process, which is why UIView animations of these specific properties stay smooth even under main-thread load.

Concretely in Compose: Modifier.graphicsLayer { translationX = dragOffset.value } updates a layer property that's composited on RenderThread, so dragging the card only touches this property per touch event rather than re-running layout for the whole card stack; the actual 120fps interpolation and GPU compositing happens independently of whatever the main thread is doing that frame.

Question 20

Why does instantiating objects (such as Paint, Path, or formatting helpers) inside custom view drawing loops directly trigger UI micro-stutters, and how does the garbage collector behavior differ between the UI thread and background workers?

Accepted Answer

onDraw()/draw(_:) is called on every single frame while a view is visible and animating — potentially 60-120 times per second. Allocating a new object inside that method means you're generating garbage at that same rate, and every one of those short-lived objects has to eventually be collected.

The GC itself doesn't discriminate between threads when it comes to which allocations it tracks, but the effect of a GC pause is far worse on the UI thread specifically: if a collection cycle (even a short, modern concurrent/generational one) happens to coincide with a frame deadline, that frame's drawing work gets delayed and you get a visible stutter, whereas the same pause happening while a background thread is doing I/O is invisible to the user. So the real problem isn't 'GC behaves differently on this thread' — it's that the UI thread has a hard, visible deadline (the frame budget) and background threads generally don't, making any allocation churn on the UI thread far more costly in perceived quality even if the raw GC cost is identical.

The fix is simply to hoist allocation out of the hot path: create the Paint, Path, Rect, and any formatter objects once (as fields, initialized in the constructor or init block) and only mutate their properties inside onDraw().
class GraphView(context: Context) : View(context) {
 private val paint = Paint().apply { color = Color.BLUE; strokeWidth = 4f } // once
 override fun onDraw(canvas: Canvas) {
 paint.color = currentColor // mutate, don't recreate
 canvas.drawPath(cachedPath, paint)
 }
}
This keeps draw-loop allocations at effectively zero, so there's nothing new for the GC to collect on every frame in the first place.

Question 21

Using on-device GPU inspection tools, you observe pervasive red overdraw across a heavily layered card UI. What structural changes to background drawables, window backgrounds, and layout nesting would you make to reduce the rendering pass to 1x or 2x?

Accepted Answer

Overdraw happens when the GPU paints the same pixel more than once in a single frame because multiple opaque (or even just non-transparent) layers stack on top of each other and nothing tells the system the layers underneath are fully hidden and can be skipped. Android's 'Debug GPU overdraw' tool color-codes this directly: true color (no overdraw) through blue/green/pink/red, where red means a pixel was painted 4+ times — that's 4x the necessary GPU fill-rate work for that region, which shows up as jank especially on mid/low-end GPUs.

The most common structural culprit is a chain of unnecessary backgrounds: the window background, then a root layout background, then a CardView background, then an inner content background, all opaque and all stacked — each one is fully painted even though only the topmost is ever visible. The fixes are mechanical: remove the window/theme background on screens that are fully covered by content (windowBackground doesn't need to be opaque if nothing shows through it), collapse redundant nested containers that only exist to hold a background color, and use canvas.clipRect or ViewGroup.setWillNotDraw(true) on containers that don't actually draw anything themselves so the system skips their draw pass entirely.

Concretely: if a CardView already draws its own background and elevation shadow, its direct parent LinearLayout shouldn't also have a solid background color behind it if that background is never visible around the card's edges — deleting that one background attribute alone often takes a region from 3x-4x overdraw (red/pink) down to 1x-2x (blue/green), which is the generally accepted acceptable range for a production UI.

Question 22

You are pushing a database migration that adds non-nullable foreign keys and splits a denormalized table containing 1,000,000 rows. How do you write the migration script and fallback strategy to guarantee zero data loss and prevent crashes if the device runs out of disk space mid-migration?

Accepted Answer

Two separate risks stack here: a non-nullable foreign key migration on a huge existing table can fail outright if any existing row would violate the new constraint (e.g. a row referencing an id that doesn't exist in the new parent table), and a large migration performed as a sequence of separate statements can leave the database in a half-migrated, corrupt state if the device runs out of disk space or the process is killed partway through.

For the first problem, you migrate in stages within the same transaction: create the new normalized tables, backfill them from the old denormalized table with a query that also handles or filters orphaned references (e.g. INSERT INTO parent SELECT DISTINCT ... before adding the FK, so every child row has a valid parent by the time the constraint is added), and only then add the NOT NULL foreign key constraint. For the second, the whole migration must run inside a single SQLite transaction (Room's Migration class does this automatically per migration) so it's atomic — either the entire migration commits, or none of it does, meaning a crash or disk-full mid-migration leaves the original, un-migrated database intact rather than a corrupted hybrid.

Example (Room):
val MIGRATION_5_6 = object : Migration(5, 6) {
 override fun migrate(db: SupportSQLiteDatabase) {
 db.execSQL("CREATE TABLE orders_new (...)")
 db.execSQL("INSERT INTO orders_new SELECT ... FROM orders WHERE customer_id IN (SELECT id FROM customers)")
 db.execSQL("DROP TABLE orders")
 db.execSQL("ALTER TABLE orders_new RENAME TO orders")
 }
}
Before shipping, you also proactively check available disk space (StatFs) and refuse to even start the migration below a safety threshold, surfacing a 'free up storage' prompt instead of attempting a migration you can predict will fail partway through.

Question 23

How do you securely store an OAuth refresh token on-device, comparing the guarantees provided by hardware-backed secure enclaves (iOS Keychain / Android Keystore) against standard encrypted file storage, especially in rooted or compromised OS environments?

Accepted Answer

The critical distinction is where the actual cryptographic key material lives. With app-level encrypted file storage, your app generates or holds an encryption key and encrypts the token with it in software — but that key itself has to be stored somewhere accessible to your process, and on a rooted/jailbroken device, an attacker with root can read your app's private storage directly, including that key, making the encryption purely a speed bump rather than a real barrier.

Android Keystore and iOS Keychain (specifically when backed by the Secure Enclave / StrongBox hardware, not just the software fallback) are fundamentally different: the actual private key material never leaves the hardware security module at all. Your app asks the hardware to encrypt/decrypt or sign on its behalf, but the raw key bytes are never exposed to the OS, to your app's process, or even to root — root access lets an attacker read files, but it doesn't let them extract a key that was never in extractable memory or storage in the first place. This is why storing the refresh token itself (not a self-managed encryption key) directly in Keychain/Keystore-backed encrypted storage is the stronger design.

Concretely on Android: use EncryptedSharedPreferences (from the Jetpack Security library) configured with a MasterKey generated via the Android Keystore with setRequestStrongBoxBacked(true) where available — this ensures the actual AES key protecting your stored token lives in hardware, not in your app's own encrypted-but-extractable key file. Even on a rooted device, the attacker can read the ciphertext but can't get the hardware to decrypt it without going through the OS's own authorization checks (which can additionally require biometric/PIN unlock per access).

Question 24

Design an offline-first sync architecture for a collaborative task management app where two devices edit the same task description simultaneously while offline. What deterministic conflict resolution strategy (e.g., CRDTs, vector clocks, or operational transforms) would you use over naive Last-Write-Wins?

Accepted Answer

Last-Write-Wins is simple but silently destroys data: if device A changes the description to 'Buy milk and eggs' offline, and device B independently changes it to 'Buy milk and bread' offline, whichever sync happens to hit the server second just overwrites the other completely — one user's edit vanishes with no indication anything was lost, which is a bad experience for a collaborative tool people actually trust with real work.

For free-text fields specifically, a CRDT (Conflict-free Replicated Data Type) designed for text — like an RGA (Replicated Growable Array) or the sequence CRDT that libraries like Automerge or Yjs implement — tracks edits as a sequence of character-level insert/delete operations, each tagged with a unique, causally-ordered id (not just a wall-clock timestamp, which can't be trusted across devices with clock skew). When two offline edits are merged, the CRDT's merge function is mathematically guaranteed to converge to the same result regardless of merge order, and it can preserve both users' insertions rather than picking one side wholesale (e.g. the merged result becomes 'Buy milk, eggs and bread' if the edits were in non-overlapping regions, or an explicit conflict marker if they truly overlapped).

For non-text state (like a task's status field, which isn't naturally mergeable) a simpler CRDT type is more appropriate: an LWW-Register with a proper vector clock or hybrid logical clock for causality (not raw device timestamps) that at least resolves consistently, plus surfacing 'this was also changed offline on your other device, review?' UI when a genuinely conflicting field change is detected, rather than silently picking a winner for something a CRDT can't meaningfully merge.

Question 25

Your news app caches article text and thumbnail references for offline reading. How would you design an eviction policy that balances fixed disk quotas (e.g., 200MB max) with Least Recently Used (LRU) tracking and Time-To-Live (TTL) expiration?

Accepted Answer

The two concerns are different and need to work together, not compete: the disk quota is a hard ceiling you never want to exceed regardless of anything else, while TTL is about correctness — an article cached three weeks ago might be stale/updated on the server even if it's still frequently accessed, so it shouldn't live forever just because it's popular.

The practical design is a size-bounded LRU as the primary structure (Android's own DiskLruCache, or a custom equivalent, tracks a journal of access order and evicts the least-recently-used entries whenever a new write would exceed the configured max size), with a separate lightweight TTL check applied on read: when an article is fetched from cache, you also check its stored fetch-timestamp against a max age (say 24-48 hours for news content), and if it's expired, treat it as a cache miss and re-fetch even though it's technically still present in the LRU store — letting it fall out of the LRU naturally on the next eviction pass rather than needing a separate background sweep.

Example sketch:
val cache = DiskLruCache.open(cacheDir, appVersion, 1, 200L * 1024 * 1024) // 200MB
fun getArticle(id: String): Article? {
 val entry = cache.get(id) ?: return null
 if (System.currentTimeMillis() - entry.fetchedAt > TTL_MS) return null // stale, re-fetch
 return entry.article
}
This way the 200MB ceiling is always enforced mechanically by the LRU store itself (you can never blow past it), while TTL independently guarantees you're not serving stale content just because it happens to be recently accessed and therefore protected from LRU eviction.

Question 26

A background sync job importing bulk server updates frequently throws database locked exceptions against read queries executed by the UI layer. How does enabling Write-Ahead Logging (WAL) resolve read/write concurrency contention, and what are its memory/checkpointing trade-offs?

Accepted Answer

SQLite's default journal mode (rollback journal) takes an exclusive lock on the entire database file for the duration of a write transaction — any read attempted during that window has to wait, and a bulk import writing thousands of rows can hold that lock long enough that UI reads start throwing SQLITE_BUSY/database-locked errors, which is exactly the symptom described.

WAL mode changes the fundamental locking model: instead of writes locking the main database file directly, writes are appended to a separate write-ahead log file, and readers continue reading from the original database file's last-committed state (or a consistent snapshot) without being blocked by an in-progress write. This gives you the property that matters here — one writer and many readers can proceed genuinely concurrently, because reads and writes are no longer contending for the same lock at all.

The trade-off is checkpointing: the WAL file only grows during writes, and periodically (or when it crosses a size threshold) it needs to be checkpointed — merged back into the main database file — which does require a brief exclusive-ish window, and a very large uncommitted WAL file means more memory/disk overhead and a longer checkpoint when it finally happens. Room enables this simply via:
Room.databaseBuilder(context, AppDb::class.java, "app.db")
 .setJournalMode(RoomDatabase.JournalMode.WRITE_AHEAD_LOGGING)
 .build()
For a bulk-import-heavy app, you'd also want to keep write transactions reasonably sized (batch commits rather than one giant transaction for a million rows) so checkpoints stay small and frequent rather than one enormous one that briefly stalls everything.

Question 27

Why is storing large binary files (like audio recordings or PDFs) as BLOBs inside SQLite considered an anti-pattern compared to saving them to scoped disk storage with database URI references, and how do you guarantee atomic file-and-record deletion?

Accepted Answer

SQLite can technically store BLOBs, but doing it for large files (multi-MB audio/PDFs) hurts in a few concrete ways: every query touching that row — even one that only needs a couple of metadata columns — has to page through the BLOB data if it's inline in the same page/row, bloating the database file size and slowing down completely unrelated reads; the whole database file also becomes harder to back up, sync, and vacuum efficiently as it balloons; and reading a large BLOB out of SQLite means loading the whole thing into memory via a cursor rather than being able to stream it, which is wasteful for something you'd otherwise just hand to a MediaPlayer or PDF renderer as a file path.

The standard pattern instead is to save the actual binary to the filesystem (app-scoped storage — getFilesDir() on Android, the app's Documents/Caches directory on iOS) and store only a URI/relative path plus metadata (size, mime type, created-at) in the database row. This keeps the database small and fast, and lets you use normal filesystem/streaming APIs for the actual file I/O.

The atomicity concern is real, though: if you delete the DB row and then delete the file as two separate steps, a crash between them leaves either an orphaned file (row gone, file remains — a slow disk leak) or a dangling reference (row remains, file gone — a crash on next access). The fix is to wrap the DB delete in a transaction and only delete the physical file after that transaction commits successfully, or better, use a lightweight 'pending deletion' marker row that a periodic cleanup job reconciles — so a crash mid-operation leaves you with a stale-but-detectable marker to clean up next launch, rather than a silent leak or a dangling pointer.

Question 28

When implementing full-database encryption at rest using SQLCipher, query execution time increases significantly on older devices. What tuning strategies (such as adjusting page sizes, KDF iterations, and memory-mapped I/O) can you apply to maintain security compliance without degrading performance?

Accepted Answer

SQLCipher's overhead comes from two independent places: the key-derivation function (PBKDF2 by default) that turns your passphrase into the actual encryption key runs once per database open and is deliberately slow (that's the point — it resists brute force), and per-page AES encryption/decryption happens on every single page read/write during normal query execution, which is the part that scales with how much data you're actually querying.

For the one-time KDF cost, SQLCipher lets you tune kdf_iter (the PBKDF2 iteration count) — the default is calibrated for desktop-class hardware and can meaningfully slow down database open on older/low-end phones; you can reduce it to a value still compliant with your security requirements (consult whatever compliance standard applies — don't just drop it arbitrarily) while cutting open time noticeably. For the ongoing per-query cost, increasing cipher_page_size from SQLCipher's default (4096 in modern versions) to match the OS's actual filesystem block size can reduce the number of encrypt/decrypt operations needed per read by amortizing the fixed per-page overhead across more data.

Example PRAGMA tuning (set immediately after opening, before any other queries):
PRAGMA key = 'user-passphrase';
PRAGMA kdf_iter = 64000; -- tuned down from a higher default, still within compliance
PRAGMA cipher_page_size = 8192;
Additionally, enabling memory-mapped I/O (PRAGMA mmap_size) lets the OS handle page caching more efficiently for read-heavy workloads, reducing redundant decrypt operations on pages already resident in memory. Always benchmark the actual target low-end device class after tuning — the right values are hardware-dependent, and dropping KDF iterations too far is a real security regression, not just a performance knob.

Question 29

You release a major app update via a 5% staged rollout, and automated monitoring alerts show a 1.2% crash rate increase within the first two hours. Walk through your triage protocol: deciding whether to halt or accelerate, packaging a hotfix binary, and deploying without resetting rollout stages.

Accepted Answer

The first decision is halt-vs-continue, and it should be driven by severity and blast radius, not just the raw percentage: a 1.2% crash rate increase concentrated on a core flow (login, checkout) is far more urgent than the same number scattered across a rarely-used settings screen. The immediate action is to halt the staged rollout at its current 5% (both Play Console and App Store Connect let you pause/halt a phased release without rolling it back to 0%), which caps further exposure while you investigate — you don't want to accelerate to 100% while actively unsure of the cause.

While halted, pull the actual crash reports (Crashlytics/Sentry) grouped by the new build's version code specifically, to confirm the regression is genuinely new and not a pre-existing issue whose relative rate just looks different against a smaller rollout sample. If it's a real, isolated regression with a clear root cause, you package a hotfix as a new build with an incremented version code — you cannot just re-push the same binary, since app stores require every submission to be a new version.

Critically, if you have a killswitch/remote-config flag protecting the specific feature that's crashing, flipping that off for the currently-rolled-out 5% is faster than waiting for a new binary to go through store review, and buys time to ship the real fix properly. Once the hotfix is approved, you resume the rollout from the same 5% stage (not reset to 0%) since those users are already stable on the previous version and don't need to be re-exposed to risk from scratch — the new percentage stages apply going forward from here.

Question 30

How do you architect a client-side feature flag and remote killswitch system so that a newly released, crashing checkout feature can be disabled globally in production in under 5 minutes without causing UI flickers or inconsistent state on active sessions?

Accepted Answer

The two hard requirements are speed (under 5 minutes, which rules out anything requiring app store review or even a full app restart to take effect) and no UI flicker or inconsistent state for users who are already mid-checkout when the flag flips.

Speed comes from a remote config service (Firebase Remote Config, LaunchDarkly, or a lightweight in-house endpoint) that the app polls or subscribes to independently of app releases — flipping a value server-side and having it reach clients within seconds via a low-latency fetch or push channel, not a new binary. To avoid mid-session inconsistency, the flag value should be resolved once per logical unit of work (e.g. once when the checkout flow is entered) and held consistent for the duration of that flow, rather than re-read on every recomposition/render — otherwise a flag flipping mid-transaction could yank the UI out from under a user who's already halfway through entering payment details, which is a worse outcome than letting that one session finish and only gating new sessions.

Concretely: on entering the checkout flow, snapshot the current flag value into that flow's own state/ViewModel once (checkoutFeatureEnabled = remoteConfig.getBoolean("new_checkout_v2")), and gate the entry point (whether to launch v2 at all) on the live value, but don't have individual screens inside an already-started flow re-check and swap mid-flight. New sessions started after the flip go straight to the old, stable checkout path; sessions already in flight complete on whichever version they started on, avoiding both flicker and a half-migrated UI state.

Question 31

After enabling aggressive code shrinking and obfuscation (R8/ProGuard), release builds crash on runtime JSON parsing while debug builds work as expected. How do you investigate the missing rule, write minimal keep configurations, and ensure dead code elimination remains effective?

Accepted Answer

This is almost always reflection-based code that R8 can't see as a real usage — JSON libraries like Gson or Moshi construct model objects and read/write their fields by name via reflection at runtime, but R8's static analysis only sees your code calling the JSON library's methods, not that the library will reach into your DTO classes' field names dynamically. Without a keep rule, R8 (correctly, from its own static view) renames or strips those fields as unused/obfuscatable, and the crash you get is typically a JsonSyntaxException or a NoSuchFieldException at runtime because the field name at deserialization time no longer matches the obfuscated name in the class file.

The investigation starts with the actual stack trace from the release crash (retrace it against the mapping.txt R8 produces, so you can read the real class/method names instead of a1.b2.c3) to identify exactly which class's deserialization is failing, then check the JSON library's own recommended ProGuard rules (most, including Gson and Moshi, publish a minimal official ruleset) rather than reaching for a blanket -keep class ** { *; } which defeats shrinking almost entirely.

Example minimal, targeted rule (much better than keeping everything):
-keepattributes Signature
-keep class com.yourapp.models.** { <fields>; }
-keep class com.google.gson.reflect.TypeToken
This keeps only the specific model classes' field names intact (what Gson actually needs) while still letting R8 fully shrink, inline, and obfuscate everything else — your actual business logic classes, unused library code, etc. — so dead code elimination stays effective everywhere except the narrow surface that genuinely needs reflection to survive.

Question 32

Design an automated CI/CD deployment pipeline (e.g., via GitHub Actions or Fastlane) that builds, signs, and uploads release artifacts to app store distribution tracks without granting continuous integration runners persistent access to unencrypted private signing keys or certificates.

Accepted Answer

The core principle is that the signing key should never sit as a plaintext file in the CI runner's filesystem or in a repo, even a private one — CI runners are ephemeral and shared infrastructure, and a leaked signing key (unlike a leaked API token) can't just be rotated; it can let an attacker sign a malicious update that looks legitimate to every existing install.

The standard pattern is a secrets manager (GitHub Actions Encrypted Secrets, or a dedicated vault like Google Secret Manager/1Password) holding the key material base64-encoded and encrypted at rest, decrypted only into the runner's ephemeral, sandboxed workspace at build time, used for that single signing operation, and never written to any cache or artifact that persists past the job. Fastlane's match tool is built exactly around this: it stores encrypted certificates/provisioning profiles in a private git repo or cloud storage, and each CI run decrypts them into a temporary keychain that's created and destroyed within that single job run, so no runner ever holds a long-lived decrypted copy.

Example GitHub Actions sketch:
- name: Decode signing key
 run: echo "${{ secrets.ANDROID_SIGNING_KEY_BASE64 }}" | base64 -d > release.jks
- name: Sign and build
 run: ./gradlew bundleRelease -Pandroid.injected.signing.store.file=release.jks -Pandroid.injected.signing.store.password=${{ secrets.KEYSTORE_PASSWORD }}
- name: Cleanup
 if: always()
 run: rm -f release.jks
Critically, the key file is written only into that job's ephemeral runner filesystem (destroyed when the job ends), the actual secret values never appear in logs (GitHub masks registered secrets automatically), and the always() cleanup step ensures the decoded file is removed even if the build step fails partway through.

Question 33

Your app binary exceeds regional download size thresholds. How would you architect the codebase to split an augmented-reality module into a dynamic on-demand feature module that is downloaded over-the-air only when a user navigates to that specific screen?

Accepted Answer

The AR module is a good candidate for splitting specifically because it's heavy (ARCore/ARKit dependencies, 3D asset bundles, shader code) and used by a minority of sessions — shipping it in the base APK/bundle means every single install pays that size cost even for users who never touch the AR feature.

On Android, this is Play Feature Delivery / Dynamic Feature Modules: you restructure the AR code into its own Gradle module (:feature:ar) with its own build.gradle declaring it as a dynamic feature of the base module, and configure its delivery mode as on-demand rather than install-time. At runtime, when the user navigates toward the AR entry point, you request the module via the SplitInstallManager API, show a download-progress UI (the module can be tens of MB, so this needs a real loading state, not a silent stall), and only proceed to launch the AR screen once SplitInstallSessionState reports installed.

Example:
val splitInstallManager = SplitInstallManagerFactory.create(context)
val request = SplitInstallRequest.newBuilder().addModule("ar").build()
splitInstallManager.startInstall(request)
 .addOnSuccessListener { sessionId -> /* monitor progress, then launch ARActivity */ }
 .addOnFailureListener { /* show retry, fall back gracefully */ }
On iOS, the closer equivalent is On-Demand Resources for the asset bundles (3D models, shaders) combined with keeping the ARKit-dependent code behind a lazy-loaded framework/module, since iOS app thinning and on-demand resources work somewhat differently from Android's dynamic feature modules but achieve the same base-size reduction goal.

Question 34

Your backend team needs to deprecate an authentication endpoint, but 10% of active users are still on app builds older than 9 months. How do you design a combined soft-prompt and hard-blocking app update mechanism that forces outdated clients to upgrade while handling edge cases like unsupported OS versions?

Accepted Answer

The mechanism needs at least two tiers because 'force everyone to update now' and 'nag people gently' solve different urgency levels, and a single blunt gate breaks the app entirely for users who genuinely can't update (an old device stuck on an OS version your latest build no longer supports).

The standard design is a remotely-configured minimum-version check, fetched early in app startup (before or alongside auth) from a lightweight config endpoint: minSupportedVersion (below this, hard block — an unskippable full-screen 'update required' screen with a direct store link, and no way to proceed into the app, which is what you'd set once the deprecated auth endpoint is actually being removed) and recommendedVersion (below this but above minSupportedVersion, a dismissible soft prompt shown once per session, nudging users toward updating without blocking them). You roll the minSupportedVersion up gradually as the deprecation date approaches — e.g. soft-prompt everyone below it for a month, then flip it to hard-block only in the final week, giving genuinely stale installs real warning rather than an instant surprise wall.

The unsupported-OS edge case is the one that needs explicit handling: if a user is on an OS version your current app build no longer targets/supports at all, forcing them toward a store update that they can't actually install (because the store won't offer a build requiring a newer OS to a device that can't run it) just strands them completely. For that segment specifically, you need either a maintained legacy-compatible build that still works against a kept-alive (even if deprecated-for-everyone-else) fallback auth path for a defined sunset window, or an explicit, honest in-app message that their device is no longer supported — silently hard-blocking them with no path forward is the failure mode to avoid.

Question 35

A release build crash reported in production displays un-symbolicated memory offsets in native C++ libraries and obfuscated class names in managed code. Explain the end-to-end mechanism of symbolication (dSYM / mapping files) and how to automate mapping uploads in your CI pipeline.

Accepted Answer

A release build strips human-readable debug symbols and (on Android) obfuscates class/method names via R8/ProGuard specifically to reduce binary size and make reverse-engineering harder — which is exactly why a crash from that same build shows you raw memory addresses (native code) or renamed classes like a.b.c.onCreate() (managed code) instead of anything useful.

Symbolication is the process of mapping those meaningless artifacts back to real source locations using a side-channel file generated at the same build time as the stripped binary: on iOS, the dSYM (debug symbol) file maps memory addresses in the crashed binary back to file/line/function names; on Android, R8/ProGuard's mapping.txt maps obfuscated class/method/field names back to their original ones. Crucially, the mapping file must correspond to the exact same build (same version code, same build variant) as the crash — a mismatched mapping file produces confidently wrong, misleading symbolication rather than an obvious failure.

The automation piece is what prevents this from being a manual, error-prone step: your CI pipeline, immediately after producing a release build, uploads that build's dSYM (or mapping.txt) to whatever crash reporting service you use (Crashlytics, Sentry, Bugsnag) tagged with the matching build/version identifier — e.g. Fastlane's upload_symbols_to_crashlytics action, or Sentry's sentry-cli upload-dif / a Gradle plugin that does this automatically as part of the release build task. Once that's wired in, every future crash from that build arrives in the dashboard already symbolicated with real file names and line numbers, with zero manual mapping-file juggling per release.

Question 36

What are the practical differences between native mobile development (Android/iOS with platform SDKs), cross-platform frameworks (Flutter, React Native), and older hybrid/WebView-based apps (Cordova/Ionic)?

Accepted Answer

Native development means writing Kotlin/Java for Android and Swift/Objective-C for iOS as two separate codebases, each compiled directly to the platform's own UI toolkit. You get full, immediate access to every platform API and the best possible performance and feel, at the cost of building and maintaining everything twice.

Cross-platform frameworks like Flutter and React Native let you write one codebase that runs on both platforms. Flutter compiles its own Dart-based widget tree down to native ARM code and draws every pixel itself via its Skia/Impeller rendering engine, so the UI looks identical across platforms by design (a trade-off some see as a downside, since it doesn't automatically pick up each platform's native look). React Native instead renders using actual native UI components (bridged from JavaScript), so it tends to look and feel more platform-native by default, but historically paid a performance cost communicating across the JS-to-native bridge (this is what the newer JSI/Fabric architecture was built to fix).

Hybrid/WebView apps (Cordova, older Ionic) go a step further: the entire app is essentially a website (HTML/CSS/JS) running inside a native WebView wrapper, with plugins exposing device APIs like camera or GPS. This is the fastest to build and reuse from an existing web codebase, but has the weakest performance and the least native feel, which is why it's largely fallen out of favor for anything beyond simple content-driven apps.

Question 37

What's the practical difference between MVVM and MVI architecture patterns in mobile app development, and when would you choose one over the other?

Accepted Answer

MVVM (Model-View-ViewModel) exposes multiple, often independent pieces of observable state from the ViewModel (a loading flag, an error message, a list of items, each as its own LiveData/StateFlow/Published property), and the View subscribes to whichever pieces it needs and updates itself incrementally as each one changes. It's straightforward to reason about for simple screens, but as a screen grows, you can end up with many independent state streams that can, in theory, produce inconsistent intermediate combinations (e.g. isLoading = false and error = null and items = empty, a state your UI logic didn't anticipate).

MVI (Model-View-Intent) instead models the entire screen as one single, immutable state object at a time (a sealed class like UiState.Loading, UiState.Success(items), UiState.Error(message)) produced by a single reducer function from user Intents (actions). The View can only ever render one state value at once, which makes impossible-state combinations structurally impossible rather than something you have to remember to guard against, and makes the state transitions easy to unit test since the reducer is a pure function of (currentState, intent) -> newState.

In practice: MVVM is the pragmatic default for most screens (Android's own Architecture Components are explicitly built around it), and MVI is worth the extra structure specifically for screens with genuinely complex state machines — multi-step flows, screens with many mutually-exclusive UI modes — where the cost of an inconsistent state slipping through is high enough to justify the added ceremony of routing everything through one reducer.

Question 38

How does dependency injection work in mobile apps (e.g., Dagger/Hilt on Android, Swift's Resolver or manual initializer injection), and why does it matter for testability?

Accepted Answer

Dependency injection means a class declares what it needs (a repository, an API client, a database) as constructor parameters instead of constructing those dependencies itself internally. Something external — a DI framework, or just a composition root you write by hand — is responsible for building the full object graph and wiring the right concrete instances into each class that needs them.

Without DI, a ViewModel that does `private val repo = ProductRepository(RetrofitClient.api, RoomDb.getInstance(context))` is hard-wired to those exact concrete implementations, which means a unit test for that ViewModel has to spin up a real network client and a real database just to test business logic that doesn't actually care about either. With DI, the ViewModel just takes `repo: ProductRepository` as a constructor parameter, and a test can pass in a fake/mock repository instead, testing the ViewModel's logic completely in isolation.

Android's Hilt (built on Dagger) automates this with annotations — @Inject constructor(...) on the class, @Module/@Provides for things that need manual construction (like a Retrofit instance), and @HiltViewModel to wire it into the Android lifecycle automatically. iOS more often uses lighter-weight manual dependency injection (passing dependencies through initializers explicitly, sometimes organized via a container) since Swift doesn't have an equally dominant compile-time DI framework, though third-party options like Resolver or Swinject exist for larger codebases that want the same graph-management benefits.

Question 39

What causes an ANR (Application Not Responding) error on Android, and what are the concrete techniques to prevent it?

Accepted Answer

An ANR is Android's watchdog mechanism firing because the main thread has been blocked past a threshold — roughly 5 seconds for a foreground activity not responding to input, or shorter windows for broadcast receivers and services. The system shows the user a dialog offering to force-close the app, which is a visible, damaging failure that shows up directly in your Play Console vitals and can affect store ranking/visibility.

The root cause is always the same shape: something that blocks is running on the main thread — synchronous network calls, large synchronous disk reads, a long-running loop or computation, a database query, or even a deadlock between the main thread and a background thread it's waiting on. The fix is architectural, not a single trick: move anything that can block onto a background dispatcher/thread (coroutines with Dispatchers.IO, RxJava schedulers, or a background Handler), and never call .get()/.join()/a blocking wait on that work from the main thread.

Concretely, tools to catch this before users do: StrictMode flags accidental main-thread I/O during development; Play Console's ANR reports in production show you exactly which stack trace was blocking when the watchdog fired, which is the fastest way to find a real-world ANR you can't reproduce locally. A common specific culprit worth calling out: a BroadcastReceiver's onReceive() runs on the main thread and has an even shorter timeout than a foreground Activity, so any nontrivial work there should be dispatched to WorkManager or a coroutine rather than done inline.

Question 40

How do you implement biometric authentication (Face ID / fingerprint) securely in a mobile app, and what are the common mistakes that undermine its security?

Accepted Answer

The core security property biometric authentication should provide is that a successful unlock is cryptographically tied to the device's secure hardware, not just a boolean 'did the user's face match' that your app code checks and then proceeds past. The common mistake is treating biometric auth as a simple gate — call an API, get true/false back, if true let the user in — which is trivially bypassable on a rooted/jailbroken device or via a debugger that just forces the boolean to true, since nothing about that flow actually required real biometric hardware involvement.

The correct pattern ties the biometric prompt to unlocking an actual cryptographic key stored in hardware (Android Keystore / iOS Secure Enclave), so the OS itself — not your app's logic — refuses to release the key material unless the biometric check genuinely passes. On Android, you generate a KeyGenParameterSpec with setUserAuthenticationRequired(true), and BiometricPrompt only lets you use that key (to encrypt/decrypt a token, or sign a challenge) after a real hardware-verified match; on iOS, you similarly protect a Keychain item with a SecAccessControl requiring biometry, and LAContext's evaluatePolicy only unlocks access to that item.

Concretely: don't do `if (biometricSucceeded) { unlockApp() }` as a standalone check. Do `if (biometricSucceeded) { val decryptedToken = cipher.doFinal(encryptedToken) }` where cipher was initialized with the hardware-backed, biometry-gated key — if biometric auth is spoofed or bypassed at the OS level (which is far harder than bypassing app-level logic), the actual decryption still fails because the key was never released. This also naturally handles the case where the user adds/changes an enrolled fingerprint, since most implementations invalidate the key on biometric enrollment changes by design, forcing re-authentication with the credential rather than silently trusting a new, unverified fingerprint.

Question 41

What's the difference between Flutter's widget tree, element tree, and render tree, and why does Flutter maintain all three separately instead of just one?

Accepted Answer

The widget tree is the one developers write directly — it's a lightweight, immutable configuration describing what the UI should look like at a point in time (a Text widget, a Container widget, etc.). Because widgets are immutable and cheap, Flutter rebuilds large parts of the widget tree constantly (on every setState, every rebuild) without that being expensive by itself — the widget tree is essentially just data, thrown away and recreated freely.

The element tree is the persistent, mutable layer that actually manages this churn: each widget, when first built, creates a corresponding Element that stays alive across rebuilds as long as the widget's type and position (key) stay stable. When a new widget tree is built, Flutter's reconciliation (very similar in spirit to React's virtual DOM diffing) compares old and new widgets at each Element and decides whether to update the existing Element in place, or discard it and mount a new one — this is why State objects survive rebuilds (they live on the Element, not the widget) and why keys matter for correctly matching widgets across rebuilds in a reordered list.

The render tree (RenderObjects) is the layer that actually does layout, painting, and hit-testing — it's the expensive part (measuring, positioning, painting pixels), and it's separated out specifically so that a widget/element rebuild doesn't necessarily force a full re-layout or repaint if the actual visual output hasn't changed. Concretely: a StatefulWidget's build() method can run frequently and cheaply because it's just re-describing widgets; the element tree efficiently reconciles which parts actually changed; and only the RenderObjects genuinely affected by a real, meaningful change go through the costly layout/paint pipeline — this three-tree separation is precisely what lets Flutter rebuild aggressively without that being a performance problem.

Question 42

How does React Native's JavaScript-to-native bridge (or the newer JSI architecture) let JS code call native modules, and what specific performance problems did the old bridge architecture have?

Accepted Answer

The original React Native bridge is fundamentally an asynchronous, batched message-passing system: JavaScript (running in its own JS engine thread) and native code (running on the platform's native UI/module threads) never call each other directly or share memory — every interaction is serialized into JSON, queued, and processed asynchronously across the bridge, then deserialized on the other side. This works, but it means every native call (even something as simple as reading a native module's property) has real serialization overhead and a round-trip delay, and it's fundamentally asynchronous even for things that are conceptually synchronous (like measuring a view's layout), which forced awkward async APIs for otherwise-simple operations.

The practical symptom is that high-frequency interactions — continuous gesture tracking, scroll-linked animations, anything needing per-frame native communication — struggle under the old bridge, because you're paying JSON serialization cost tens of times per second, and the batching can introduce visible lag between a touch event and the native-driven visual response.

JSI (JavaScript Interface), the foundation of React Native's newer architecture, replaces this with direct, synchronous bindings: JavaScript objects can hold direct references to C++ host objects, and calling a native method from JS is a direct function call through JSI, not a serialized message across an async queue — no JSON stringify/parse round-trip, and synchronous calls become genuinely possible when needed. This is what enables features like TurboModules (native modules lazily loaded and called directly via JSI) and Fabric (the new rendering system using the same direct-binding approach for view updates), collapsing the old bridge's serialization tax specifically for the high-frequency interaction patterns that suffered most under it.

Question 43

How would you design push notification handling to support both silent (data-only) and visible notifications, while respecting each platform's background delivery guarantees?

Accepted Answer

The two categories serve different purposes and have very different delivery guarantees. A visible notification (has a title/body the OS displays itself) is handled by the OS notification tray directly — your app code may not even run if the app is fully closed, since the OS renders it from the payload. A silent/data-only push (no visible alert, just a data payload) is meant to wake your app code briefly in the background to do work — sync new content, update a badge count, refresh a cache — without necessarily showing anything to the user.

The critical design point is that data-only pushes have no delivery guarantee on either platform: iOS explicitly reserves the right to throttle or drop background pushes entirely if the OS decides the app is using too much background time or the user rarely opens the app, and Android's Doze mode similarly delays/coalesces data messages under battery optimization. So a silent push should never be the sole mechanism for anything the user actually depends on (an urgent balance update, a critical alert) — it should be an optimization/prefetch layer on top of a reliable fallback like a foreground refresh-on-open.

Concretely with FCM: a message with only a data block (no notification block) arrives to your app's own onMessageReceived() even in the background (subject to the throttling above), letting your code decide whether to show a local notification, silently update local storage, or do nothing; a message with a notification block is shown by the OS automatically when the app is backgrounded/killed, and only reaches your code's onMessageReceived() when the app is in the foreground. Designing for this means: use notification-block pushes for anything the user must see reliably, and data-only pushes purely as a best-effort 'wake up and sync if you can' hint, with your app's own foreground/periodic sync as the guaranteed path.

Question 44

What's the difference between the runtime permission models on Android and iOS, and how should an app handle a user who has permanently denied a permission?

Accepted Answer

Both platforms moved to runtime (ask-at-point-of-use) permissions rather than install-time blanket grants, but the specifics differ. Android shows a system dialog the first time you request a dangerous permission (camera, location, etc.), and if the user denies it, you can ask again — but if they deny twice (or check 'don't ask again' depending on OS version), shouldShowRequestPermissionRationale() returns false and subsequent requests are silently auto-denied by the OS without even showing a dialog, meaning your only path forward is directing the user to the app's system Settings page manually. iOS asks once per permission type ever; if denied, calling the request API again does nothing (no dialog, immediate denial), and the app must direct the user to Settings via a deep link (UIApplication.openSettingsURLString) to change it.

The UX pattern that works on both: before the very first permission request, show your own explanatory pre-prompt UI ('we need camera access to scan your ID') so the user understands why before the system dialog appears, since a bare system dialog with no context gets denied more often. After a permanent denial, detect that state (Android: shouldShowRequestPermissionRationale is false and permission is still denied; iOS: authorization status is .denied and it's not the first ask) and show your own UI explaining that the feature is unavailable, with a button that deep-links directly to your app's Settings entry rather than a generic 'permission denied' dead end.

A related trap worth knowing: never gate core business logic on a permission being granted without a graceful degraded path — the feature should visibly explain why it's unavailable and offer the settings deep link, not silently fail or crash on a null location/camera reference.

Question 45

How do you detect and fix a memory leak caused by a static or long-lived reference holding onto an Activity or Context?

Accepted Answer

This is one of the most common Android leak patterns: something with a longer lifetime than the screen — a static field, a singleton, a long-lived background thread/callback, or a Handler with a delayed message still queued — holds a direct reference to an Activity (or a View, which itself references its Activity via getContext()). When the user navigates away and the Activity is destroyed, the garbage collector can't reclaim it because that static/long-lived reference is still pointing to it, so the entire Activity (and everything it references — its whole View hierarchy, potentially large bitmaps) stays resident in memory indefinitely, and this compounds every time the user re-enters that screen, since each old instance leaks separately.

Detection: LeakCanary is the standard tool — it hooks into Activity/Fragment destruction, and if the object isn't garbage collected within a short window after being expected to be, it captures a heap dump and shows you the exact reference chain keeping it alive (e.g. 'MyApp.instance -> ImageLoader.context -> MainActivity'), which pinpoints the leaking field directly rather than requiring manual heap dump analysis.

The fix depends on the pattern: if a singleton needs some Context, it should hold applicationContext (which lives for the process's entire lifetime anyway, so it can't leak an Activity) rather than the Activity context passed in accidentally; a Handler with pending delayed messages should call removeCallbacksAndMessages(null) in onDestroy()/onStop(); a long-lived listener/callback registered on a singleton should be unregistered symmetrically in the matching lifecycle callback. Example: `class ImageLoader { companion object { lateinit var appContext: Context } }` initialized once with `context.applicationContext`, never the raw Activity context — this one change eliminates an entire class of leaks from that singleton.

Question 46

What is Kotlin Multiplatform (KMP), and how does the expect/actual mechanism let you share business logic across Android and iOS while still using fully native UI on each platform?

Accepted Answer

Kotlin Multiplatform lets you write shared code once (business logic, networking, data models, database access) in Kotlin, compiled to a shared module that runs as normal JVM bytecode on Android and as a native framework (via Kotlin/Native) linked directly into an iOS app — while each platform still builds its actual UI natively (Jetpack Compose or XML views on Android, SwiftUI or UIKit on iOS). This is a meaningfully different trade-off from Flutter/React Native: you're not sharing UI at all, only the logic layer beneath it, which means each platform keeps a fully native look, feel, and access to platform-specific APIs for anything UI-related, at the cost of still writing two separate UI layers.

The expect/actual mechanism is how shared code handles the cases where a platform-specific implementation is genuinely needed — something like reading a secure token from platform storage, where the API is fundamentally different between Android Keystore and iOS Keychain. Shared code declares an expect function or class (a signature with no implementation, essentially an interface contract), and each platform's source set provides an actual implementation matching that signature; the shared code calls the expect declaration without knowing or caring which actual is behind it at compile time for that target.

Example:
// commonMain
expect fun getSecureToken(): String?
// androidMain
actual fun getSecureToken(): String? = EncryptedSharedPreferences...
// iosMain
actual fun getSecureToken(): String? = KeychainWrapper...
A shared ViewModel-equivalent or repository in commonMain calls getSecureToken() directly, and the correct platform implementation is linked in automatically per target at compile time — letting a single repository class, network layer, and set of business rules be written and tested exactly once, while each platform's actual screens remain fully native Compose or SwiftUI.

Question 47

How do you write a UI test (Espresso, XCUITest, or Appium) that reliably waits for asynchronous loading states instead of becoming flaky?

Accepted Answer

The classic flaky-test mistake is inserting a fixed sleep/delay (Thread.sleep(2000)) to 'wait for the network call to finish' — this is both slow (you always wait the full amount even when the response was instant) and unreliable (on a slower CI machine or under network jitter, 2 seconds isn't always enough, so the test still flakes intermittently just less often, which is worse than failing consistently because it erodes trust in the whole suite).

The correct approach is condition-based waiting: poll for the actual UI state you're waiting on (a specific view becoming visible, a loading spinner disappearing, specific text appearing) with a reasonable timeout, rather than waiting a fixed duration regardless of actual readiness. Espresso has IdlingResource specifically for this — you register a resource that reports 'idle' only once your async work (a Retrofit call, a coroutine) actually completes, and Espresso automatically pauses test execution until every registered IdlingResource reports idle before proceeding to the next assertion, with no manual sleep at all. XCUITest has the equivalent via XCTNSPredicateExpectation or waitForExistence(timeout:), which polls for a specific element/state rather than sleeping blindly.

Example (Espresso, with an IdlingResource wired to the app's actual network/coroutine dispatcher):
onView(withId(R.id.loadingSpinner)).check(matches(not(isDisplayed()))) // implicitly waits via IdlingResource
onView(withId(R.id.resultsList)).check(matches(isDisplayed()))
With IdlingResource properly wired to the actual network/coroutine dispatcher used by the app, this test passes reliably whether the mocked response takes 50ms or 3 seconds, and fails fast and clearly (rather than flakily) if the loading state genuinely never resolves within the timeout.

Question 48

How do you implement accessibility support for a custom-drawn UI component (one that doesn't use standard platform widgets) so that it works correctly with TalkBack (Android) or VoiceOver (iOS)?

Accepted Answer

Standard widgets (Button, Switch, TextField) get accessibility support for free because the platform's accessibility service already knows how to describe and interact with them. A custom-drawn component — say, a canvas-drawn rating widget or a custom chart — is, from the screen reader's perspective, just an opaque rectangle with no semantic meaning at all unless you explicitly attach that meaning yourself.

On Android, this means implementing (or extending) AccessibilityNodeInfo/AccessibilityDelegate on the custom View, or in Compose, applying semantics {} modifiers directly: setting contentDescription for what the element is, role (Role.Button, Role.Switch, etc.) for how it should be announced and interacted with, and stateDescription for dynamic state ('3 out of 5 stars', '75% complete') that needs to update as the component changes. You also need to make sure the component correctly reports focus and responds to accessibility actions (a TalkBack double-tap should trigger the same action a real tap would, which usually falls out naturally if you're using the same onClick handler, but custom gesture detectors sometimes bypass this).

Example in Compose for a custom rating bar:
Modifier.semantics {
 contentDescription = "Rating"
 stateDescription = "$currentRating out of 5 stars"
 role = Role.Button
}
On iOS, the equivalent is setting isAccessibilityElement = true, accessibilityLabel, accessibilityValue (for the dynamic '3 out of 5' part), and accessibilityTraits on the custom UIView/SwiftUI view. The concrete test that actually validates this (code review alone isn't enough) is turning on TalkBack/VoiceOver and using the component blind, by swipe-navigation only — if you can't tell what it is or interact with it without looking at the screen, real users with screen readers can't either.

Question 49

What are App Clips (iOS) and Instant Apps (Android), and what are the key technical constraints that shape how you'd architect one?

Accepted Answer

Both let a user experience a small slice of your app without a full install — tapping an NFC tag, QR code, or a link triggers a lightweight, streamed version of a specific feature (e.g. paying for parking, viewing a restaurant menu and ordering) that launches almost instantly and can prompt a full install afterward if the user wants more. The whole value proposition depends on near-instant launch, which is the constraint that shapes everything else about how you build one.

App Clips have a hard 10MB (formerly 15MB) size limit for the clip's own binary and are architecturally a separate, minimal target in your Xcode project that shares code with the main app via a framework, but must exclude anything not essential to that one specific flow — no large asset bundles, no unrelated feature code, and it must be usable without requiring the user to sign in with a brand-new account (Apple pushes hard for Sign in with Apple or a similarly frictionless auth path, since a lengthy signup defeats the instant-experience premise). Android Instant Apps work similarly but are built from the same dynamic-feature-module infrastructure used for on-demand delivery — you mark specific feature modules as 'instant-enabled,' and Google Play serves just that module (streamed, not fully installed) when the instant experience is triggered, with a roughly 15MB compressed limit typically recommended for a smooth experience though the hard technical cap is larger.

The practical architecture implication: the shared/instant-eligible code has to be genuinely decoupled from anything requiring full-app-only capabilities (background services, certain permissions that only make sense for an installed app), and the flow needs its own minimal auth and payment path that doesn't assume the user has (or will create) a persistent account — designing for the instant surface from the start, rather than trying to carve one out of a monolithic app later, is what actually keeps it under the size and friction constraints both platforms impose.

Question 50

How do you architect an app to support multiple build flavors or schemes (dev/staging/prod) with different API endpoints, feature flags, and signing configurations?

Accepted Answer

The goal is that switching environments is a build-time configuration choice, never something hardcoded and manually edited in source before each build (which is slow and error-prone — someone eventually ships a build still pointed at staging, or forgets to flip a debug flag back before a release).

On Android, Gradle product flavors are built exactly for this: you define dev, staging, and prod flavors (each can have its own applicationIdSuffix so all three can be installed on one device simultaneously for testing), and each flavor's own source set (src/dev/, src/staging/, src/prod/) provides flavor-specific values — a BuildConfig field for the API base URL, a different google-services.json for a separate Firebase project per environment, and separate signing configs (dev/staging typically debug-signed, prod release-signed with the real upload key, often kept out of the flavor definition itself and injected via CI secrets). On iOS, the equivalent is Xcode schemes/configurations combined with .xcconfig files per environment, each defining its own API_BASE_URL and bundle identifier suffix, selected via scheme rather than a manually-edited constant.

Example (Android build.gradle sketch):
productFlavors {
 dev { applicationIdSuffix ".dev"; buildConfigField "String", "API_URL", "\"https://api-dev.example.com\"" }
 staging { applicationIdSuffix ".staging"; buildConfigField "String", "API_URL", "\"https://api-staging.example.com\"" }
 prod { buildConfigField "String", "API_URL", "\"https://api.example.com\"" }
}
Code then reads BuildConfig.API_URL rather than any hardcoded string, and CI pipelines select the flavor explicitly per pipeline (assembleDevDebug vs bundleProdRelease) rather than relying on a developer remembering to switch anything locally before a release build.

Question 51

What is the difference between native mobile app development and cross-platform (hybrid) development, like using React Native or Flutter?

Accepted Answer

Native development means building an app using the platform's own language and tools — Kotlin or Java for Android in Android Studio, Swift or Objective-C for iOS in Xcode. You end up with two separate codebases, one per platform, but you get full access to every native API and typically the best performance and the truest platform look and feel.

Cross-platform development uses a framework like React Native or Flutter to write one codebase that runs on both Android and iOS. React Native translates your JavaScript code into real native UI components under the hood, while Flutter draws its own UI directly using its own rendering engine. Either way, you save time by maintaining one codebase instead of two, though you occasionally still need small platform-specific bits of code for things the framework doesn't support yet.

For example, adding a simple "Share" button. In native Android (Kotlin) you'd write:
```kotlin
val shareIntent = Intent(Intent.ACTION_SEND).apply {
    type = "text/plain"
    putExtra(Intent.EXTRA_TEXT, "Check out this app!")
}
startActivity(Intent.createChooser(shareIntent, "Share via"))
```
In React Native, the same feature is one small piece of JavaScript that works on both platforms:
```javascript
import { Share } from 'react-native';
Share.share({ message: 'Check out this app!' });
```
A small team building a simple content app for both app stores quickly would likely pick cross-platform to move fast with one codebase; a team building something performance-heavy like a camera app or a game would more likely pick native for full control over each platform.

Question 52

What is the Activity/screen lifecycle in mobile apps, and why does it matter where you put your setup and cleanup code?

Accepted Answer

Every screen in a mobile app goes through a lifecycle — a set of stages the operating system moves it through as the user opens it, backgrounds it, and eventually leaves it. On Android these are methods on an Activity: onCreate() (the screen is being built for the first time), onStart() (about to become visible), onResume() (now fully visible and interactive), onPause() (partially hidden — e.g. a dialog popped up or the user is navigating away), onStop() (fully hidden, e.g. the user went to the home screen), and onDestroy() (the system is finished with it). iOS has the same idea on a UIViewController: viewDidLoad(), viewWillAppear(), viewDidAppear(), viewWillDisappear(), viewDidDisappear().

This matters because it tells you exactly where to start and stop things. Something like a camera preview or a location listener should start in onResume/onStart, because that's precisely when the screen is actually visible to the user, and it should stop again in onPause/onStop so you're not wasting battery or memory running something nobody can currently see. A very common beginner mistake is starting expensive work in onCreate() instead — since onCreate() only runs once, but onResume()/onPause() run every single time the screen comes to the foreground or leaves it, code placed in the wrong callback can either run too rarely or too often.

Example (Android, Kotlin):
```kotlin
class CameraActivity : AppCompatActivity() {
    override fun onResume() {
        super.onResume()
        camera.startPreview() // screen is visible now, safe to use the camera
    }
    override fun onPause() {
        super.onPause()
        camera.stopPreview() // screen is about to be hidden, release the resource
    }
}
```
This way the camera only runs while its screen is actually on top and visible, instead of quietly draining the battery in the background.

Question 53

What is the difference between SharedPreferences (or UserDefaults on iOS) and a local database like SQLite for storing data on a mobile device?

Accepted Answer

Mobile apps need to save data on the device, and which tool you reach for depends on what kind of data it is. SharedPreferences on Android (UserDefaults on iOS) is a simple key-value store meant for small, simple settings — things like "is dark mode turned on", "has the user already seen onboarding", or a saved username. You give it a key and a value, and it quietly handles reading and writing a small file behind the scenes; it isn't built to hold large or structured collections of data.

A local database like SQLite (used through Room on Android, or Core Data/SQLite directly on iOS) is meant for bigger, structured, relational data — a list of hundreds of to-do items, cached articles, a shopping cart, or chat messages. A real database lets you query, filter, and sort that data (e.g. "give me every task that's due today"), which a flat key-value store simply isn't designed to do. You could technically serialize a whole list into one giant JSON string and stuff it into SharedPreferences, but that gets slow and awkward fast as the list grows, and you lose the ability to query it properly.

Example — a simple setting versus a list of structured records:
```kotlin
// SharedPreferences: one small, simple flag
sharedPrefs.edit().putBoolean("dark_mode_enabled", true).apply()

// Room (SQLite): a real table of structured data you can query
@Entity data class Task(@PrimaryKey val id: Int, val title: String, val isDone: Boolean)

@Dao interface TaskDao {
    @Query("SELECT * FROM Task WHERE isDone = 0")
    fun getPendingTasks(): List<Task>
}
```
The dark-mode flag is a perfect fit for SharedPreferences since it's one tiny value read as-is; the task list needs a real database because the app has to filter and search through it later, not just read the whole thing back untouched.

Question 54

What is an API, and how does a mobile app typically use a REST API to get data from a server?

Accepted Answer

Almost every modern mobile app needs to talk to a server somewhere — to log a user in, load a list of products, or submit a form. It does this through an API (Application Programming Interface), which is essentially an agreed-upon set of URLs and rules the server exposes so the app knows exactly how to ask for data and what shape of answer to expect back. The most common style is a REST API, where each URL represents some resource (for example, /users/42 represents the user with id 42), and the app uses standard HTTP methods to act on it: GET to read data, POST to create something new, PUT or PATCH to update it, and DELETE to remove it.

The typical flow looks like this: the app sends an HTTP request to a URL — often including a login/auth token so the server knows who's asking — the server looks up or changes something in its own database, and sends a response back, usually formatted as JSON (a simple, readable text format of key-value pairs). The app then parses that JSON into objects it can use to update whatever's on screen.

Example — fetching a user's profile:
```javascript
fetch('https://api.example.com/users/42', {
  headers: { Authorization: 'Bearer <token>' }
})
  .then(response => response.json())
  .then(data => console.log(data));
// Server responds with JSON like:
// { "id": 42, "name": "Asha", "email": "asha@example.com" }
```
Here the app sends a GET request asking for user 42, and the server replies with a small JSON object describing that user, which the app then displays on the profile screen — this simple request-and-response pattern over HTTP is how nearly every mobile app gets its data from the internet.

Mobile Interview Questions & Answers

Ready to practice these live?