Cross Platform Framework Experience Questions

Discuss hands-on experience with React Native and/or Flutter, understanding of trade-offs between native and cross-platform development, and scenarios where each approach is optimal. Be prepared to explain why a company might choose cross-platform frameworks for certain products.

EasyTechnical

70 practiced

Explain state management options in React Native and Flutter for simple and moderately complex apps. Contrast using local state (setState/useState) versus Provider/Context versus full state containers like Redux/MobX in React Native, and setState versus Provider/BLoC/Cubit in Flutter. When should a team choose each approach?

EasyTechnical

72 practiced

List the required system dependencies and step-by-step commands to create a new production-ready React Native project and a new Flutter project on macOS that target both iOS and Android. Include steps for installing Node, Yarn or PNPM, CocoaPods, Android SDKs, Xcode setup, environment variables, and how to verify emulators and simulators are working.

Sample Answer

**System dependencies (macOS)**- Homebrew, Xcode (Command Line Tools + full Xcode), Android Studio (SDK + AVD), Java JDK (11+), Node (via nvm), Yarn or pnpm, CocoaPods, watchman (optional), Flutter SDK (for Flutter project).

**Global prep**

bash

# Install Homebrew
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# Install common tools
brew install nvm yarn pnpm watchman cocoapods
sudo gem install cocoapods   # alternative if brew not used

**Node + package manager**

bash

# Install nvm and Node LTS
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash
source ~/.nvm/nvm.sh
nvm install --lts
# choose yarn or pnpm
npm install -g yarn
# or
npm install -g pnpm

**Xcode**- Install from App Store. Open once, accept license:

bash

sudo xcodebuild -license accept
xcode-select --install

**Android SDK / Studio**- Install Android Studio, open SDK Manager -> install SDK Platform (e.g., 33), Platform Tools, Build-tools; create an AVD in AVD Manager.

**Environment variables (add to ~/.zshrc or ~/.bash_profile)**

bash

# Android
export ANDROID_SDK_ROOT=$HOME/Library/Android/sdk
export PATH=$PATH:$ANDROID_SDK_ROOT/emulator
export PATH=$PATH:$ANDROID_SDK_ROOT/platform-tools
export PATH=$PATH:$ANDROID_SDK_ROOT/tools/bin

source the file after editing.

**Create React Native (production-ready basics)**

bash

# Use React Native CLI
npx react-native init MyApp --template react-native@latest
cd MyApp
# iOS pods
cd ios && pod install && cd ..
# Run
npx react-native run-ios   # opens Simulator
npx react-native run-android  # starts emulator

Add production builds: open Xcode -> set scheme to Release; for Android:

bash

cd android
./gradlew assembleRelease

**Create Flutter project**

bash

# install flutter sdk (follow flutter.dev) then:
flutter doctor   # resolves dependencies
flutter create my_flutter_app
cd my_flutter_app
# iOS
flutter build ios --release
# Android
flutter build apk --release
# Run
flutter run -d iosSimulator
flutter emulators --launch <emulator_id>
flutter run -d emulator-5554

**Verify simulators/emulators**

bash

# iOS simulators
xcrun simctl list devices

# Android emulators list and start
emulator -list-avds
emulator -avd <AVD_NAME>

# Check Flutter/React setups
flutter doctor -v
npx react-native info

Tips: keep Xcode and SDK versions aligned, sign iOS Release builds in Xcode, enable hardware acceleration (HAXM/Hypervisor) for Android emulator.

HardTechnical

74 practiced

You are leading a team tasked with migrating a large native iOS and Android app to a cross-platform framework without disrupting releases. Provide a detailed incremental migration plan including integration approach, repository/layout changes, CI adjustments, testing and QA strategy, risk mitigation for platform-specific features, and success/failure criteria.

Sample Answer

**Situation & goal**I lead migration of a large native iOS/Android app to a cross-platform framework (React Native or Flutter) incrementally with zero-release disruption.

**High-level approach**- Strangler pattern: ship new features in cross-platform modules while keeping existing native screens intact.- Select framework after spike (evaluate performance, native-bridge overhead, ecosystem for plugins like camera, push).

