DEV Community: PEAKIQ

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.

React Native iOS Google Sign-In: Production Setup Guide

PEAKIQ — Mon, 25 May 2026 12:46:44 +0000

Originally published on PEAKIQ

Source: https://www.peakiq.in/blog/production-google-sign-in-setup-for-react-native-ios

This guide explains how to configure Google authentication in a React Native iOS application using:

React Native CLI
TypeScript
Google Sign-In SDK
iOS OAuth Client

Install Google Sign-In Package

npm install @react-native-google-signin/google-signin

Install iOS pods:

cd ios && pod install

Create Google OAuth iOS Client

Open Google Cloud Console:

https://console.cloud.google.com

Navigate:

APIs & Services
    ↓
Credentials
    ↓
Create Credentials
    ↓
OAuth Client ID

Choose:

iOS

Configure Bundle Identifier

Use the same iOS bundle identifier from Xcode.

Example:

com.idsvault.app

Find it in:

Xcode
   ↓
Targets
   ↓
General
   ↓
Bundle Identifier

Configure Google Sign-In

Create:

src/config/google.ts

import {
  GoogleSignin,
} from '@react-native-google-signin/google-signin';

GoogleSignin.configure({
  iosClientId:
    'YOUR_IOS_CLIENT_ID',
});

AppDelegate Setup

Open:

ios/AppDelegate.swift

Add import:

import GoogleSignIn

Add callback handler inside AppDelegate:

func application(
  _ app: UIApplication,
  open url: URL,
  options: [UIApplication.OpenURLOptionsKey : Any] = [:]
) -> Bool {
  return GIDSignIn.sharedInstance.handle(url)
}

Add URL Scheme

Google Sign-In on iOS requires URL scheme registration.

Open:

ios/YourProject/Info.plist

Add:

<key>CFBundleURLTypes</key>
<array>
  <dict>
    <key>CFBundleURLSchemes</key>
    <array>
      <string>
        YOUR_REVERSED_CLIENT_ID
      </string>
    </array>
  </dict>
</array>

Example:

<string>
com.googleusercontent.apps.xxxxxxxxx
</string>

Important

Use:

REVERSED_CLIENT_ID

NOT:

CLIENT_ID
bundle identifier
web client ID

React Native Google Login

import {
  GoogleSignin,
} from '@react-native-google-signin/google-signin';

export async function continueWithGoogle() {

  await GoogleSignin.hasPlayServices();

  const userInfo =
    await GoogleSignin.signIn();

  console.log(userInfo);

  const idToken =
    userInfo.data?.idToken;

  console.log(idToken);

  return idToken;
}

Example Button Usage

<TouchableOpacity
  onPress={continueWithGoogle}
>
  <Text>
    Continue with Google
  </Text>
</TouchableOpacity>

Common iOS Error

Your app is missing support for the following URL schemes

Fix:

add REVERSED_CLIENT_ID
clean build
reinstall app

Clean Build

cd ios
xcodebuild clean

Reinstall app:

npx react-native run-ios

Final Result

After successful setup:

Tap Google button
    ↓
Google login popup
    ↓
Authenticate
    ↓
Return to app
    ↓
Receive Google ID token

Your React Native iOS app now supports production-grade Google Sign-In.

AI Business Evolution: What to Expect in 2026

PEAKIQ — Mon, 25 May 2026 03:09:26 +0000

Originally published on PEAKIQ

Source: https://www.peakiq.in/blog/future-of-artificial-intelligence-in-business

Navigating the AI-Driven Future of Business

Artificial Intelligence is not just a technological trend — it is a transformational force reshaping how businesses operate, compete, and grow across every industry. The role of AI in business is poised to expand in ways that bring new opportunities, real challenges, and fundamental shifts in how organizations think and act.

This article explores the most significant directions that AI is taking business, and what leaders need to understand to navigate them well.

AI as an Augmentation Tool

The most important thing to understand about AI's trajectory in business is that its greatest value lies in augmenting people, not replacing them. AI-driven automation and decision-support systems free employees from repetitive, low-judgment work — giving them more capacity for creative thinking, complex problem-solving, and meaningful client interactions.

