Mobile Networking and API Integration Questions

Covers the design and implementation of network communication between mobile clients and backend services. Core protocol knowledge including Hypertext Transfer Protocol and secure Hypertext Transfer Protocol, representational state transfer principles, request and response serialization such as JavaScript Object Notation and protocol buffers, and API patterns suitable for mobile consumption. Platform specific implementation details including Apple iOS networking stacks and libraries such as URLSession, Android libraries such as OkHttp and Retrofit, and cross platform considerations. Reliability and resilience topics including network connectivity change handling, connection pooling, retry strategies and exponential backoff, timeout management, interceptors and middleware, circuit breaker and rate limiting patterns, and error classification and recovery. Performance and efficiency topics including request batching, compression, payload size reduction, caching strategies, cache invalidation, offline first approaches, local data storage and synchronization, conflict resolution strategies, and optimization for bandwidth constrained networks. Security and authentication including Transport Layer Security and certificate pinning, secure sockets layer considerations, token based authentication and refresh flows including Open Authorization and JSON Web Tokens, secure storage of credentials, and certificate and key management. Testing, debugging and observability including network mocking and stubbing, integration testing strategies, logging and telemetry for network flows, monitoring for latency and error rates, and handling of streaming and real time channels such as WebSocket and long polling when applicable.

HardTechnical

25 practiced

Design a comprehensive testing strategy for mobile networked features: include unit tests with network mocking/stubbing, integration tests with a simulated backend, end-to-end tests on device farms with flaky networks, deterministic replay of server responses, and CI strategies to run these tests reliably. Mention tools and frameworks you'd use.

Sample Answer

**Overview / goals**Design a test pyramid that gives fast feedback (unit), realistic behaviour (integration with simulated backend), and full-user validation (E2E on devices), while making tests deterministic and CI-reliable under flaky networks.

**Unit tests (fast, deterministic)**- Tools: iOS XCTest + URLProtocol-based stubs or OHHTTPStubs; Android JUnit + Mockito + OkHttp MockWebServer.- Strategy: isolate networking layer by injecting an HTTP client interface; mock network responses and clocks; assert request formation, retries, and error handling.- Example: use MockWebServer to enqueue JSON and verify headers and retry counts.

**Integration tests (simulated backend)**- Tools: WireMock standalone / Docker, MockWebServer for Android, local Swift/Vapor server for iOS.- Strategy: run app build pointing to WireMock host in a test profile; test real serialization, persistence, and retry/backoff logic against scripted latency, 500s, auth flows.- Use contract tests (Pact) to verify API expectations between mobile and backend teams.

**Deterministic replay of server responses**- Tools: WireMock recordings, VCR-like recordings, or saved MockWebServer enqueues; Charles/mitmproxy session dumps for complex flows.- Strategy: record golden interactions, store mappings in repo, run replay mode in CI to reproduce specific bugs. Pin timestamps/UUIDs via dependency injection to avoid nondeterminism.

**End-to-end on device farms with flaky networks**- Tools: Firebase Test Lab, AWS Device Farm, BrowserStack App Automate; Espresso/XCUITest for automation.- Network conditions: use Network Link Conditioner (iOS), tc/netem on device farm VMs, or device-farm network shaping to simulate latency, jitter, loss, and throttling.- Strategy: run E2E suites under multiple profiles (good/3G/edge/packet-loss). Capture logs, videos, and HARs. Validate UX: offline flows, sync, resume-after-reconnect.

**Flaky-test mitigation & observability**- Mark long-running flaky scenarios as nightly; for PRs run fast smoke E2E.- Auto-rerun transient failures (1–2 retries) with strict logging; quarantine persistent flaky tests.- Collect telemetry: screenshots, network traces, device logs, and deterministic seeds.

**CI strategy**- Pipeline tiers: 1. Pre-merge: unit tests + static analysis (Xcode Analyzer, detekt/ktlint), run in parallel on GitHub Actions / CircleCI / Bitrise. 2. Merge gate: integration tests against WireMock in Docker, run in CI matrix (iOS/Android, API versions). 3. Post-merge/nightly: E2E on device farms (Firebase/AWS/BrowserStack), network-shaping matrix, contract verification.- Artifacts: store recordings, device logs, videos for debugging. Use caching for builds, and split tests to parallel device shards.- Rollout tie-in: use staged rollouts and feature flags to limit blast radius; run canary E2E before full release.

