Mobile Platform Knowledge Questions

Understanding the iOS and Android mobile platforms, their development ecosystems, and the practical tradeoffs of native and cross platform approaches. Topics include platform languages and toolchains such as Swift and Objective C for iOS and Kotlin and Java for Android, platform architecture and application lifecycle, user interface frameworks and design guidelines, performance and memory considerations, platform specific security and permission models, testing strategies and device fragmentation, build and release processes including app store distribution and versioning, continuous integration and continuous delivery for mobile, and interoperability with backend services. Candidates should be able to explain when to choose native versus cross platform solutions, discuss debugging and profiling tools, and describe how platform constraints influence design and operational decisions.

MediumSystem Design

69 practiced

Design a CI/CD pipeline that builds, tests, and releases both Android and iOS apps using GitHub Actions and Fastlane. Describe the pipeline stages, how you manage build matrices and parallel jobs, secure signing and secret management, running unit and UI tests on device clouds, caching dependencies, artifact storage, and the process to publish to Play Store and App Store Connect.

Sample Answer

**Pipeline overview (stages)** - PR -> CI: lint, unit tests, build checks - Merge to main -> CD: full builds, UI tests on device cloud, artifact storage, staged release - Release gates: manual approval for production

**Build matrix & parallelism** - Use GitHub Actions matrix strategy for OS/ABI/Flavors (android: API 29/31, iOS: 14/16) and variants (debug/release). - Split heavy jobs (android build, ios build, android UI, ios UI) into parallel workflows; use job concurrency to limit device cloud slots.

**Secrets & signing** - Store keystore, KEYSTORE_PASSWORD, FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD, Apple API key JSON, service account JSON in GitHub Secrets. - Decrypt signing artifacts at runtime using actions/checkout + actions/upload-artifact for transient use; restrict secrets to protected branches and require approvals. - For iOS, use Fastlane match (private git-backed certs) or Apple App Store Connect API keys; for Android, use Google Play service account JSON.

**Testing on device clouds** - Integrate Firebase Test Lab (Android) and BrowserStack or Bitrise device cloud (iOS) via CLI; upload APK/IPA and run matrix of device+OS tests. Collect logs, screenshots, and video as artifacts.

**Caching & dependency management** - Cache Gradle, .gradle/caches, ~/.m2, CocoaPods/Carthage/SwiftPM artifacts using actions/cache keyed by lockfile + OS + toolchain. Restore to speed builds.

**Artifacts & storage** - Upload build outputs and test reports to GitHub artifacts or an S3 bucket. Tag artifacts with build number, git commit, branch.

**Publishing** - Android: use Fastlane supply with service account to upload to internal, alpha, beta tracks; automate track promotion after approval. - iOS: use Fastlane pilot / deliver with App Store Connect API key to upload dSYMs and IPA, submit to TestFlight, require manual review step for production release.

**Observability & rollbacks** - Publish build status to Slack, include test summaries. Keep signed artifact snapshots for fast rollback and use staged rollouts (Play Store) and phased releases (App Store).

EasyTechnical

61 practiced

You need to decide between native development and a cross-platform framework for a new data-driven app with standard UI components and modest access to device APIs. Explain the criteria you would use to choose native iOS/Android versus React Native or Flutter, covering performance, developer skillset, third-party library support, long term maintenance, time-to-market, and testing implications.

MediumTechnical

78 practiced

A React Native app displays janky animations on older Android devices due to bridge overhead and heavy JS work. Propose concrete optimization strategies covering architecture changes, native modules, offloading work from the JS thread, using Hermes, FlatList optimizations, and profiling tools you would use to measure improvements.

Sample Answer

**Brief approach**Focus on removing JS-thread work from the animation path, move time-sensitive work to native/JSI, enable Hermes, optimize lists, and measure before/after with frame-level profilers.

**Architecture changes**- Introduce JSI/TurboModules-friendly architecture: move heavy modules to native (Kotlin/Java) or implement as TurboModules so they don’t cross the slow bridge repeatedly.- Adopt UI-driven patterns: use React Native Fabric (if available) and prefer synchronous UI-thread updates for layout/animation-critical work.

**Native modules & offloading**- Implement animation logic in native or via Reanimated 2 worklets (JSI): run math and interpolation on the UI thread (no bridge).- Use native modules for expensive data processing (parsing, image decoding) and return results via events or shared memory.- Use InteractionManager / Offscreen threads to defer non-critical JS work.

**Hermes**- Enable Hermes on Android (reduces memory & startup, faster GC).- Precompile with Hermes bytecode, enable inlineRequires and RAM bundles to reduce runtime parsing.- Use Hermes profiler to inspect JS call stacks and GC pauses.

**FlatList optimizations**- Use keyExtractor, getItemLayout, initialNumToRender, maxToRenderPerBatch, windowSize carefully.- Avoid inline renderItem closures; memoize item components (React.memo, PureComponent).- Use removeClippedSubviews where appropriate and enable virtualization.- Implement incremental data loading and avoid heavy computations inside renderItem.