Organizations that frame AI as a tool for human empowerment will outperform those that see it purely as a cost-reduction mechanism. The competitive advantage goes to teams that work with AI effectively, not to AI working instead of teams.

Hyper-Personalization and Customer Experience

AI's ability to process large volumes of behavioral data and surface actionable patterns is fundamentally changing how businesses serve customers. Products, services, and communications can now be tailored with a precision that was operationally impossible even five years ago.

This shift toward hyper-personalization is not merely about better marketing. It changes the nature of the customer relationship — when interactions feel genuinely relevant, customers develop stronger brand loyalty and are more likely to forgive occasional failures. The businesses that get this right will not just retain customers more effectively; they will make switching to a competitor feel like a step backward.

AI-Enhanced Decision-Making

Across functions — supply chain, finance, hiring, product development — AI-powered predictive analytics gives organizations foresight that was previously unavailable or prohibitively expensive to develop. Demand forecasting, risk modeling, and scenario planning become faster and more accurate when grounded in real-time data rather than historical averages and intuition alone.

The shift here is not that AI makes decisions for organizations. It is that AI raises the quality of information available to decision-makers at every level, compressing the time between sensing a change and responding to it.

"AI will not be the sole force driving business — it will be the indispensable partner that amplifies human potential and shapes the very fabric of innovation."

The Rise of Explainable AI

As AI becomes more embedded in consequential decisions — credit approvals, hiring shortlists, medical triage, fraud detection — the demand for transparency in how those decisions are made is intensifying. Explainable AI (XAI) refers to systems designed to surface understandable reasoning alongside their outputs, rather than producing results from an opaque process.

For businesses, this is both a regulatory and a trust issue. Regulators in the EU, US, and elsewhere are moving toward requirements for algorithmic accountability. Beyond compliance, customers and employees are more likely to accept AI-influenced decisions when they can understand the logic behind them. Investing in explainability is increasingly inseparable from responsible AI deployment.

AI in Cybersecurity

The same properties that make AI powerful for business — pattern recognition at scale, real-time processing, continuous learning — make it essential for defending against modern cyber threats. AI-driven security systems can detect anomalies, flag suspicious behavior, and respond to incidents faster than any human security team operating alone.

This matters because the threat landscape is evolving at a pace that traditional rule-based security tools cannot match. Attackers are also beginning to use AI, which means defenses that do not incorporate it will fall progressively further behind. Cybersecurity is becoming an AI arms race, and standing still is not a neutral position.

AI and Sustainability

AI is emerging as one of the most practical tools available for organizations serious about their sustainability commitments. Applications range from optimizing energy consumption in data centers and manufacturing facilities, to reducing food waste in logistics networks, to improving the accuracy of carbon accounting across complex supply chains.

Sustainability is also increasingly a business performance issue, not just a values one. Investors, enterprise customers, and regulators are applying growing pressure on organizations to demonstrate measurable progress. AI-driven efficiency gains offer a path to meeting those expectations without sacrificing operational performance.

Challenges and Ethical Considerations

The potential of AI in business is real, but so are the risks that come with deploying it at scale. Several challenges deserve serious organizational attention:

Bias — AI systems trained on historical data can encode and amplify existing inequities. Auditing models for discriminatory outputs is not optional for organizations that care about fair outcomes.
Data privacy — AI systems are often data-hungry. Collecting and retaining the data they need must be balanced against customer privacy rights and regulatory obligations.
Workforce transition — As AI automates certain tasks, the workforce needs pathways to reskill. Organizations that invest in this proactively will navigate the transition more smoothly than those that treat it as someone else's problem.
Accountability — When an AI-driven decision causes harm, it must be clear who is responsible. Diffusing accountability across a model and its developers is not an acceptable answer.

Navigating these challenges responsibly is what separates organizations that build durable trust in their AI systems from those that accumulate hidden liability.

What This Means for Business Leaders

AI's integration into business is not a future event to prepare for — it is an ongoing shift already underway. The organizations gaining ground are those that treat AI adoption as a strategic capability to develop over time, not a single implementation project with a finish line.

