React Native Risk Assessment & Management 4 — Questions and Answers
Question 1: What risk arises from using `console.log` statements in a production React Native build?
- Sensitive data may be exposed in device logs and it degrades JS thread performance (Correct answer)
- The app will crash immediately on launch in release mode
- Metro will refuse to bundle files containing console.log
- Hermes will disable JIT optimization for logged functions
Correct answer: Sensitive data may be exposed in device logs and it degrades JS thread performance
Production logs can leak sensitive data and incur unnecessary JS thread overhead; they should be stripped via Babel transforms.
Question 2: A React Native app's CI pipeline runs only unit tests with mocked native modules. What risk does this testing strategy leave unaddressed?
- Integration failures between JavaScript code and actual native module implementations on real devices (Correct answer)
- TypeScript type errors in shared utility functions
- Incorrect Redux reducer logic
- CSS-in-JS styling inconsistencies across screens
Correct answer: Integration failures between JavaScript code and actual native module implementations on real devices
Mocked native modules cannot detect mismatches between the JS bridge contract and the actual native implementation, requiring device/emulator testing.
Question 3: Which risk does using a single shared Redux store for all screens in a large React Native app introduce?
- Unrelated state changes can trigger unnecessary re-renders across the entire component tree (Correct answer)
- Redux DevTools cannot connect to React Native's Metro server
- Navigation state cannot be persisted with React Navigation
- The store becomes inaccessible after the app enters background
Correct answer: Unrelated state changes can trigger unnecessary re-renders across the entire component tree
A monolithic store with poorly-memoized selectors causes cascading re-renders; use `reselect` and split reducers to isolate state changes.
Question 4: What is the primary risk of not code-signing a React Native Android release APK before distributing it outside the Play Store?
- Users receive no integrity guarantee — the APK could be tampered with and repackaged with malware (Correct answer)
- The APK will crash on all Android 10+ devices
- Google Play Services will block the app from accessing device APIs
- Metro source maps will be embedded in plaintext
Correct answer: Users receive no integrity guarantee — the APK could be tampered with and repackaged with malware
Unsigned or improperly-signed APKs have no cryptographic integrity guarantee, enabling trivial repackaging attacks.
Question 5: Which approach best mitigates the risk of React Native's JavaScript thread being blocked by heavy computation?
- Offload CPU-intensive work to a Web Worker via react-native-workers or a native module (Correct answer)
- Increase the JavaScript thread's priority in the React Native runtime config
- Split computation across multiple `setState` calls in a loop
- Use synchronous native module methods for all heavy tasks
Correct answer: Offload CPU-intensive work to a Web Worker via react-native-workers or a native module
Moving CPU-heavy work off the JS thread prevents frame drops and UI freezes caused by blocking the single-threaded JS runtime.
Question 6: A React Native team stores API keys directly in their JavaScript source code. What is the correct risk mitigation?
- Move secrets to environment variables loaded via react-native-config or a secrets manager, never bundle them in JS (Correct answer)
- Obfuscate the source code with ProGuard to hide the keys
- Use Base64 encoding to prevent key extraction from the bundle
- Store keys in AsyncStorage populated at first launch
Correct answer: Move secrets to environment variables loaded via react-native-config or a secrets manager, never bundle them in JS
Bundled JavaScript can be extracted from any APK/IPA, so API keys must live server-side or in secure environment configs, not in the JS bundle.
Question 7: What risk does neglecting to handle the `AppState` change to 'background' introduce in a React Native app with active network polling?
- Continued background polling drains battery and may violate iOS background execution limits, causing termination (Correct answer)
- The app will immediately crash when backgrounded on Android
- React Navigation will lose the current route on foreground resume
- Metro bundler will disconnect from the development server
Correct answer: Continued background polling drains battery and may violate iOS background execution limits, causing termination
iOS strictly limits background execution time; unmanaged polling in the background leads to battery drain and OS-forced termination.
React Native Risk Assessment & Management 4
What risk arises from using `console.log` statements in a production React Native build?