Concurrency and Threading on Mobile Platforms Questions

Comprehensive understanding of concurrent programming specific to mobile. iOS: Grand Central Dispatch (GCD), OperationQueue, NSOperationQueue, thread safety, synchronization primitives. Android: ThreadPoolExecutor, Handler, HandlerThread, Coroutines, thread safety. Cross-platform reactive patterns with RxSwift, RxKotlin. Understanding race conditions, deadlocks, priority inversion, and how to design thread-safe mobile code. Real experience debugging concurrency bugs.

EasyTechnical

29 practiced

Explain DispatchQueue.global().async versus DispatchQueue.main.async and describe the purpose of Quality of Service (QoS) classes in GCD. Give examples of when to use user-initiated, user-interactive, and background QoS and describe the responsiveness and energy trade-offs.

Sample Answer

**Brief answer / difference**- DispatchQueue.global().async runs work on a background thread pool (concurrent). Use it for non-UI, CPU or I/O work.- DispatchQueue.main.async schedules work on the main thread. Use it for UI updates and anything that must run serially on main.

swift

DispatchQueue.global(qos: .userInitiated).async {
    let result = heavyComputation()
    DispatchQueue.main.async {
        self.label.text = "\(result)" // UI update on main
    }
}

**QoS classes (purpose)**- QoS expresses priority and intent to the system so scheduler and energy manager can balance responsiveness vs battery.- Higher QoS => more CPU, lower latency; lower QoS => deferred work, better energy efficiency.

**When to use**- userInteractive: UI animations, immediate event handling (e.g., responding to touches, smooth scrolling). Must be near-instant.- userInitiated: Work started by user requiring quick result (e.g., opening a document, tapping “refresh”). Use for fetching data that should appear immediately.- background: Prefetching, indexing, backups, analytics uploads — tasks that can run opportunistically and be deferred to save power.

**Responsiveness vs energy trade-offs**- High QoS (userInteractive/userInitiated) improves responsiveness but increases CPU wakeups and energy use.- Low QoS (background) conserves battery but may delay completion or be throttled under load.- Choose the lowest QoS that still meets your UX requirements; always perform UI updates on main.

HardSystem Design

35 practiced

Design a comprehensive strategy to migrate a large multi-platform mobile app to structured concurrency (Swift async/await and Kotlin coroutines) without regressions. Include progressive migration steps, wrapping existing callback libraries, cancellation propagation and lifecycle scoping, test strategies to detect regressions, and a rollout plan to minimize user impact.

Sample Answer

**Clarify goals & constraints**- Zero-regression: preserve behavior, perf, battery.- Support iOS (Swift async/await) and Android (Kotlin coroutines) incrementally.- Maintain lifecycle/cancellation and third‑party callbacks.

**High-level progressive migration**1. Audit hot paths and libraries that use callbacks/promises. Prioritize networking, DB, heavy I/O.2. Introduce adapters around boundaries (module-by-module). Start with non-UI infrastructure (network layer, repo layer) then UI viewmodels/controllers.3. Migrate tests + CI per module. Roll out feature flags and staged releases.

**Wrapping existing callback libraries**- Create safe bridge helpers:

swift

// Swift: wrap callback into async function
func fetchData() async throws -> Data {
  try await withCheckedThrowingContinuation { cont in
    legacyFetch { result, error in
      if let e = error { cont.resume(throwing: e) } else { cont.resume(returning: result) }
    }
  }
}

kotlin

// Kotlin: wrap callback into suspend function
suspend fun fetchData(): Data = suspendCancellableCoroutine { cont ->
  legacyFetch(object: Callback { override fun onDone(d){ cont.resume(d) } })
  cont.invokeOnCancellation { cancelLegacy() }
}

- Centralize adapters to limit churn and handle threading.

**Cancellation propagation & lifecycle scoping**- Enforce structured concurrency: expose suspend/async APIs that require CoroutineScope/Task-local scoping.- iOS: tie async tasks to Task and use Task.cancel() in viewWillDisappear or use actor/TaskGroup patterns.- Android: use lifecycleScope/viewModelScope; ensure wrappers call invokeOnCancellation to cancel underlying work.- Propagate cancellation through repository/service layers—never swallow CancellationException/TaskCancellation.

**Testing strategy**- Unit: adapt existing callback tests to async tests; assert task cancellation behavior and resource cleanup.- Integration: deterministic fake clocks, network stubs; run stress tests for concurrency (race conditions).- Regression: golden snapshot tests for UI; crash metrics and ANR monitoring.- CI: add fuzzing and concurrency sanitizers where available (Thread Sanitizer, kotlinx-coroutines debug).