That means investing in data infrastructure, building AI literacy across teams, establishing clear governance for how AI is used, and staying close to how the regulatory environment is evolving. The businesses that do this well will be better positioned to move quickly when new capabilities emerge — and more resilient when things go wrong.

Posted on Peakiq.in · AI · Business Strategy

React Native Environment Info Script for Windows & Mac

PEAKIQ — Mon, 25 May 2026 02:51:32 +0000

Originally published on PEAKIQ

Source: https://www.peakiq.in/blog/react-native-environment-info-script-for-windows-mac

Get Full Details of Your React Native Environment

When debugging build issues or setting up a new machine, knowing exactly what is installed — and which versions — saves a lot of guesswork. These scripts collect system information, installed binaries, SDKs, IDEs, and npm packages for a React Native environment on both Windows and macOS.

Windows (PowerShell)

How to run

Save the script as react-native-info.ps1
Open PowerShell and navigate to the file location
Allow script execution for the current session and run it:

Set-ExecutionPolicy Unrestricted -Scope Process
.\react-native-info.ps1

Script

# Get System Info
Write-Host "System info`n"

Write-Host "System:"
Write-Host "   OS: $(Get-CimInstance Win32_OperatingSystem | Select-Object -ExpandProperty Caption)"
Write-Host "   CPU: $(Get-CimInstance Win32_Processor | Select-Object -ExpandProperty Name)"
Write-Host "   Memory: $(Get-CimInstance Win32_ComputerSystem | Select-Object -ExpandProperty TotalPhysicalMemory | ForEach-Object { [math]::Round($_ / 1GB, 2) }) GB"
Write-Host "   Shell: PowerShell $($PSVersionTable.PSVersion)"

# Get Installed Binaries
Write-Host "`nBinaries:"
Write-Host "   Node: $(node -v)"
Write-Host "   Yarn: $(yarn -v)"
Write-Host "   npm: $(npm -v)"
$watchmanVersion = (Get-Command watchman -ErrorAction SilentlyContinue) ? (watchman --version) : "Not Found"
Write-Host "   Watchman: $watchmanVersion"

# Get Installed Managers
Write-Host "`nManagers:"
$chocoVersion = (choco -v 2>$null) ? (choco -v) : "Not Installed"
Write-Host "   Chocolatey: $chocoVersion"
$scoopVersion = (scoop -v 2>$null) ? (scoop -v) : "Not Installed"
Write-Host "   Scoop: $scoopVersion"

# Get SDKs
Write-Host "`nSDKs:"
Write-Host "   Android SDK: $(Get-ItemProperty -Path 'HKLM:\SOFTWARE\Android Studio' -ErrorAction SilentlyContinue | Select-Object -ExpandProperty Path)"
Write-Host "   Java: $(java -version 2>&1 | Select-String -Pattern 'version' | ForEach-Object { $_ -replace 'java version "', '' -replace '"', '' })"

# Get Installed IDEs
Write-Host "`nIDEs:"
Write-Host "   Xcode: Not Available on Windows"
$androidStudio = (Get-Command "C:\Program Files\Android\Android Studio\bin\studio64.exe" -ErrorAction SilentlyContinue) ? "Installed" : "Not Installed"
Write-Host "   Android Studio: $androidStudio"

# Get npm package versions
Write-Host "`nnpm Packages:"
$reactNativeCli = npm show @react-native-community/cli version
$reactVersion = npm show react version
$reactNativeVersion = npm show react-native version
Write-Host "   @react-native-community/cli: $reactNativeCli"
Write-Host "   react: $reactVersion"
Write-Host "   react-native: $reactNativeVersion"

Write-Host "`nnpm Global Packages:"
$globalReactNative = npm list -g --depth=0 | Select-String 'react-native' | ForEach-Object { ($_ -split '@')[1] }
Write-Host "   *react-native*: $($globalReactNative -join ', ')"

macOS (Bash)

How to run

Save the script as react-native-info.sh
Make it executable:

chmod +x react-native-info.sh

Run it:

./react-native-info.sh

Script

#!/bin/bash

echo "React Native Environment Info for macOS"

