DEV Community: Rushikesh Pandit

A dependency-first checklist for upgrading React Native

Rushikesh Pandit — Fri, 16 Oct 2026 14:37:45 +0000

Most upgrade guides start with the template diff. I now start about five steps earlier, because that's
where the surprises live.

1. List your native dependencies

A native dependency is any package with an ios/ folder, an android/ folder or a .podspec. Each one
is a separate compatibility question. Here's a small script (Node 18+, run from your project root):

// list-native-deps.mjs
import { readdirSync, existsSync, statSync } from 'node:fs';
import { join } from 'node:path';

const root = join(process.cwd(), 'node_modules');
const isNative = (dir) =>
  existsSync(join(dir, 'android')) ||
  existsSync(join(dir, 'ios')) ||
  readdirSync(dir).some((f) => f.endsWith('.podspec'));

const candidates = [];
for (const name of readdirSync(root)) {
  if (name.startsWith('.')) continue;
  if (name.startsWith('@')) {
    for (const sub of readdirSync(join(root, name))) candidates.push(join(root, name, sub));
  } else {
    candidates.push(join(root, name));
  }
}

for (const dir of candidates) {
  try {
    if (statSync(dir).isDirectory() && isNative(dir)) console.log(dir.replace(root + '/', ''));
  } catch {}
}

Caveat: with pnpm, only your direct dependencies appear at the top level of node_modules, so you'll see
direct native deps but not every transitive one.

2. Check each against the target version

For each native dependency: when was the last release? Does the README or changelog mention your target
React Native version? Are there open issues with the version number in the title? Write the answer down
as compatible / unknown / broken.

3. Check peer dependency ranges

Look at peerDependencies for react and react-native in each library. A pinned upper bound is an early
warning, even if everything installs with --legacy-peer-deps.

4. Verify the toolchain

Read the release notes for your target version and list the required Xcode, JDK, Node and Android Gradle
Plugin versions. Compare with your CI images and your teammates' machines. Mismatches here fail late.

5. Dry-run on a throwaway branch

Bump, install, build both platforms, run the app. Time-box it. Record every failure with the file and the
error. This list is your real estimate.

6. Now apply the Upgrade Helper diff

With the risk list in hand, the diff is much easier to apply, because you know what's likely to collide.

One hop or several?

Jumping many versions at once is faster when it works and harder to debug when it doesn't. If your dry run
shows many unknowns, stepping through intermediate versions can isolate failures. Decide using your risk
list, not habit.

Automating steps 1–4

I'm building rn-upgrade-doctor to automate the inventory and compatibility checks and produce a
project-specific risk report. CLI public on 20 Oct: rn-upgrade-doctor

What step would you add to this list?

iOS 27 Crashing Your App at Launch? Every Fix for the UIScene Lifecycle Error

Rushikesh Pandit — Wed, 14 Oct 2026 13:41:43 +0000

You rebuilt your app, it compiled with zero warnings, and the moment it opens on an iOS 27 device it vanishes. No JS error. No managed exception. Just a flash of the launch screen and a dead process.

If that's you, you've probably hit this line in the device log:

Application failed to launch: UIScene life cycle is required for apps
 built with this SDK.

This post explains what is actually happening, and walks through every fix I could verify, from plain UIKit to React Native, Expo, and a few other stacks.

First, a correction to the common story

The popular framing is "apps built with older Xcode crash on iOS 27". The sources I checked say the opposite:

The check is tied to the SDK you build with, not the iOS version on the phone.
An app built with Xcode 26 (iOS 26 SDK) still launches on iOS 27.
An app built with Xcode 27 (iOS 27 SDK) that hasn't adopted the UIScene lifecycle is killed at launch on iOS 27.

Apple's iOS & iPadOS 27 release notes put it in one sentence: apps built with the latest SDK must adopt the scene-based life cycle or they fail to launch. That is why "it worked yesterday" is true: nothing in your code changed, only your toolchain did.

A nasty side effect: the same Xcode 27 build can still launch fine on iOS 26, so a smoke test on an older phone can pass while every iOS 27 user crashes.

How to confirm it's this crash

The crash report looks like this:

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0  UIKitCore  ___UIApplicationEvaluateRuntimeIssueForNoSceneLifecycleAdoption_block_invoke

If you see NoSceneLifecycleAdoption in the top frames, you're in the right place. It happens in both Debug and Release.

Do you need to migrate?

Per Apple's TN3187, migrate if either is true:

The UIApplicationSceneManifest key is missing from your Info.plist, or it has no configurations.
Your app delegate doesn't implement application(_:configurationForConnecting:options:).

Note that a manifest containing only UIApplicationSupportsMultipleScenes does not count as adopting scenes. Also, only adoption is required. You do not have to support multiple windows.

Fix 1: Adopt scenes in a native UIKit app (the real fix)

Step 1: Add the scene manifest to Info.plist

<key>UIApplicationSceneManifest</key>
<dict>
    <key>UIApplicationSupportsMultipleScenes</key>
    <false/>
    <key>UISceneConfigurations</key>
    <dict>
        <key>UIWindowSceneSessionRoleApplication</key>
        <array>
            <dict>
                <key>UISceneConfigurationName</key>
                <string>Default Configuration</string>
                <key>UISceneDelegateClassName</key>
                <string>$(PRODUCT_MODULE_NAME).SceneDelegate</string>
                <key>UISceneStoryboardFile</key>
                <string>Main</string>
            </dict>
        </array>
    </dict>
</dict>

If you use a storyboard, keep the storyboard name in the scene configuration. If you build your UI in code, drop UISceneStoryboardFile.

Step 2: Create a SceneDelegate that owns the window

import UIKit

class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    var window: UIWindow?

    func scene(
        _ scene: UIScene,
        willConnectTo session: UISceneSession,
        options connectionOptions: UIScene.ConnectionOptions
    ) {
        guard let windowScene = scene as? UIWindowScene else { return }

        window = UIWindow(windowScene: windowScene)
        window?.rootViewController = YourRootViewController()
        window?.makeKeyAndVisible()
    }
}

Remove window creation from application(_:didFinishLaunchingWithOptions:). An app delegate that creates its own UIWindow with no scene delegate is exactly what triggers the crash.

Step 3: Move the lifecycle callbacks

UIApplicationDelegate	UISceneDelegate
`applicationDidBecomeActive(_:)`	`sceneDidBecomeActive(_:)`
`applicationWillResignActive(_:)`	`sceneWillResignActive(_:)`
`applicationDidEnterBackground(_:)`	`sceneDidEnterBackground(_:)`
`applicationWillEnterForeground(_:)`	`sceneWillEnterForeground(_:)`

Optional: configure scenes in code instead of the plist

If you need dynamic configuration, implement this in your app delegate:

func application(
    _ application: UIApplication,
    configurationForConnecting connectingSceneSession: UISceneSession,
    options: UIScene.ConnectionOptions
) -> UISceneConfiguration {
    UISceneConfiguration(name: "Default Configuration",
                         sessionRole: connectingSceneSession.role)
}

Fix 2: Don't forget what silently stops working after you migrate

Adopting scenes fixes the launch crash, but it moves responsibilities. These are the regressions that compile fine and fail quietly:

Deep links and universal links. URL opens and user activities go to the scene delegate. application(_:open:options:) and application(_:continue:restorationHandler:) on the app delegate stop being called.
Cold-start links. A link that launches the app no longer shows up in launchOptions. It arrives in connectionOptions.urlContexts and connectionOptions.userActivities inside scene(_:willConnectTo:options:).
Startup code that assumes a window. didFinishLaunching now returns before any window exists. Anything touching the window or root view controller belongs after the scene connects.
Code that reads UIApplication.shared.delegate?.window. The app delegate no longer owns the window.

Test deep links two ways: with the app running, and with the app fully closed.

Fix 3: React Native

Check where you stand

You've adopted scenes if your Info.plist has a UIApplicationSceneManifest with scene configurations, or your app delegate implements application(_:configurationForConnecting:options:).

Upgrade path

React Native 0.88 is reported as the first release whose template adopts scenes: a SceneDelegate.swift starts React Native in the window scene and Info.plist references it. As of early October it was still a release candidate.
0.87 and earlier have nothing in the template. Upgrade, then copy the scene delegate and the Info.plist changes from the Upgrade Helper.

The library crash that appears after you adopt scenes

On the new template the AppDelegate has no window property. Libraries that still do this will crash:

UIViewController *root = [UIApplication sharedApplication].delegate.window.rootViewController;

-[AppDelegate window]: unrecognized selector sent to instance

The one-line fix inside the library is:

UIViewController *root = RCTPresentedViewController();  // or RCTKeyWindow().rootViewController

Libraries reported to be affected by this pattern include react-native-blob-util, @react-native-firebase/messaging (crashes at launch), react-native-google-mobile-ads, react-native-date-picker, react-native-image-crop-picker, and rn-fetch-blob. Until upstream ships fixes, a patch-package patch with the line above works. Check each library's open PRs first.

Forward deep links from the scene delegate

Nothing crashes if you forget this. Linking just stops firing. A sketch to adapt to your project:

func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
    guard let url = URLContexts.first?.url else { return }
    RCTLinkingManager.application(UIApplication.shared, open: url, options: [:])
}