**Trade-offs**- Full device E2E is slow/costly; mitigate with targeted smoke tests on PRs and more exhaustive nightly runs.- Recordings speed up reproducibility but may drift—maintain periodic re-recording and contract tests.

This strategy balances speed, realism, determinism, and CI reliability for mobile networked features.

MediumTechnical

28 practiced

Describe adaptive strategies to handle different network types (2G/3G/4G/5G/Wi-Fi) from a mobile client perspective. Cover detection approaches, adaptive image/video resolution, prefetching policies, sync frequency adjustments, and how to balance bandwidth savings against user experience.

Sample Answer

**Situation / goal (one line)** Optimize a mobile client to adapt behavior across 2G/3G/4G/5G/Wi‑Fi to maximize UX while saving bandwidth and battery.

**Detection approaches** - Use platform APIs: Android ConnectivityManager + NetworkCapabilities (TRANSPORT_WIFI, isMetered, linkDownstreamBandwidthKbps); iOS Network.framework / NWPathMonitor and CTCarrier/servingCell for radio type. - Augment with runtime probes: measure RTT, throughput (small HEAD/GET or QUIC ping), and observe TCP slow-start. Use heuristics: high RTT + low throughput → downgrade.

**Adaptive image/video resolution** - Map measured bandwidth + device DPI to quality tiers (e.g., 144/360/720/1080). Start with conservative bitrate then upswitch on stable capacity. - Use progressive images/WebP/AVIF and adaptive streaming (HLS/DASH) with ABR buffers; prefer keyframe spacing tuned for mobile.

**Prefetching policies** - Respect connectivity: enable aggressive prefetch on Wi‑Fi/unmetered, conservative on 4G, disable on 2G or metered/Data Saver. - Use user signals: battery saver, roaming, user preference. Prioritize likely next items (LRU + score from navigation patterns). Limit concurrency and size.

**Sync frequency adjustments** - Throttle background sync on slow networks or low battery. Use exponential backoff, push notifications for real‑time needs, and batch sync when entering Wi‑Fi. For near‑real‑time features, reduce payload (deltas) and increase server‑push usage.

**Balancing bandwidth vs UX** - Define SLAs per feature: critical (messaging) vs non‑critical (high‑res thumbnails). Use progressive enhancement: low quality immediately, replace with high quality when possible. - Expose user controls (data saver toggle). Telemetry: log quality switches and user engagement to tune thresholds.

**Example heuristic** - If measured throughput > 5 Mbps → stream 720p; 1–5 Mbps → 360p; <1 Mbps or RTT > 300ms → serve low-res + pause autoplay.

**Trade-offs / best practices** - Prefer conservative defaults, optimize for perceived speed (first meaningful paint), batch and compress, respect privacy and metering, test on real devices and networks.

EasyTechnical

28 practiced

Describe practical strategies a mobile app should use to handle changes in network connectivity (online, offline, flaky networks) on both iOS and Android. Include how you would surface state to the UI, queue or pause requests, retry policies, and when to fall back to local data.

MediumTechnical

26 practiced

Design a resumable multipart upload solution for large files (photos/videos) from mobile devices. Describe client-side chunking, server-side assembly, resume tokens, integrity checks (checksums), pause/resume UX, bandwidth-aware chunk size adaptation, and API endpoints required to support resume and verification.

Sample Answer

**Approach summary (mobile-first)** Design client-side chunking + server-side assembly with resumable tokens, per-chunk checksums, adaptive chunk sizing based on bandwidth, and clear UX for pause/resume.

**Client-side chunking & bandwidth-aware adaptation**- Start with default chunk size (e.g., 256 KB). Measure upload throughput during first 2 chunks and adjust: increase chunk size up to 5 MB on high bandwidth, decrease to 64 KB on low bandwidth or high failure rate.- Upload chunks in parallel (2-4) when on Wi‑Fi; single-threaded on cellular to save battery/data.- Each chunk: include sequence index, byte-range, SHA-256 checksum.

**Resume tokens & API endpoints**- POST /uploads/initiate -> returns uploadId, resumeToken, upload URL, policy, chunkSize- PUT /uploads/{uploadId}/chunk -> headers: Content-Range, Chunk-Index, Checksum; body: chunk bytes- POST /uploads/{uploadId}/complete -> body: list of chunk checksums or server-side manifest- GET /uploads/{uploadId}/status -> returns uploaded chunk bitmap, last-accepted-offset- DELETE /uploads/{uploadId} -> abort