# System Info
echo -e "\nSystem Info:"
echo "   OS: $(sw_vers -productName) $(sw_vers -productVersion)"
echo "   CPU: $(sysctl -n machdep.cpu.brand_string)"
echo "   Memory: $(sysctl -n hw.memsize | awk '{print $1/1073741824 " GB"}')"
echo "   Shell: $SHELL"

# Installed Binaries
echo -e "\nBinaries:"
echo "   Node: $(node -v)"
echo "   Yarn: $(yarn -v)"
echo "   npm: $(npm -v)"
WATCHMAN_VERSION=$(watchman --version 2>/dev/null || echo "Not Found")
echo "   Watchman: $WATCHMAN_VERSION"

# Package Managers
echo -e "\nPackage Managers:"
echo "   Homebrew: $(brew -v | head -n 1)"

# SDKs
echo -e "\nSDKs:"
ANDROID_SDK=${ANDROID_HOME:-"Not Found"}
echo "   Android SDK: $ANDROID_SDK"
echo "   Java: $(java -version 2>&1 | awk -F '"' '/version/ {print $2}')"

# IDEs
echo -e "\nIDEs:"
XCODE_VERSION=$(xcodebuild -version 2>/dev/null || echo "Not Installed")
echo "   Xcode: $XCODE_VERSION"
ANDROID_STUDIO=$(ls /Applications | grep "Android Studio" || echo "Not Installed")
echo "   Android Studio: $ANDROID_STUDIO"

# npm Packages
echo -e "\nnpm Packages:"
echo "   @react-native-community/cli: $(npm show @react-native-community/cli version)"
echo "   react: $(npm show react version)"
echo "   react-native: $(npm show react-native version)"

echo -e "\nnpm Global Packages:"
GLOBAL_REACT_NATIVE=$(npm list -g --depth=0 | grep react-native || echo "Not Installed")
echo "   *react-native*: $GLOBAL_REACT_NATIVE"

What Each Script Collects

Section	Details
System	OS name, CPU, total memory, shell version
Binaries	Node, Yarn, npm, Watchman
Package managers	Chocolatey / Scoop (Windows), Homebrew (macOS)
SDKs	Android SDK path, Java version
IDEs	Xcode (macOS only), Android Studio
npm packages	Latest published versions of core RN packages
npm global	Globally installed React Native packages

Notes

The PowerShell script requires Set-ExecutionPolicy Unrestricted -Scope Process to run unsigned scripts. This only affects the current session and does not change your system policy permanently.
The Bash script fixes a minor bug in the original — $ANDROID_HOME now uses ${ANDROID_HOME:-"Not Found"} instead of echo $ANDROID_HOME which would silently print nothing if the variable is unset.
The npm show calls fetch the latest published version from the registry, not what is installed locally. To check locally installed versions, use npm list --depth=0 inside your project instead.

Custom Native Splash Screen Flutter: flutter_native_splash Guide

PEAKIQ — Mon, 25 May 2026 02:37:18 +0000

Originally published on PEAKIQ

Source: https://www.peakiq.in/blog/how-to-implement-a-custom-native-splash-screen-in-flutter

How to Add a Native Splash Screen in Flutter

A splash screen is the first thing users see when they open your app. In Flutter, you can create a native splash screen that appears instantly — before Flutter even loads — using the flutter_native_splash package. This gives your app a polished, professional feel from the very first frame.

In this tutorial you will configure colors, apply the splash to both iOS and Android, and control exactly when the splash disappears using preserve() and remove().

Step 1 — Install the Package

Add flutter_native_splash to your pubspec.yaml under dev_dependencies:

dev_dependencies:
  flutter_native_splash: ^2.4.7

Then fetch it:

flutter pub get

Step 2 — Create the Configuration File

Create a file named flutter_native_splash.yaml in your project root and add:

flutter_native_splash:
  color: "#000000"
  fullscreen: true

android_12:
  color: "#000000"
  icon_background_color: "#111111"

This configuration sets a black background, enables fullscreen mode, and applies correct styling for Android 12 and above — which has its own splash API that requires separate configuration.