**Integration approach**- Embed RN/Flutter as a module in existing apps (iOS Pod / Android AAR). Expose a clear native ↔ JS/Dart bridge surface.- Start with non-critical feature flows (settings, onboarding) to validate tooling and UX parity.

**Repository & layout**- Monorepo with packages: /native-ios, /native-android, /mobile-cross (RN|Flutter), /shared (ui, analytics), /scripts.- Versioned SDK-like interface between native and cross code. Keep platform-specific adapters in /platform-adapters.

**CI/CD adjustments**- Parallel pipelines: maintain existing native pipelines; add cross-platform build and test pipelines.- CI steps: install deps, build cross module, run unit tests, run platform integration build (embed module), run E2E smoke on device farm.- Gate: require native pipeline green before store release; add canary releases (beta channel) for cross changes.

**Testing & QA**- Unit tests for business logic in cross layer. Snapshot / widget tests for UI.- Native integration tests to validate bridge calls and lifecycle.- E2E: Detox (RN) or Flutter integration tests plus Firebase Test Lab / BrowserStack matrix across OS versions.- Performance regression tests (startup, memory, FPS) automated with benchmarks.

**Risk mitigation for platform-specific features**- Maintain native modules for heavy platform APIs (AR, advanced camera). Wrap them with cross-platform facades.- Define fallbacks and feature flags to toggle between native and cross implementation.- Early POCs for push notifications, background tasks, and in-app purchases.

**Rollout & monitoring**- Progressive rollout (10% → 50% → 100%) with feature flags.- Monitoring: crashes, latency, ANRs, custom metrics, and user funnels. Use Sentry/Crashlytics + performance traces.

**Success / Failure criteria**- Success: parity in critical user flows, ≤5% performance regression, crash rate ≤ baseline + 10%, developer velocity improvement (time-to-deliver new screen reduced).- Failure signals: repeated production regressions, missing platform capabilities causing critical features to fail, or developer velocity decreases.

**Fallback plan**- Revert flag to native, fix issues, iterate on module. Keep native codebase fully functional until full cutover.

HardTechnical

88 practiced

You're asked to build and maintain a cross-platform native plugin exposing BLE (Bluetooth Low Energy) features to both React Native and Flutter. Provide a plan covering API design, JS/Dart bindings, native implementation considerations, device testing strategy, CI for publishing to npm and pub.dev, and how to handle breaking changes across platforms.

Sample Answer

**Overview / goals**I would deliver a single core native BLE layer (iOS/Android) with thin platform-specific adapters and idiomatic JS and Dart bindings so feature parity, performance and testing are consistent.

**API design**- Define stable, minimal surface: scan/start/stop/connect/disconnect/read/write/notify/permissions/state/events- Use async patterns: Promises for JS, Futures/Streams for Dart; emit events for advertisement/notification/connection changes- Versioned API with semantic versioning and feature flags

**JS/Dart bindings**- React Native: NativeModules + EventEmitter; expose Promise-based APIs and an observable for notifications- Flutter: MethodChannel + EventChannel; return Future for calls, Stream for events- Keep thin mapping: convert native errors to structured error objects

**Native implementation**- iOS: CoreBluetooth in Swift; background modes, state restoration, permission prompts, central/peripheral roles- Android: Kotlin, BluetoothLeScanner/Gatt with foreground services for long scans, handle Android 12+ permissions and location requirements- Centralized platform-agnostic business logic in shared module patterns where feasible

**Device testing strategy**- Matrix of devices: Android (API 23, 26, 29, 31+), iOS (13,14,15+), several vendors- Real devices for GATT, emulators for basic flows- Automated E2E with a BLE test harness (Raspberry Pi or Nordic DK) simulating peripherals and scripted scenarios

**CI & publishing**- CI pipelines: GitHub Actions with matrix builds for iOS (macOS runners) and Android- Run unit tests, integration tests against simulator/emulator and a hardware test farm (or cloud device lab)- Automate publishing: npm package build from CI with changelog and signed commits; pub.dev publish via CI using service account tokens; gated releases on tag and passing tests

