DEV Community: Adil Mezghouti

Polyfills, Shims, and Native Modules: Lessons from Building a React Native Crypto Wallet

Adil Mezghouti — Mon, 10 Aug 2026 16:44:19 +0000

Preface: This article is about my experience building a crypto mobile wallet back in 2021.

Intro

Building a crypto wallet in React Native is a masterclass in edge-case architecture. Unlike standard mobile applications that simply fetch JSON from a REST API, a crypto wallet acts as an isolated cryptographic engine. It must generate entropy, derive keys, sign transactions, encode raw binary payloads, and communicate with decentralized networks.

When you attempt to bring standard Web3 JavaScript libraries into React Native, you quickly discover a fundamental disconnect: most Web3 packages were written assuming either a full Node.js runtime or a web browser environment. React Native's JavaScript engine (Hermes or JavaScriptCore) provides neither.

To make a mobile crypto wallet work, you inevitably have to master three distinct strategies: Polyfilling, Shimming, and Native Modules. Here is how each strategy fits into building a wallet, when to reach for them, and how the ecosystem has evolved.

The Three Strategies in a Wallet Architecture

                       ┌──────────────────────────────────────────┐
                       │       React Native Wallet Application    │
                       └────────────────────┬─────────────────────┘
                                            │
        ┌───────────────────────────────────┼───────────────────────────────────┐
        ▼                                   ▼                                   ▼
┌───────────────────────┐       ┌───────────────────────┐       ┌───────────────────────┐
│       POLYFILLS       │       │         SHIMS         │       │    NATIVE MODULES     │
├───────────────────────┤       ├───────────────────────┤       ├───────────────────────┤
│ • crypto.getRandom    │       │ • global.Buffer       │       │ • iOS Secure Enclave  │
│   Values              │       │ • readable-stream     │       │ • Android Keystore    │
│ • TextEncoder/Decoder │       │ • path / events       │       │ • C++ secp256k1 via   │
│ • URL/URLSearchParams │       │   (via Metro aliases) │       │   JSI for fast signing│
└───────────────────────┘       └───────────────────────┘       └───────────────────────┘

Polyfilling: Restoring Missing Web Standards

What it is: Code that detects if a standard Web API exists in the JavaScript runtime. If missing, it dynamically attaches a spec-compliant JS implementation directly to the global scope.
Wallet Context: Web3 SDKs (like Ethers.js, Viem, or WalletConnect) rely heavily on browser primitives for RPC formatting, address validation, and entropy generation. Without polyfills, functions expecting URL or TextEncoder crash immediately.

// Polyfilling entropy generation for bip39 seed phrase generation
import 'react-native-get-random-values';

// Now standard Web Crypto entropy works globally in JS
const randomBytes = crypto.getRandomValues(new Uint8Array(32));

Shimming: Adapting Node.js Ecosystem Dependencies

What it is: Intercepting API calls to wrap, adapt, or alias non-standard environments (specifically Node.js built-in libraries) so they run inside React Native.
Wallet Context: Core crypto primitives like bip39, ethereumjs-util, bs58, and hdkey were originally written for Node.js. They rely on built-ins like Buffer, stream, and crypto. Metro doesn't resolve these by default, requiring shims and bundler aliases to map them to React Native JS equivalents.

1. Global Injection (In your entry point, e.g., `index.js`)

Before any Web3 or crypto library imports execute, you inject required Node globals into globalThis:

// In index.js / entry point
global.Buffer = require('react-native-buffer').Buffer;

2. Metro Bundler Aliasing (`metro.config.js`)

Injecting globals isn't enough on its own—when a package internally executes require('crypto') or require('stream'), Metro will still fail to resolve the module. You must configure Metro to alias Node's built-in modules to React Native-compatible browser/JS polyfill packages:

// metro.config.js
const { getDefaultConfig, mergeConfig } = require('@react-native/metro-config');

const defaultConfig = getDefaultConfig(__dirname);