**Profiling & measurement**- Measure baseline: Android Systrace / Perfetto and React Native perf monitor (show FPS).- Use Flipper: React DevTools, Hermes plugin, and React Native Performance plugin.- Android Studio CPU & GPU profilers and adb shell dumpsys gfxinfo <package> for frame metrics.- Use Reanimated’s frame callback traces if using worklets.- Metrics to track: JS thread time, UI thread time, total frame time, dropped frames, GC pauses.

**Concrete example**- Replace Animated.timing linked to JS with Reanimated worklet driving transform on UI thread.- Move JSON parsing of payloads into a native module returning a cursor or pre-parsed structure.- After changes: run Perfetto + Hermes profiler, expect JS-thread time reduced, stable 60/30 FPS and <16ms frame times on target devices.

This combination reduces bridge overhead, eliminates JS jitter on animation frames, and gives measurable improvements via the profiling suite.

MediumSystem Design

58 practiced

You must refactor a monolithic Android app into modular feature and domain modules to speed up build times and support independent team ownership. Propose a modularization strategy including module boundaries, dependency rules, Gradle configuration recommendations, caching and CI strategies, and how to share resources like branding and networking clients without creating tight coupling.

Sample Answer

**Approach & goals**Split by feature + core domain to reduce rebuild scope, enable team ownership, and keep stable contracts between modules.

**Module boundaries**- feature/{auth,search,profile} — UI, navigation, viewmodels, compose/fragments; depends only on domain and core-android.- domain/{user,search} — business logic, use-cases, interfaces, DTOs; no Android UI deps.- core/{android,network,ui,branding} — shared Android utilities, Retrofit/OkHttp clients, theme, icons.- app — thin shell, aggregates feature modules, composition root, DI wiring.

**Dependency rules**- Unidirectional: app -> feature -> domain -> core (core has no feature deps).- Domain exposes interfaces; core implements platform specifics. Use inversion (interfaces in domain, impl in core).

**Gradle recommendations**- Use Gradle Kotlin DSL, enable configuration on demand and build cache.- Use implementation vs api correctly: domain published as api only when necessary.- Enable Gradle’s configuration cache and parallel project execution.- Example DI-friendly Gradle feature module:

kotlin

plugins { id("com.android.library"); kotlin("android") }
android { compileSdk = 34 }
dependencies {
  implementation(project(":domain:user"))
  implementation(project(":core:android"))
  implementation("com.google.dagger:hilt-android:2.44")
}

**Caching & CI**- Enable remote build cache (Gradle Enterprise or Bazel/Build Cache), incremental compilation, and Gradle configuration cache.- CI: run matrix — changed-module-aware builds (only affected modules), full verification nightly. Use artifact caching for AARs.

**Sharing resources without tight coupling**- Branding: core:branding provides resource-only module with sealed tokens (colors, styles) and theme APIs.- Networking: domain defines repository interfaces; core:network provides Retrofit client and OkHttp interceptors, injected via DI.- Use clean interfaces, compile-only resource modules, and module-level resource prefixes to avoid collisions.

**Trade-offs**- Extra upfront work for API contracts and DI wiring; payback via faster developer builds and clearer ownership.

HardTechnical

66 practiced

Given the Swift code snippet below, identify memory management issues and refactor to avoid retain cycles while preserving behavior. Explain why the leak occurs and how your fix prevents it.class DataFetcher { var completion: (() -> Void)? func fetch() { networkCall { self.completion?() } } }

Sample Answer

**Approach — root cause**The closure passed to networkCall captures self strongly: networkCall { self.completion?() }. If that closure lives longer than the caller expects (network queue, timer, etc.), self (DataFetcher) is kept alive until the closure runs. Also, the stored completion closure itself might capture the caller strongly, creating indirect cycles. Use weak/unowned captures and safe optional unwrapping to break strong references.

**Refactored code**

swift

class DataFetcher {
    var completion: (() -> Void)?

    func fetch() {
        networkCall { [weak self] in
            // Capture self weakly to avoid retaining DataFetcher
            guard let self = self else { return } 
            self.completion?()
        }
    }
}

**Why the leak occurs**- The closure passed to networkCall captures self strongly by default. If that closure is retained by the networking layer (or stored until completion), it retains DataFetcher.- If completion also captures the creator (e.g., a view controller) strongly, you can get a retain cycle: ViewController -> DataFetcher -> completion -> ViewController.

**Why this fix works**- [weak self] makes the closure hold only a weak reference; if DataFetcher is deallocated before the network returns, the closure won’t keep it alive and will safely no-op.- Using guard let self = self prevents accidental use of a deallocated object.- Ensure callers set completion with [weak self] if they reference self inside completion to avoid the reciprocal cycle.

**Alternative**- Use [unowned self] only when you're certain self will outlive the closure (rare for async network callbacks).- Capture completion locally to avoid races:

swift

networkCall { [weak self] in
  guard let self = self else { return }
  let c = self.completion
  c?()
}

This preserves behavior while eliminating retain cycles and potential memory leaks.

Unlock Full Question Bank

Get access to hundreds of Mobile Platform Knowledge interview questions and detailed answers.

Join thousands of developers preparing for their dream job.