DEV Community: punith sunny

# How My Technical Deep-Dive on React Native Process Death Reached 18K+ Views in 18 Hours

punith sunny — Sun, 08 Nov 2026 06:26:23 +0000

What I learned from launching a commercial React Native background-location SDK in a skeptical developer community.

Selling commercial developer tools to software engineers is difficult.

Developers are naturally skeptical. We question paywalls, look past marketing language, and often ask a fair question: "Why shouldn't I just build this myself?"

A few days ago, I introduced my commercial React Native background-location SDK, React Native Background Location Pro, to the r/reactnative community. The technical discussion that followed was much bigger than I expected.

Within just 18 hours, the post passed 18,000 views and reached a 93.1% upvote ratio. By the 48-hour mark, Reddit insights showed 18K total views (+144 vs prior checkpoint), 50 upvotes, and 9 comments. It also sparked an international discussion among React Native developers about background execution, process termination, native persistence, and the trade-offs imposed by Android and iOS.

The response wasn't the result of a paid campaign or a growth trick. The post focused on a concrete engineering problem: what happens to a background-location pipeline when the operating system suspends or terminates the app process?

That problem is especially challenging in React Native because a robust solution cannot assume that the JavaScript runtime will always be available. Android foreground services, iOS background-execution rules, native persistence, and operating-system lifecycle decisions all matter.

The experience reinforced an important lesson for independent developers, consultants, and open-source maintainers: when introducing a technical product to an engineering audience, don't lead with features. Start with the problem, explain constraints, and show engineering decisions.

This article breaks down how I approached the launch of a React Native SDK built around the New Architecture (TurboModules + JSI), how I used a technical deep-dive to invite meaningful discussion, and what I learned about reducing evaluation friction for developers considering a commercial tool.

About the author: I'm Punith Manthri, a React Native and native mobile engineer focused on Android, iOS, and the React Native New Architecture. I maintain react-native-pdf-jsi, a native PDF-rendering library for React Native, and build React Native Background Location Pro.

1) The launch: lead with an engineering problem

Reddit post: https://www.reddit.com/r/reactnative/comments/1xq4m83/i_built_a_background_location_sdk_for_react/
Proof screenshot:

I intentionally did not frame the post as a pure product announcement.

Instead of saying "I built an SDK, please buy it," I focused on the engineering challenge that motivated it: keeping critical location work resilient when JS is paused, backgrounded, or unavailable.

That gave developers something concrete to evaluate and debate. The comments became technical discussion, not just launch reactions.

Reach and engagement snapshot (first 48 hours)

Total views: 18K
Upvotes: 50
Upvote ratio: 93.1%
Comments: 9

Hourly distribution highlights

The reach curve followed a classic launch spike, then a long tail:

Hour 1: 67 views
Hour 2: 1,528 views
Hour 3: 1,766 views
Hour 4: 1,635 views
Hour 5: 1,810 views (peak)
Hour 6: 1,585 views
Hours 7-12: 1,281 -> 781 views
Hours 13-19: 583 -> 393 views (steady taper)
Hours 20-48: minimal to no additional hourly increments in the exported insights

This pattern suggests the post earned strong initial distribution and then transitioned into lower-velocity discovery.

Audience geography

Top countries by views:

United States: 25.3%
India: 8.4%
United Kingdom: 5.7%
Other regions combined: 60.5%

For a React Native infrastructure topic, this was useful validation that the discussion reached a broad global developer audience, not only a local network.

What people actually asked

The early comments quickly converged into three serious themes:

Free alternative comparison: "How is this better than react-native-nitro-geolocation?"
Paid incumbent comparison: "How does this compare to react-native-background-geolocation?"
IP durability question: "If binaries can be reverse engineered, how do eval/commercial models hold up?"

That was useful because these are the exact questions teams ask before adopting any location SDK.

2) The core problem: background execution is not guaranteed

If your architecture assumes JavaScript is always alive, background location will eventually fail in real-world conditions.

flowchart TD
    A[User starts tracking] --> B[RN JS thread handles capture queue and retries]
    B --> C[App goes to background]
    C --> D{OS allows process to keep running?}
    D -- Yes --> E[JS timers and callbacks continue for now]
    D -- No --> F[Process suspended or terminated]
    F --> G[RN JS runtime unavailable]
    G --> H[No JS queue processing]
    H --> I[No JS retry scheduler]
    I --> J[Buffered events not flushed]
    J --> K[Tracking gaps and delayed or lost uploads]

    E --> L{Network is unstable?}
    L -- Yes --> M[Needs retry and backoff logic]
    M --> N{JS still alive later?}
    N -- No --> I
    N -- Yes --> O[Retries resume]