**Rollout plan**- Canary build to internal users -> staged rollout (5%/25%/100%) by feature flag per platform.- Monitor Sentry/crash, performance KPIs (latency, battery), ANRs, and user metrics.- Quick rollback: keep old API endpoints and wrappers available and feature-flagged.

**Trade-offs & fallback**- Start with thin adapter layer to revert quickly. Full native async conversion only after both platform test coverage and production stability are proven.

This approach keeps changes incremental, ensures cancellation & lifecycle correctness, and provides measurable rollback and test safety to avoid regressions.

HardTechnical

31 practiced

Analyze the pros and cons of using Reactive extensions (RxSwift/RxKotlin) versus structured concurrency (async/await, Kotlin Flow) for complex mobile event processing that requires backpressure, cancellation, and composition of streams from sensors and network. Provide guidance on when to choose one approach, how to interoperate between them, and migration patterns for mixed codebases.

Sample Answer

**Clarify requirements**You need high-throughput sensor + network streams with backpressure, cancellation tied to lifecycle, and complex composition (filtering, windowing, debounce, merge).

**Pros / Cons — Rx (RxSwift / RxKotlin)**- Pros: mature operators for composition (buffer, window, sample), explicit backpressure via Flowable (RxKotlin) or manual strategies, rich tooling and operator semantics familiar across platforms.- Cons: cognitive overhead, interop friction with coroutines, lifecycle cancellation must be wired explicitly, heavier memory/ battery risk if misused.

**Pros / Cons — Structured Concurrency (async/await + Flow)**- Pros: explicit cancellation via CoroutineScope, predictable structured lifecycles, Kotlin Flow has built-in backpressure (suspending emissions), clearer error propagation, lighter runtime.- Cons: Flow operator set smaller vs Rx (but growing); Rx-style operators need combination of channels / callbackFlow; cross-platform parity: Swift concurrency is newer than RxSwift.

**When to choose**- Choose Rx when: large existing Rx codebase, need complex Rx-only operators or cross-platform operator parity, or third-party libs expose Rx APIs.- Choose structured concurrency when: new code, prefer lifecycle-safe cancellation, Kotlin-first projects, focus on clarity and resource safety.

**Interop patterns**- Wrapper/adapters: expose a small interface (e.g., SensorStream) and implement Rx or Flow underneath.- Rx -> Flow: use callbackFlow { val disposable = observable.subscribe { trySend(it) }; awaitClose { disposable.dispose() } }- Flow -> Rx: flow.collect { emitter.onNext(it) } inside a coroutine launched on appropriate scope; for Swift, convert Task-based sequences to RxObservables via Subjects.

**Migration patterns**- Strangler: encapsulate feature-level modules; replace module internals with Flow/async while keeping public Rx API until consumers migrate.- Facade: create facade interfaces returning domain-level streams; implement both Rx and Flow adapters; add tests.- Incremental: start with new features in Flow/async, provide bridging adapters, and measure resource / battery metrics.- Safety: add integration tests that validate cancellation and backpressure behavior; monitor memory/battery.

**Practical tips**- For sensors (high-frequency): prefer Flow with buffer/drop strategies or Rx Flowable with backpressure to avoid UI overload.- Tie coroutine scopes to lifecycle (ViewModelScope / lifecycleScope) and on iOS use Task cancellation or structured concurrency.- Document invariants: who cancels, who buffers, operator semantics.

This approach balances correctness, lifecycle safety, and an incremental path from Rx to structured concurrency.

HardTechnical

41 practiced

Design and sketch an implementation of a thread-safe memory pool/allocator for small frequently allocated objects used by a performance-sensitive iOS game. Requirements: minimize lock contention with per-thread caches, support dynamic growth and reclamation, avoid fragmentation, and provide fast lock-free paths where possible. Explain chosen data structures, synchronization strategy, and how to handle thread exit and reclamation.

Sample Answer

**Approach (brief)** Provide a global lock-free slab allocator with per-thread caches (thread-local free lists) for fast paths. Slabs are fixed-size pages subdivided into N object slots. Global allocator handles slab creation, reclamation and cross-thread freeing.

**Data structures**- Global: atomic list of partial/full slabs, and concurrent free-slab pool.- Slab: 4KB aligned block, bitmap for allocations, atomic refcount.- Per-thread cache: thread_local array of free pointers (stack-like), capacity C.

**Fast path**- Allocation: try pop from thread_local cache (lock-free).- If empty: pop from slab’s lock-free free-list or fetch a new slab from global (slow path).- Free: if current thread owns slab, push to thread_local cache; else push to slab’s atomic remote-free-list and optionally signal owner.