const config = {
  resolver: {
    // Map Node.js core modules to RN-compatible npm packages
    extraNodeModules: {
      crypto: require.resolve('react-native-quick-crypto'),
      stream: require.resolve('readable-stream'),
      buffer: require.resolve('react-native-buffer'),
    },
  },
};
...

Native Modules (TurboModules / JSI): Hardware Security & High-Perf C++

What it is: Writing native code (Swift/Objective-C on iOS, Kotlin/Java on Android, or C++ via JSI) to expose native capabilities, security hardware, or compiled C/C++ libraries to JavaScript.
Wallet Context: A pure JavaScript engine running heavy cryptographic routines can choke the single-threaded event loop, leading to very poor performance.

Persisting RN Settings Across Reinstalls Without User Accounts

Adil Mezghouti — Thu, 06 Aug 2026 14:32:40 +0000

A while back, I worked on a React Native app that had no support for user sign-ups or accounts. Despite that, we had a clear requirement: preserve user customizations across app installs.
Users needed their custom theme choices, language/locale settings, and favorited items to survive if they deleted and reinstalled the app. Furthermore, we needed to keep their anonymous analytics IDs persistent so we wouldn't pollute our data pipeline with "duplicate" new users every time someone reinstalled.

Without a backend database or user ID to attach data to, I solved this by leveraging @react-native-async-storage/async-storage alongside the built-in native OS backup mechanisms (iCloud on iOS and Google Auto Backup on Android). Here is how it works, what to watch out for, and how to set it up.

1. Requirements, Constraints & User Cost

Before relying on native backups, you need to be aware of how the OS handles state restoration:

Device Backup Prerequisite: This strategy relies on the user having OS-level backups toggled on (Settings > Apple Account > iCloud Backup on iOS or Settings > Google > Backup on Android). If a user turns this off, state resets on reinstall.
Zero Cost for Users: Users do not need paid cloud storage tiers:
- Android: Google Auto Backup gives up to 25 MB per app for free—and it is completely exempt from the user's 15 GB personal Google Drive quota.
- iOS: Settings payloads are tiny JSON files (< 100 KB) that consume virtually zero space in Apple's free 5 GB iCloud tier.
Security & Latency Guardrails: Never store sensitive tokens or credentials in AsyncStorage backup files (use Keychain/KeyStore instead). Also, keep in mind that OS cloud snapshots trigger asynchronously (usually on Wi-Fi while charging). An immediate reinstall seconds after a setting change might restore the previous snapshot.

2. Code Implementation

Instead of cluttering storage with isolated keys, consolidate your guest preferences and anonymous analytics ID into a single schema.

import AsyncStorage from '@react-native-async-storage/async-storage';

export interface GuestAppState {
  analyticsId: string;
  settings: {
    theme: 'light' | 'dark' | 'system';
    locale: string;
  };
  favorites: string[]; // Array of favorited item IDs
}

const STORAGE_KEY = '@app_guest_state_v1';

export const saveGuestState = async (state: GuestAppState): Promise<void> => {
  try {
    await AsyncStorage.setItem(STORAGE_KEY, JSON.stringify(state));
  } catch (error) {
    console.error('Failed to persist guest state:', error);
  }
};

export const loadGuestState = async (): Promise<GuestAppState | null> => {
  try {
    const raw = await AsyncStorage.getItem(STORAGE_KEY);
    return raw ? JSON.parse(raw) : null;
  } catch (error) {
    console.error('Failed to hydrate guest state:', error);
    return null;
  }
};

How It Works Under the Hood

When a user reinstalls the app:

AsyncStorage writes keys to standard internal storage locations (iOS Documents directory / Android internal SQLite/Key-Value files).
The native OS includes these files in its scheduled cloud snapshot.
Upon reinstalling, the OS restores the application sandbox files before the React Native JavaScript bundle executes its initial boot.
When your app mounts, loadGuestState() reads the restored JSON file as if the app was never uninstalled—preserving theme, favorites, and the original analyticsId.