func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
    RCTLinkingManager.application(UIApplication.shared,
                                  continue: userActivity,
                                  restorationHandler: { _ in })
}

Also read connectionOptions.urlContexts in willConnectTo for cold starts.

Fix 4: Expo

SDK 58 (in beta since mid-September) is reported to generate the scene delegate by default.
SDK 57 can opt in. It needs expo 57.0.23+ and expo-build-properties 57.0.20+:

["expo-build-properties", { "ios": { "enableSceneSupport": true } }]

Then regenerate the native project:

npx expo prebuild --clean

SDK 56 and earlier need an SDK upgrade first.
If your ios/ folder is generated by prebuild and the template still creates the window in didFinishLaunching, one team solved it durably with a small config plugin that applies the two changes on every prebuild, rather than hand-editing a folder that gets regenerated.

Fix 5: Other stacks

.NET MAUI. Add Platforms/iOS/SceneDelegate.cs deriving from MauiUISceneDelegate (registered as SceneDelegate), and add the scene manifest to every iOS Info.plist, using the configuration name __MAUI_DEFAULT_SCENE_CONFIGURATION__. Templates from MAUI 10.0.110 (22 Sept 2026) include this. Older projects don't get it automatically, so upgrading the package alone does not fix an existing app. Don't forget every flavor-specific plist.
Cordova. cordova-ios 8.1.1 apps built with Xcode 27 are reported to show a blank screen and the same error. Track the open issue in apache/cordova-ios (#1725) and update the platform and any plugins that inject windows into the app delegate.
Tauri / Dioxus. Release builds with a scene manifest crashed until a fix in tao, reported as shipped in tao 0.37.0. Update the dependency and regenerate the iOS project.
Flutter and native plugins. One vendor reported an EXC_BAD_ACCESS near GeneratedPluginRegistrant.register(with:) after adopting scenes, caused by plugin code that expected registrar setup in the app delegate. If you use Flutter, check your Flutter version's iOS scene guidance and update plugins that handle deep links.
Third-party SDKs. Some vendors ship separate SDK lines per Xcode major version (for example Microsoft's Intune SDK has a release line for Xcode 26 and a different one for Xcode 16). Check your SDKs' release notes before switching toolchains.

Fix 6: Stay on Xcode 26 for now (a stopgap, not a plan)

If you can't migrate this week, keep production builds on the toolchain that works. One open-source team fixed a TestFlight launch crash on iOS 27.2 by pinning their store builds to Xcode 26.6, after confirming the working build was linked against the iOS 26.5 SDK.

In practice that means:

Pin Xcode 26.6 on your CI image (for EAS, a macos-tahoe-26.5-xcode-26.6 image).
Keep a separate lane that builds with Xcode 27 so you find breakage early.
Check your build's SDK: the DTXcode and DTSDKName keys in the built Info.plist tell you which SDK produced it.

A reported deadline makes this temporary: Apple is said to have announced that from April 2027, apps uploaded to App Store Connect must be built with the iOS 27 SDK. I could not confirm that on Apple's own pages, so verify it in your App Store Connect announcements before planning around it.

Fix 7: Other Xcode 27 issues you may hit in the same upgrade

These are build-time or tooling problems rather than the launch crash, but they tend to show up together:

Deployment target errors. Xcode 27 rejects pods declaring an IPHONEOS_DEPLOYMENT_TARGET below 15.0. A common fix is a post_install hook in your Podfile that raises the target for offending pods.
No Simulator.app. One report says Xcode 27 no longer ships Simulator.app (it ships DeviceHub.app), which broke expo run:ios on older @expo/cli versions. Update your CLI tooling.
Stale build data. After toolchain changes, clear it: rm -rf ~/Library/Developer/Xcode/DerivedData/* and rebuild.
Beta-era dyld crashes. If your app dies before any Swift runs on an iOS 27 beta device, it can be a third-party framework symbol issue rather than scenes. Update the dependency and file a Feedback report.

A checklist you can paste into a ticket

Confirm the crash: NoSceneLifecycleAdoption in the report.
Add UIApplicationSceneManifest with a scene configuration to every Info.plist (all flavors).
Add a SceneDelegate that creates the window; remove window creation from the app delegate.
Move applicationDidBecomeActive and friends to the scene equivalents.
Move URL and user-activity handling to the scene delegate; handle cold-start links from connectionOptions.
Audit dependencies for delegate.window and similar app-delegate assumptions.
Delete DerivedData, rebuild with Xcode 27.
Test on an iOS 27 simulator or device. An iOS 26 device will not show the problem.
Test deep links, push taps and every picker/ad/menu that presents UI, from both warm and cold starts.

Wrap-up

The takeaway is less "old Xcode breaks on iOS 27" and more "the moment you move to Xcode 27, Apple's long-announced scene requirement becomes an assert". The fix itself is small, the follow-on regressions (deep links, window-dependent startup, third-party libraries) are where the time goes, so adopt scenes while you're still on Xcode 26, ship it, and then upgrade the toolchain.

If you've hit a variant I didn't cover, tell me in the comments and I'll add it.

Sources

Apple, TN3187: Migrating to the UIKit scene-based life cycle
Apple, iOS & iPadOS 27 Release Notes (UIKit deprecations)
Dan Ardelean, .NET MAUI crash at launch with Xcode 27
Alican Akyol, Xcode 27 won't launch 93% of React Native apps
Expo SDK 57 + Xcode 27 scene lifecycle fix
apache/cordova-ios #1725, DioxusLabs/dioxus #5853, multica-ai/multica #8447 and #9025
mbeckm/workout-tracker PR #129 (pinning to Xcode 26.6)
Airbridge SceneDelegate migration guide

Found this helpful? Drop a ❤️ on the article!
Questions or suggestions? Drop them in the comments below.

Feel free to reach out:
LinkedIn: https://www.linkedin.com/in/rushikesh-pandit-646834100/
GitHub: https://github.com/rushikeshpandit
Portfolio: https://www.rushikeshpandit.in

#ReactNative #MobileDevelopment #SoftwareEngineering #iOS #Swift #iOS27

Why every React Native upgrade takes longer than you estimated (and how to estimate honestly)

Rushikesh Pandit — Tue, 13 Oct 2026 14:43:03 +0000

Almost every React Native upgrade I've worked on was estimated in days and delivered in weeks.
It's not that engineers estimate badly. It's that the estimate usually covers the wrong thing.

What we usually estimate

"Bump react-native, fix whatever the Upgrade Helper diff says, run the app."
That's the visible part of the work. The React Native Upgrade Helper
is excellent at it: it shows the file-by-file changes between two versions of a fresh template.

What actually takes the time

Native dependencies. Every library with an ios/ or android/ folder is a separate upgrade inside your upgrade. Each has its own compatibility story, maintainers and release cadence.
Toolchain coupling. A React Native bump can pull in new requirements for Xcode, the Android Gradle Plugin, the JDK or Node. These fail late, in CI, on someone else's machine.
Template drift. Your project's native files stopped matching the template years ago. A diff against a clean template can't know about your custom changes.
Architecture changes. Newer React Native versions change defaults (for example around the New Architecture). Libraries that never adopted the new model become blockers. Check the release notes of your target version for the current state.
Unknown unknowns. Abandoned packages, patched dependencies (patch-package) and forks.

A more honest estimate in four steps

Count native dependencies. The number matters more than total dependencies.
Classify each one: actively maintained / slow / abandoned, and "known compatible with the target version" / "unknown" / "known broken".
Do a time-boxed dry run on a throwaway branch: bump, install, build iOS and Android, record every failure. Stop after a fixed time (say a day).
Estimate from the dry run: your known failures plus a buffer proportional to the unknown count.

Give stakeholders a risk range, not a date

"Two weeks if three unknown dependencies behave, five if they don't" is more useful and more honest than a single number. It also tells your manager where the risk is.

What I'm building

I'm working on a tool, rn-upgrade-doctor, that automates steps 1 and 2 and produces a project-specific risk report. The CLI goes public on 20 Oct. If you want early access: [https://rnupgradedoctor.dev]

What was the worst upgrade estimate you ever got wrong? I'd love to hear it in the comments.

Building a Native QR/Barcode Scanner for React Native — New Architecture Ready

Rushikesh Pandit — Sat, 30 May 2026 09:25:44 +0000

Most QR scanner libraries for React Native share the same problems — they're unmaintained, they don't support the New Architecture, or they pull in a full camera SDK for what is a single-feature module. I wanted something lean, production-grade, and built the right way. So I built it.

This is react-native-qr-camera-pro — a QR and barcode scanner for React Native built entirely with native code. No JavaScript frame processing. No unnecessary dependencies. Swift on iOS, Kotlin on Android, TurboModules and Fabric throughout.

Why Native-Only?

The common alternative is running frame analysis in JavaScript — grabbing frames via a JS-accessible camera API and running a WASM or JS barcode decoder on them. It works, but it puts real pressure on the JS thread and limits your frame rate.

With native-only processing:

iOS uses AVCaptureMetadataOutput — Apple's own pipeline for detecting machine-readable codes. Frames are never copied to user space; the kernel hands off a reference to the same buffer.
Android uses CameraX ImageAnalysis + ML Kit — Google's on-device barcode scanner backed by hardware-accelerated inference where available.

The JS bridge is touched at most once every 500ms to deliver a result. Everything else stays native.

Architecture

The module is three layers:

Architecture

The module is three layers, each with a single responsibility:

Layer	What it does
JavaScript / TypeScript	Public API — `QrCameraProView`, `startScanning()`, `stopScanning()`, `toggleTorch()`, `useBarcodeScanner()`, `useCameraError()`
Native Bridge (TurboModules + Fabric)	Type-safe JSI communication between JS and native. Codegen spec drives both the iOS C++ adapter and the Android Kotlin stub.
Native Platform (iOS + Android)	All camera and barcode logic. AVFoundation on iOS, CameraX + ML Kit on Android. Zero JS involvement in frame processing.

iOS (Swift)

Class	Responsibility
`QrCameraProSwift`	Owns the `AVCaptureSession` lifecycle
`BarcodeThrottler`	Throttle + dedup logic
`BarcodeTypeMapper`	Maps `AVMetadataObject.ObjectType` → JS string
`QrCameraProView`	Hosts `AVCaptureVideoPreviewLayer`
`QrCameraProViewManager`	Vends view instances to Fabric

Android (Kotlin)

Class	Responsibility
`QrCameraProModule`	Camera session lifecycle + event emission
`BarcodeThrottler`	Throttle + dedup logic (same contract as iOS)
`BarcodeFormatMapper`	Maps ML Kit `FORMAT_*` int → JS string
`BarcodeAnalyzer`	CameraX frame analysis + ML Kit client
`QrCameraProView`	Hosts CameraX `PreviewView`
`QrCameraProViewManager`	Vends view instances to Fabric

TurboModules handle all imperative calls (startScanning, stopScanning, toggleTorch) and event emission (onBarcodeScanned, onCameraError) via JSI — no JSON serialisation, no async queue hop.

Fabric handles the camera preview component. The preview surface (AVCaptureVideoPreviewLayer on iOS, CameraX PreviewView on Android) is a native sublayer that React Native sizes and positions. The preview frame rate is fully decoupled from the JS render cycle.

Threading

Getting threads right is the most important part of a camera module.

iOS:

AVCaptureSession setup and startRunning() run on a dedicated background DispatchQueue — Apple's docs are explicit that startRunning() blocks and must not run on the main thread
Metadata callbacks run on DispatchQueue.main — lightweight string reads, no extra context switch needed
All NotificationCenter posts to QrCameraProView happen on main (UIKit requirement)

Android:

bindToLifecycle runs on the UI thread (CameraX requirement)
Frame analysis runs on a dedicated single-thread ExecutorService — keeps the main thread clear
ML Kit results are handled on the same executor thread before being forwarded to JS

Scan Throttling

AVCaptureMetadataOutput and ML Kit can fire multiple times per second for a single held barcode. Forwarding every detection to JavaScript would saturate the bridge.

Both platforms implement a BarcodeThrottler that gates emissions:

Same code within 500ms → suppressed
Same code after 500ms → allowed (intentional re-scan)
Different code → always allowed
Throttle state resets on every stopScanning() call

The 500ms default keeps the bridge load minimal while remaining imperceptible to users.

The JS API

Hooks

// Subscribe to scan results
useBarcodeScanner((barcode: Barcode) => {
  console.log(barcode.data, barcode.type);
});

// Subscribe to camera errors
useCameraError((error: CameraErrorEvent) => {
  Alert.alert('Camera Error', error.message);
});

Both hooks subscribe once on mount and unsubscribe once on unmount — regardless of how many times the parent re-renders or passes a new callback reference. The latest callback is always called via a ref. This keeps the native listener count stable at 1 for the lifetime of the component.

Imperative API

startScanning();   // starts the session, requests permission on Android
stopScanning();    // stops the session, releases camera hardware
toggleTorch(true); // torch on
toggleTorch(false);// torch off

Native view

<QrCameraProView style={{ flex: 1 }} />

Renders AVCaptureVideoPreviewLayer on iOS and CameraX PreviewView on Android. Style it like any other View.

Supported Formats

Type string	Format
`QR_CODE`	QR Code
`EAN_8`	EAN-8
`EAN_13`	EAN-13
`PDF_417`	PDF-417
`AZTEC`	Aztec
`CODE_128`	Code 128
`CODE_39`	Code 39
`CODE_93`	Code 93
`DATA_MATRIX`	Data Matrix
`ITF`	Interleaved 2 of 5
`ITF_14`	ITF-14
`UPC_E`	UPC-E

Installation

yarn add react-native-qr-camera-pro
# or
npm install react-native-qr-camera-pro

iOS — add to Info.plist:

<key>NSCameraUsageDescription</key>
<string>$(PRODUCT_NAME) needs camera access to scan QR codes.</string>

Then cd ios && pod install.

Android — the CAMERA permission is declared in the library manifest and merged automatically. No manual edits needed.

Use Cases

Retail / inventory — scan product barcodes for stock checks
Event check-in — verify QR-coded tickets at entry
Logistics — track packages by scanning shipping labels
Payments — read QR codes for payment flows
Authentication — QR-based 2FA or login

What's Next

Scan region / viewfinder crop
Scan success haptic feedback
Expo plugin

If you're building anything on React Native that needs reliable, fast barcode scanning without pulling in a full camera SDK — give it a try. Feedback welcome, especially from anyone hitting edge cases on specific devices or Android versions.

npm Package
GitHub Repository
Full Documentation
Issue Tracker

Found this helpful? Drop a ❤️ on the article and ⭐ on GitHub!
Questions or suggestions? Drop them in the comments below.

Feel free to reach out:
LinkedIn: https://www.linkedin.com/in/rushikesh-pandit-646834100/
GitHub: https://github.com/rushikeshpandit
Portfolio: https://www.rushikeshpandit.in

ReactNative #TypeScript #MobileDevelopment #SoftwareEngineering #iOS #Android #Swift #Kotlin #OpenSource #TurboModules #CameraX #AVFoundation

Handling Sensitive UI Data in React Native: Practical Approaches Across iOS and Android

Rushikesh Pandit — Tue, 31 Mar 2026 10:06:41 +0000

Handling Sensitive UI Data in React Native

Introduction

As mobile applications increasingly deal with sensitive user data—financial details, personal health information, authentication flows—UI-level privacy becomes a non-trivial concern.

While backend security is well understood, protecting what’s visible on the screen is often overlooked.

The Core Problem

Each platform handles screen privacy differently:

Android

Uses FLAG_SECURE to block screenshots and recordings
Requires ContentObserver to detect screenshots

iOS

No direct API to block screenshots
Relies on UITextField (isSecureTextEntry) behavior

Key Areas to Address

1. Screen Capture Protection

Android provides native support. iOS requires workaround techniques.

2. App Switcher Snapshots

Apps must hide sensitive data before going to background.

3. Screenshot Detection

Detection is possible, prevention is limited.

4. Clipboard Management

Sensitive data should be cleared proactively.

5. Copy/Paste Restrictions

Needs native-level interception.

Architectural Approach

A scalable approach includes:

Hooks for declarative usage
Imperative APIs for lifecycle control
View wrappers for sensitive UI

Trade-offs

iOS limitations on screenshot blocking
Android emulator bypasses
UX vs security balance

Conclusion

UI privacy is a cross-platform engineering problem requiring thoughtful abstraction and careful handling of OS differences.

If you're building anything in fintech, banking, or enterprise on React Native and want a lightweight security layer without pulling in a large SDK — give it a try.
Feedback welcome, especially if you hit false positives on specific devices.

Built with Swift, Kotlin, and C++. No external dependencies.

Links:

npm Package
GitHub Repository
Full Documentation
Issue Tracker

Found this helpful? Drop a ❤️ on the article and ⭐ on GitHub!
Questions or suggestions? Drop them in the comments below!

Feel free to reach out to me if you have any questions or need assistance.
LinkedIn: https://www.linkedin.com/in/rushikesh-pandit-646834100/
GitHub: https://github.com/rushikeshpandit
Portfolio: https://www.rushikeshpandit.in

#ReactNative #TypeScript #MobileDevelopment #SoftwareEngineering #DevCommunity #root-detection #jailbreak-detection #mobile-security
#device-integrity

Detecting Rooted & Jailbroken Devices in React Native — How I Built It and What I Learned

Rushikesh Pandit — Sun, 08 Mar 2026 06:08:32 +0000

I've been working on a React Native security library for the past few months. Not because there wasn't anything out there, but because most existing solutions were either outdated, not maintained, or didn't support the New Architecture.

So I built react-native-root-jail-detect from scratch — native Swift for iOS, Kotlin + C++ for Android, full TurboModules and Fabric support.
Here's what I learned building it.

The Problem With Simple File Checks

Most jailbreak detection libraries do something like this:

let jailbreakPaths = ["/Applications/Cydia.app", "/bin/bash"]
return jailbreakPaths.contains { FileManager.default.fileExists(atPath: $0) }

This works — until it doesn't. /bin/sh exists on stock iOS. /var/log/syslog exists on non-jailbroken devices. And on the simulator, the entire macOS filesystem is exposed, so paths like /usr/bin/ssh and /etc/ssh/sshd_config all exist on a perfectly clean machine.

The fix isn't just a better list of paths. It's knowing which paths are safe to check, where, and when.
For the simulator I gate real-device-only checks behind:

#if targetEnvironment(simulator)
return false
#else
// actual checks
#endif

And paths like /bin/bash only go into a realDeviceOnlyPaths list that never runs on simulator.

Debugger Detection Is Trickier Than It Looks

There are four common approaches:

sysctl P_TRACED — most reliable

var info = kinfo_proc()
var size = MemoryLayout<kinfo_proc>.size
var name: [Int32] = [CTL_KERN, KERN_PROC, KERN_PROC_PID, getpid()]
let ret = sysctl(&name, 4, &info, &size, nil, 0)
guard ret == 0 else { return false }
return (info.kp_proc.p_flag & P_TRACED) != 0

Mach exception ports — catches LLDB specifically

// If EXC_MASK_BREAKPOINT has a valid port registered,
// something is listening for breakpoints
let result = task_get_exception_ports(
    mach_task_self_,
    exception_mask_t(EXC_MASK_BREAKPOINT),
    masks, &count, ports, behaviors, flavors
)
// Validate ports are not MACH_PORT_NULL — avoids false positives

ptrace TRACEME

if ptrace(PT_TRACE_ME, 0, nil, 0) == -1 {
    return errno == EPERM  // already being traced
}
ptrace(PT_DETACH, 0, nil, 0)
return false

TracerPid on Android

File("/proc/self/status").forEachLine { line ->
    if (line.startsWith("TracerPid:")) {
        return line.substringAfter(":").trim().toInt() > 0
    }
}

The gotcha I hit: when you run your app via Xcode on a real device, Xcode automatically attaches LLDB. No breakpoints needed — just running from Xcode is enough to trigger all three iOS checks. The fix is gating these behind #if DEBUG or a custom build flag like SECURITY_CHECKS_ENABLED that you only set on Release and Staging schemes.

Frida Detection

Frida is the main tool attackers use to hook into running apps and bypass security checks. Detecting it has a few layers:

Loaded image scan:

for i in 0..<_dyld_image_count() {
    let name = String(cString: _dyld_get_image_name(i)).lowercased()
    if name.contains("frida") || name.contains("gum-js") {
        return true
    }
}

Symbol lookup:

let suspiciousSymbols = ["gum_js_loop", "frida_agent_main", "gum_script_backend_create"]
for sym in suspiciousSymbols {
    if dlsym(UnsafeMutableRawPointer(bitPattern: -2), sym) != nil {
        return true
    }
}

On Android — memory map scan:

std::ifstream maps("/proc/self/maps");
std::string line;
while (std::getline(maps, line)) {
    if (line.find("frida") != std::string::npos ||
        line.find("gum-js") != std::string::npos) {
        return true;
    }
}

These only catch unobfuscated Frida. A determined attacker can rename the agent. But most script-kiddie level attacks use default Frida, and this catches those reliably.

The Runtime Watchdog

This was the most interesting part to build. File path checks and debugger checks at launch are good, but they miss a common attack pattern:

App launches — device looks clean
Attacker attaches Frida or LLDB after launch
App never re-checks — attacker is in

The watchdog solves this by running checks continuously on a background thread with randomized timing (±40% jitter to make it harder to predict and bypass):

private static func randomDelay(base: TimeInterval) -> TimeInterval {
    let jitter = base * 0.4
    return base + TimeInterval.random(in: -jitter...jitter)
}

It also checks for timing gaps — if the loop stalls for more than interval * 4, it's a signal that the process was paused (e.g. by a debugger hitting a breakpoint):

if now - lastRun > interval * 4 {
    handleThreat(detector: detector)
}

Three response modes depending on how aggressive you want to be:

enum ProtectionMode {
    case logOnly       // log and continue
    case throwException // crash with reason
    case terminate     // kill(getpid(), SIGKILL)
}

For most apps I'd recommend logOnly in staging and terminate in production.

Method Swizzling Detection — What Didn't Work
My first approach was checking if UIViewController.viewDidLoad's IMP pointed back to UIKit:

// ❌ This doesn't work
let imagePath = String(cString: fname).lowercased()
return !imagePath.contains("uikit")

Problem: viewDidLoad is a Swift method. Its IMP can point to a Swift-to-ObjC thunk or a dispatch stub — neither resolves to a UIKit path via dladdr. Every app that overrides viewDidLoad would trigger this.
The fix is checking pure ObjC methods with stable, well-known IMPs instead:

// ✅ This works
let checks: [(AnyClass, Selector, String)] = [
    (NSObject.self, #selector(NSObject.description), "libobjc"),
    (NSObject.self, NSSelectorFromString("respondsToSelector:"), "libobjc"),
    (NSArray.self,  #selector(getter: NSArray.count), "corefounda"),
]
// Verify each IMP resolves back to its expected binary via dladdr

Usage

npm install react-native-root-jail-detect

import RootJailDetect, { SecurityWatchdog, ProtectionMode } from 'react-native-root-jail-detect';

// One-shot check
const isCompromised = await RootJailDetect.isDeviceRooted();
const reasons = await RootJailDetect.getDetectionReasons();

// Continuous monitoring
SecurityWatchdog.start({
  intervalMs: 3000,
  mode: ProtectionMode.TERMINATE,
});

// Stop monitoring
SecurityWatchdog.stop();

What's Next

Certificate pinning integration
Integrity check for the JS bundle itself
Anti-tampering for the native binary

Built with Swift, Kotlin, and C++. No external dependencies.

Links:

npm Package
GitHub Repository
Full Documentation
Issue Tracker

Found this helpful? Drop a ❤️ on the article and ⭐ on GitHub!
Questions or suggestions? Drop them in the comments below!

#ReactNative #TypeScript #MobileDevelopment #SoftwareEngineering #DevCommunity #root-detection #jailbreak-detection #mobile-security
#device-integrity

Published a Lightweight Library for Root/Jailbreak Detection React Native

Rushikesh Pandit — Sun, 22 Feb 2026 12:55:02 +0000

react-native-root-jail-detect

Security is first thing in mobile app development, especially for banking, fintech, and enterprise applications. One critical security measure is detecting whether a device has been rooted (Android) or jailbroken (iOS). These compromised devices can expose your app to security vulnerabilities, data breaches, and unauthorized access.

Today, I'm excited to share react-native-root-jail-detect - a lightweight, open-source library that makes device security checks incredibly simple.

Why Another Root/Jailbreak Detection Library?

When building security-focused React Native apps, I noticed most existing solutions were either:

Too heavy (bloating app size)
Performance-intensive
Closed-source or poorly maintained
Complex APIs requiring extensive setup

I wanted something different: simple, fast, tiny, and open source forever.

What Makes This Special?

Incredibly Lightweight (~60KB)

In a world where every kilobyte matters for app store optimization and user experience, this library weighs in at just ~60KB. That's smaller than most image assets in your app!

# Installation is a breeze
npm install react-native-root-jail-detect

Clean & Simple API

Forget complex configurations. One method, one promise, one boolean result:

import RootJailDetect from 'react-native-root-jail-detect';

const isCompromised = await RootJailDetect.isDeviceRooted();

if (isCompromised) {
  // Handle accordingly - restrict features, show warning, etc.
}

That's it. No configuration files, no initialization, no complex setup.

New Architecture Ready

Built from the ground up to support React Native's new architecture (Fabric and TurboModules). Future-proof your security implementation today.

Battle-Tested Detection Methods

The library doesn't rely on a single detection method. Instead, it employs multiple techniques:

For Android (Root Detection):

Binary file scanning (su, Superuser.apk, etc.)
Runtime command execution attempts
Multiple common root path checks

For iOS (Jailbreak Detection):

Cydia and jailbreak app detection
Restricted file system access attempts
Sandbox integrity verification

Real-World Usage Example

Here's how you might integrate it into a banking app:

import React, { useEffect, useState } from 'react';
import { Alert } from 'react-native';
import RootJailDetect from 'react-native-root-jail-detect';

const BankingApp = () => {
  const [securityPassed, setSecurityPassed] = useState(false);

  useEffect(() => {
    performSecurityCheck();
  }, []);

  const performSecurityCheck = async () => {
    try {
      const isRooted = await RootJailDetect.isDeviceRooted();

      if (isRooted) {
        Alert.alert(
          'Security Alert',
          'Your device appears to be rooted/jailbroken. ' +
          'For your security, some features will be restricted.',
          [
            { text: 'Learn More', onPress: () => openSecurityInfo() },
            { text: 'OK', style: 'cancel' }
          ]
        );
        setSecurityPassed(false);
      } else {
        setSecurityPassed(true);
      }
    } catch (error) {
      console.error('Security check failed:', error);
      // Handle gracefully - perhaps allow access but log the incident
      setSecurityPassed(true);
    }
  };

  if (!securityPassed) {
    return <RestrictedModeUI />;
  }

  return <FullBankingFeatures />;
};

Perfect Use Cases

This library shines in applications requiring enhanced security:

Banking & Fintech Apps:
- Protect transaction integrity
- Comply with financial regulations
- Prevent unauthorized access to accounts
Enterprise Applications
- Enforce corporate security policies
- MDM compliance
- Protect confidential business data
Healthcare Apps
- HIPAA compliance requirements
- Patient data protection
- Secure telehealth platforms
Gaming Apps
- Prevent cheating
- Protect in-app purchases
- Maintain fair gameplay
E-commerce & Payment Apps
- PCI-DSS compliance
- Secure payment processing
- Fraud prevention

Important Considerations

While this library is highly effective, it's important to understand its limitations:

Not 100% Foolproof: Sophisticated concealment tools exist (RootCloak, Liberty, etc.)
Part of Defense-in-Depth: Use alongside SSL pinning, code obfuscation, and server-side validation
User Experience Matters: Don't alienate legitimate users with heavy-handed restrictions
Keep Updated: Root/jailbreak methods evolve; regular updates are crucial

Best Practices for Implementation

Graceful Degradation

Don't immediately lock users out. Consider a tiered approach:

const handleRootedDevice = async () => {
  const isRooted = await RootJailDetect.isDeviceRooted();

  if (isRooted) {
    // Tier 1: Show warning, allow basic features
    showSecurityWarning();

    // Tier 2: Disable sensitive features
    disableBiometricAuth();
    disableStoredPaymentMethods();

    // Tier 3: Require additional verification
    requireTwoFactorAuth();

    // Analytics: Log for fraud detection
    logSecurityEvent('rooted_device_detected');
  }
};

Combine with Other Security Measures

const comprehensiveSecurityCheck = async () => {
  const checks = await Promise.all([
    RootJailDetect.isDeviceRooted(),
    checkSSLPinning(),
    validateAppIntegrity(),
    verifyDebuggerAbsence()
  ]);

  return checks.every(check => check === true);
};

Server-Side Validation

Never rely solely on client-side checks:

const authenticateWithSecurityCheck = async (credentials) => {
  const isRooted = await RootJailDetect.isDeviceRooted();

  // Send security status to backend
  const response = await fetch('/api/auth', {
    method: 'POST',
    body: JSON.stringify({
      ...credentials,
      deviceSecurity: {
        isRooted,
        deviceId: getDeviceId(),
        appIntegrity: getAppSignature()
      }
    })
  });

  // Server makes final decision on access
  return response.json();
};

Open Source Forever

This project is and will always remain 100% open source under the MIT license. Why?

Transparency: Security through obscurity doesn't work
Community: Better detection methods emerge from collaborative effort
Trust: You can audit every line of code
Innovation: Fork it, modify it, contribute back

Every contribution, no matter how small, makes a difference!

Get Started Today

# Install
npm install react-native-root-jail-detect

# iOS
cd ios && pod install && cd ..

# Use
import RootJailDetect from 'react-native-root-jail-detect';
const isRooted = await RootJailDetect.isDeviceRooted();

Building secure mobile apps doesn't have to be complicated or expensive. With react-native-root-jail-detect, you get enterprise-grade security detection in a package smaller than a thumbnail image.

Whether you're building the next fintech unicorn or a simple app that handles sensitive data, this library provides the peace of mind that comes with knowing your users' device integrity.

Give it a try, star the repo, and join me in making React Native apps more secure for everyone!

Links:

npm Package
GitHub Repository
Full Documentation
Issue Tracker

Found this helpful? Drop a ❤️ on the article and ⭐ on GitHub!
Questions or suggestions? Drop them in the comments below!

#ReactNative #TypeScript #MobileDevelopment #SoftwareEngineering #DevCommunity #root-detection #jailbreak-detection #mobile-security
#device-integrity

Mastering React Native with TypeScript: From Basics to Brilliance - Part 3

Rushikesh Pandit — Sat, 02 Aug 2025 15:03:53 +0000

React Native has come a long way, and with the latest versions offering improved performance and TypeScript-first development, it’s a great time to dive into building robust apps with navigation and API communication in mind.
In this article, we’ll explore:

Setting up React Navigation in a TypeScript project
Working with Stacks and Tabs
Managing API calls with axios and useEffect
Handling loading, error, and data states
Bonus: Tips for organizing your codebase!

Prerequisites

Node.js 18+
React Native CLI or Expo (we'll go with bare React Native here)
React Native 0.76+
TypeScript
Basic understanding of React Native components

Setup React Navigation

First, install the required dependencies:

npm install @react-navigation/native
npm install react-native-screens react-native-safe-area-context react-native-gesture-handler react-native-reanimated
npx pod-install

Then install the stack and bottom tab navigators:

npm install @react-navigation/native-stack @react-navigation/bottom-tabs

Update babel.config.js for reanimated (if not Expo):

module.exports = {
  presets: ['module:metro-react-native-babel-preset'],
  plugins: ['react-native-reanimated/plugin'],
};

Create Navigation Structure

navigation/RootNavigator.tsx

import React from 'react';
import { NavigationContainer } from '@react-navigation/native';
import { createNativeStackNavigator } from '@react-navigation/native-stack';
import HomeScreen from '../screens/HomeScreen';
import DetailsScreen from '../screens/DetailsScreen';

export type RootStackParamList = {
  Home: undefined;
  Details: { userId: number };
};

const Stack = createNativeStackNavigator<RootStackParamList>();

const RootNavigator = () => (
  <NavigationContainer>
    <Stack.Navigator initialRouteName="Home">
      <Stack.Screen name="Home" component={HomeScreen} />
      <Stack.Screen name="Details" component={DetailsScreen} />
    </Stack.Navigator>
  </NavigationContainer>
);

export default RootNavigator;

Create Screen Components for Home Screen

screens/HomeScreen.tsx

import React, { useEffect, useState } from 'react';
import { View, Text, Button, FlatList, ActivityIndicator } from 'react-native';
import axios from 'axios';
import { NativeStackScreenProps } from '@react-navigation/native-stack';
import { RootStackParamList } from '../navigation/RootNavigator';

type Props = NativeStackScreenProps<RootStackParamList, 'Home'>;

interface User {
  id: number;
  name: string;
}

const HomeScreen: React.FC<Props> = ({ navigation }) => {
  const [users, setUsers] = useState<User[]>([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    axios.get<User[]>('https://jsonplaceholder.typicode.com/users')
      .then(response => setUsers(response.data))
      .catch(err => setError(err.message))
      .finally(() => setLoading(false));
  }, []);

  if (loading) return <ActivityIndicator />;
  if (error) return <Text>Error: {error}</Text>;

  return (
    <FlatList
      data={users}
      keyExtractor={item => item.id.toString()}
      renderItem={({ item }) => (
        <View style={{ padding: 10 }}>
          <Text>{item.name}</Text>
          <Button
            title="View Details"
            onPress={() => navigation.navigate('Details', { userId: item.id })}
          />
        </View>
      )}
    />
  );
};

export default HomeScreen;

Create Screen Components for Detail Screen

screens/DetailsScreen.tsx

import React, { useEffect, useState } from 'react';
import { View, Text, ActivityIndicator } from 'react-native';
import { NativeStackScreenProps } from '@react-navigation/native-stack';
import axios from 'axios';
import { RootStackParamList } from '../navigation/RootNavigator';

type Props = NativeStackScreenProps<RootStackParamList, 'Details'>;

interface UserDetail {
  id: number;
  name: string;
  email: string;
  phone: string;
}

const DetailsScreen: React.FC<Props> = ({ route }) => {
  const { userId } = route.params;
  const [user, setUser] = useState<UserDetail | null>(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    axios.get<UserDetail>(`https://jsonplaceholder.typicode.com/users/${userId}`)
      .then(response => setUser(response.data))
      .finally(() => setLoading(false));
  }, [userId]);

  if (loading) return <ActivityIndicator />;
  if (!user) return <Text>No user found</Text>;

  return (
    <View style={{ padding: 20 }}>
      <Text style={{ fontSize: 18 }}>{user.name}</Text>
      <Text>{user.email}</Text>
      <Text>{user.phone}</Text>
    </View>
  );
};

export default DetailsScreen;

Organize API Layer (Optional but Recommended)

Create a file api/client.ts:

import axios from 'axios';

const client = axios.create({
  baseURL: 'https://jsonplaceholder.typicode.com/',
  timeout: 5000,
});

export default client;

Then import and use client.get() instead of axios.get().

Project Structure Suggestion

/src
  /navigation
    RootNavigator.tsx
  /screens
    HomeScreen.tsx
    DetailsScreen.tsx
  /api
    client.ts
  /types
    index.ts
App.tsx

Final Thoughts

React Navigation’s TypeScript support makes route safety a breeze.
Centralizing API calls helps scale and debug faster.
Handling loading/error/data states improves user experience.
Organize your folders early—it pays off later!

That's it for today. In the next part of this series, we’ll explore advanced topics like redux toolkit and it's implementation.

#ReactNative #TypeScript #MobileDevelopment #SoftwareEngineering #DevCommunity

Mastering React Native with TypeScript: From Basics to Brilliance - Part 2

Rushikesh Pandit — Sat, 26 Jul 2025 07:21:13 +0000

React Native hooks provide an intuitive way to manage state and side effects in your components. Introduced in React 16.8, hooks allow us to use state and other React features without writing class components, making functional components powerful and more readable.

In this article, we will explore the most commonly used hooks, how they work, and how you can leverage them in your React Native projects. We’ll also look at how to create custom hooks.

Why Hooks?

Hooks are functions that let you “hook into” React state and lifecycle features from function components. They make your code cleaner, easier to understand, and reusable.

`useState`

useState is one of the most commonly used hooks. It lets you add state to functional components. With useState, you can create variables that store component-level data and re-render your component whenever that data changes.

import React, { useState } from 'react';
import { Text, Button, View } from 'react-native';

const Counter = () => {
  const [count, setCount] = useState<number>(0);

  return (
    <View>
      <Text>Count: {count}</Text>
      <Button title="Increase" onPress={() => setCount(count + 1)} />
    </View>
  );
};

export default Counter;

How it works:

useState takes the initial value (0 in the example) and returns an array containing the current value (count) and a function to update it (setCount).

`useEffect`

useEffect is used to perform side effects in function components. It runs after every render by default but can also be customized to run only when specific values change.

import React, { useState, useEffect } from 'react';
import { Text, View } from 'react-native';

const DataFetcher = () => {
  const [data, setData] = useState<string | null>(null);

  useEffect(() => {
    // Simulate fetching data from an API
    const fetchData = async () => {
      const result = await new Promise((resolve) => 
        setTimeout(() => resolve("Fetched Data"), 2000)
      );
      setData(result as string);
    };

    fetchData();
  }, []); // empty array ensures this runs once when the component mounts

  return <View>{data ? <Text>{data}</Text> : <Text>Loading...</Text>}</View>;
};

export default DataFetcher;

How it works:

useEffect runs after the component renders. In this case, we simulate fetching data, and the effect only runs once because of the empty dependency array [].

`useContext`

useContext allows you to use values from React's Context API. This is helpful for passing data like theme or authentication information without prop drilling.

import React, { createContext, useContext } from 'react';
import { Text, View } from 'react-native';

// Create a context
const ThemeContext = createContext('light');

const ThemedComponent = () => {
  const theme = useContext(ThemeContext);
  return <Text>Current Theme: {theme}</Text>;
};

const App = () => (
  <ThemeContext.Provider value="dark">
    <View>
      <ThemedComponent />
    </View>
  </ThemeContext.Provider>
);

export default App;

How it works:

useContext allows you to consume the value of the nearest ThemeContext.Provider, eliminating the need to pass down props manually.

`useReducer`

useReducer is similar to useState but is used for more complex state logic. It is often used when the state has multiple transitions.

import React, { useReducer } from 'react';
import { Text, Button, View } from 'react-native';

type Action = { type: 'increment' | 'decrement' };
const reducer = (state: number, action: Action) => {
  switch (action.type) {
    case 'increment':
      return state + 1;
    case 'decrement':
      return state - 1;
    default:
      return state;
  }
};

const Counter = () => {
  const [count, dispatch] = useReducer(reducer, 0);

  return (
    <View>
      <Text>Count: {count}</Text>
      <Button title="Increase" onPress={() => dispatch({ type: 'increment' })} />
      <Button title="Decrease" onPress={() => dispatch({ type: 'decrement' })} />
    </View>
  );
};

export default Counter;

How it works:

useReducer takes a reducer function and an initial state, returning the current state and a dispatch function to trigger state changes.

`useCallback`

useCallback is used to memoize functions so they aren’t recreated on every render, which can be useful for optimization in child components.

import React, { useState, useCallback } from 'react';
import { Text, Button, View } from 'react-native';

const ChildComponent = React.memo(({ onClick }: { onClick: () => void }) => (
  <Button title="Click me" onPress={onClick} />
));

const ParentComponent = () => {
  const [count, setCount] = useState(0);

  const increment = useCallback(() => {
    setCount((prev) => prev + 1);
  }, []); // Function is memoized, won't recreate unless dependencies change

  return (
    <View>
      <Text>Count: {count}</Text>
      <ChildComponent onClick={increment} />
    </View>
  );
};

export default ParentComponent;

How it works:

useCallback returns a memoized version of the increment function, ensuring it is not recreated unless dependencies change.

`useMemo`

useMemo is used to memoize values instead of functions. It recalculates the value only when dependencies change, improving performance in expensive calculations.

import React, { useMemo, useState } from 'react';
import { Text, Button, View } from 'react-native';

const ExpensiveComponent = () => {
  const [count, setCount] = useState(0);

  const expensiveCalculation = useMemo(() => {
    // Simulate an expensive computation
    return count * 1000;
  }, [count]);

  return (
    <View>
      <Text>Result: {expensiveCalculation}</Text>
      <Button title="Increase Count" onPress={() => setCount(count + 1)} />
    </View>
  );
};

export default ExpensiveComponent;

How it works:

useMemo ensures the expensive calculation runs only when count changes.

`useRef`

useRef is used to persist values across renders without causing a re-render. It’s often used to reference DOM elements or hold mutable values.

import React, { useRef } from 'react';
import { Button, TextInput, View } from 'react-native';

const InputFocus = () => {
  const inputRef = useRef<TextInput | null>(null);

  const focusInput = () => {
    inputRef.current?.focus();
  };

  return (
    <View>
      <TextInput ref={inputRef} style={{ height: 40, borderColor: 'gray', borderWidth: 1 }} />
      <Button title="Focus Input" onPress={focusInput} />
    </View>
  );
};

export default InputFocus;

How it works:

useRef creates a reference to the TextInput component, allowing us to programmatically control its focus.

`useLayoutEffect`

useLayoutEffect works similarly to useEffect but is fired synchronously after all DOM mutations, ensuring your effect runs before the browser paints.

import React, { useLayoutEffect, useState } from 'react';
import { Text, View } from 'react-native';

const LayoutEffectComponent = () => {
  const [layout, setLayout] = useState({ width: 0, height: 0 });

  useLayoutEffect(() => {
    // This effect runs before the browser updates the screen
    setLayout({ width: 100, height: 100 });
  }, []);

  return (
    <View style={{ width: layout.width, height: layout.height }}>
      <Text>Layout size: {layout.width} x {layout.height}</Text>
    </View>
  );
};

export default LayoutEffectComponent;

How it works:

useLayoutEffect is useful for reading layout measurements and synchronizing DOM mutations.

Creating Custom Hooks

Custom hooks allow you to extract and reuse logic from components. They are simply functions that use hooks internally.

import { useState, useEffect } from 'react';

const useFetchData = (url: string) => {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const fetchData = async () => {
      const response = await fetch(url);
      const result = await response.json();
      setData(result);
      setLoading(false);
    };
    fetchData();
  }, [url]);

  return { data, loading };
};

export default useFetchData;

You can now use useFetchData in any component to fetch data.

import React from 'react';
import { Text, View } from 'react-native';
import useFetchData from './useFetchData';

const DataComponent = () => {
  const { data, loading } = useFetchData('https://jsonplaceholder.typicode.com/todos/1');

  return (
    <View>{loading ? <Text>Loading...</Text> : <Text>{JSON.stringify(data)}</Text>}</View>
  );
};

export default DataComponent;

React hooks, combined with TypeScript, offer a powerful and concise way to manage state and side effects in your React Native apps. By mastering hooks like useState, useEffect, and others, you can write cleaner, more efficient components. Additionally, creating custom hooks allows you to reuse logic across your application.

That's it for today. In the next part of this series, we’ll explore advanced topics like navigation, animations, and working with APIs.

#ReactNative #TypeScript #MobileDevelopment #SoftwareEngineering #DevCommunity

Mastering React Native with TypeScript: From Basics to Brilliance - Part 1

Rushikesh Pandit — Thu, 09 Jan 2025 14:37:05 +0000

Are you ready to dive into the world of mobile app development without mastering two separate languages for iOS and Android? Meet React Native—the game-changing framework from Facebook that lets you build high-performance, cross-platform apps using the language you already love: JavaScript (and in our case, TypeScript)!

With React Native, you can build apps that look, feel, and perform as a true native app would. No wonder it's powering industry-leading apps like Instagram, Airbnb, and Tesla.

Kickstarting your journey into the world of React Native 0.76 with TypeScript, we are going to go over what the core building blocks of any application are. Whether you're a curious beginner or an experienced developer seeking to hone your abilities in TypeScript, this guide will get you moving toward mobile development greatness.

We're covering everything you need to know to build your first app:

The Core Components include View, Text, and ScrollView
Styling techniques that make your UI pop
Managing Props and State for dynamic interactions
Mastering lists with FlatList for seamless data handling

By the end of this series, you’ll not only understand the foundation of React Native but also have practical, real-world code snippets to kickstart your app development journey. Let’s make your dream app a reality—starting now!!

Core Components in React Native

Core components are the basic building blocks of every React Native application. They connect the JavaScript world with the native world, and that is where you get the building blocks to craft amazing user interfaces. Let's take a look at each of them.

1 . View

The View component is the fundamental container in React Native. It’s used to group and layout other components. Think of it as a div in web development.

Example: Creating a Centered Box

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

const App = () => (
  <View style={styles.container}>
    <View style={styles.box} />
  </View>
);

const styles = StyleSheet.create({
  container: { flex: 1, justifyContent: 'center', alignItems: 'center' },
  box: { width: 100, height: 100, backgroundColor: 'blue' },
});

export default App;

Here, we use flex: 1 to ensure the View fills the entire screen, and justifyContent and alignItems center the box.

2 . Text

The Text component is used for rendering text on the screen. It supports various text styles and nested elements.

Example: Displaying Styled Text

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

const App = () => (
  <Text style={styles.text}>Hello, React Native with TypeScript!</Text>
);

const styles = StyleSheet.create({
  text: { fontSize: 20, color: 'purple', textAlign: 'center', marginTop: 20 },
});

export default App;

Notice how we use fontSize, color, and textAlign to style the Text component.

3 . Image

The Image component is used to display images. It supports both local and remote image sources.

Example: Displaying a Remote Image

import React from 'react';
import { Image, StyleSheet } from 'react-native';

const App = () => (
  <Image
    source={{ uri: 'https://reactnative.dev/img/tiny_logo.png' }}
    style={styles.image}
  />
);

const styles = StyleSheet.create({
  image: { width: 100, height: 100, borderRadius: 10 },
});

export default App;

The borderRadius property gives the image rounded corners.

4 . TextInput

The TextInput component captures user input. It supports properties like placeholder, onChangeText, and value.

Example: Handling User Input

import React, { useState } from 'react';
import { TextInput, StyleSheet, View, Text } from 'react-native';

const App = () => {
  const [input, setInput] = useState<string>('');

  return (
    <View style={styles.container}>
      <TextInput
        style={styles.input}
        placeholder="Type here..."
        value={input}
        onChangeText={setInput}
      />
      <Text>You typed: {input}</Text>
    </View>
  );
};

const styles = StyleSheet.create({
  container: { padding: 20 },
  input: { borderWidth: 1, borderColor: '#ccc', padding: 10, borderRadius: 5, marginBottom: 10 },
});

export default App;

The onChangeText handler updates the state with the user’s input.

5 . TouchableOpacity

The TouchableOpacity component enables touch interactions with a fading effect.

Example: Creating a Button

import React from 'react';
import { TouchableOpacity, Text, StyleSheet } from 'react-native';

const App = () => (
  <TouchableOpacity style={styles.button} onPress={() => alert('Button Pressed!')}>
    <Text style={styles.text}>Press Me</Text>
  </TouchableOpacity>
);

const styles = StyleSheet.create({
  button: { backgroundColor: 'blue', padding: 10, borderRadius: 5 },
  text: { color: 'white', textAlign: 'center' },
});

export default App;

The onPress handler triggers an action when the button is tapped.

6 . ScrollView

The ScrollView component allows for scrollable content. It’s ideal for layouts with a small amount of content that won’t require heavy performance optimization.

Example: Rendering a Scrollable List

import React from 'react';
import { ScrollView, Text, StyleSheet } from 'react-native';

const App = () => (
  <ScrollView contentContainerStyle={styles.container}>
    {Array.from({ length: 20 }, (_, i) => (
      <Text key={i} style={styles.text}>Item {i + 1}</Text>
    ))}
  </ScrollView>
);

const styles = StyleSheet.create({
  container: { padding: 10 },
  text: { fontSize: 16, marginVertical: 5 },
});

export default App;

Here, we dynamically generate 20 items and render them inside a ScrollView.

7 . FlatList

The FlatList component is designed for rendering large datasets efficiently. It only renders items currently visible on the screen, significantly improving performance.

Example: Rendering a List

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

const data = [
  { id: '1', name: 'Item 1' },
  { id: '2', name: 'Item 2' },
  { id: '3', name: 'Item 3' },
];

const App = () => (
  <FlatList
    data={data}
    keyExtractor={(item) => item.id}
    renderItem={({ item }) => (
      <View style={styles.item}>
        <Text style={styles.text}>{item.name}</Text>
      </View>
    )}
  />
);

const styles = StyleSheet.create({
  item: {
    padding: 20,
    borderBottomWidth: 1,
    borderBottomColor: '#ccc',
  },
  text: {
    fontSize: 18,
  },
});

export default App;

Key Difference Between FlatList and ScrollView:

Use FlatList for large, dynamic datasets to optimize performance.
Use ScrollView for smaller datasets or static content.

Styling in React Native

Styling in React Native is achieved using the StyleSheet API. It borrows heavily from CSS but is tailored to work with native platforms for optimal performance.

1 . StyleSheet API

The StyleSheet API provides a way to define styles separately and reuse them across components.

Example: Creating Reusable Styles

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

const App = () => (
  <View style={styles.container}>
    <Text style={styles.text}>Reusable Styles with StyleSheet</Text>
  </View>
);

const styles = StyleSheet.create({
  container: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
    backgroundColor: '#f0f0f0',
  },
  text: {
    fontSize: 20,
    color: 'blue',
  },
});

export default App;

2 . Flexbox Layout

React Native employs Flexbox for layout management. Flexbox helps to define the alignment, distribution, and spacing of elements within a container.

Example: Aligning Items Horizontally

const styles = StyleSheet.create({
  container: {
    flex: 1,
    flexDirection: 'row',
    justifyContent: 'space-between',
    alignItems: 'center',
    padding: 10,
  },
});

3 . Platform-Specific Styling

React Native allows platform-specific styles using the Platform module.

Example: Conditional Styling

import { Platform, StyleSheet } from 'react-native';

const styles = StyleSheet.create({
  text: {
    fontSize: Platform.OS === 'ios' ? 20 : 18,
    color: Platform.OS === 'ios' ? 'blue' : 'green',
  },
});

Props and State Management

1 . Props

Props allow you to pass data from a parent component to a child component.

Example: Custom Greeting Component

import React from 'react';
import { Text } from 'react-native';

const Greeting = ({ name }: { name: string }) => (
  <Text>Hello, {name}!</Text>
);

const App = () => <Greeting name="React Native" />;

export default App;

2 . State Management with useState

The useState hook is used to manage state in functional components.

Example: Counter Component

import React, { useState } from 'react';
import { View, Text, Button, StyleSheet } from 'react-native';

const Counter = () => {
  const [count, setCount] = useState<number>(0);

  return (
    <View style={styles.container}>
      <Text style={styles.text}>Count: {count}</Text>
      <Button title="Increase" onPress={() => setCount(count + 1)} />
    </View>
  );
};

const styles = StyleSheet.create({
  container: {
    padding: 20,
  },
  text: {
    fontSize: 18,
    marginBottom: 10,
  },
});

export default Counter;

3 . Typing Props with TypeScript

Using TypeScript ensures type safety when passing props.

Example: Typing Props

interface GreetingProps {
  name: string;
}

const Greeting = ({ name }: GreetingProps) => (
  <Text>Hello, {name}!</Text>
);

That's it for today. In the next part of this series, we’ll explore advanced topics like navigation, animations, hooks, and working with APIs.

#ReactNative #TypeScript #MobileDevelopment #SoftwareEngineering #DevCommunity

Leverage ETS for Shared State in Phoenix

Rushikesh Pandit — Mon, 09 Dec 2024 13:45:00 +0000

When building web applications, managing shared state efficiently is often a challenge. For Elixir developers, ETS (Erlang Term Storage) provides an incredibly powerful tool to tackle this problem. ETS is a robust, in-memory data store built into the Erlang VM, offering fast lookups, concurrent access, and persistence during a process’s lifetime.

In this blog, we’ll explore how ETS works, why it’s an excellent choice for shared state in Phoenix applications, and demonstrate practical examples with code snippets.

What is ETS?

ETS (Erlang Term Storage) is a highly efficient in-memory storage system available in Elixir and Erlang. It supports storing key-value pairs, lists, and tuples and is designed to handle high-performance operations with concurrent reads and writes. ETS tables live as long as the process that owns them, making them ideal for managing temporary or shared state.

Why Use ETS in Phoenix?

ETS is a great fit for Phoenix applications in scenarios such as:

Caching: Store frequently accessed data, such as API responses or computed results, for quick retrieval.
Session Management: Maintain temporary user session data across requests.
Rate Limiting: Track user activity to enforce API rate limits.
Real-Time Data Sharing: Share data between processes efficiently.

ETS Basics

To get started, let’s create and manipulate a simple ETS table. You can create a table using :ets.new/2 and interact with it using functions like :ets.insert/2 and :ets.lookup/2.

# Creating an ETS table
table = :ets.new(:example_table, [:set, :public])

# Inserting data
:ets.insert(table, {:key, "value"})

# Retrieving data
case :ets.lookup(table, :key) do
  [{:key, value}] -> IO.puts("Found: #{value}")
  [] -> IO.puts("Not found")
end

Using ETS in Phoenix

Let’s dive into a practical example: caching frequently accessed data in a Phoenix application.

1. ETS for Caching API Data

Suppose you have a Phoenix controller that fetches data from an external API. Instead of fetching the data on every request, you can cache the result in ETS.

ETS Cache Setup

Create a module to manage your ETS table:

defmodule MyApp.Cache do
  @table :api_cache

  def start_link do
    :ets.new(@table, [:named_table, :set, :public, read_concurrency: true])
    {:ok, %{}}
  end

  def put(key, value) do
    :ets.insert(@table, {key, value})
  end

  def get(key) do
    case :ets.lookup(@table, key) do
      [{^key, value}] -> {:ok, value}
      [] -> :error
    end
  end
end

Fetching and Caching API Data

Use this module in your controller:

defmodule MyAppWeb.PageController do
  use MyAppWeb, :controller

  alias MyApp.Cache

  def index(conn, _params) do
    data =
      case Cache.get(:api_data) do
        {:ok, cached_data} ->
          cached_data

        :error ->
          # Fetch data from external API
          api_data = fetch_data_from_api()
          Cache.put(:api_data, api_data)
          api_data
      end

    render(conn, "index.html", data: data)
  end

  defp fetch_data_from_api do
    # Simulated API call
    %{key: "value", timestamp: DateTime.utc_now()}
  end
end

Now, subsequent requests to index/2 will retrieve data from the ETS cache instead of making repeated API calls.

2. Rate Limiting with ETS

Another practical use case is rate limiting. You can use ETS to track how many requests a user has made within a given time window.

Rate Limiter Module

defmodule MyApp.RateLimiter do
  @table :rate_limiter

  def start_link do
    :ets.new(@table, [:named_table, :set, :public])
    {:ok, %{}}
  end

  def allow?(user_id, limit \\ 10) do
    case :ets.lookup(@table, user_id) do
      [{^user_id, count}] when count >= limit ->
        false

      [{^user_id, count}] ->
        :ets.insert(@table, {user_id, count + 1})
        true

      [] ->
        :ets.insert(@table, {user_id, 1})
        true
    end
  end
end

Using the Rate Limiter

Integrate it into a Phoenix controller to enforce limits:

defmodule MyAppWeb.ApiController do
  use MyAppWeb, :controller

  alias MyApp.RateLimiter

  def index(conn, _params) do
    user_id = get_user_id(conn)

    if RateLimiter.allow?(user_id) do
      json(conn, %{message: "Request allowed"})
    else
      conn
      |> put_status(:too_many_requests)
      |> json(%{error: "Rate limit exceeded"})
    end
  end

  defp get_user_id(conn) do
    # Example: extract user ID from session or token
    conn.assigns[:current_user].id
  end
end

This setup ensures that a user cannot exceed the specified request limit, and ETS handles the tracking efficiently.

Advanced ETS Tips

Named Tables: Use named tables ([:named_table]) for global access across processes.
Concurrency Options: Use :read_concurrency and :write_concurrency for performance optimization in read-heavy or write-heavy scenarios.
Persistence: Combine ETS with :dets (Disk ETS) to persist data across application restarts.

Limitations of ETS
While ETS is powerful, it’s important to be aware of its limitations:

Table Lifespan: Tables are tied to the lifecycle of their owning process. If the process crashes, the table is lost.
Manual Garbage Collection: ETS doesn’t automatically manage expired data. You’ll need to implement a cleanup mechanism if necessary.
Cluster Awareness: ETS is not distributed across nodes in a cluster. For distributed setups, consider using Mnesia or a database.

ETS is a fantastic tool for managing shared state in Phoenix applications. Its simplicity and speed make it ideal for caching, rate limiting, and real-time data sharing. However, understanding its limitations is key to using it effectively.

Have you used ETS in your Phoenix projects? Share your experiences in the comments or let me know what other ETS use cases you'd like to explore!

Feel free to reach out if you need help.

LinkedIn: https://www.linkedin.com/in/rushikesh-pandit
GitHub: https://github.com/rushikeshpandit
Portfolio: https://www.rushikeshpandit.in

#myelixirstatus , #elixir , #phoenixframework

Harness PubSub for Real-Time Features in Phoenix Framework

Rushikesh Pandit — Mon, 02 Dec 2024 13:03:14 +0000

When it comes to building real-time web applications, the Phoenix framework is hard to beat. At the heart of its real-time capabilities lies Phoenix.PubSub, a powerful messaging system that allows processes to subscribe to and broadcast messages within an application. Whether you’re building live notifications, collaborative tools, or event-driven systems, PubSub is your go-to tool.

In this blog, we’ll explore how Phoenix.PubSub works, dive into practical use cases, and demonstrate step-by-step examples to integrate it into your projects.

What is Phoenix.PubSub?

Phoenix.PubSub is a publish-subscribe mechanism built into the Phoenix framework. It allows you to broadcast messages to multiple subscribers efficiently, enabling real-time communication across your application.

Key Concepts:

Publishers: Send messages to a specific topic.
Subscribers: Listen for messages on topics they are interested in.
Topics: Strings representing the channel for communication (e.g., "notifications", "room:lobby"). PubSub is transport-agnostic, meaning it can work seamlessly across distributed systems.

Why Use PubSub?

PubSub is an excellent fit for scenarios like:

Real-time notifications: Push updates instantly to users (e.g., alerts, badges).
Collaborative tools: Enable live edits or actions in shared environments (e.g., Google Docs-style collaboration).
Event broadcasting: Notify multiple processes of significant events (e.g., user activity).
Scalability: Distribute messages across nodes in a clustered environment.

Setting Up PubSub

PubSub is automatically included in new Phoenix applications, but to use it effectively, let’s break down the setup.

1. Configuration
Ensure your application’s PubSub module is defined in lib/my_app/application.ex. It’s typically added by default.

defmodule MyApp.Application do
  use Application

  def start(_type, _args) do
    children = [
      {Phoenix.PubSub, name: MyApp.PubSub}
    ]

    opts = [strategy: :one_for_one, name: MyApp.Supervisor]
    Supervisor.start_link(children, opts)
  end
end

2. Broadcasting Messages

Use Phoenix.PubSub.broadcast/3 to send messages to a specific topic.

Phoenix.PubSub.broadcast(MyApp.PubSub, "notifications", %{message: "New user signed up!"})

3. Subscribing to Topics

Processes can subscribe to a topic using Phoenix.PubSub.subscribe/2.

Phoenix.PubSub.subscribe(MyApp.PubSub, "notifications")

Real-World Example: Notifications System

Let’s build a simple notification system where users receive real-time updates whenever a new notification is added.

Creating the PubSub Integration

1. Subscribe to Notifications
When a LiveView mounts, subscribe the process to the "notifications" topic.

def mount(_params, _session, socket) do
  Phoenix.PubSub.subscribe(MyApp.PubSub, "notifications")
  {:ok, assign(socket, notifications: [])}
end

2. Handle Incoming Messages
When a message is broadcasted, handle it with handle_info/2 and update the LiveView state.

def handle_info(%{message: message}, socket) do
  {:noreply, assign(socket, notifications: [message | socket.assigns.notifications])}
end

3. Broadcast Notifications
Trigger broadcasts from any part of the app (e.g., a controller or background worker).

def notify_users(message) do
  Phoenix.PubSub.broadcast(MyApp.PubSub, "notifications", %{message: message})
end

LiveView Template

<div id="notifications">
  <h3>Notifications</h3>
  <ul>
    <%= for notification <- @notifications do %>
      <li><%= notification %></li>
    <% end %>
  </ul>
</div>

With these steps, users will receive live updates in their notifications list whenever notify_users/1 is called.

Advanced Use Case: Collaborative Editing

PubSub shines in collaborative tools. For instance, imagine a real-time collaborative text editor where multiple users edit the same document.

Broadcasting Edits

def handle_event("edit", %{"content" => content}, socket) do
  Phoenix.PubSub.broadcast(MyApp.PubSub, "document:123", %{content: content})
  {:noreply, socket}
end

Subscribing to Edits

def mount(_params, _session, socket) do
  Phoenix.PubSub.subscribe(MyApp.PubSub, "document:123")
  {:ok, assign(socket, content: "")}
end

def handle_info(%{content: content}, socket) do
  {:noreply, assign(socket, content: content)}
end

Testing PubSub

You can test your PubSub implementation easily using iex. Open multiple iex sessions and ensure they subscribe to the same topic:

Phoenix.PubSub.subscribe(MyApp.PubSub, "test_topic")

Phoenix.PubSub.broadcast(MyApp.PubSub, "test_topic", %{data: "Hello, PubSub!"})

All subscribers to "test_topic" should receive the broadcast message.

Scaling PubSub Across Nodes

Phoenix.PubSub supports distributed systems out of the box. To enable clustering:

Add :libcluster to your dependencies.
Configure clustering in config/runtime.exs:

config :libcluster,
  topologies: [
    example: [
      strategy: Cluster.Strategy.Gossip
    ]
  ]

Start your application on multiple nodes, and messages will seamlessly propagate across them.

Phoenix.PubSub is a powerful tool for building real-time features in Elixir applications. Whether you’re creating a simple notification system or scaling to a distributed collaborative environment, PubSub provides the flexibility and performance you need.

If you’ve built something cool with Phoenix.PubSub, let me know in the comments—I’d love to hear about your experience!

Feel free to reach out if you need help.

LinkedIn: https://www.linkedin.com/in/rushikesh-pandit
GitHub: https://github.com/rushikeshpandit
Portfolio: https://www.rushikeshpandit.in

#myelixirstatus , #elixir , #phoenixframework