In general, this is why JS-only orchestration becomes fragile under real mobile lifecycle conditions: once the runtime is paused or killed, scheduled retry and flush logic cannot execute until JS is alive again.

The core constraints are platform-level:

Android: foreground services can keep work alive, but process death, OEM behavior, power modes, and permission policy still shape reliability.
iOS: background execution is policy-driven and strict; termination and relaunch behavior has hard limits that every implementation must respect.
React Native: JS is excellent for product logic, but critical background reliability must be designed to survive JS lifecycle disruption.

The practical takeaway: background systems must treat JS as a consumer of state, not the single point of truth for capture, storage, and delivery.

One commenter asked a great question: "Is this really a JS issue? Can't all of this be done in JS with SQLite?"

The correct answer is nuanced:

SQLite itself is not the limitation.
The limitation is runtime lifecycle: JS-coordinated retries and background orchestration cannot run when the React Native runtime is unavailable.
Native components can keep critical capture/persistence/sync logic active under platform-approved background execution windows.

3) The architecture: move critical work closer to the platform

I designed the SDK so the React Native layer stays simple while critical reliability paths live natively.

At a high level:

Android path: Kotlin-native tracking components manage capture and lifecycle continuity.
iOS path: Swift-native tracking components respect iOS background constraints and lifecycle behavior.
Persistence: location records are stored locally first, then uploaded using resilient retry behavior.
React Native interface: TurboModule + JSI expose a typed API for start/stop/status and events.

What I share publicly is the architecture, trade-offs, and integration behavior. I avoid publishing proprietary internal implementation details that would expose commercial source IP.

4) Reducing evaluation friction

The fastest way to lose developer trust is to make evaluation difficult.

So I optimized for low-friction validation:

publish an evaluation package developers can run in their own app,
provide clear setup docs for Android/iOS permissions and expected behavior,
make runtime status observable so testers can see what is happening,
use a straightforward one-time licensing model instead of recurring confusion.

Engineers do not buy claims; they buy confidence from hands-on testing.

For commercial SDKs, this matters even more: the pricing conversation goes much better when engineers can verify behavior directly on their own routes, devices, and failure scenarios before committing.

5) What the community discussion taught me

The comments raised exactly the questions I hoped to surface:

"How is this different from free alternatives?"
"How does this compare to established paid SDKs?"
"What happens under process death and weak network conditions?"
"How transparent is the architecture if parts are commercially licensed?"
"What are the limits on iOS and Android that no SDK can bypass?"

These are healthy questions. Responding directly (without defensive marketing) increased credibility far more than trying to "win" every argument.

The practical comparison framing that worked

When developers asked about alternatives, the most credible format was:

Acknowledge strengths of competitors first.
- Nitro: strong free JSI-first foundation.
- Transistorsoft: mature incumbent with long track record.
Then explain your value without overclaiming.
- You are not selling "geolocation calls"; you are selling an opinionated production reliability pipeline.
- You offer a one-time model and source ownership path for teams that value control.
Be explicit about limits.
- iOS lifecycle behavior is controlled by iOS.
- No SDK can promise unrestricted background execution under all OS states.

That tone turned potential pushback into serious technical dialogue.

6) What I would repeat - and what I would change

What I would repeat

Lead with a hard engineering problem, not a feature list.
Publish constraints and limitations clearly.
Invite comparison with alternatives.
Keep pricing and licensing explicit.

What I would change

Prepare a tighter comparison table up front (free vs paid, ownership vs convenience, maturity vs flexibility).
Add more "failure mode" examples to show exactly where architectural choices matter.
Publish a short FAQ earlier to reduce repeated objections.
Add one prepared response for the "JS can do this too" question, focused on lifecycle rather than language wars.
Add one prepared response for reverse-engineering concerns, focused on economics and maintenance cost instead of fear-based arguments.

7) Guardrails: sharing value without exposing proprietary logic

For commercial dev tools, there is a balance:

Share problem framing, system design, platform constraints, and integration contracts.
Protect internal source-level implementation details, private heuristics, and non-public operational techniques.

That balance lets you contribute technical value publicly while preserving the business model that funds ongoing maintenance.

Closing thought

The biggest takeaway was not the view count. It was that a detailed, honest discussion of a difficult engineering problem can earn attention from exactly the community a developer tool is built for.

For independent developers, credibility is not created by saying "enterprise-grade." It comes from explaining constraints, showing trade-offs, acknowledging platform limits, and giving engineers enough information to evaluate the approach themselves.

Build the solution. Explain the trade-offs. Let the engineering speak.

Why background location tracking fails in React Native (and how I fixed it with JSI & TurboModules)