**Handling breaking changes**- Use semver and major-versioned packages if needed- Deprecate first: provide compatibility shims for a release cycle, emit console/warn messages, document migration guides and codemods- Keep native logs for mismatch detection; include runtime version checks in bindings to throw helpful errors

This plan balances safety, developer ergonomics, and lifecycle management for a robust cross-platform BLE plugin.

HardTechnical

76 practiced

A production Android app built with React Native crashes intermittently only on devices running Android 8.0 and produces native SIGSEGV tombstones but no JS stack trace. Walk through a detailed investigative process including how you would collect tombstones, symbolize native addresses, analyze NDK stack traces, identify JNI misuse or memory corruption, and design reproducible tests.

Sample Answer

**Approach overview**Start by collecting all native crash artifacts, symbolize them, inspect the NDK stack and JNI boundaries for misuse/corruption, then design reproducible tests and mitigations. Focus on Android 8.0 (Oreo) quirks (background execution limits, memory layout).

**Collect tombstones**- Pull device tombstones: `adb root && adb pull /data/tombstones/ tombstones/`- If app runs as non-root, get `adb bugreport > bugreport.zip` (contains tombstones and logs).- Capture logcat around crash: `adb logcat -b crash -b main -d > logcat.txt`.- Save app APK and matching native .so and unstripped .so from your build.

**Symbolize native addresses**- Use the app’s unstripped .so and the exact build ID.- addr2line example:

bash

arm-linux-androideabi-addr2line -f -C -e libyour.so 0xdeadbeef

- For multiple frames use `ndk-stack` or `llvm-symbolizer`. Ensure build IDs match; if not, locate proper artifact in your CI artifacts.

**Analyze NDK stack traces**- Determine crash type (SIGSEGV read/write, PC in libc vs your module).- Look for patterns: crashing in JNI calls, c-alloc/free, or in third-party native libs.- If PC is inside libc while stack shows your native code nearby, suspect memory corruption.

**Look for JNI misuse / memory corruption**- Common issues: - Using freed local/global references, dangling pointers to Java objects. - Incorrect `GetStringUTFChars`/`ReleaseStringUTFChars` pairing. - Passing invalid jobject across threads without proper GlobalRef. - Buffer overflows, off-by-one in native buffers.- Use the tombstone’s register/state dump: check source address and stack pointers for invalid addresses.- If crash occurs only on Oreo, consider differences in memory layout / hardened malloc; intermittent => heap corruption.

**Reproducible tests & instrumentation**- Build debug/native-symbol builds and reproduce on Android 8.0 device.- Enable AddressSanitizer/UndefinedBehaviorSanitizer for native modules (rebuild NDK module with ASAN). Run long stress tests.- Use Android’s Memory Tools: ASAN, Valgrind-like tools (where possible), and malloc debug options (`export MALLOC_CONF` if using jemalloc).- Add extra JNI checks: validate jobject != NULL, verify thread-attached state, add sentinel values around buffers.- Create unit tests that exercise JNI boundaries and heavy-concurrency scenarios. Use monkey/stress (UI/Application exerciser) and automated repro harness to call suspicious native APIs repeatedly.- If intermittent, add logging with Canary values, heartbeat and periodic heap checks, and optionally use Breakpad/Crashpad to capture symbols and full dumps in production.

**Root cause discovery loop**- Reproduce with ASAN to get exact failing line. If ASAN doesn’t trigger, create deterministic test cases that isolate the native function, fuzz inputs, and run on same Android 8.0 OEM image.- Once pinpointed, fix: correct JNI reference lifetime, bounds-checks, thread-attach logic, or replace unsafe APIs.- Verify fix with long-run stress on multiple Oreo devices and roll out staged release with enhanced crash reporting.

**Takeaways**- Collect tombstones and unstripped binaries, symbolize precisely.- Use ASAN and extra JNI validation to find corruption.- Design focused stress/repro tests that mimic production behavior on Android 8.0 to validate the fix.

Unlock Full Question Bank

Get access to hundreds of Cross Platform Framework Experience interview questions and detailed answers.

Join thousands of developers preparing for their dream job.