Once the file is ready, generate the native splash assets:

flutter pub run flutter_native_splash:create

Re-run this command every time you update the YAML file. Changes to the configuration are not picked up automatically.

Step 3 — Control the Splash Programmatically

By default, the splash disappears as soon as Flutter finishes rendering its first frame. In most real apps, you need it to stay visible longer while async work completes — loading user data, initializing storage, fetching remote config, or validating a session.

The package provides two methods for this:

FlutterNativeSplash.preserve() — holds the splash open until you are ready
FlutterNativeSplash.remove() — dismisses the splash and reveals the app UI

Full working example

import 'package:flutter/material.dart';
import 'package:flutter_native_splash/flutter_native_splash.dart';

void main() {
  WidgetsBinding widgetsBinding = WidgetsFlutterBinding.ensureInitialized();
  FlutterNativeSplash.preserve(widgetsBinding: widgetsBinding);
  runApp(const MainApp());
}

class MainApp extends StatefulWidget {
  const MainApp({super.key});

  @override
  State<MainApp> createState() => _MyAppState();
}

class _MyAppState extends State<MainApp> {
  @override
  void initState() {
    super.initState();
    _initializeApp();
  }

  Future<void> _initializeApp() async {
    // Replace this with your real initialization logic
    await Future.delayed(const Duration(seconds: 3));
    FlutterNativeSplash.remove();
  }

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      home: Scaffold(
        backgroundColor: Colors.white,
        body: Center(
          child: Text("Native Splash"),
        ),
      ),
    );
  }
}

How it works

WidgetsFlutterBinding.ensureInitialized() must be called before preserve() because the splash system hooks into the widget binding lifecycle. Passing the binding reference to preserve() tells the package to hold the splash until you explicitly call remove().

In _initializeApp, replace Future.delayed with your actual startup work — API calls, shared preferences initialization, feature flag fetches, or user session validation. Call remove() only after all of it is complete.

Configuration Options

The YAML file supports more than just background color. Common options worth knowing:

Option	What it does
`color`	Background color in hex
`image`	Path to a logo or icon, e.g. `assets/logo.png`
`fullscreen`	Hides the status bar during the splash
`color_dark`	Background color when the device is in dark mode
`image_dark`	Separate image for dark mode
`android_12.color`	Android 12+ specific background color
`android_12.icon_background_color`	Background behind the icon on Android 12+

iOS and Android can each have separate image and color values, so the splash can match each platform's conventions exactly.

Tips for Production

Add your app logo with image: assets/logo.png and rerun the creation command
Configure color_dark and image_dark for dark mode support
Use different images or colors per platform by adding android: and ios: sections
Add a background gradient on Android by pointing to a custom drawable file
Always rerun flutter pub run flutter_native_splash:create after any YAML change

Result

With this setup in place, the native splash loads instantly on app open, stays visible while initialization completes, and dismisses cleanly when the app is ready — giving users a smooth, professional experience from the very first frame.

DEV Community: PEAKIQ

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

When to Use hitSlop

Why It Matters

Quick Reference

SonarQube for React & React Native: Improve Code Quality

Why SonarQube in React & React Native Projects?

Setting Up SonarQube Locally on macOS

Step 1: Install and Launch SonarQube

Step 2: Install the Sonar Scanner

Step 3: Add the Configuration File

Run the Analysis

React Native Considerations

Test Coverage Integration

Bonus: Combine with Git Hooks

CI/CD Integration

Final Thoughts: Clean Code Is Sustainable Code

React Native Background Downloads, ZIP Extraction & Notifications

1. Create a React Native Project

2. Install Required Libraries

3. Platform Configuration

Android

iOS

4. Full Implementation

5. How It Works

Background Downloads

ZIP Extraction

File Traversal

Notifications

Use Cases

Automate React Native App Updates with Fastlane & Remote Config

Automating App Updates in React Native with Fastlane and Remote Config

Prerequisites

Step 1 — Set Up Fastlane

Step 2 — Use Remote Config for Update Checks

Configure the parameter in Firebase

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

What is `hitSlop`?

When to Use `hitSlop`