DEV Community: PEAKIQ

Build a Production QR/Barcode Scanner Modal in React Native

PEAKIQ — Fri, 18 Sep 2026 11:22:46 +0000

Originally published on PEAKIQ

Source: https://www.peakiq.in/blog/building-a-production-qr-barcode-scanner-modal-in-react-native

Most React Native scanner tutorials stop at "drop in a camera view and read a code." That works fine on a simulator and falls apart the moment it meets a mid-range Android phone in a warehouse with bad lighting. The gap between "scans in the demo" and "scans reliably, on both platforms, in the hand of someone who isn't looking at a tutorial" is where most of the actual engineering lives.

Below is the scanner we ship: a full-screen modal with a close button, title, gallery picker, flashlight, a three-dot menu, and a zoom pill — reading QR codes and barcodes on iOS and Android from a single call site.

const value = await QRBarcodeScanner.open({ title: "'Scan Product QR' });"
if (value) lookupProduct(value);

The stack

Package	Purpose
`react-native-vision-camera`	Camera + native scanning
`vision-camera-barcodes-scanner`	ML Kit barcode frame processor (iOS path)
`react-native-torch-nitro`	Hardware flashlight
`react-native-worklets-core`	Worklet → JS hop (`useRunOnJS`)
`react-native-ml-kit/barcode-scanning`	Decode still photos and gallery images
`zustand`	The one small store the whole thing runs on
`react-native-safe-area-context`	Insets inside the modal window

npm i react-native-vision-camera react-native-worklets-core \
    react-native-torch-nitro react-native-ml-kit/barcode-scanning \
    vision-camera-barcodes-scanner zustand
cd ios && pod install

Android needs the bundled ML Kit model — this is what makes the native code-scanner path actually decode anything; without it, the code still compiles but has no model to run against. Add this to android/gradle.properties:

VisionCamera_enableCodeScanner=true

That's the entire native setup. Everything else below is application code.

Step 1: A store that owns every scan session

The scanner is driven by a single Zustand store. open() returns a promise, close(value) resolves it, and setResult() parks an outcome for the modal to render. The detail worth calling out is the re-entrancy guard — it exists because re-calling open() while a session was already showing used to silently wipe a parked "Invalid QR" result out from under the user. Fixing it once here means every caller is safe automatically.

import { create } from 'zustand';

export type ScanFormat = string | number | null | undefined;
export type ScanCodeType = 'qr' | 'barcode';

export type ScanOutcomeState =
  | 'invalid'
  | 'qrCodeNotFound'
  | 'error'
  | 'productFound'
  | 'unknownBarcode';

export interface ScanOutcome {
  state: ScanOutcomeState;
  barcode?: string;
  productName?: string;
  type?: ScanCodeType;
  product?: {
    productName: string;
    unNumber: string;
    location: string;
    batch: string;
    expiry: string;
    hazard: string;
  };
}

export interface QRBarcodeScannerOptions {
  title?: string;
  message?: string;
  /** Runs the instant a code is read, inside the scanner. */
  validate?: (value: string) => boolean;
  /** Caller-driven: fires with each valid code while the scanner stays open. */
  onCodeRead?: (value: string, format?: ScanFormat) => void;
  onSearch?: (barcode?: string) => void;
  onCreate?: (barcode?: string) => void;
}

interface ScannerStoreState {
  visible: boolean;
  options: QRBarcodeScannerOptions | null;
  result: ScanOutcome | null;
  resolve: ((value: string | null) => void) | null;
  open: (options?: QRBarcodeScannerOptions) => Promise<string | null>;
  close: (value?: string | null) => void;
  setResult: (result: ScanOutcome | null) => void;
}

export const useScannerStore = create<ScannerStoreState>((set, get) => ({
  visible: false,
  options: null,
  result: null,
  resolve: null,

  open: (options = {}) => {
    if (get().visible) {
      // Already showing — never clobber a parked result or orphan the live
      // resolver. Hand the caller "cancelled" instead.
      return Promise.resolve<string | null>(null);
    }
    return new Promise<string | null>((resolve) => {
      set({ visible: true, options: options || {}, result: null, resolve });
    });
  },

  close: (value: string | null = null) => {
    const { resolve } = get();
    if (resolve) resolve(value); // wake the awaiting caller
    set({ visible: false, options: null, result: null, resolve: null });
  },

  setResult: (result) => set({ result }),
}));

/** Convenience singleton so any module can open the scanner. */
export const QRBarcodeScanner = {
  open: (options?: QRBarcodeScannerOptions) =>
    useScannerStore.getState().open(options),
  close: (value?: string | null) => useScannerStore.getState().close(value),
  setResult: (r: ScanOutcome | null) => useScannerStore.getState().setResult(r),
};

Step 2: One modal, mounted once, genuinely full-screen

This mounts a single time at your app root, next to whatever hosts your alerts. Two details matter here:

transparent={false} (the default) is what makes it actually full-screen rather than a sheet over the current view.
The child is only mounted while visible is true. Each open starts a fresh camera session; each close fully tears it down. There is never a camera running behind another screen.

A top-level Modal is a separate native window, so it needs its own SafeAreaProvider — your app's normal inset provider doesn't reach inside it.

import React, { forwardRef, useState } from 'react';
import { Modal } from 'react-native';
import { SafeAreaProvider } from 'react-native-safe-area-context';
import BarcodeScannerScreen from './BarcodeScannerScreen';
import { useScannerStore } from './scannerStore';

export const ScannerModal = forwardRef<unknown, {}>((_props, _ref) => {
  const visible = useScannerStore((s) => s.visible);
  const options = useScannerStore((s) => s.options);
  const result = useScannerStore((s) => s.result);
  const close = useScannerStore((s) => s.close);
  const [galleryNoticeKey, setGalleryNoticeKey] = useState(0);

  return (
    <Modal visible={visible} animationType="fade" onRequestClose={() => close()}>
      {visible && (
        <SafeAreaProvider>
          <BarcodeScannerScreen
            title={options?.title}
            message={options?.message}
            validate={options?.validate}
            onCodeRead={options?.onCodeRead}
            onSearch={options?.onSearch}
            onCreate={options?.onCreate}
            result={result}
            onClose={() => close()}
            galleryNoticeKey={galleryNoticeKey}
          />
        </SafeAreaProvider>
      )}
    </Modal>
  );
});

If any of your other screens wrap themselves in their own <Modal>, a second top-level modal will present behind one that's already open. The fix is a small presenter stack: a screen that owns its own modal mounts a local copy of this one and pushes itself onto a shared hostStack; the app-root modal only presents when that stack is empty. Same store, same UI — the stack just decides which native window renders it.

Step 3: The screen that ties the pieces together

This owns the top bar, torch, zoom, continuous mode, validation, and result rendering. After a scan, the camera "parks" by toggling cameraActive off rather than unmounting anything.

import React, { useEffect, useRef, useState } from 'react';
import { AppState, Platform, StyleSheet, Text, View } from 'react-native';
import { useCameraDevice } from 'react-native-vision-camera';
import { useTorch } from 'react-native-torch-nitro';
import CameraPreview from './CameraPreview';
import ScannerTopBar from './ScannerTopBar';
import ScannerMenu from './ScannerMenu';
import ZoomControl from './ZoomControl';
import ScanResultChip from './ScanResultChip';
import ResultOverlay from './ResultOverlay';
import { ScanOutcome, ScanFormat, useScannerStore } from './scannerStore';

interface Props {
  visible?: boolean;
  title?: string;
  message?: string;
  validate?: (value: string) => boolean;
  result?: ScanOutcome | null;
  onCodeRead?: (value: string, format?: ScanFormat) => void;
  onSearch?: (barcode?: string) => void;
  onCreate?: (barcode?: string) => void;
  onClose: () => void;
  galleryNoticeKey?: number;
}

const BarcodeScannerScreen: React.FC<Props> = ({
  visible = true,
  title,
  message,
  validate,
  result: pushedResult,
  onCodeRead,
  onClose,
}) => {
  const setResult = useScannerStore((s) => s.setResult);
  const [flashOn, setFlashOn] = useState(false);
  const [scannedValue, setScannedValue] = useState<string | null>(null);
  const [scannedFormat, setScannedFormat] = useState<ScanFormat>(null);
  const [zoom, setZoom] = useState(1);
  const [continuous, setContinuous] = useState(false);
  const [menuVisible, setMenuVisible] = useState(false);
  const [resetKey, setResetKey] = useState(0);

  // Single physical device on Android — CameraX binding an ImageAnalysis use
  // case to a logical/combo multi-camera is unreliable across OEMs.
  const device = useCameraDevice('back', Platform.OS === 'android'
    ? undefined
    : { physicalDevices: ['ultra-wide-angle-camera', 'wide-angle-camera', 'telephoto-camera'] });

  // 0.5x only exists if the device has an ultra-wide lens (minZoom < 1).
  const canZoomOut = (device?.minZoom ?? 1) < 1;
  const zoomOptions = canZoomOut ? [0.5, 1, 2] : [1, 2];

  const { toggle, off } = useTorch({ onStateChanged: setFlashOn });
  const offRef = useRef(off);
  offRef.current = off;

  // Torch must never survive leaving the foreground — some OEMs keep the
  // flash burning in the background unless you kill it explicitly.
  useEffect(() => {
    const sub = AppState.addEventListener('change', () => {
      setFlashOn(false);
      offRef.current();
    });
    return () => sub.remove();
  }, []);

  // Park a scan → kill the torch too; nothing left to light up.
  useEffect(() => {
    if (scannedValue != null) {
      setFlashOn(false);
      offRef.current();
    }
  }, [scannedValue]);

  const cameraActive = visible && (continuous || scannedValue == null);

  const handleScanned = (value: string, format?: ScanFormat) => {
    setResult(null);
    setScannedValue(value);
    setScannedFormat(format ?? null);
    if (validate && !validate(value)) {
      // Wrong kind of code: show "Invalid QR code", park the camera, and do
      // NOT resolve the open() promise — the bad value never leaks upward.
      setResult({ state: 'invalid' });
      return;
    }
    if (onCodeRead) onCodeRead(value, format);
  };

  const handleScanAgain = () => {
    setScannedValue(null);
    setScannedFormat(null);
    setResetKey((k) => k + 1);
    setResult(null);
  };

  return (
    <View style={styles.screen}>
      <CameraPreview
        device={device}
        onCodeScanned={handleScanned}
        isActive={cameraActive}
        zoom={zoom}
        continuous={continuous}
        resetKey={resetKey}
      />

      <ScannerTopBar
        title={title}
        onClose={onClose}
        flashOn={flashOn}
        onToggleFlash={() => toggle()}
        onMore={() => setMenuVisible((v) => !v)}
        onPickFromGallery={() => {}} // wire your ImagePicker here
      />

      {message && cameraActive && (
        <View style={styles.messageWrap} pointerEvents="none">
          <Text style={styles.messageText}>{message}</Text>
        </View>
      )}

      <ScannerMenu
        visible={menuVisible}
        continuous={continuous}
        onToggleContinuous={() => { setContinuous((c) => !c); setMenuVisible(false); }}
        onClose={() => setMenuVisible(false)}
      />

      {cameraActive && (
        <ZoomControl value={zoom} options={zoomOptions} onChange={setZoom} />
      )}

      {pushedResult != null ? (
        <ResultOverlay outcome={pushedResult} onScanAgain={handleScanAgain} onClose={onClose} />
      ) : (
        !onCodeRead &&
        scannedValue != null && (
          <ScanResultChip
            value={scannedValue}
            onClose={onClose}
            onScanAgain={handleScanAgain}
            onDone={() => useScannerStore.getState().close(scannedValue)}
          />
        )
      )}
    </View>
  );
};

const styles = StyleSheet.create({
  screen: { flex: 1, backgroundColor: '#1C1C1C' },
  messageWrap: { position: 'absolute', left: 20, right: 20, top: '40%', alignItems: 'center' },
  messageText: {
    color: '#FFF', fontSize: 16, fontWeight: '600', textAlign: 'center',
    paddingHorizontal: 20, paddingVertical: 12,
    backgroundColor: 'rgba(0,0,0,0.55)', borderRadius: 12, overflow: 'hidden',
  },
});

export default BarcodeScannerScreen;

Step 4: Two scanning paths, one funnel

This is the core of the whole implementation, and it splits by platform for a reason that isn't obvious from the API surface. iOS uses the ML Kit frame-processor worklet. Android uses VisionCamera's native CodeScanner (CameraX) instead, because on a lot of Android OEM hardware the frame-processor stream arrives out of focus — the full autodetect path on Android just isn't trustworthy the way it is on iOS.

To cover the hardware where even that isn't enough, there's a still-photo safety net on Android: snap and decode roughly every 900ms. That path was proven to decode on the specific problem hardware that motivated it. A frame gate on top of both paths ensures only codes inside the drawn scan box actually count as a read.

import React, { useCallback, useEffect, useRef } from 'react';
import { Linking, Platform, StyleSheet, Text, TouchableOpacity, View } from 'react-native';
import {
  Camera, useCameraFormat, useCameraPermission, useCodeScanner, useFrameProcessor,
} from 'react-native-vision-camera';
import type { CameraDevice, Code, CodeType } from 'react-native-vision-camera';
import { useBarcodeScanner } from 'react-native-vision-camera-barcodes-scanner';
import MlKitBarcodeScanning from '@react-native-ml-kit/barcode-scanning';
import { useRunOnJS } from 'react-native-worklets-core';
import ScanFrame from './ScanFrame';
import { ScanFormat } from './scannerStore';

interface Props {
  device?: CameraDevice;
  onCodeScanned?: (value: string, format?: ScanFormat) => void;
  isActive?: boolean;
  zoom?: number;
  continuous?: boolean;
  resetKey?: number;
}

const FRAME_CONFIG = { widthPercent: 0.92, heightPercent: 0.45 };

const NATIVE_CODE_TYPES: CodeType[] = [
  'aztec', 'code-128', 'code-39', 'code-93', 'codabar', 'data-matrix',
  'ean-13', 'ean-8', 'itf', 'pdf-417', 'qr', 'upc-a', 'upc-e',
];

const CameraPreview: React.FC<Props> = ({
  device, onCodeScanned, isActive = true, zoom = 1, continuous = false, resetKey = 0,
}) => {
  const { hasPermission, requestPermission } = useCameraPermission();
  const cameraRef = useRef<Camera>(null);
  const handledCodeRef = useRef(false);
  const lastDeliveredRef = useRef<string | null>(null);
  const layoutRef = useRef({ width: 0, height: 0 });
  const frameBoxRef = useRef({ x: 0, y: 0, width: 0, height: 0 });
  const previewOriginRef = useRef({ x: 0, y: 0 });
  const previewNodeRef = useRef<View | null>(null);
  const onCodeScannedRef = useRef(onCodeScanned);

  const absZoom = device
    ? Math.min(Math.max(zoom, device.minZoom), device.maxZoom)
    : zoom;

  // Android: without an explicit format the analysis stream lands at 640x480,
  // far too coarse for ML Kit to resolve a QR at normal distance.
  const format = useCameraFormat(device, [
    { videoResolution: { width: 1920, height: 1080 } },
    { fps: 30 },
  ]);

  // Android-only focus pulse: some CameraX chipsets deliver out-of-focus
  // ImageAnalysis frames until an explicit focus() call is fired.
  useEffect(() => {
    if (Platform.OS !== 'android' || !isActive) return;
    const pulse = () => {
      const { width, height } = layoutRef.current;
      if (width > 0 && height > 0)
        cameraRef.current?.focus({ x: width / 2, y: height / 2 }).catch(() => {});
    };
    const initial = setTimeout(pulse, 400);
    const interval = setInterval(pulse, 2000);
    return () => { clearTimeout(initial); clearInterval(interval); };
  }, [isActive]);

  useEffect(() => {
    if (isActive && !continuous) handledCodeRef.current = false;
    if (!isActive) lastDeliveredRef.current = null;
  }, [isActive, continuous]);

  useEffect(() => {
    if (resetKey > 0) { handledCodeRef.current = false; lastDeliveredRef.current = null; }
  }, [resetKey]);

  const onCameraLayout = useCallback((e: any) => {
    const { width, height } = e.nativeEvent.layout;
    layoutRef.current = { width, height };
    previewNodeRef.current?.measureInWindow?.((x, y) => {
      previewOriginRef.current = { x, y };
    });
  }, []);

  const onFrameBox = useCallback((box: { x: number; y: number; width: number; height: number }) => {
    const o = previewOriginRef.current;
    frameBoxRef.current = { x: box.x - o.x, y: box.y - o.y, width: box.width, height: box.height };
  }, []);

  // JS-side delivery: single-shot latch in normal mode, dedupe in continuous mode.
  const onBarcodesDetectedJS = useCallback(
    (barcodes: any[]) => {
      if (!barcodes.length) return;
      const barcode = barcodes[0];
      const value = barcode?.rawValue;
      if (!value) return;
      if (continuous) {
        if (value === lastDeliveredRef.current) return;
        lastDeliveredRef.current = value;
      } else {
        if (handledCodeRef.current) return;
        handledCodeRef.current = true;
      }
      onCodeScannedRef.current?.(value, barcode?.format);
    },
    [continuous],
  );
  const onBarcodesJS = useRunOnJS(onBarcodesDetectedJS, [onBarcodesDetectedJS]);

  // Native CodeScanner path (Android): bounds are already dp-relative to the
  // preview, so the frame gate compares directly.
  const handleNativeCodeScan = useCallback(
    (codes: Code[]) => {
      if (!isActive) return;
      const box = frameBoxRef.current;
      for (const code of codes) {
        if (!code?.value) continue;
        if (box.width > 0 && box.height > 0 && code.frame) {
          const cx = code.frame.x + code.frame.width / 2;
          const cy = code.frame.y + code.frame.height / 2;
          if (cx < box.x || cx > box.x + box.width || cy < box.y || cy > box.y + box.height) continue;
        }
        onBarcodesDetectedJS([{ rawValue: code.value, format: code.type }]);
        return;
      }
    },
    [isActive, onBarcodesDetectedJS],
  );

  const codeScanner = useCodeScanner({
    codeTypes: NATIVE_CODE_TYPES,
    onCodeScanned: handleNativeCodeScan,
  });

  const { scanBarcodes } = useBarcodeScanner([
    'aztec', 'code_128', 'code_39', 'code_93', 'codabar', 'data_matrix',
    'ean_13', 'ean_8', 'itf', 'pdf_417', 'qr', 'upc_a', 'upc_e',
  ]);

  // iOS worklet path, with a coordinate gate that inverts the aspect-fill
  // transform so barcode coordinates line up with the drawn scan box.
  const frameProcessor = useFrameProcessor(
    (frame: any) => {
      'worklet';
      let barcodes: any[] = [];
      try { barcodes = scanBarcodes(frame); } catch { return; }
      if (!barcodes.length) return;
      const barcode = barcodes[0];
      if (!barcode?.rawValue) return;

      const viewW = layoutRef.current.width, viewH = layoutRef.current.height;
      const rawW = frame.width, rawH = frame.height;
      if (!(viewW > 0 && viewH > 0 && rawW > 0 && rawH > 0)) return;

      let fbX = frameBoxRef.current.x, fbY = frameBoxRef.current.y;
      let fbW = frameBoxRef.current.width, fbH = frameBoxRef.current.height;
      if (!(fbW > 0 && fbH > 0)) {
        fbW = viewW * FRAME_CONFIG.widthPercent;
        fbH = viewH * FRAME_CONFIG.heightPercent;
        fbX = (viewW - fbW) / 2; fbY = (viewH - fbH) / 2;
      }

      const bcx = barcode.left + (barcode.width || 0) / 2;
      const bcy = barcode.top + (barcode.height || 0) / 2;

      // Portrait content space = rotated raw buffer.
      const contentW = rawH, contentH = rawW;
      const scale = Math.max(viewW / contentW, viewH / contentH);
      const scaledW = contentW * scale, scaledH = contentH * scale;
      const offX = (scaledW - viewW) / 2, offY = (scaledH - viewH) / 2;
      const invA = 1 / scale;

      // iOS coordinates live in raw space — rotate into upright content space.
      let checkCx = bcx, checkCy = bcy;
      if (Platform.OS === 'ios') {
        const o = frame.orientation;
        if (o === 'portrait') { checkCx = bcx; checkCy = bcy; }
        else if (o === 'portrait-upside-down') { checkCx = rawW - bcx; checkCy = rawH - bcy; }
        else if (o === 'landscape-left') { checkCx = bcy; checkCy = rawW - bcx; }
        else { checkCx = rawH - bcy; checkCy = bcx; }
      }

      const corners = [
        [fbX, fbY], [fbX + fbW, fbY], [fbX, fbY + fbH], [fbX + fbW, fbY + fbH],
      ];
      let rMinX = Infinity, rMaxX = -Infinity, rMinY = Infinity, rMaxY = -Infinity;
      for (const [sx, sy] of corners) {
        const rx = (sx + offX) * invA, ry = (sy + offY) * invA;
        if (rx < rMinX) rMinX = rx; if (rx > rMaxX) rMaxX = rx;
        if (ry < rMinY) rMinY = ry; if (ry > rMaxY) rMaxY = ry;
      }
      const inFrame =
        checkCx >= rMinX && checkCx <= rMaxX &&
        checkCy >= rMinY && checkCy <= rMaxY;
      if (!inFrame) return;

      onBarcodesJS(barcodes);
    },
    [],
  );

  // Android safety net: still-photo backstop for hardware the frame
  // processor never focuses correctly.
  const stillScanBusyRef = useRef(false);
  useEffect(() => {
    if (Platform.OS !== 'android' || !isActive) return;
    const interval = setInterval(async () => {
      if (stillScanBusyRef.current) return;
      stillScanBusyRef.current = true;
      try {
        const photo = await cameraRef.current?.takePhoto();
        if (!photo) return;
        const results = await MlKitBarcodeScanning.scan(`file://${photo.path}`);
        if (results.length > 0) {
          onBarcodesDetectedJS(
            results.map((r) => ({ rawValue: r.value, format: r.format })),
          );
        }
      } catch { /* frame just missed */ } finally {
        stillScanBusyRef.current = false;
      }
    }, 900);
    return () => clearInterval(interval);
  }, [isActive, onBarcodesDetectedJS]);

  if (!hasPermission) {
    return (
      <View style={styles.preview}>
        <Text style={styles.message}>Camera permission is required to scan.</Text>
        <TouchableOpacity style={styles.button} onPress={requestPermission}>
          <Text style={styles.buttonText}>Allow Camera</Text>
        </TouchableOpacity>
        <TouchableOpacity style={styles.link} onPress={() =>
          Platform.OS === 'ios' ? Linking.openURL('app-settings:') : Linking.openSettings()}>
          <Text style={styles.linkText}>Open Settings</Text>
        </TouchableOpacity>
      </View>
    );
  }
  if (!device) {
    return (
      <View style={styles.preview}>
        <Text style={styles.message}>No camera device available.</Text>
      </View>
    );
  }

  return (
    <View
      ref={(node) => { previewNodeRef.current = node; }}
      style={styles.preview}
      onLayout={onCameraLayout}
      collapsable={false}
      pointerEvents="box-none"
    >
      <Camera
        ref={cameraRef}
        style={StyleSheet.absoluteFill}
        device={device}
        format={Platform.OS === 'android' ? format : undefined}
        isActive={isActive}
        zoom={absZoom}
        enableZoomGesture={false}
        codeScanner={Platform.OS === 'android' ? codeScanner : undefined}
        frameProcessor={Platform.OS === 'android' ? undefined : frameProcessor}
        photo={Platform.OS === 'android'}
        pixelFormat="yuv"
        onError={(e) => console.warn('[camera]', e.message)}
      />

      <View style={styles.scanFrameWrap} pointerEvents="none">
        <ScanFrame
          instructionText="Position barcode or QR code inside the frame"
          config={FRAME_CONFIG}
          onFrameBox={onFrameBox}
        />
      </View>
    </View>
  );
};

const styles = StyleSheet.create({
  preview: { ...StyleSheet.absoluteFillObject, backgroundColor: '#1C1C1C', alignItems: 'center', justifyContent: 'center', overflow: 'hidden' },
  message: { color: 'rgba(255,255,255,0.85)', fontSize: 15, textAlign: 'center', marginBottom: 12 },
  button: { backgroundColor: '#4E2BA1', borderRadius: 10, paddingHorizontal: 20, paddingVertical: 12 },
  buttonText: { color: '#FFF', fontSize: 15, fontWeight: '600' },
  link: { paddingVertical: 8 },
  linkText: { color: '#7EB2FF', fontSize: 14, fontWeight: '600' },
  scanFrameWrap: { ...StyleSheet.absoluteFillObject },
});

export default CameraPreview;

Step 5: The scan frame

A self-contained overlay, no extra libraries. It measures its own on-screen box and reports it back so the camera gate compares against the exact same rectangle the user sees.

import React, { useCallback, useRef } from 'react';
import { StyleSheet, Text, View } from 'react-native';

interface Props {
  instructionText: string;
  config: { widthPercent: number; heightPercent: number };
  onFrameBox: (box: { x: number; y: number; width: number; height: number }) => void;
}

const ScanFrame: React.FC<Props> = ({ instructionText, config, onFrameBox }) => {
  const rootRef = useRef<View>(null);

  const onLayout = useCallback(() => {
    rootRef.current?.measureInWindow((x, y, w, h) => {
      onFrameBox({ x, y, width: w, height: h });
    });
  }, [onFrameBox]);

  return (
    <View ref={rootRef} style={styles.wrap} pointerEvents="none" onLayout={onLayout}>
      <View
        style={{
          width: `${config.widthPercent * 100}%`,
          height: `${config.heightPercent * 100}%`,
        }}
      >
        <View style={styles.frame} />
      </View>
      <Text style={styles.instructions}>{instructionText}</Text>
    </View>
  );
};

const styles = StyleSheet.create({
  wrap: { flex: 1, alignItems: 'center', justifyContent: 'center' },
  frame: {
    flex: 1,
    borderWidth: 2,
    borderColor: 'rgba(255,255,255,0.9)',
    borderRadius: 16,
    backgroundColor: 'rgba(0,0,0,0)',
  },
  instructions: {
    marginTop: 16, color: '#FFF', fontSize: 13, fontWeight: '500',
    textAlign: 'center', textShadowColor: 'rgba(0,0,0,0.8)', textShadowRadius: 4,
  },
});

export default ScanFrame;

A nicer touch, optional: dim everything outside the frame with react-native-hole-view, giving a flashlight-style cutout. The bordered frame above already communicates the target clearly enough without it.

Step 6: The top bar — six controls, one hard constraint

The reason this file needs care is 360dp-wide Android phones. Every pixel of width is spoken for, and the title will happily push the three-dot menu off the edge if you let it. The rule: the title may shrink, the buttons never clip, and below 380dp the whole row compacts.

import React from 'react';
import { StyleSheet, Text, TouchableOpacity, useWindowDimensions, View } from 'react-native';
import { useSafeAreaInsets } from 'react-native-safe-area-context';
import Ionicons from 'react-native-vector-icons/Ionicons';

interface Props {
  title?: string;
  onClose: () => void;
  flashOn: boolean;
  onToggleFlash: () => void;
  onMore: () => void;
  onPickFromGallery: () => void;
}

const BTN = 36;
const BTN_COMPACT = 32;

const RoundIconButton: React.FC<{
  onPress: () => void; size?: number; children: React.ReactNode;
}> = ({ onPress, size = BTN, children }) => (
  <TouchableOpacity
    onPress={onPress}
    activeOpacity={0.8}
    style={[styles.circleBtn, { width: size, height: size, borderRadius: size / 2 }]}
  >
    {children}
  </TouchableOpacity>
);

const ScannerTopBar: React.FC<Props> = ({
  title = 'Scan Code', onClose, flashOn, onToggleFlash, onMore, onPickFromGallery,
}) => {
  const insets = useSafeAreaInsets();
  const { width } = useWindowDimensions();
  const compact = width < 380;

  return (
    <View style={[styles.container, { paddingTop: insets.top + 8, paddingHorizontal: compact ? 10 : 16 }]}>
      <RoundIconButton onPress={onClose} size={compact ? BTN_COMPACT : BTN}>
        <Ionicons name="close" size={compact ? 18 : 20} color="#FFF" />
      </RoundIconButton>

      <View style={[styles.titlePill, compact && styles.titlePillCompact]}>
        <Text style={styles.titleText} numberOfLines={1} ellipsizeMode="tail">{title}</Text>
        {!compact && <Ionicons name="chevron-forward" size={13} color="rgba(255,255,255,0.7)" />}
      </View>

      <View style={[styles.rightGroup, compact && styles.rightGroupCompact]}>
        <RoundIconButton onPress={onPickFromGallery} size={compact ? BTN_COMPACT : BTN}>
          <Ionicons name="image-outline" size={compact ? 17 : 19} color="#FFF" />
        </RoundIconButton>
        <RoundIconButton onPress={onToggleFlash} size={compact ? BTN_COMPACT : BTN}>
          <Ionicons name={flashOn ? 'flash' : 'flash-off'} size={compact ? 17 : 19} color="#FFF" />
        </RoundIconButton>
        <RoundIconButton onPress={onMore} size={compact ? BTN_COMPACT : BTN}>
          <Ionicons name="ellipsis-horizontal" size={compact ? 18 : 20} color="#FFF" />
        </RoundIconButton>
      </View>
    </View>
  );
};

const styles = StyleSheet.create({
  container: {
    position: 'absolute', top: 0, left: 0, right: 0,
    flexDirection: 'row', alignItems: 'center', justifyContent: 'space-between',
  },
  circleBtn: {
    backgroundColor: 'rgba(25, 25, 25, 0.6)',
    alignItems: 'center', justifyContent: 'center',
  },
  titlePill: {
    flexDirection: 'row', alignItems: 'center', gap: 4,
    height: 32, paddingHorizontal: 14, borderRadius: 16,
    backgroundColor: 'rgba(25, 25, 25, 0.6)',
    flexShrink: 1, minWidth: 0, flexWrap: 'nowrap',
  },
  titlePillCompact: { height: 30, paddingHorizontal: 10, borderRadius: 15 },
  titleText: { color: '#FFF', fontSize: 13, fontWeight: '500', flexShrink: 1 },
  rightGroup: { flexDirection: 'row', gap: 8 },
  rightGroupCompact: { gap: 6 },
});

export default ScannerTopBar;

Step 7: The overflow menu and zoom pill

The three-dot menu is a backdrop plus a card anchored under the button, with a plain-View toggle for continuous scan mode — no switch library needed.

import React from 'react';
import { StyleSheet, Text, TouchableOpacity, View } from 'react-native';
import { useSafeAreaInsets } from 'react-native-safe-area-context';
import Ionicons from 'react-native-vector-icons/Ionicons';

interface Props {
  visible: boolean;
  continuous: boolean;
  onToggleContinuous: () => void;
  onClose: () => void;
}

const ScannerMenu: React.FC<Props> = ({ visible, continuous, onToggleContinuous, onClose }) => {
  const insets = useSafeAreaInsets();
  if (!visible) return null;

  return (
    <>
      <TouchableOpacity style={styles.backdrop} activeOpacity={1} onPress={onClose} />
      <View style={[styles.menu, { top: insets.top + 58 }]}>
        <TouchableOpacity style={styles.menuItem} activeOpacity={0.7} onPress={onToggleContinuous}>
          <View style={styles.menuItemLeft}>
            <Ionicons name="repeat" size={18} color="#FFF" />
            <Text style={styles.menuItemText}>Continuous scan</Text>
          </View>
          <View style={[styles.switch, continuous && styles.switchOn]}>
            <View style={[styles.switchKnob, continuous && styles.switchKnobOn]} />
          </View>
        </TouchableOpacity>
      </View>
    </>
  );
};

const styles = StyleSheet.create({
  backdrop: { ...StyleSheet.absoluteFillObject },
  menu: {
    position: 'absolute', right: 16, minWidth: 220,
    backgroundColor: 'rgba(28, 28, 36, 0.97)', borderRadius: 16, paddingVertical: 6,
    borderWidth: StyleSheet.hairlineWidth, borderColor: 'rgba(255,255,255,0.1)',
    shadowColor: '#000', shadowOpacity: 0.4, shadowRadius: 12, shadowOffset: { width: 0, height: 4 },
    elevation: 6,
  },
  menuItem: { flexDirection: 'row', alignItems: 'center', justifyContent: 'space-between', paddingHorizontal: 14, paddingVertical: 12 },
  menuItemLeft: { flexDirection: 'row', alignItems: 'center', gap: 10 },
  menuItemText: { color: '#FFF', fontSize: 14, fontWeight: '600' },
  switch: {
    width: 44, height: 26, borderRadius: 13, backgroundColor: 'rgba(255,255,255,0.2)',
    justifyContent: 'center', paddingHorizontal: 3,
  },
  switchOn: { backgroundColor: '#30D158' },
  switchKnob: { width: 20, height: 20, borderRadius: 10, backgroundColor: '#FFF' },
  switchKnobOn: { alignSelf: 'flex-end' },
});

export default ScannerMenu;

The zoom pill only shows 0.5x if the hardware reports an ultra-wide lens (device.minZoom < 1) and disappears automatically once a code is read, since it unmounts along with cameraActive.

import React from 'react';
import { StyleSheet, Text, TouchableOpacity, View } from 'react-native';
import { useSafeAreaInsets } from 'react-native-safe-area-context';

interface Props {
  value: number;
  options: number[];
  onChange: (zoom: number) => void;
}

const ZoomControl: React.FC<Props> = ({ value, options, onChange }) => {
  const insets = useSafeAreaInsets();
  return (
    <View style={[styles.wrap, { bottom: insets.bottom + 22 }]}>
      <View style={styles.pill}>
        {options.map((zoom) => {
          const selected = zoom === value;
          return (
            <TouchableOpacity key={zoom} onPress={() => onChange(zoom)}
              activeOpacity={0.8}
              style={[styles.option, selected && styles.optionSelected]}>
              <Text style={[styles.label, selected && styles.labelSelected]}>{zoom}x</Text>
            </TouchableOpacity>
          );
        })}
      </View>
    </View>
  );
};

const styles = StyleSheet.create({
  wrap: { position: 'absolute', left: 0, right: 0, alignItems: 'center' },
  pill: { flexDirection: 'row', borderRadius: 22, padding: 4, backgroundColor: 'rgba(25,25,25,0.6)' },
  option: { paddingHorizontal: 16, paddingVertical: 8, borderRadius: 18 },
  optionSelected: { backgroundColor: '#FFF' },
  label: { color: 'rgba(255,255,255,0.85)', fontSize: 13.5, fontWeight: '600' },
  labelSelected: { color: '#1C1C1C', fontWeight: '700' },
});

export default ZoomControl;

Step 8: Rendering the result

There are two modes. In the simple case, a raw-value chip shows with "Scan again" and "Done":

import React from 'react';
import { StyleSheet, Text, TouchableOpacity, View } from 'react-native';
import Ionicons from 'react-native-vector-icons/Ionicons';

interface Props {
  value: string;
  onClose: () => void;
  onScanAgain: () => void;
  onDone: () => void;
}

const ScanResultChip: React.FC<Props> = ({ value, onClose, onScanAgain, onDone }) => (
  <View style={styles.wrap}>
    <View style={styles.chip}>
      <Ionicons name="checkmark-circle" size={20} color="#30D158" />
      <Text style={styles.value} numberOfLines={2} ellipsizeMode="middle">{value}</Text>
      <TouchableOpacity onPress={onClose} style={styles.iconBtn}>
        <Ionicons name="close" size={18} color="#FFF" />
      </TouchableOpacity>
      <TouchableOpacity onPress={onScanAgain} style={styles.action}>
        <Ionicons name="refresh" size={16} color="#FFF" />
        <Text style={styles.actionText}>Scan again</Text>
      </TouchableOpacity>
      <TouchableOpacity onPress={onDone} style={[styles.action, styles.primary]}>
        <Text style={styles.actionText}>Done</Text>
      </TouchableOpacity>
    </View>
  </View>
);

const styles = StyleSheet.create({
  wrap: { position: 'absolute', left: 12, right: 12, bottom: 40, alignItems: 'center' },
  chip: {
    flexDirection: 'row', alignItems: 'center', gap: 10,
    backgroundColor: 'rgba(28,28,36,0.97)', borderRadius: 999,
    paddingHorizontal: 16, paddingVertical: 10,
    borderWidth: StyleSheet.hairlineWidth, borderColor: 'rgba(255,255,255,0.1)',
  },
  value: { color: '#FFF', fontSize: 13, flexShrink: 1, maxWidth: 160 },
  iconBtn: { padding: 2 },
  action: { flexDirection: 'row', alignItems: 'center', gap: 4, paddingHorizontal: 8, paddingVertical: 4, borderRadius: 12 },
  primary: { backgroundColor: 'rgba(255,255,255,0.15)' },
  actionText: { color: '#FFF', fontSize: 13, fontWeight: '600' },
});

export default ScanResultChip;

When the caller wants to drive the flow itself — looking up a product before deciding what to show — it pushes a typed outcome instead, and a bottom sheet renders it:

// ResultSheet.tsx — a generic bottom sheet; the chip drives the header.
import React from 'react';
import { StyleSheet, Text, View } from 'react-native';
import { ScanOutcome } from './scannerStore';

const META: Record<string, { title: string; message: string }> = {
  invalid: { title: 'Invalid QR code', message: 'This QR code is not valid here. Please scan the correct code.' },
  qrCodeNotFound: { title: 'QR code not found', message: 'This QR code could not be read.\nPlease try again.' },
  error: { title: 'Something went wrong', message: 'An error occurred while processing the scan.\nPlease try again.' },
  productFound: { title: 'Product found', message: '' },
  unknownBarcode: { title: 'Product not found', message: 'No matching product for this barcode.' },
};

const ResultSheet: React.FC<{ outcome: ScanOutcome }> = ({ outcome }) => (
  <View style={styles.sheet}>
    <Text style={styles.title}>{META[outcome.state]?.title ?? 'Scan'}</Text>
    {!!META[outcome.state]?.message && (
      <Text style={styles.message}>{META[outcome.state].message}</Text>
    )}
    {!!outcome.barcode && <Text style={styles.barcode}>{outcome.barcode}</Text>}
  </View>
);

const styles = StyleSheet.create({
  sheet: {
    backgroundColor: 'rgba(28,28,36,0.97)', borderRadius: 20, padding: 20,
    borderWidth: StyleSheet.hairlineWidth, borderColor: 'rgba(255,255,255,0.1)',
  },
  title: { color: '#FFF', fontSize: 17, fontWeight: '700', marginBottom: 6 },
  message: { color: 'rgba(255,255,255,0.75)', fontSize: 14, lineHeight: 20 },
  barcode: { color: '#7EB2FF', fontSize: 13, marginTop: 10 },
});

export default ResultSheet;

// ResultOverlay.tsx — routes an outcome to chip + sheet.
import React from 'react';
import { StyleSheet, Text, View } from 'react-native';
import ResultSheet from './ResultSheet';
import { ScanOutcome } from './scannerStore';

interface Props {
  outcome: ScanOutcome;
  onScanAgain: () => void;
  onClose: () => void;
}

const ResultOverlay: React.FC<Props> = ({ outcome, onScanAgain, onClose }) => {
  const isInvalid = outcome.state === 'invalid';
  return (
    <View style={styles.wrap}>
      {!isInvalid && (
        <View style={styles.actions}>
          <Text style={styles.link} onPress={onScanAgain}>Scan again</Text>
          <Text style={styles.link} onPress={onClose}>Close</Text>
        </View>
      )}
      <ResultSheet outcome={outcome} />
    </View>
  );
};

const styles = StyleSheet.create({
  wrap: { position: 'absolute', left: 12, right: 12, bottom: 40 },
  actions: { flexDirection: 'row', justifyContent: 'space-between', paddingBottom: 10 },
  link: { color: '#7EB2FF', fontSize: 14, fontWeight: '600' },
});

export default ResultOverlay;

Using it

A plain scan that resolves to a string:

import { QRBarcodeScanner } from './scannerStore';

const value = await QRBarcodeScanner.open({ title: 'Scan Product QR' });
if (value) navigation.navigate('Detail', { id: value });

Validation inside the scanner, so a wrong-kind code shows "Invalid QR code" and never reaches the caller at all, structurally:

const value = await QRBarcodeScanner.open({
  title: 'Scan Login QR',
  validate: (raw) => {
    const parsed = JSON.parse(raw); // must be a login config JSON
    return !!parsed?.issuer && !!parsed?.clientId;
  },
});
if (value) loginWithConfig(value);

Caller-driven, where the scanner stays open while a lookup happens and the outcome is pushed back in:

QRBarcodeScanner.open({
  title: 'Scan Product QR',
  onCodeRead: (value) => {
    const product = findProduct(value);
    if (product) {
      QRBarcodeScanner.setResult({ state: 'productFound', barcode: value, product });
    } else {
      QRBarcodeScanner.setResult({ state: 'unknownBarcode', barcode: value });
    }
  },
});

The gotchas worth their own paragraph

Torch vs. background. Force the torch off on every AppState change, not only when the app returns to the foreground. Some Android OEMs leave the flash burning in the background otherwise.

codeScanner and frameProcessor are mutually exclusive on Android, since both create an ImageAnalysis use case under the hood. Pick exactly one, branched by Platform.OS.

Android frame-processor focus. Some chipsets hand the frame processor out-of-focus frames even while the preview itself looks sharp. The native CodeScanner plus the 900ms still-photo backstop are the two fixes this relies on — the still-photo path was proven to decode on the hardware that originally motivated it.

Behind another modal. If any screen owns its own <Modal>, a second root-level modal renders behind it, not on top. Keep the one-modal-at-root rule, and add the small presenter-stack from Step 2 for the screens that break it.

Re-entrancy. open() called while the scanner is already visible has to return "cancelled," not wipe result, options, or resolve out from under the current session — otherwise something like an auto-open on app resume can silently erase a result the user hasn't seen yet.

Before calling it done

Cold launch — the scanner opens on the first try on both platforms.
A valid code parks the camera; Done resolves the promise.
A wrong-kind code shows "Invalid QR code" and parks; Scan again re-arms it.
A parked result survives backgrounding and returning to the app.
Torch turns off immediately on backgrounding.
On a 360dp Android device, close, gallery, flash, and the overflow menu are all fully tappable, and the title truncates instead of pushing them off-screen.
Codes outside the drawn frame are ignored.
Ten-plus scans in a row on Android produce no dead frames.

None of the individual pieces here are exotic — a store, a modal, a camera view, a frame gate. What makes a scanner like this hard to get right is that it has to behave identically across two camera stacks that don't agree on what "in focus" means, and the fixes for that only show up once you've tested on the actual hardware that breaks. Copy the files in order, wire QRBarcodeScanner.open() to a button, and it holds up the same on a 360dp Android phone as it does on a Pro Max.

Hotel Indradhar — Hotel in Dharamshala

PEAKIQ — Thu, 17 Sep 2026 09:03:57 +0000

Originally published on PEAKIQ

Source: https://www.peakiq.in/showcase/hotel-indradhar-hotel-in-dharamshala

Hotel Indradhar — A Modern Digital Gateway to Dharamshala

Hotel Indradhar, nestled in the picturesque hills of Dharamshala, sought to elevate its digital presence with a website that truly reflected its modern comforts, breathtaking Dhauladhar mountain views, and unique guest experiences. PeakIQ partnered with Hotel Indradhar to craft a compelling online platform, transforming their digital footprint into an inviting portal for prospective guests.

The Challenge

The hospitality sector thrives on visibility and a seamless booking experience. Hotel Indradhar needed a website that was not only aesthetically pleasing but also highly functional, easy to navigate, and optimized for search engines to attract a wider audience. The key challenges included:

Outdated Online Presence: A previous website lacked modern design, mobile responsiveness, and effective content management.
Showcasing Unique Selling Points: The need to prominently feature their diverse room options, amenities, and the stunning natural beauty of Dharamshala.
Improving Guest Engagement: Creating a platform that encouraged exploration, direct inquiries, and bookings.
Search Engine Visibility: Ensuring the website ranked well for relevant keywords to drive organic traffic.

PeakIQ's Solution

PeakIQ delivered a comprehensive web solution, encompassing design, development, and search engine optimization, tailored specifically for Hotel Indradhar's needs. Our approach focused on creating a user-centric experience combined with robust backend functionality.

Intuitive Design & User Experience: A clean, modern, and visually rich design was implemented, prioritizing easy navigation and showcasing the hotel's elegance and location.
Responsive Web Development: Built with a mobile-first approach, ensuring a flawless experience across all devices, from desktops to smartphones.
Dynamic Room & Gallery Management: Developed custom modules to allow Hotel Indradhar to easily upload, manage, and display high-quality images and details for each room type and amenity.
Local SEO Optimization: Implemented targeted SEO strategies to improve visibility for searches related to "Hotel in Dharamshala" and other relevant local keywords, driving qualified traffic.
Robust Content Management System (CMS): Empowered the hotel staff with an easy-to-use CMS to update content, room details, special offers, and gallery images without technical assistance.

Key Features & Implementation Highlights

Visually Engaging Galleries: High-resolution photo galleries for rooms, amenities, and surrounding landscapes.
Detailed Room Pages: Dedicated pages for each room type with comprehensive descriptions, features, and pricing information.
Amenities & Services Showcase: Clear presentation of all hotel amenities, from dining options to recreational facilities.
Location & Attractions Guide: Integrated maps and information on nearby attractions, emphasizing the beauty of the Dhauladhar range.
Direct Contact & Inquiry Forms: Streamlined processes for guest inquiries and direct booking requests.
Blog/News Section: A platform for sharing updates, local events, and travel tips to engage visitors.

Outcomes & Impact

The collaboration with PeakIQ resulted in a significant transformation for Hotel Indradhar's online presence, yielding tangible benefits:

Enhanced Online Presence: A sophisticated and modern website that accurately reflects the quality and ambiance of Hotel Indradhar.
Improved User Engagement: Visitors spend more time exploring the site, leading to higher conversion rates for inquiries and bookings.
Increased Organic Traffic: Strategic SEO efforts led to a measurable increase in search engine rankings and organic visitor acquisition.
Streamlined Content Management: The intuitive CMS empowers the Hotel Indradhar team to keep the website fresh and up-to-date with minimal effort.
Better Guest Experience: A user-friendly interface allows prospective guests to easily find all necessary information, fostering trust and encouraging reservations.

Delivery Notes

PeakIQ's iterative development process ensured close collaboration with the Hotel Indradhar team at every stage. From initial design mock-ups to final deployment and post-launch support, our focus remained on delivering a solution that was not only visually appealing but also strategically aligned with the hotel's business goals. The project was completed on time, demonstrating PeakIQ's commitment to quality and client satisfaction.

Explore the Website

Discover the elegant digital experience we crafted for Hotel Indradhar: Visit Hotel Indradhar

React Native: Prevent Screenshots on Android & Blur on iOS

PEAKIQ — Tue, 11 Aug 2026 08:02:03 +0000

Originally published on PEAKIQ

Source: https://www.peakiq.in/blog/prevent-screenshots-on-android-blur-on-ios

Sensitive screens leak in ways that have nothing to do with your backend. A user screenshots their balance to send to a friend, forgets about it, and it sits in their camera roll indefinitely. The phone gets lost or stolen. The screenshot ends up in a cloud backup nobody audited. None of that is a server breach, but it's still a data leak — and for regulated apps, still your liability.

The two platforms aren't symmetric here. Android can block a screenshot at the OS level, full stop — the capture fails, no image is produced. iOS gives apps no such API; the system reads the screen buffer directly and nothing running in the app can intercept that. The best available approach there is detection plus proactively blurring content the instant the app leaves the foreground, since that's the same moment both a screenshot and the App Switcher preview get taken.

We recently added this to a React Native app for a client in banking, where the account and payment screens needed to be genuinely screenshot-proof on Android and, at minimum, blurred out of the App Switcher and camera roll on iOS. Below is how the whole thing fits together — the Android native module, the iOS native module, the JS layer that ties them into one hook, and the navigator-level fix for the gap that isn't obvious until you test it on a real stack.

Step 1: Add the Android Native Module

This lives under android/app/src/main/java/.../screenshotprotection in the RN app's native Android project — nothing to add from the JS side yet.

Create ScreenshotProtectionModule.kt. This is the module that toggles FLAG_SECURE on the current Activity's window.
Create ScreenshotProtectionPackage.kt to register the module with React Native's package list.
Add the package to MainApplication.kt's getPackages() override.

// ScreenshotProtectionModule.kt
package com.yourapp.screenshotprotection

import android.view.WindowManager
import com.facebook.react.bridge.ReactApplicationContext
import com.facebook.react.bridge.ReactContextBaseJavaModule
import com.facebook.react.bridge.ReactMethod
import com.facebook.react.bridge.Promise

class ScreenshotProtectionModule(reactContext: ReactApplicationContext) :
    ReactContextBaseJavaModule(reactContext) {

    override fun getName() = "ScreenshotProtection"

    @ReactMethod
    fun enable(promise: Promise) {
        currentActivity?.runOnUiThread {
            currentActivity?.window?.setFlags(
                WindowManager.LayoutParams.FLAG_SECURE,
                WindowManager.LayoutParams.FLAG_SECURE
            )
            promise.resolve(true)
        } ?: promise.reject("NO_ACTIVITY", "No current activity")
    }

    @ReactMethod
    fun disable(promise: Promise) {
        currentActivity?.runOnUiThread {
            currentActivity?.window?.clearFlags(WindowManager.LayoutParams.FLAG_SECURE)
            promise.resolve(true)
        } ?: promise.reject("NO_ACTIVITY", "No current activity")
    }
}

// ScreenshotProtectionPackage.kt
package com.yourapp.screenshotprotection

import com.facebook.react.ReactPackage
import com.facebook.react.bridge.NativeModule
import com.facebook.react.bridge.ReactApplicationContext
import com.facebook.react.uimanager.ViewManager

class ScreenshotProtectionPackage : ReactPackage {
    override fun createNativeModules(reactContext: ReactApplicationContext): List<NativeModule> =
        listOf(ScreenshotProtectionModule(reactContext))

    override fun createViewManagers(reactContext: ReactApplicationContext): List<ViewManager<*, *>> =
        emptyList()
}

FLAG_SECURE is set on the whole Activity window, not a single React view — on Android this is really "protect this window for as long as the flag is on," which is why the JS layer in Step 4 has to be careful about exactly when it toggles.

Step 2: Add the iOS Native Module

iOS can't block the capture, but it can react to it. This module does two things: hides content the instant the app resigns active state (covers both an actual screenshot and the App Switcher preview), and emits an event to JS when a screenshot notification actually fires, so the app can log it or warn the user.

In Xcode, add ScreenshotProtection.swift and ScreenshotProtection.m to the main app target — this is a small native module, not a widget extension, so no new target is needed.
Bridge it to React Native with the RCT_EXTERN_MODULE macro.

// ScreenshotProtection.swift
import UIKit

@objc(ScreenshotProtection)
class ScreenshotProtection: RCTEventEmitter {

  private var overlay: UIView?

  override func supportedEvents() -> [String]! {
    return ["onScreenshotTaken"]
  }

  override init() {
    super.init()
    NotificationCenter.default.addObserver(
      self, selector: #selector(screenshotTaken),
      name: UIApplication.userDidTakeScreenshotNotification, object: nil
    )
    NotificationCenter.default.addObserver(
      self, selector: #selector(addBlur),
      name: UIApplication.willResignActiveNotification, object: nil
    )
    NotificationCenter.default.addObserver(
      self, selector: #selector(removeBlur),
      name: UIApplication.didBecomeActiveNotification, object: nil
    )
  }

  @objc func screenshotTaken() {
    sendEvent(withName: "onScreenshotTaken", body: nil)
  }

  @objc func addBlur() {
    guard let window = UIApplication.shared.windows.first, overlay == nil else { return }
    let blur = UIVisualEffectView(effect: UIBlurEffect(style: .systemMaterialDark))
    blur.frame = window.bounds
    blur.tag = 9999
    window.addSubview(blur)
    overlay = blur
  }

  @objc func removeBlur() {
    overlay?.removeFromSuperview()
    overlay = nil
  }

  @objc override static func requiresMainQueueSetup() -> Bool { true }
}

// ScreenshotProtection.m
#import <React/RCTBridgeModule.h>
#import <React/RCTEventEmitter.h>

@interface RCT_EXTERN_MODULE(ScreenshotProtection, RCTEventEmitter)
RCT_EXTERN_METHOD(supportedEvents)
@end

The willResignActiveNotification / didBecomeActiveNotification pair fires for the App Switcher, incoming calls, Control Center — anything that suspends the app, not just screenshots. That's deliberate: it's the same moment iOS renders the App Switcher preview, so one hook covers both leaks.

Step 3: A Ref-Counted Manager, Not a Bare Toggle

A naive "enable on mount, disable on unmount" hook breaks the moment two protected screens overlap — a protected modal opening over a protected screen turns protection off the instant the modal closes, even though the screen underneath still needs it. Tying it to a specific navigation library's focus/blur events also couples this small utility to whatever nav stack happens to be in use today.

The more robust option is a singleton with reference counting, driven only by mount/unmount:

// SecureScreenManager.js
import { NativeModules, Platform } from 'react-native';

const { ScreenshotProtection } = NativeModules;

class SecureScreenManager {
  activeCount = 0;

  acquire() {
    this.activeCount++;
    if (Platform.OS === 'android' && this.activeCount === 1) {
      ScreenshotProtection.enable();
    }
  }

  release() {
    this.activeCount = Math.max(0, this.activeCount - 1);
    if (Platform.OS === 'android' && this.activeCount === 0) {
      ScreenshotProtection.disable();
    }
  }
}

export const secureScreenManager = new SecureScreenManager();

// useScreenshotProtection.js
import { useEffect } from 'react';
import { NativeModules, NativeEventEmitter, Platform } from 'react-native';
import { secureScreenManager } from './SecureScreenManager';

const { ScreenshotProtection } = NativeModules;
const emitter =
  Platform.OS === 'ios' ? new NativeEventEmitter(ScreenshotProtection) : null;

export function useScreenshotProtection(onScreenshot) {
  useEffect(() => {
    secureScreenManager.acquire();

    // iOS: blur is handled natively; we just wire up the callback
    const sub = emitter?.addListener('onScreenshotTaken', () => {
      onScreenshot?.();
    });

    return () => {
      secureScreenManager.release();
      sub?.remove();
    };
  }, [onScreenshot]);
}

The count only reaches zero once every protected component currently mounted has released, so nested or overlapping protected screens no longer disable each other prematurely.

Step 4: Close the Stack Navigator Gap

Reference counting fixes overlap, but it still assumes mount tracks visibility — which isn't true by default in a stack navigator. A screen pushed underneath another one usually stays mounted, so pushing an unprotected screen on top of a protected one doesn't release the count, and FLAG_SECURE stays on for the whole stack rather than the one screen that needed it.

Fix this at the navigator config, not in the hook, so it holds regardless of which navigation library the app uses:

React Navigation: set unmountOnBlur: true in the sensitive screen's options.
Expo Router: present the sensitive route as "modal" — modals unmount on dismiss.

Either way, "mounted" and "visible" stay the same thing for protected screens, which is what the manager in Step 3 actually needs to be correct.

Usage on a screen, once everything is wired up:

function AccountDetailsScreen() {
  useScreenshotProtection(() => {
    console.warn('Screenshot detected on AccountDetailsScreen');
  });

  return (
    <View>
      <Text>Account: •••• 4821</Text>
      <Text>Balance: $12,480.00</Text>
    </View>
  );
}

The Real Lesson Here

None of the individual pieces here are complicated — a native flag, a notification observer, a ref count, a navigator option. What makes this easy to get subtly wrong is that "protected" and "visible" look like the same concept until you actually push a second screen on top and check whether the flag turned off. Test each transition independently: opening the screen directly, opening it under a modal, and navigating away from it inside a stack.

If you're adding this to your own app, this is the order that avoids backtracking:

Add the Android native module and register the package.
Add the iOS native module and bridge it with RCT_EXTERN_MODULE.
Build the ref-counted manager instead of a bare mount/unmount toggle.
Set unmountOnBlur (or present as a modal) on every sensitive screen.
Test on physical devices only — the iOS simulator doesn't reproduce screenshot notifications or the App Switcher snapshot, and testing there alone gives false confidence.

What this doesn't cover: a second phone photographing the screen, or screen recording software outside iOS's own capture APIs — no software fix exists for either. Treat this as raising the cost of casual leaks, not as a hard security boundary, and keep the most sensitive fields (full card numbers, SSNs) off screen entirely where the flow allows it.

React Native iOS Control Center Widget with Deep Linking

PEAKIQ — Sun, 26 Jul 2026 04:06:26 +0000

Originally published on PEAKIQ

Source: https://www.peakiq.in/blog/adding-an-ios-control-center-widget-with-deep-linking-to-a-react-native-app

iOS 18 opened up Control Center to third-party apps, and it's a genuinely underused surface. Most teams treat Control Center as an Apple-only space — timers, flashlight, screen recording — and never consider that a single tap from there could drop a user straight into a specific screen of their own app. For an app where certain actions are reached for constantly throughout the day, that's not a minor convenience. It removes an entire app-launch-and-navigate cycle.

We recently added this to a React Native app where field users needed fast access to one particular screen, dozens of times a day, often with their hands full. Below is how the whole thing fits together — the widget extension, the App Intent that drives it, the entitlements that make it possible, and the deep link that hands control back to the React Native side.

Step 1: Add a Widget Extension Target

Control Center controls live inside a WidgetKit extension, not the main app target. This has to be added from Xcode directly — there's no way to do it from the React Native / CocoaPods side.

Open the .xcworkspace (not .xcodeproj) for the React Native app in Xcode.
Go to File → New → Target…
In the template picker, select Widget Extension under the iOS tab.
Name it — this becomes both the target name and, by default, the bundle ID suffix. ComplyStationControls in this example.
Check Include Control Widget in the options that follow. This is what scaffolds a ControlWidget alongside the usual timeline-based widget code — without it, Xcode only gives you a home-screen widget.
When prompted to activate the new scheme, choose Activate. Xcode will also ask whether to embed the extension in the main app target — accept this, since a widget extension only ships as part of the app that hosts it.
Xcode generates a new folder with a Bundle.swift, a Control.swift (or similarly named) file, an Info.plist, and a .entitlements file already wired into the new target's build settings. These generated files are what get replaced with the ones below — the scaffold is mostly boilerplate meant to be overwritten.
Delete anything Xcode generated for a timeline-based widget view (the TimelineProvider, SimpleEntry, and widget View struct) if the goal is a Control Center button only, since those aren't used here.
Confirm the new target's Deployment Target is iOS 18.0 or later — ControlWidget and AppIntent-driven controls don't exist before iOS 18, and a lower deployment target will fail to compile once the code below is added.

Once the target exists, the generated Info.plist for the extension just declares it as a WidgetKit extension:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>NSExtension</key>
    <dict>
        <key>NSExtensionPointIdentifier</key>
        <string>com.apple.widgetkit-extension</string>
    </dict>
</dict>
</plist>

Nothing to customize here — this is boilerplate every widget extension needs.

Step 2: Define the Control Widget Itself

A ControlWidget is what actually renders as a button in Control Center. It needs a unique kind identifier and an AppIntent to run when tapped:

//
//  ComplyStationControlsControl.swift
//  ComplyStationControls
//

import AppIntents
import SwiftUI
import WidgetKit

struct ComplyStationControlsControl: ControlWidget {

    var body: some ControlWidgetConfiguration {

        StaticControlConfiguration(
            kind: "com.peakiq.PEAKIQ.ComplyStationControls"
        ) {

            ControlWidgetButton(action: OpenAppIntent()) {
              Label("Chemical Inventory", image: "Chemical")
            }
        }
    }
}

The kind string is the widget's stable identity — reverse-DNS style, scoped to your bundle ID, and it should never change once shipped, since the system uses it to track the widget across updates.

Every widget extension needs a bundle entry point, same as the main app has @main on its App struct:

//
//  ComplyStationControlsBundle.swift
//  ComplyStationControls
//

import WidgetKit
import SwiftUI

@main
struct ComplyStationControlsBundle: WidgetBundle {
    var body: some Widget {
        ComplyStationControls()
        ComplyStationControlsControl()
    }
}

Step 3: Write the App Intent That Deep Links Back Into the App

This is the part doing the actual work. OpenAppIntent needs to do two things when tapped: tell the main app which screen to open, and actually open the app via a custom URL scheme.

//
//  OpenAppIntent.swift
//  ComplyStationControlsExtension
//

import AppIntents

struct OpenAppIntent: AppIntent {

    static let title: LocalizedStringResource = "Open PEAKIQ"
    static var openAppWhenRun = true
    static var isDiscoverable = true

    private let appGroupId = "group.peakiq.widget"
    private let siriEntityKey = "siri_selected_entity"

    func perform() async throws -> some IntentResult & OpensIntent {

        let entity = "open:chemicalinventory"

        if let defaults = UserDefaults(suiteName: appGroupId) {
            defaults.set(entity, forKey: siriEntityKey)
        }

        let encodedValue = entity.addingPercentEncoding(
            withAllowedCharacters: .urlHostAllowed
        )!

        let url = URL(string: "peakiq://\(encodedValue)")!

        return .result(opensIntent: OpenURLIntent(url))
    }
}

Two mechanisms are doing the work here, deliberately in parallel rather than relying on just one:

Shared UserDefaults via an app group. The target screen identifier is written to storage the main app can also read, ahead of the app actually opening. This matters because the app might already be running in the background — a cold-start deep link handler alone wouldn't catch that case.
A custom URL scheme. OpenURLIntent is what actually triggers the app to open (or come to the foreground), carrying the same encoded value as the URL host. On the React Native side, this is picked up by the standard Linking API exactly like any other deep link.

Both are set to the same value, so however the RN app ends up checking — a fresh Linking.getInitialURL() call or reading the app group defaults on AppState change — it lands on the correct screen.

Step 4: Share Data Across Targets With an App Group

Widget extensions run in their own sandboxed process, separate from the main app. They can't just read the main app's UserDefaults directly — that's what the app group entitlement is for. It needs to be added to both the main app target and the widget extension target, with matching identifiers:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.application-groups</key>
    <array>
        <string>group.peakiq.widget</string>
        <string>group.peakiq.shared</string>
    </array>
</dict>
</plist>

Skipping this step is the single most common reason a Control Center widget silently fails to hand off state to the main app — the intent runs fine, the URL opens fine, but UserDefaults(suiteName:) on either side quietly returns nil because the entitlement isn't wired up on one of the two targets.

Step 5: Handle the Deep Link on the React Native Side

With the native half done, the React Native app just needs its usual Linking handling — nothing control-widget-specific about it:

import { Linking } from 'react-native';

useEffect(() => {
  const handleUrl = ({ url }) => {
    const path = url.replace('peakiq://', '');
    if (path === 'open:chemicalinventory') {
      navigation.navigate('ChemicalInventory');
    }
  };

  Linking.getInitialURL().then((url) => {
    if (url) handleUrl({ url });
  });

  const subscription = Linking.addEventListener('url', handleUrl);
  return () => subscription.remove();
}, []);

Because the identity link (peakiq://open:chemicalinventory) and the app-group fallback carry the same encoded entity string, this handler is the only place routing logic needs to live, regardless of whether the app was cold-launched or already running.

The Real Lesson Here

None of the individual pieces here are complicated — a widget target, an intent, an entitlement, a URL scheme. What makes Control Center integrations easy to get wrong is that they span two separate processes that don't share memory, only a sandboxed group container and a URL scheme. Test each handoff path independently: cold launch from a terminated state, foreground resume from backgrounded, and first-run before the entitlement has ever been exercised. Any one of those three quietly failing looks identical from the outside — the button just does nothing.

If you're adding this to your own app, this is the order that avoids backtracking:

Add the widget extension target and the bundle entry point.
Write the AppIntent with both the app-group write and the URL scheme.
Add the app group entitlement to both targets before testing anything.
Wire up Linking handling on the React Native side.
Test cold launch, backgrounded resume, and first-run separately.

The payoff is disproportionate to the setup cost — a single tap from Control Center, no unlocking into the app first, straight to the screen someone actually needed.

Optimize React Native Cold Start Time Under 1 Second

PEAKIQ — Fri, 26 Jun 2026 04:42:09 +0000

Originally published on PEAKIQ

Source: https://www.peakiq.in/blog/optimize-react-native-cold-start-time-under-1-second

A React Native app's cold start time is one of the few metrics where the cost of neglect compounds quietly until it doesn't. Slow launches don't usually show up as a single dramatic bug report — they show up as a slow erosion in retention, a string of one-star reviews using words like "laggy" or "slow to open," and a growing sense that something is wrong without anyone pointing at the exact cause.

That was the situation with an app we worked on recently. Cold start was sitting above four seconds. Users were backing out before the home screen even rendered. The fixes that brought it under a second weren't exotic — they were items that had been sitting in the backlog for months under the label "optimize later." Below is the breakdown of what we changed, in the order it mattered.

Step 1: Confirm Hermes Is Actually Doing Its Job

If there is one item to check before anything else, it's this. Hermes is Meta's JavaScript engine purpose-built for React Native, and its core advantage over JavaScriptCore or V8 is that it precompiles JavaScript into bytecode ahead of time. Instead of the device parsing and compiling your JS bundle at launch, it just executes already-compiled bytecode.

In recent React Native versions, Hermes is the default engine, so the common failure mode isn't "Hermes is off" — it's a leftover override that disabled it during a migration, or a build configuration that never got updated. Worth confirming directly in your Gradle config:

// android/app/build.gradle
project.ext.react = [
    enableHermes: true
]

And on iOS, in your Podfile:

:hermes_enabled => true

This single configuration check accounted for the largest single chunk of recovered launch time in our case. If your app predates Hermes being default, or went through a bare-workflow migration at some point, it's worth verifying explicitly rather than assuming.

Step 2: Stop Doing Setup Work Before the First Paint

The next biggest offender was App.js itself. It's common for an app's root component to run a list of setup tasks synchronously before anything renders — initializing an SDK, setting up analytics, hydrating a Redux store from storage, resolving a deep link, checking a remote config flag. Each one feels small in isolation. Stacked together, they delay the very first frame the user sees.

The fix is to separate what must happen before render from what can happen after it. Almost nothing actually needs to block the first paint:

useEffect(() => {
  // Runs after the first frame has already painted
  const id = setTimeout(() => {
    initAnalyticsSdk();
    hydrateStore();
    resolveDeepLink();
    fetchRemoteConfig();
  }, 0);

  return () => clearTimeout(id);
}, []);

setTimeout(fn, 0) pushes execution to the next tick of the event loop, which means the UI thread gets to paint the first screen before any of this work runs. The user sees something immediately; the app catches up quietly in the background. This single change is disproportionately effective relative to how little code it requires.

Step 3: Trim the JS Bundle

A larger bundle means more bytes to download, parse, and execute before your app can do anything. Three changes contributed the most here, with no architectural rework required.

Import only what you use. A full lodash import pulls in the entire library even if you're using two functions from it:

// Pulls in the entire library
import _ from 'lodash';

// Only pulls in what's actually used
import debounce from 'lodash-es/debounce';
import merge from 'lodash-es/merge';

Strip console statements from production builds. Debug logging is useful in development and pure overhead in production:

// babel.config.js
module.exports = {
  plugins: ['transform-remove-console'],
};

Convert raster images to WebP. Hero images and other large raster assets are routinely 25–35% smaller in WebP than the equivalent PNG or JPEG with no visible quality loss, and a lighter bundle means less to process at startup.

None of these are individually dramatic, but together they meaningfully reduce what the JS engine has to load before your app is interactive.

Step 4: Load Screens On Demand, Not All at Once

The last major fix addressed how screens were imported. It's common, especially as an app grows, for every screen in the navigation tree to be imported eagerly at the top level — meaning the JS engine parses and initializes all of them on every single cold start, even the ones a given user session will never visit.

Switching to lazy loading for everything except the initial screen changes that:

import React, { Suspense } from 'react';

// Loaded immediately — this is what the user sees first
import HomeScreen from './screens/HomeScreen';

// Loaded only when actually navigated to
const ProfileScreen = React.lazy(() => import('./screens/ProfileScreen'));
const SettingsScreen = React.lazy(() => import('./screens/SettingsScreen'));

function AppNavigator() {
  return (
    <Suspense fallback={<LoadingSpinner />}>
      {/* navigator and routes go here */}
    </Suspense>
  );
}

Only the screen the user actually sees first pays the loading cost upfront. Everything else is deferred until it's actually needed, which has a direct and measurable effect on initial JS execution time.

The Real Lesson Here

None of these four fixes required new architecture, a major dependency upgrade, or weeks of work. Each one had been sitting in a backlog, individually small enough to deprioritize, collectively responsible for the bulk of a multi-second delay.

That's the pattern worth internalizing: on mobile, there is no loading spinner users are conditioned to wait through the way they sometimes will on the web. A slow cold start is just a black screen, and a black screen reads as broken. Perceived speed at launch is part of how users judge the rest of the product before they've used a single feature.

If your React Native app's cold start time is sitting above two seconds, this is a reasonable order to work through:

Confirm Hermes is actually enabled and being used at build time.
Move every non-essential setup task in your root component out from in front of the first paint.
Audit your bundle for unnecessary imports, debug logging, and unoptimized images.
Lazy-load every screen except the one the user lands on first.

None of it is clever. Most of it is just unfinished housekeeping — which is usually where the easiest wins are hiding.

Rust & React Native: Build a TOTP Authenticator App

PEAKIQ — Tue, 23 Jun 2026 03:10:10 +0000

Originally published on PEAKIQ

Source: https://www.peakiq.in/blog/building-a-totp-authenticator-with-rust-and-react-native

Building a TOTP Authenticator with Rust and React Native

Two-factor authentication built around Time-based One-Time Passwords (TOTP) is one of those features that looks simple from the outside and turns out to have a surprising number of sharp edges once you actually build it: secret generation, QR provisioning, clock drift tolerance, secure storage on the client, and rate limiting on the server all need to work together correctly or the whole thing becomes either insecure or unusable.

This post walks through building a TOTP system end to end: a Rust backend that handles secret generation and verification, and a React Native client that scans an enrollment QR code, stores the secret securely, and displays a rolling six-digit code.

Why build this yourself

Most teams reach for a hosted identity provider for two-factor authentication, and for good reason — TOTP touches cryptography, secure storage, and rate limiting, all areas where a small mistake has real consequences. Building it yourself makes sense when you already own the authentication layer (your own user database, your own session model) and want TOTP as a native part of that system rather than a redirect to a third party.

This is also a genuinely good way to understand the protocol. TOTP is defined in RFC 6238, and it is small enough that implementing it from the spec, rather than treating it as a black box, makes every later debugging session easier — "why did this code fail to verify" stops being a mystery once you've written the HMAC step yourself.

How TOTP actually works

Before any code, it helps to be precise about what TOTP is doing:

Enrollment: the server generates a random secret (typically 160 bits) for the user and encodes it into an otpauth:// URI, which is rendered as a QR code.
Scanning: the user's authenticator app (or in our case, the React Native app itself) scans that QR code and extracts the secret.
Code generation: both the server and the client independently compute HOTP(secret, time_counter), where time_counter is the current Unix time divided by a step size (usually 30 seconds), truncated to a 6-digit code.
Verification: when the user submits a code, the server recomputes the expected code for the current time step (and usually one step before/after, to tolerate clock drift) and compares.

The critical property is that the server never needs to ask the client for the secret again after enrollment — both sides derive the same code independently from the shared secret and the current time, with nothing transmitted over the wire except the 6-digit code itself.

Architecture overview

The system has two halves that need to agree on exactly one thing: the secret, and the algorithm parameters (digits, period, hash algorithm) used to turn that secret into a code.

┌─────────────────────┐                      ┌──────────────────────┐
│   React Native App   │                      │      Rust API         │
│                       │                      │                       │
│  1. Request enrollment│ ───────────────────> │  Generate secret       │
│                       │                      │  Build otpauth:// URI  │
│  2. Render/scan QR    │ <─────────────────── │  Return URI + secret   │
│                       │                      │                       │
│  3. Store secret      │                      │                       │
│     (Keychain/        │                      │                       │
│      Keystore)        │                      │                       │
│                       │                      │                       │
│  4. Submit 6-digit    │ ───────────────────> │  Verify against        │
│     code              │                      │  stored secret +       │
│                       │ <─────────────────── │  time window           │
└─────────────────────┘                      └──────────────────────┘

A detail worth deciding early: does the React Native app scan a QR code generated by another authenticator's enrollment flow (the way Google Authenticator or Authy would), or does your own Rust backend generate the secret and your own app immediately consumes it without ever needing to scan anything? Both are valid, and this post covers the scanning path since it is the more general case — it also covers importing TOTP secrets from any third-party service that exposes a standard otpauth:// QR code, which is the more useful feature in practice.

The Rust backend

Dependencies

[dependencies]
totp-rs = { version = "5", features = ["qr"] }
rand = "0.8"
base32 = "0.5"
axum = "0.7"
serde = { version = "1", features = ["derive"] }
serde_json = "1"
sqlx = { version = "0.7", features = ["postgres", "runtime-tokio"] }

totp-rs handles the RFC 6238 math correctly, including the time-window tolerance, so there is no good reason to hand-roll the HMAC step yourself in production — the value of understanding the algorithm is in being able to reason about edge cases, not in reimplementing a primitive that a well-tested crate already gets right.

Generating a secret and enrollment URI

use totp_rs::{Algorithm, TOTP, Secret};

pub struct EnrollmentResponse {
    pub secret_base32: String,
    pub otpauth_uri: String,
}

pub fn create_enrollment(account_email: &str, issuer: &str) -> EnrollmentResponse {
    let secret = Secret::generate_secret();

    let totp = TOTP::new(
        Algorithm::SHA1,
        6,
        1,
        30,
        secret.to_bytes().expect("valid secret bytes"),
        Some(issuer.to_string()),
        account_email.to_string(),
    )
    .expect("valid TOTP parameters");

    EnrollmentResponse {
        secret_base32: secret.to_encoded().to_string(),
        otpauth_uri: totp.get_url(),
    }
}

A few parameter choices here are worth calling out explicitly, because changing any of them breaks compatibility with standard authenticator apps:

Algorithm::SHA1 — almost every authenticator app, including the React Native client built later in this post, assumes SHA1 unless told otherwise. SHA256/SHA512 are supported by the spec but poorly supported in practice.
6 digits — the near-universal default. Some banks use 8, but this breaks compatibility with most consumer authenticator apps.
30 second period — also near-universal. Shorter periods make codes expire before users can type them; longer periods widen the window an attacker has to use a leaked code.
The 1 parameter is the verification window (covered below) — it does not affect enrollment, only how lenient check is at verification time.

The secret itself (secret.to_bytes()) is what gets stored server-side, associated with the user's account, in your database — never the base32-encoded string alone without understanding that they are the same secret in two encodings. Store it encrypted at rest if your database doesn't already provide encryption at rest at the disk layer.

Storing the secret

#[derive(sqlx::FromRow)]
struct TotpEnrollment {
    user_id: i64,
    secret: Vec<u8>,
    confirmed: bool,
}

pub async fn save_pending_enrollment(
    pool: &sqlx::PgPool,
    user_id: i64,
    secret_bytes: &[u8],
) -> Result<(), sqlx::Error> {
    sqlx::query(
        "INSERT INTO totp_enrollments (user_id, secret, confirmed)
         VALUES ($1, $2, false)
         ON CONFLICT (user_id) DO UPDATE SET secret = $2, confirmed = false",
    )
    .bind(user_id)
    .bind(secret_bytes)
    .execute(pool)
    .await?;

    Ok(())
}

The confirmed flag matters more than it looks: a secret should not be treated as "the user's active TOTP secret" until they have proven they can generate a valid code from it. Without this step, a user could scan a QR code, never actually finish setting up their authenticator app correctly, and get locked out of their own account on the next login — or worse, an attacker who can see the enrollment response (but not necessarily the user's authenticator app) gains no benefit, but a confirmation step closes off any ambiguity about whether enrollment actually succeeded.

Verifying a submitted code

use totp_rs::{Algorithm, TOTP, Secret};
use std::time::{SystemTime, UNIX_EPOCH};

pub fn verify_code(secret_bytes: &[u8], submitted_code: &str) -> bool {
    let totp = TOTP::new(
        Algorithm::SHA1,
        6,
        1,
        30,
        secret_bytes.to_vec(),
        None,
        String::new(),
    )
    .expect("valid TOTP parameters");

    let now = SystemTime::now()
        .duration_since(UNIX_EPOCH)
        .expect("system time before epoch")
        .as_secs();

    totp.check(submitted_code, now)
}

totp.check with a window of 1 (set in the TOTP::new call) accepts codes from the previous, current, and next 30-second step — a 90-second tolerance window total. This is what absorbs ordinary clock drift between the user's phone and your server without meaningfully weakening security; widening it further starts trading real security margin for marginal usability gains, since each extra step is another valid code an attacker could use if they intercepted one.

Rate limiting verification attempts

A TOTP code is only 6 digits — one million possibilities. Without rate limiting, brute-forcing a code within its 30-90 second validity window is computationally easy. This is the part of the system most likely to be skipped, and it is not optional.

use std::collections::HashMap;
use std::sync::Mutex;
use std::time::{Duration, Instant};

pub struct AttemptTracker {
    attempts: Mutex<HashMap<i64, Vec<Instant>>>,
}

impl AttemptTracker {
    pub fn new() -> Self {
        Self { attempts: Mutex::new(HashMap::new()) }
    }

    pub fn record_and_check(&self, user_id: i64, max_attempts: usize, window: Duration) -> bool {
        let mut attempts = self.attempts.lock().expect("lock not poisoned");
        let now = Instant::now();
        let user_attempts = attempts.entry(user_id).or_insert_with(Vec::new);

        user_attempts.retain(|t| now.duration_since(*t) < window);

        if user_attempts.len() >= max_attempts {
            return false;
        }

        user_attempts.push(now);
        true
    }
}

A reasonable starting point is something like 5 attempts per 5-minute window per user, returned as a 429 from your verification endpoint once exceeded. This in-memory tracker is fine for a single instance; if you're running multiple replicas behind a load balancer — which lines up with nginx-based scaling setups — this state needs to move to Redis so all replicas share the same attempt count instead of each one independently allowing 5 attempts.

The verification endpoint

use axum::{extract::State, Json};
use serde::Deserialize;

#[derive(Deserialize)]
pub struct VerifyRequest {
    user_id: i64,
    code: String,
}

pub async fn verify_totp_handler(
    State(state): State<AppState>,
    Json(payload): Json<VerifyRequest>,
) -> Result<Json<serde_json::Value>, axum::http::StatusCode> {
    if !state
        .attempt_tracker
        .record_and_check(payload.user_id, 5, std::time::Duration::from_secs(300))
    {
        return Err(axum::http::StatusCode::TOO_MANY_REQUESTS);
    }

    let enrollment = sqlx::query_as::<_, TotpEnrollment>(
        "SELECT user_id, secret, confirmed FROM totp_enrollments WHERE user_id = $1",
    )
    .bind(payload.user_id)
    .fetch_optional(&state.pool)
    .await
    .map_err(|_| axum::http::StatusCode::INTERNAL_SERVER_ERROR)?
    .ok_or(axum::http::StatusCode::NOT_FOUND)?;

    let is_valid = verify_code(&enrollment.secret, &payload.code);

    Ok(Json(serde_json::json!({ "valid": is_valid })))
}

One subtlety: this endpoint returns { "valid": false } for a wrong code rather than a different status code for "wrong code" versus "no code submitted" versus "user not enrolled." Keeping these responses uniform avoids leaking information about which accounts have TOTP enabled to anyone probing the endpoint.

The React Native client

The client side has three jobs: scan a QR code and extract the secret, store that secret somewhere an attacker can't easily read it, and generate a rolling 6-digit code locally without needing to ask the server for one.

Dependencies

npm install react-native-vision-camera react-native-keychain otpauth

react-native-vision-camera handles the QR scan, react-native-keychain wraps iOS Keychain and Android Keystore for secure local storage, and otpauth is a small, well-tested JS implementation of RFC 6238 for generating codes on the client.

Parsing the scanned QR code

An otpauth:// URI looks like this:

otpauth://totp/MyApp:user@example.com?secret=JBSWY3DPEHPK3PXP&issuer=MyApp&algorithm=SHA1&digits=6&period=30

Once a barcode scanner outputs that raw string, parsing it is straightforward:

import * as OTPAuth from 'otpauth';

export function parseOtpAuthUri(rawValue: string) {
  if (!rawValue.startsWith('otpauth://totp/')) {
    throw new Error('Not a valid TOTP enrollment QR code');
  }

  const totp = OTPAuth.URI.parse(rawValue);

  if (!(totp instanceof OTPAuth.TOTP)) {
    throw new Error('QR code is not a TOTP entry');
  }

  return {
    issuer: totp.issuer ?? '',
    accountName: totp.label ?? '',
    secret: totp.secret.base32,
    algorithm: totp.algorithm,
    digits: totp.digits,
    period: totp.period,
  };
}

This is the same shape of work your existing useQrScanner / scanRawValue flow already does for generic QR content — the only addition here is validating the otpauth:// scheme and handing the parsed fields off to a typed structure before anything gets stored.

Storing the secret securely

The secret must never land in AsyncStorage, Redux state persisted to disk, or anywhere else that isn't backed by the platform's hardware-backed secure storage. react-native-keychain is the standard choice:

import * as Keychain from 'react-native-keychain';

const TOTP_SERVICE = 'com.yourapp.totp';

export async function storeTotpSecret(accountKey: string, secret: string) {
  await Keychain.setGenericPassword(accountKey, secret, {
    service: `${TOTP_SERVICE}.${accountKey}`,
    accessible: Keychain.ACCESSIBLE.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
  });
}

export async function getTotpSecret(accountKey: string): Promise<string | null> {
  const credentials = await Keychain.getGenericPassword({
    service: `${TOTP_SERVICE}.${accountKey}`,
  });
  return credentials ? credentials.password : null;
}

WHEN_UNLOCKED_THIS_DEVICE_ONLY is the important option here: it prevents the secret from being included in iCloud Keychain backups or restored onto a different device, and it requires the device to be unlocked to read it back. For an authenticator secret, this is the correct tradeoff — losing access on device migration is the expected behavior, not a bug, and matches how dedicated authenticator apps behave.

Generating the live code

import * as OTPAuth from 'otpauth';

export function generateCurrentCode(secret: string): { code: string; secondsRemaining: number } {
  const totp = new OTPAuth.TOTP({
    secret: OTPAuth.Secret.fromBase32(secret),
    algorithm: 'SHA1',
    digits: 6,
    period: 30,
  });

  const code = totp.generate();
  const secondsRemaining = 30 - (Math.floor(Date.now() / 1000) % 30);

  return { code, secondsRemaining };
}

A typical authenticator UI re-runs this every second on a timer to update both the displayed code and a countdown ring, regenerating only when the underlying code actually changes:

import { useEffect, useState } from 'react';

export function useLiveTotpCode(secret: string | null) {
  const [state, setState] = useState<{ code: string; secondsRemaining: number } | null>(null);

  useEffect(() => {
    if (!secret) {
      setState(null);
      return;
    }

    const update = () => setState(generateCurrentCode(secret));
    update();

    const interval = setInterval(update, 1000);
    return () => clearInterval(interval);
  }, [secret]);

  return state;
}

Wiring the scan into enrollment

This is where the scanning work fits into the existing CameraWithScanner pattern: once onScan fires with a raw value, route it through parseOtpAuthUri, and only call storeTotpSecret after the user confirms the parsed issuer and account name look correct — the same confirm-before-commit shape as the TotpReviewModal step in a typical scan flow, rather than silently saving the instant a QR code is detected.

const handleScan = useCallback((rawValue: string) => {
  try {
    const parsed = parseOtpAuthUri(rawValue);
    setPendingEnrollment(parsed); // shown in a review modal before saving
  } catch (error) {
    Toast.show('This QR code is not a valid authenticator code.', Toast.SHORT);
  }
}, []);

Security considerations

A short checklist worth treating as non-negotiable rather than nice-to-have:

Never log the secret or the generated code, in either the Rust backend or the React Native app. Logging frameworks and crash reporters (Sentry included) need explicit scrubbing rules for any field that might contain a TOTP secret — this is the same category of concern as scrubbing PII, just with higher stakes if it leaks.
Rate limit verification attempts server-side, as covered above. Rate limit per user, not just per IP, since a shared network (office Wi-Fi, mobile carrier NAT) can otherwise lock out unrelated users.
Require a confirmed, valid code before marking enrollment complete. Don't treat "QR code was scanned" as equivalent to "TOTP is now protecting this account."
Plan account recovery before launch, not after. Losing access to an authenticator app is common and predictable — back-up codes, generated once at enrollment and shown exactly once, are the standard mitigation.
Keep the verification window tight. A window of 1 (90 seconds total) is a reasonable default; resist the temptation to widen it to "fix" user complaints about expired codes, since that's usually a UX problem (slow network round-trip, no countdown shown) rather than a clock-drift problem.

Testing the full flow

End to end, a manual test pass should cover:

Enroll a new TOTP secret, scan the resulting QR code with the React Native client, confirm the parsed issuer/account name display correctly.
Submit the live-generated code back to the verification endpoint and confirm it succeeds.
Wait for a code to expire (just past the 30-second boundary) and confirm an old code is rejected once it falls outside the window.
Submit 6 incorrect codes in a row and confirm the 6th request returns 429 rather than a verification failure.
Kill and restart the app, confirm the stored secret is still readable from Keychain/Keystore and a fresh code generates correctly.

Where to go from here

This covers the core mechanics, but a production system typically layers on top of this: backup codes for recovery, a "remember this device for 30 days" cookie to avoid prompting on every login, and admin tooling to revoke a user's TOTP enrollment if their device is lost. The protocol itself, though, is exactly what's covered above — everything else is product decisions built on top of a correctly implemented RFC 6238 core.

React Native Vision Camera: Reusable Component Guide

PEAKIQ — Thu, 11 Jun 2026 12:04:35 +0000

Originally published on PEAKIQ

Source: https://www.peakiq.in/blog/building-a-reusable-vision-camera-component-in-react-native

Building a Reusable Vision Camera Component in React Native

react-native-vision-camera is the go-to camera library for React Native in 2025 — but wiring up photo capture, video recording, and barcode scanning in every screen gets repetitive fast.

This guide walks through building a single reusable VisionCamera component that handles all three, exposed via a clean ref API. Published on peakiq.in.

What We're Building

A single VisionCamera component that:

Takes photos with configurable flash
Records video with a start/stop ref API
Optionally scans barcodes in real time
Accepts an overlay slot for custom UI
Clamps zoom between device min and max
Handles missing camera devices gracefully

Dependencies

npm install react-native-vision-camera react-native-vision-camera-barcode-scanner

Make sure you have camera and microphone permissions configured in both AndroidManifest.xml and Info.plist.

The Handle Interface

We expose three imperative methods via forwardRef so the parent screen can control the camera without prop drilling:

export interface VisionCameraHandle {
  takePhoto: (options?: { flash?: 'on' | 'off' | 'auto' }) => Promise<string>;
  recordAsync: () => Promise<{ uri: string; codec: string }>;
  stopRecording: () => Promise<void>;
}

takePhoto resolves with the file path of the captured image
recordAsync starts recording and resolves with the video URI when stopped
stopRecording signals the recorder to finalize and save

Component Props

interface Props {
  style?: StyleProp<ViewStyle>;
  zoom?: number;
  maxZoom?: number;
  isActive?: boolean;
  overlay?: React.ReactNode;
  flash?: 'on' | 'off' | 'auto';
  onMountError?: (error: Error) => void;
  onCameraReady?: () => void;
  onBarCodeRead?: (barcode: { value: string; type: string }) => void;
  enableBarcode?: boolean;
  enableVideo?: boolean;
}

enableBarcode and enableVideo are opt-in — outputs are only registered when needed, which keeps the camera pipeline lean.

Full Implementation

import React, { forwardRef, useImperativeHandle, useRef } from 'react';
import { View, StyleProp, ViewStyle, Text, StyleSheet } from 'react-native';
import {
  Camera,
  useCameraDevice,
  usePhotoOutput,
  useVideoOutput,
} from 'react-native-vision-camera';
import { useBarcodeScannerOutput } from 'react-native-vision-camera-barcode-scanner';

export interface VisionCameraHandle {
  takePhoto: (options?: { flash?: 'on' | 'off' | 'auto' }) => Promise<string>;
  recordAsync: () => Promise<{ uri: string; codec: string }>;
  stopRecording: () => Promise<void>;
}

interface Props {
  style?: StyleProp<ViewStyle>;
  zoom?: number;
  maxZoom?: number;
  isActive?: boolean;
  overlay?: React.ReactNode;
  flash?: 'on' | 'off' | 'auto';
  onMountError?: (error: Error) => void;
  onCameraReady?: () => void;
  onBarCodeRead?: (barcode: { value: string; type: string }) => void;
  enableBarcode?: boolean;
  enableVideo?: boolean;
}

const VisionCamera = forwardRef<VisionCameraHandle, Props>(
  (
    {
      style,
      zoom = 1,
      maxZoom,
      isActive = true,
      overlay,
      flash = 'off',
      onMountError,
      onCameraReady,
      onBarCodeRead,
      enableBarcode = false,
      enableVideo = false,
    },
    ref,
  ) => {
    const device = useCameraDevice('back');
    const photoOutput = usePhotoOutput();
    const videoOutput = useVideoOutput({ enableAudio: enableVideo });
    const recorderRef = useRef<any>(null);

    const barcodeOutput = useBarcodeScannerOutput({
      barcodeFormats: ['all-formats'],
      onBarcodeScanned: (barcodes) => {
        if (!enableBarcode) return;
        const first = barcodes[0];
        if (first) {
          onBarCodeRead?.({
            value: first.rawValue ?? '',
            type: first.format ?? '',
          });
        }
      },
      onError: (error) => {
        console.warn('Barcode scanner error', error);
      },
    });

    useImperativeHandle(
      ref,
      () => ({
        takePhoto: async (options) => {
          const { filePath } = await photoOutput.capturePhotoToFile(
            { flashMode: options?.flash ?? flash },
            {},
          );
          return filePath;
        },

        recordAsync: () => {
          return new Promise(async (resolve, reject) => {
            try {
              const recorder = await videoOutput.createRecorder({});
              recorderRef.current = recorder;

              await recorder.startRecording(
                (filePath, reason) => {
                  resolve({ uri: `file://${filePath}`, codec: 'mp4' });
                },
                (error) => {
                  reject(error);
                },
              );
            } catch (e) {
              reject(e);
            }
          });
        },

        stopRecording: async () => {
          try {
            await recorderRef.current?.stopRecording();
            recorderRef.current = null;
          } catch (error) {
            console.info(error);
          }
        },
      }),
      [photoOutput, videoOutput, flash],
    );

    if (!device) {
      return (
        <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
          <Text>No camera device found</Text>
        </View>
      );
    }

    const resolvedMaxZoom = maxZoom ?? device.maxZoom;
    const clampedZoom = Math.min(Math.max(zoom, device.minZoom), resolvedMaxZoom);

    const outputs = [
      photoOutput,
      ...(enableVideo ? [videoOutput] : []),
      ...(enableBarcode ? [barcodeOutput] : []),
    ];

    return (
      <View style={{ flex: 1 }}>
        <Camera
          style={[StyleSheet.absoluteFill, style]}
          device={device}
          isActive={isActive}
          zoom={clampedZoom}
          outputs={outputs}
          onStarted={onCameraReady}
          onError={(error) => onMountError?.(new Error(error.message))}
        />
        {overlay}
      </View>
    );
  },
);

VisionCamera.displayName = 'VisionCamera';

export default VisionCamera;

Key Design Decisions

Conditional outputs array

Outputs are only added to the camera pipeline when the corresponding feature is enabled:

const outputs = [
  photoOutput,
  ...(enableVideo ? [videoOutput] : []),
  ...(enableBarcode ? [barcodeOutput] : []),
];

This avoids unnecessary processing — a photo-only screen won't pay the cost of video or barcode initialization.

Zoom clamping

Zoom is clamped between the device's reported minZoom and maxZoom values, with an optional maxZoom prop override:

const resolvedMaxZoom = maxZoom ?? device.maxZoom;
const clampedZoom = Math.min(Math.max(zoom, device.minZoom), resolvedMaxZoom);

Recorder ref

The active recorder instance is stored in a useRef so stopRecording can access it without closing over stale state:

const recorderRef = useRef<any>(null);

Usage Example

import { useRef } from 'react';
import VisionCamera, { VisionCameraHandle } from './VisionCamera';

const ScannerScreen = () => {
  const cameraRef = useRef<VisionCameraHandle>(null);

  const handleCapture = async () => {
    const path = await cameraRef.current?.takePhoto({ flash: 'auto' });
    console.log('Photo saved at:', path);
  };

  return (
    <VisionCamera
      ref={cameraRef}
      enableBarcode
      onBarCodeRead={({ value, type }) => console.log(type, value)}
      onCameraReady={() => console.log('Camera ready')}
      overlay={<ScannerOverlay />}
    />
  );
};

What to Build Next

Add front camera support by accepting a cameraPosition prop ('back' | 'front')
Expose zoom gesture handling via react-native-gesture-handler
Add a captureMode prop to switch between photo and video mode declaratively
Integrate with a global media store to manage captured files

Published on peakiq.in — React Native guides, component patterns, and tutorials.

React Native hitSlop: Enhance Tappable Area for Small Buttons

PEAKIQ — Sun, 07 Jun 2026 04:28:01 +0000

Originally published on PEAKIQ

Source: https://www.peakiq.in/blog/react-native-hitslop-make-tiny-taps-easy

React Native `hitSlop` Explained — Improve Touch Area for Small Buttons

Small buttons are a UX problem. Users miss them. They tap again. They get frustrated.
hitSlop solves this without touching your layout. Published on peakiq.in.

What is `hitSlop`?

hitSlop is a prop available on touchable components like Pressable, TouchableOpacity, and TouchableHighlight. It expands the tappable area of a component beyond its visual bounds — invisibly.

No extra padding. No layout shifts. Just a larger touch target.

How It Works

You can pass hitSlop in two ways:

As a number — expands the touch area equally on all four sides:

hitSlop={10}

As an object — expands each side independently:

hitSlop={{ top: 10, right: 16, bottom: 10, left: 16 }}

Think of it as invisible padding around the touch target that only exists for the finger, not the layout.

Example: Close Button

A close button is a classic case — small icon, easy to miss.

import { Pressable, Text } from 'react-native';

export function CloseButton({ onPress }) {
  return (
    <Pressable
      onPress={onPress}
      hitSlop={10}
      style={{ padding: 4 }}
      accessibilityLabel="Close"
      accessibilityRole="button"
    >
      <Text>✕</Text>
    </Pressable>
  );
}

Even if the user taps slightly outside the icon, the press still registers. The visual size stays the same.

When to Use `hitSlop`

hitSlop is most useful when:

The button is visually small (icon-only buttons, close icons, inline links)
You cannot increase padding without breaking the layout
You want to meet the recommended 44×44dp minimum touch target size (Apple HIG / Material Design)
You need better accessibility without restructuring your component tree

Why It Matters

Reduces missed taps on small UI elements
Improves usability without any visual or layout changes
Works on both iOS and Android
Takes two seconds to add and immediately improves the feel of your app

Quick Reference

// Equal expansion on all sides
<Pressable hitSlop={12} onPress={onPress}>

// Per-side expansion
<Pressable hitSlop={{ top: 8, right: 16, bottom: 8, left: 16 }} onPress={onPress}>

Published on peakiq.in — React Native guides, tips, and tutorials.

SonarQube for React & React Native: Improve Code Quality

PEAKIQ — Sun, 07 Jun 2026 04:23:11 +0000

Originally published on PEAKIQ

Source: https://www.peakiq.in/blog/level-up-your-react-react-native-code-quality-with-sonarqube-a-deep-dive

A practical 2025 deep dive into static analysis, security scanning, and code smell detection — beyond what ESLint and Prettier can do. Published on peakiq.in.

Why SonarQube in React & React Native Projects?

Linters like ESLint and formatters like Prettier are great — but they only scratch the surface. SonarQube brings a deeper layer of quality assurance:

Deep static analysis beyond standard lint rules
Security vulnerability detection across your entire codebase
Code smell detection that flags maintainability issues early
Visual dashboards showing test coverage, technical debt, and maintainability scores

It's not about replacing your current tools — it's about supercharging them.

Setting Up SonarQube Locally on macOS

Step 1: Install and Launch SonarQube

brew install sonar
sonar start

Visit http://localhost:9000 and log in with admin / admin.

You now have a running SonarQube server on your machine.

Step 2: Install the Sonar Scanner

The Sonar Scanner is the CLI tool that connects your project code to the SonarQube server:

brew install sonar-scanner

Step 3: Add the Configuration File

At the root of your React or React Native project, create the properties file:

touch sonar-project.properties

Then add the following configuration:

sonar.projectKey=my-awesome-app
sonar.projectName=My Awesome App
sonar.sources=src
sonar.exclusions=**/__tests__/**,**/*.test.js,**/*.spec.tsx
sonar.language=js
sonar.sourceEncoding=UTF-8
sonar.javascript.lcov.reportPaths=coverage/lcov.info

Run the Analysis

First, build and test your app to generate coverage output (especially if you use Jest):

npm run test -- --coverage

Then trigger the scanner:

sonar-scanner

Your SonarQube dashboard will now populate with real-time code insights.

React Native Considerations

Modern React Native apps typically have:

Shared components between iOS and Android
JS/TS-only source code under src/
Native modules in android/ and ios/ that don't need analysis

Update your config to reflect this:

sonar.sources=src
sonar.exclusions=android/**,ios/**,**/*.test.tsx

Use TypeScript with strict mode enabled in tsconfig.json to boost type safety — SonarQube will respect and leverage it during analysis.

Test Coverage Integration

To visualize exactly what you're not testing:

Run Jest with the coverage flag: jest --coverage
This outputs lcov.info under your coverage/ directory
Point SonarQube to it via sonar.javascript.lcov.reportPaths in your properties file

You'll get heatmaps of untested components, making it easy to spot weak points across your project.

Bonus: Combine with Git Hooks

Prevent bad code from ever reaching your Sonar dashboard by linting and formatting before every commit. Install Husky and lint-staged:

npm install husky lint-staged --save-dev

Configure lint-staged in your package.json:

{
  "lint-staged": {
    "**/*.tsx": ["eslint --fix", "prettier --write"]
  }
}

This way your Sonar dashboard stays clean before any code gets merged.

CI/CD Integration

If you're using GitHub Actions, Bitrise, or Fastlane for React Native, add a scan step like this:

- name: SonarQube Scan
  run: |
    sonar-scanner \
      -Dsonar.projectKey=my-awesome-app \
      -Dsonar.sources=src \
      -Dsonar.login=${{ secrets.SONAR_TOKEN }}

Store your token securely as a SONAR_TOKEN secret in your repository settings.

Final Thoughts: Clean Code Is Sustainable Code

Codebases grow fast. React projects sprawl. React Native multiplies the surface area across platforms. Without active quality gates, you're inviting chaos.

SonarQube doesn't just point fingers — it creates a shared understanding of quality across your entire team. In 2025, that's not just helpful — it's essential.

Published on peakiq.in — React Native guides and tutorials.

React Native Background Downloads, ZIP Extraction & Notifications

PEAKIQ — Sun, 07 Jun 2026 04:03:38 +0000

Originally published on PEAKIQ

Source: https://www.peakiq.in/blog/managing-background-downloads-unzipping-files-and-notifications-in-react-native

A complete guide to handling background file downloads, extracting ZIP archives, and notifying users in React Native. Published on peakiq.in.

1. Create a React Native Project

If you don't already have a project initialized, scaffold one using the React Native CLI:

npx react-native init MyApp

2. Install Required Libraries

Four libraries power this implementation, each handling a distinct responsibility:

Library	Purpose
`@kesha-antonov/react-native-background-downloader`	Background downloads that persist across app restarts
`react-native-zip-archive`	Extracting ZIP files after download completes
`react-native-notifications`	Local push alerts when download finishes
`react-native-fs`	File system operations and recursive path traversal

Install via npm:

npm install @kesha-antonov/react-native-background-downloader \
  react-native-zip-archive \
  react-native-notifications \
  react-native-fs

Or via yarn:

yarn add @kesha-antonov/react-native-background-downloader \
  react-native-zip-archive \
  react-native-notifications \
  react-native-fs

3. Platform Configuration

Android

Add required permissions in AndroidManifest.xml
Enable background services if needed
Grant internet and storage permissions

iOS

Configure notification permissions in your app settings
Enable Background Fetch mode
Enable Background Processing under Background Modes

4. Full Implementation

A complete component handling the full download lifecycle — background download, ZIP extraction, progress tracking, and local notifications:

import React, { useState, useEffect } from 'react';
import { View } from 'react-native';
import * as Progress from 'react-native-progress';
import { Notifications } from 'react-native-notifications';
import RNBackgroundDownloader from '@kesha-antonov/react-native-background-downloader';
import { unzip } from 'react-native-zip-archive';
import RNFS from 'react-native-fs';

// Recursively collect all file paths inside a directory
const collectFilePaths = async (
  dirPath: string,
  filePaths: string[] = []
): Promise<string[]> => {
  const contents = await RNFS.readDir(dirPath);
  for (const item of contents) {
    if (item.isDirectory()) {
      await collectFilePaths(item.path, filePaths);
    } else {
      filePaths.push(item.path);
    }
  }
  return filePaths;
};

const DownloadScreen: React.FC = () => {
  const [progress, setProgress] = useState<number>(0);

  useEffect(() => {
    Notifications.registerRemoteNotifications();
    checkExistingDownloads();
  }, []);

  // Resume any downloads that were interrupted by an app restart
  const checkExistingDownloads = async () => {
    const tasks = await RNBackgroundDownloader.checkForExistingDownloads();
    const task = tasks.find(t => t.id === 'file_11111');
    if (task) {
      task
        .progress(({ bytesDownloaded, bytesTotal }) =>
          setProgress(bytesDownloaded / bytesTotal)
        )
        .done(() => console.log('Resumed download completed'))
        .error(console.error);
    }
  };

  const sendNotification = () => {
    Notifications.postLocalNotification({
      body: 'File Uploaded!',
      title: 'Download Completed',
      sound: 'chime.aiff',
      silent: false,
    });
  };

  const downloadFile = (url: string): Promise<string> => {
    return new Promise((resolve, reject) => {
      const destination = `${RNBackgroundDownloader.directories.documents}/file_11111.zip`;
      RNBackgroundDownloader.download({ id: 'file_11111', url, destination })
        .progress(({ bytesDownloaded, bytesTotal }) =>
          setProgress(bytesDownloaded / bytesTotal)
        )
        .done(() => resolve(destination))
        .error(reject);
    });
  };

  const downloadAndUnzip = async () => {
    try {
      const filePath = await downloadFile('http://localhost:5005/download');

      const unzipPath = await unzip(
        filePath,
        `${RNBackgroundDownloader.directories.documents}/file_${Date.now()}`
      );

      const files = await collectFilePaths(unzipPath);
      console.log(files);

      sendNotification();
    } catch (err) {
      console.error(err);
    }
  };

  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
      {progress > 0 && (
        <>
          <Text>{`Progress: ${(progress * 100).toFixed(2)}%`}</Text>
          <Progress.Bar progress={progress} width={350} />
        </>
      )}
      <Text onPress={downloadAndUnzip}>Download & Extract</Text>
    </View>
  );
};

export default DownloadScreen;

5. How It Works

Background Downloads

Uses react-native-background-downloader to handle downloads that survive app restarts. The checkForExistingDownloads() call on mount automatically resumes any interrupted tasks.

ZIP Extraction

Once the download resolves, react-native-zip-archive's unzip() extracts the archive into a uniquely named directory using Date.now() to avoid collisions.

File Traversal

react-native-fs recursively walks the extracted directory tree, collecting every file path into a flat array.

Notifications

A local push notification fires immediately after extraction completes, letting the user know their content is ready — even if the app is in the background.

Use Cases

This pattern works well for any app dealing with large file downloads:

Offline content bundles
Media and video downloads
PDF and document packs
SDS and compliance files
Course or educational materials
Map tile packages

Published on peakiq.in — React Native guides and tutorials.

Automate React Native App Updates with Fastlane & Remote Config

PEAKIQ — Sat, 06 Jun 2026 04:10:42 +0000

Originally published on PEAKIQ

Source: https://www.peakiq.in/blog/automating-app-updates-in-react-native-with-fastlane-and-remote-config

Automating App Updates in React Native with Fastlane and Remote Config

Managing app updates across iOS and Android is repetitive work. Fastlane automates the build and release pipeline, while Firebase Remote Config lets you enforce a minimum required version without shipping a new build to change the threshold. Together they give you a reliable, low-maintenance update system.

This guide walks through setting up both, then connecting them via a GitHub Actions workflow.

Prerequisites

A React Native project
A Firebase project with Remote Config enabled
Fastlane installed locally
Basic familiarity with GitHub Actions

Step 1 — Set Up Fastlane

Initialize Fastlane in your project root:

fastlane init

Follow the prompts to configure it for your project. This creates a fastlane/ directory containing a Fastfile and an Appfile.

Update your Fastfile with lanes for both iOS and Android. Each lane should handle the steps relevant to your release process — incrementing the build number, running tests, building the app, and uploading to the App Store or Google Play.

A minimal Android lane looks like this:

lane :android_deploy do
  gradle(task: 'bundle', build_type: 'Release')
  upload_to_play_store(track: 'internal')
end

And for iOS:

lane :ios_deploy do
  match(type: 'appstore')
  build_app(scheme: 'YourApp')
  upload_to_app_store
end

Customize these based on your signing setup, test requirements, and target release track.

Step 2 — Use Remote Config for Update Checks

Configure the parameter in Firebase

In the Firebase Console, go to Remote Config and create a new parameter named minimum_required_version. Set its default value to the minimum version string you want to enforce, for example 2.0.0.

When you want to raise the minimum — after deprecating an old API, fixing a critical bug, or shipping a breaking change — update this value in the console and publish. No new app build required.

Fetch and check the version in your app

Install the required packages if you have not already:

npm install @react-native-firebase/app @react-native-firebase/remote-config react-native-device-info
cd ios && pod install

Then add the version check to your app entry point:

import { useEffect } from 'react';
import { Alert, Linking } from 'react-native';
import DeviceInfo from 'react-native-device-info';
import remoteConfig from '@react-native-firebase/remote-config';

const useUpdateCheck = () => {
  useEffect(() => {
    async function checkForUpdate() {
      await remoteConfig().fetchAndActivate();

      const minimumRequiredVersion = remoteConfig()
        .getValue('minimum_required_version')
        .asString();

      const currentVersion = DeviceInfo.getVersion();

      if (compareVersions(currentVersion, minimumRequiredVersion) < 0) {
        Alert.alert(
          'Update Required',
          'A new version of the app is available. Please update to continue.',
          [
            {
              text: 'Update Now',
              onPress: () => {
                // Android
                Linking.openURL('market://details?id=com.yourapp.package');
                // iOS — replace with your App Store URL
                // Linking.openURL('itms-apps://itunes.apple.com/app/idYOURAPPID');
              },
            },
          ],
          { cancelable: false }
        );
      }
    }

    checkForUpdate();
  }, []);
};

export default useUpdateCheck;

Call useUpdateCheck() from your root component. The { cancelable: false } option on the alert prevents users from dismissing the prompt without updating.

You will need a compareVersions utility that parses semver strings and returns a negative number if the first argument is older than the second. A simple implementation:

const compareVersions = (a, b) => {
  const pa = a.split('.').map(Number);
  const pb = b.split('.').map(Number);
  for (let i = 0; i < 3; i++) {
    if ((pa[i] || 0) < (pb[i] || 0)) return -1;
    if ((pa[i] || 0) > (pb[i] || 0)) return 1;
  }
  return 0;
};

Step 3 — GitHub Actions Workflow

Create the workflow file

Add a workflow at .github/workflows/deploy.yml:

name: Deploy React Native App

on:
  push:
    branches:
      - main

jobs:
  deploy-android:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
      - name: Install dependencies
        run: npm install
      - name: Set up Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.1'
          bundler-cache: true
      - name: Deploy Android
        run: bundle exec fastlane android_deploy
        env:
          FASTLANE_JSON_KEY_DATA: ${{ secrets.FASTLANE_JSON_KEY_DATA }}

  deploy-ios:
    runs-on: macos-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
      - name: Install dependencies
        run: npm install && cd ios && pod install
      - name: Set up Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.1'
          bundler-cache: true
      - name: Deploy iOS
        run: bundle exec fastlane ios_deploy
        env:
          FASTLANE_USER: ${{ secrets.FASTLANE_USER }}
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
          APP_STORE_CONNECT_API_KEY: ${{ secrets.APP_STORE_CONNECT_API_KEY }}

Add GitHub Secrets

In your repository, go to Settings > Secrets and variables > Actions and add the secrets referenced in the workflow:

Secret	What it holds
`FASTLANE_JSON_KEY_DATA`	Google Play service account JSON key
`FASTLANE_USER`	Apple ID used for App Store Connect
`MATCH_PASSWORD`	Password for your Fastlane Match certificate repo
`APP_STORE_CONNECT_API_KEY`	App Store Connect API key JSON

Push changes to the main branch to trigger the workflow.

How It All Connects

Once this is in place, the release flow works like this:

Push to main — GitHub Actions builds and deploys the app via Fastlane
The new build ships to users through the App Store or Google Play
When you need to force an update, raise minimum_required_version in Firebase Remote Config and publish
On next app launch, users running an older version see the mandatory update prompt

No code change or new release is needed to adjust the minimum version threshold — that control lives entirely in Firebase.

Notes

Always test the compareVersions logic with edge cases — versions like 1.10.0 vs 1.9.0 trip up naive string comparison.
Consider adding a fetchAndActivate timeout via remoteConfig().setConfigSettings({ fetchTimeMillis: 3000 }) to avoid blocking app startup if Firebase is slow to respond.
For iOS, make sure the Linking.openURL target uses the correct itms-apps:// scheme with your actual App Store app ID.

Effective Request Cancellation with Axios in JavaScript

PEAKIQ — Sat, 06 Jun 2026 03:33:59 +0000

Originally published on PEAKIQ

Source: https://www.peakiq.in/blog/effective-request-cancellation-with-axios-in-javascript

How CancelTokens Work

A CancelToken is a token you attach to an Axios request. When you want to cancel that request, you call the cancel() function on the token source. Axios intercepts the cancellation, aborts the request, and throws a specific cancellation error that you can catch and handle separately from other errors.

The four things to understand:

Creating a token — axios.CancelToken.source() returns a { token, cancel } pair. Pass token to the request and call cancel() when you want to abort.
Canceling a request — Calling cancel(message) immediately interrupts any in-flight request using that token.
Handling cancellation errors — Axios throws a CanceledError on cancellation. Use axios.isCancel(error) to distinguish it from real network or server errors.
Resetting the token — After canceling, create a new CancelToken.source() before making the next request. A canceled token cannot be reused.

Implementation

Cancel token module

Create a shared module that holds the current token source and exposes a reset function. This lets any part of your application cancel the active request and prepare a fresh token in one call.

// cancel.js

/* eslint-disable import/no-mutable-exports */
import axios from 'axios';

export let axiosCancelSource = axios.CancelToken.source();

export const resetCancelSource = (cancelMessage = 'Request is Cancelled') => {
  axiosCancelSource.cancel(cancelMessage);
  axiosCancelSource = axios.CancelToken.source();
};

axiosCancelSource is exported as a mutable let so the reference can be updated when resetCancelSource creates a new source. The eslint-disable comment suppresses the mutable export warning — this pattern is intentional here.

Using the token in a request

Import the shared token and attach it to your Axios config. In the finally block, reset the source so the next call gets a clean token.

// DownloadClass.js

import axios from 'axios';
import { axiosCancelSource, resetCancelSource } from '../components/shared/cancelToken';

export class DownloadAssessment {
  static async downloadFromServer(paramData) {
    const { axiosReqPayload } = paramData;

    try {
      const response = await axios({
        ...axiosReqPayload,
        cancelToken: axiosCancelSource.token,
      });
      return response.data;
    } catch (error) {
      if (axios.isCancel(error)) {
        console.log('Request canceled:', error.message);
        // Handle cancellation — update UI state, log, or silently ignore
      } else {
        throw error; // Re-throw real errors so callers can handle them
      }
    } finally {
      // Reset after every request — success, error, or cancellation
      resetCancelSource();
    }
  }
}

The finally block ensures resetCancelSource runs regardless of outcome. Without this, a failed or canceled request would leave the token in a canceled state, causing all subsequent requests to fail immediately.

Triggering Cancellation

Call resetCancelSource() from anywhere in your application when you need to abort the current request:

import { resetCancelSource } from '../components/shared/cancelToken';

// On component unmount, route change, or user action
resetCancelSource('User navigated away');

This cancels the active request and immediately prepares a fresh token for the next one.

Best Practices

Call resetCancelSource in component cleanup functions (useEffect return, componentWillUnmount) to prevent state updates on unmounted components.
Always use axios.isCancel(error) before deciding how to handle a caught error — swallowing a real network error as if it were a cancellation is a common bug.
Never reuse a canceled token. Always call axios.CancelToken.source() to create a new one before the next request.
If you are using Axios 0.22+, consider migrating to the AbortController API, which is the web standard equivalent and is now supported natively by Axios.

Summary

Concept	How it works
Create token	`axios.CancelToken.source()` returns `{ token, cancel }`
Attach to request	Pass `token` as `cancelToken` in the Axios config
Cancel	Call `cancel(message)` on the source
Detect cancellation	`axios.isCancel(error)` returns `true` for canceled requests
Reset	Call `axios.CancelToken.source()` again before the next request

Request cancellation is a small addition to your Axios setup that pays dividends in application reliability — fewer race conditions, cleaner unmount behavior, and a better experience when users change their mind mid-request.

DEV Community: PEAKIQ

Build a Production QR/Barcode Scanner Modal in React Native

The stack

Step 1: A store that owns every scan session

Step 2: One modal, mounted once, genuinely full-screen

Step 3: The screen that ties the pieces together

Step 4: Two scanning paths, one funnel

Step 5: The scan frame

Step 6: The top bar — six controls, one hard constraint

Step 7: The overflow menu and zoom pill

Step 8: Rendering the result

Using it

The gotchas worth their own paragraph

Before calling it done

Hotel Indradhar — Hotel in Dharamshala

Hotel Indradhar — A Modern Digital Gateway to Dharamshala

The Challenge

PeakIQ's Solution

Key Features & Implementation Highlights

Outcomes & Impact

Delivery Notes

Explore the Website

React Native: Prevent Screenshots on Android & Blur on iOS

Step 1: Add the Android Native Module

Step 2: Add the iOS Native Module

Step 3: A Ref-Counted Manager, Not a Bare Toggle

Step 4: Close the Stack Navigator Gap

The Real Lesson Here

React Native iOS Control Center Widget with Deep Linking

Step 1: Add a Widget Extension Target

Step 2: Define the Control Widget Itself

Step 3: Write the App Intent That Deep Links Back Into the App

Step 4: Share Data Across Targets With an App Group

Step 5: Handle the Deep Link on the React Native Side

The Real Lesson Here

Optimize React Native Cold Start Time Under 1 Second

Step 1: Confirm Hermes Is Actually Doing Its Job

Step 2: Stop Doing Setup Work Before the First Paint

Step 3: Trim the JS Bundle

Step 4: Load Screens On Demand, Not All at Once

The Real Lesson Here

Rust & React Native: Build a TOTP Authenticator App

Building a TOTP Authenticator with Rust and React Native

Why build this yourself

How TOTP actually works

Architecture overview

The Rust backend

Dependencies

Generating a secret and enrollment URI

Storing the secret

Verifying a submitted code

Rate limiting verification attempts

The verification endpoint

The React Native client

Dependencies

Parsing the scanned QR code

Storing the secret securely

Generating the live code

Wiring the scan into enrollment

Security considerations

Testing the full flow

Where to go from here

React Native Vision Camera: Reusable Component Guide

Building a Reusable Vision Camera Component in React Native

What We're Building

Dependencies

The Handle Interface

Component Props

Full Implementation

Key Design Decisions

Conditional outputs array

Zoom clamping

Recorder ref

Usage Example

What to Build Next

React Native hitSlop: Enhance Tappable Area for Small Buttons

React Native hitSlop Explained — Improve Touch Area for Small Buttons

What is hitSlop?

How It Works

Example: Close Button

React Native `hitSlop` Explained — Improve Touch Area for Small Buttons

What is `hitSlop`?

When to Use `hitSlop`