ResumeToken: short opaque token tied to user/device, expires, stored server-side mapping to current manifest and allowed offsets.

**Server-side assembly & verification**- Store chunks in temporary object storage (S3 multipart or block store). Verify each chunk checksum on receive; write metadata manifest.- On complete, validate all chunk checksums, reassemble (or use S3 multipart complete), compute final checksum (SHA-256) and compare with client-supplied overall checksum.- Move to CDN origin and return final URL + content hash.

**Pause/Resume UX**- Expose progress and persisted uploadId/resumeToken in secure local storage; allow user to pause which halts transfers but keeps manifest.- On resume, query GET status, upload missing chunks. Show expected remaining data and estimated time using current throughput.

**Integrity & retries**- Per-chunk SHA-256, server ACKs each chunk with sequence and stored checksum. Client retries failed chunks with exponential backoff; avoid reuploading validated chunks.

**Other considerations**- Auth per request (short-lived token), encryption in transit, optionally client-side encryption for privacy, quota and GC for abandoned uploads.

HardTechnical

23 practiced

Design how to share networking and retry logic between an iOS app using URLSession and an Android app using OkHttp. Identify which components (models, serialization, retry policy, backoff algorithms) can be shared via Kotlin Multiplatform or shared libraries, and which must remain platform-specific (background tasks, native push integration). Provide API boundaries and an example of the public interface.

Sample Answer

**Approach (brief)** Share pure business logic, models, serialization and retry/backoff algorithms in a Kotlin Multiplatform (KMP) module. Keep native integration (URLSession, OkHttp, background scheduling, push) in thin platform adapters that implement KMP-defined interfaces.

**What to share (KMP)**- Models / DTOs (data classes)- Serialization (kotlinx.serialization) + canonical JSON schema- Networking contract interfaces (HttpClient abstraction)- Retry policy and backoff algorithms (exponential, jitter, circuit-breaker helpers)- Common errors and mapping rules- Unit-testable request/response validators

**Platform-specific**- Concrete HTTP transport: OkHttp engine (Android), URLSession engine (iOS/Swift wrapper)- Background fetch / WorkManager / BGTask scheduling- Push notification registration & deep-link handling- Platform credential/keychain storage (secure store wrappers)

**API boundaries**- KMP exposes a small HttpClient interface and RetryPolicy types. Platform modules provide Engine implementations.

Example public interface (Kotlin Multiplatform)

kotlin

// commonMain
interface HttpEngine {
  suspend fun execute(request: HttpRequest): HttpResponse
}

data class HttpRequest(val method: HttpMethod, val url: String, val headers: Map<String,String>, val body: ByteArray? = null)
data class HttpResponse(val status: Int, val headers: Map<String,String>, val body: ByteArray?)

interface RetryPolicy {
  fun shouldRetry(attempt: Int, response: HttpResponse?, error: Throwable?): Boolean
  fun backoffMillis(attempt: Int): Long
}

class HttpClient(private val engine: HttpEngine, private val retry: RetryPolicy) {
  suspend fun send(request: HttpRequest): HttpResponse {
    var attempt = 0
    while (true) {
      try {
        val resp = engine.execute(request)
        if (!retry.shouldRetry(attempt, resp, null)) return resp
      } catch (e: Throwable) {
        if (!retry.shouldRetry(attempt, null, e)) throw e
      }
      attempt++
      kotlinx.coroutines.delay(retry.backoffMillis(attempt))
    }
  }
}

Platform adapters implement HttpEngine:- Android: OkHttpEngine (wraps OkHttp, configures timeouts, connection pooling)- iOS: UrlSessionEngine (Swift/Objective-C wrapper around URLSession exposed to KMP via cinterop or Kotlin/Native)

**Example retry/backoff strategies (shared)**- Exponential with full jitter: backoff = random_between(0, base * 2^attempt)- Max attempts, idempotency check (only retry safe methods or explicit idempotent token)

**Design notes / trade-offs**- Keep engine minimal to allow per-platform optimizations (connection pooling, HTTP/2).- Use kotlinx.serialization to ensure identical wire format.- Surface telemetry hooks (events/callbacks) in common API; platform provides native logging/tracing.- For long-running background uploads use platform-native scheduling; expose resumable upload tokens via shared models.

This design keeps networking behavior consistent while allowing native best-practices on each OS.

Unlock Full Question Bank

Get access to hundreds of Mobile Networking and API Integration interview questions and detailed answers.

Join thousands of developers preparing for their dream job.