3. Essential Native Configuration

For native backups to work smoothly across installations, you need a few minor native file configurations.

Android Setup (`android/app/src/main`)

Ensure android:allowBackup="true" is set in AndroidManifest.xml:

<!-- AndroidManifest.xml -->
<application
    android:allowBackup="true"
    android:fullBackupContent="@xml/backup_rules"
    android:dataExtractionRules="@xml/data_extraction_rules">
    <!-- ... -->
</application>

Define explicit rules in res/xml/data_extraction_rules.xml (for Android 12+) to ensure AsyncStorage databases and shared preferences are backed up:

<?xml version="1.0" encoding="utf-8"?>
<data-extraction-rules>
    <cloud-backup>
        <include domain="sharedpref" path="." />
        <include domain="database" path="." />
    </cloud-backup>
</data-extraction-rules>

iOS Setup

iOS automatically backs up the app's Documents directory to iCloud by default. No Xcode configuration is required unless you manually flag files using NSURLIsExcludedFromBackupKey.

Wrap-Up

Relying on native OS cloud backups for AsyncStorage is an effective way to preserve user customizations in accountless React Native apps. You keep user preferences intact, avoid backend infrastructure costs, maintain accurate analytics identity, and never cost your users a dime in cloud storage fees.

5 React Native Interview Questions You must know how to solve

Adil Mezghouti — Sun, 19 Jul 2026 14:01:59 +0000

If you're prepping for a React Native interview, the truth is that most companies aren't testing whether you know some obscure API, they're testing whether you can build small, correct, and stateful UI under time pressure. Here are five patterns that show up constantly, what they're actually testing, and the mistakes that trip people up.

1. The Stepper Counter (useState basics)

The simplest possible test: a number, a + button, a - button. Trivial to get working, easy to get wrong in the details interviewers actually care about:

Are you mutating state directly, or going through the setter?
Does rapid clicking behave correctly, or are you reading stale state from a closure
(setCount(count + 1) vs setCount(c => c + 1))?
Did you clamp the range, if the spec asked for one? If you can't explain why the functional updater form matters, that's the tell an interviewer is listening for.

2. The Todo List (list state + keys)

This is where useState collides with arrays and objects, and where most bugs live:

Are you spreading into a new array/object on every update, or mutating in place (which won't re-render, or will just be wrong with React 19's stricter expectations)?
Are you using a stable key (an id), not the array index, especially once delete/reorder is in the mix?
Toggling "done" on one item shouldn't re-render the whole list conceptually, even if in practice RN doesn't punish you the way a huge web list might.

3. The Tip Calculator (derived state)

The trap here is state you don't need. A tip calculator has exactly one piece of real state, the bill amount and the tip percentage, and the tip/total are derived, not stored. Candidates who reach for a third useState for the computed total are demonstrating a habit that causes real bugs later: stored values that can drift out of sync with their inputs.

4. Live Search Filter (controlled input + performance instinct)

A TextInput that filters a list as you type. Functionally simple, but it's easy to get wrong:

Do you filter on every keystroke against the full source list (correct, and fine at small scale), or accidentally filter against the already-filtered list (a classic bug that quietly breaks "undo" a character)?
Do you know when you'd reach for debouncing, even if this list is small enough not to need it?

5. Star Rating (interaction + accessibility instinct)

A row of tappable stars that reflects and sets a rating. This tests something the other four don't: translating a design into discrete interactive elements, plus whether you think about accessibility
by default (does each star have an accessible label like "Rate 3 stars," or is it just a bare Pressable with an icon?).

Practicing these for real

Reading about these patterns only gets you so far, you need to actually write the component and see it render. I built rnprep.dev for exactly this: a live CodeMirror editor next to a real React Native preview (self-hosted react-native-web + Babel, not a hosted simulator or iframe), covering these five problems plus AI-graded feedback on your solution. No signup, no API key needed.

If you've got a pattern you think should be on this list, the problem set is open source.