punith sunny — Sat, 07 Nov 2026 12:16:08 +0000

Why Background Location Tracking Fails in React Native (And How I Fixed It with JSI & TurboModules)

About the Author

Hi, I’m Punith Manthri, a Senior React Native Developer with 5 years of experience specializing in native module bridging, JSI, and the New Architecture. I am the creator and maintainer of react-native-pdf-jsi, a high-performance PDF library built on JSI that has surpassed 350,000+ downloads on npm (with over 65,000 weekly downloads). I spend most of my time writing native Kotlin, Swift, and C++ to push the boundaries of what React Native can do.

If you have ever built a React Native app that requires background location (like a delivery, fitness, or fleet-tracking app), you know the nightmare.

You write the code, test it in the simulator, and it works perfectly. You put the phone in your pocket, walk around the block, and look at your database. Half the data is missing.

I’ve used the major players (expo-location, Transistorsoft) and they are great, but I kept hitting the same production walls. So, I decided to build a native-only solution from scratch.

Here is what I learned about why background location breaks in React Native, and how the New Architecture (JSI/TurboModules) finally solves it.

1. JS Background Tasks are a Trap

If you rely on expo-task-manager or standard JS background tasks, your location logic runs in the JavaScript thread.

The Problem:
Modern mobile OSes (especially Android) are ruthless. When the device runs low on RAM, or sits idle for too long, the OS will kill your app process to save battery. When the process dies, the JS runtime dies. Your background task stops, and you only find out days later when your data has massive gaps.

The Fix:
The tracking engine must be 100% native.

On Android, this means a Kotlin Foreground Service using FusedLocationProvider.
On iOS, this means Swift CLLocationManager with background modes enabled.

The JS thread should only be used to update the UI. The actual tracking and network requests must be detached from React entirely.

2. Motion Detection Needs to "Fail Open"

To save battery, most libraries use motion sensors (accelerometer, significant motion) to "park" the GPS when the device is stationary.

The Problem:
Android vendor ROMs (like Xiaomi or Samsung) and iOS CMMotionActivityManager frequently misclassify "slow movement" (like a hiker or a phone in a bag) as "stationary." The GPS silently sleeps, and you lose the route.

The Fix:
The motion gate must fail open. If the OS denies motion permissions, or the sensor fails to trigger, the engine must default to always-on GPS. It should never pause silently without a clear error state.

3. The "Duplicate Upload" Nightmare

If a user goes through a tunnel or a basement, they lose network. If you handle your retry logic in JavaScript, and the app is killed mid-request, you either lose the location points or duplicate them on your backend when the app restarts.

The Fix:
You need a native SQLite queue (using Room on Android).

Every location fix is written to SQLite before anything else.
Uploads are batched with Idempotency Keys.
If a 5xx error or timeout occurs, the native layer uses exponential backoff with jitter.

By keeping the queue native, the sync survives process death. When the app reboots, the native layer picks up exactly where it left off.

4. The Apple & Google Store Rejection Problem

Background location is the #1 reason apps get rejected from the App Store and Google Play. Apple's "Prominent Disclosure" requirements and Google's "Foreground Service" declarations are a compliance nightmare.

The Fix:
You need precise Info.plist purpose strings, clear AndroidManifest.xml foreground service types, and a privacy manifest (PrivacyInfo.xcprivacy).

How the New Architecture (JSI) Changes the Game

Older background location libraries relied on the legacy bridge, which meant high latency and serialization overhead when sending high-frequency location points to JS.

By building exclusively for the New Architecture, I was able to use:

TurboModules: To ensure synchronous, instant initialization of the native tracking service.
JSI (JavaScript Interface): To query the native SQLite queue state directly from the JS thread without blocking or asynchronous overhead.

What I Built

Because I couldn't find an open-source solution that handled all of the above natively, I built React Native Background Location Pro.

It is a complete, production-grade SDK that runs Kotlin and Swift behind a TurboModule (JSI). It includes:

🛡️ Self-healing tracking (survives app kills, reboots, and OS updates).
📶 Offline-first native SQLite queues.
🏪 A "Store Approval Blueprint" to help you pass Apple/Google review.
🗺️ A live map dashboard for testing.

Try it for free

I know commercial SDKs can be a hard sell, so I published a free debug evaluation build on npm. It runs the full production native engine (Kotlin/Swift binaries) with zero time limits in debug mode. You can test crash recovery, airplane mode, and the native queues in your own app before deciding if it's right for you.

View the source & docs:
👉 GitHub Repository
👉 NPM Package

Install the free eval:


bash
npm i react-native-background-location-pro-eval