**Synchronization**- Use atomic operations (compare-and-swap) for per-thread stacks and slab free-lists.- Global slab lists use lock-free Treiber stacks or a small mutex for slab metadata changes to simplify correctness.

**Thread exit & reclamation**- On thread exit, drain thread_local cache back to global: push into slab remote-free-lists or return whole slabs to global pool.- Use epoch-based reclamation (lightweight) or a hazard-pointer style epoch to safely free slabs when no thread can access them.- Slab garbage: when all slots free and not referenced, move slab to OS return pool.

**Sketch (Swift-like pseudocode)**

swift

final class Slab {
  var base: UnsafeMutableRawPointer
  var bitmap: Atomic<UInt64>
  var remoteFreeHead: Atomic<UnsafeMutableRawPointer?> = Atomic(nil)
  var freeCount: Atomic<Int>
}
@_threadLocal var localCache: [UnsafeMutableRawPointer] = []
func alloc() -> UnsafeMutableRawPointer? {
  if let p = localCache.popLast() { return p }                      // fast path
  // slow path: try pop from slab free-list, else acquire new slab
}
func free(_ p: UnsafeMutableRawPointer) {
  if localCache.count < CAP { localCache.append(p); return }       // fast path
  // remote push into slab.remoteFreeHead (CAS)
}

**Trade-offs & notes**- Fixed-size slabs reduce fragmentation; for multiple sizes, maintain size-classes.- Epoch-based reclamation costs periodic scans but avoids global locks.- Use small mutex only for rare global operations to keep fast paths lock-free.- Measure per-device; tune slab size and per-thread cache capacity for memory vs latency.

MediumTechnical

41 practiced

Using Kotlin coroutines, design a cancellable API wrapper that performs a network call with automatic retries and exponential backoff. Provide sample code that runs on Dispatchers.IO, supports immediate cancellation by the caller, includes jitter on backoff, and demonstrates how to launch and cancel from a ViewModel when the view is destroyed.

Sample Answer

**Approach (brief)** Use a suspend wrapper that runs on Dispatchers.IO, checks coroutine cancellation, and retries with exponential backoff + jitter. Expose a Job from ViewModel to allow immediate cancellation on view destroy.

**Implementation**

kotlin

import kotlinx.coroutines.*
import kotlin.random.Random
import kotlin.time.Duration.Companion.milliseconds

suspend fun <T> retryWithBackoff(
    maxAttempts: Int = 5,
    baseDelayMs: Long = 500,
    maxDelayMs: Long = 10_000,
    jitterFactor: Double = 0.5,
    block: suspend () -> T
): T {
    var attempt = 0
    var lastError: Throwable? = null
    while (attempt < maxAttempts) {
        ensureActive() // immediate cancellation check
        try {
            return withContext(Dispatchers.IO) { block() } // network call on IO
        } catch (e: Throwable) {
            lastError = e
            attempt++
            if (attempt >= maxAttempts || e is CancellationException) throw e
            // exponential backoff with jitter
            val exp = (baseDelayMs * (1L shl (attempt - 1))).coerceAtMost(maxDelayMs)
            val jitter = (Random.nextDouble() * jitterFactor * exp).toLong()
            val delayMs = (exp - jitter/2).coerceAtLeast(0)
            delay(delayMs)
        }
    }
    throw lastError ?: IllegalStateException("Unknown error")
}

**ViewModel usage (launch & cancel)**

kotlin

class MyViewModel: ViewModel() {
  private var fetchJob: Job? = null

  fun fetchData() {
    fetchJob?.cancel()
    fetchJob = viewModelScope.launch {
      try {
        val result = retryWithBackoff { api.fetchSomething() } // suspend network call
        // handle success on Main (viewModelScope is Main by default)
      } catch (e: CancellationException) {
        // cancelled: ignore or cleanup
      } catch (e: Exception) {
        // handle failure
      }
    }
  }

  override fun onCleared() {
    fetchJob?.cancel() // ensures immediate cancellation when ViewModel destroyed
    super.onCleared()
  }
}

**Notes & reasoning**- ensureActive() and throwing CancellationException ensure quick exit. - withContext(Dispatchers.IO) ensures blocking network runs on IO. - Jitter reduces thundering-herd. - Caller (ViewModel) holds Job for explicit cancellation; viewModelScope cleans up automatically on lifecycle end.

Unlock Full Question Bank

Get access to hundreds of Concurrency and Threading on Mobile Platforms interview questions and detailed answers.

Join thousands of developers preparing for their dream job.