DEV Community: mohammad rostami

One React Native App, Multiple IAP Providers: Architecture, Autolinking and Build Isolation

mohammad rostami — Fri, 09 Oct 2026 17:49:44 +0000

When I started adding a second in-app purchase provider to a React Native app, the application-level design looked straightforward.

Both stores needed almost the same things:

load products
start a purchase
restore purchases
check ownership

The SDKs were different, but the business flow was not. So the first step was the obvious one: hide the store-specific code behind a shared interface and let the rest of the app depend on that interface.

That part worked.

The problem appeared one layer lower.

A clean TypeScript provider abstraction does not tell React Native which native modules should exist in the binary. If both store SDKs are installed, autolinking can still discover both of them. At that point the problem is no longer only about choosing the right provider at runtime. It is also about deciding which native billing implementation is allowed into each build.

That distinction changed the way I structured the integration.

The provider abstraction worked until the native build

I still wanted the application to see one commerce contract.

A screen should be able to call purchase() without knowing which marketplace is underneath it. Entitlement logic should not contain store-specific branches. Product UI should not care which native SDK returned the data.

A small interface is enough to define that boundary:

export type Product = {
  id: string;
  title: string;
  price: string;
};

export type Purchase = {
  productId: string;
  transactionId: string;
};

export interface IAPProvider {
  connect(): Promise<void>;
  getProducts(productIds: string[]): Promise<Product[]>;
  purchase(productId: string): Promise<Purchase>;
  restorePurchases(): Promise<Purchase[]>;
}

Each store can adapt its own SDK to that contract:

export class StoreAProvider implements IAPProvider {
  async connect(): Promise<void> {
    // Connect to Store A billing.
  }

  async getProducts(productIds: string[]): Promise<Product[]> {
    // Map Store A product models to the app's Product shape.
    return [];
  }

  async purchase(productId: string): Promise<Purchase> {
    // Execute the native Store A purchase flow.
    return {
      productId,
      transactionId: "store-a-transaction",
    };
  }

  async restorePurchases(): Promise<Purchase[]> {
    return [];
  }
}

The second provider implements the same interface, and a mock provider can cover development:

export class MockIAPProvider implements IAPProvider {
  async connect(): Promise<void> {}

  async getProducts(productIds: string[]): Promise<Product[]> {
    return productIds.map((id) => ({
      id,
      title: `Mock product ${id}`,
      price: "0",
    }));
  }

  async purchase(productId: string): Promise<Purchase> {
    return {
      productId,
      transactionId: `mock-${Date.now()}`,
    };
  }

  async restorePurchases(): Promise<Purchase[]> {
    return [];
  }
}

This kept the application code clean, and I would use the same abstraction again.

What it did not solve was native dependency isolation.

Autolinking changes what "selected provider" means

At the JavaScript level, selecting a provider is simple:

export const COMMERCE_TARGETS = ["mock", "storeA", "storeB"] as const;

export type CommerceTarget = (typeof COMMERCE_TARGETS)[number];

export function createIAPProvider(
  target: CommerceTarget,
): IAPProvider {
  switch (target) {
    case "storeA":
      return new StoreAProvider();

    case "storeB":
      return new StoreBProvider();

    case "mock":
      return new MockIAPProvider();
  }
}

That answers which implementation the application should call.

React Native still has another decision to make during the native build: which modules should be linked into the binary.

If both billing SDKs are installed in node_modules, both are candidates for native discovery. Choosing StoreAProvider in TypeScript does not automatically remove Store B's package from Gradle, the Android manifest, or native module registration.

The dependency tree can still look like this:

node_modules
├── store-a-iap-sdk
└── store-b-iap-sdk

That was the part my first design did not account for.

I had treated provider selection as a runtime concern, but native billing capability is also a build-time concern.

Runtime provider selection is not the same as native dependency isolation.

Two SDKs that look almost identical from JavaScript can still have very different native behavior. They may bring different Gradle dependencies, initialization code, manifest changes, lifecycle assumptions, or React Native compatibility constraints.

Once both exist in the same binary, all of those differences become part of the release surface.

Make the store a build-time concern

The model that worked better was to treat each marketplace build as a native variant of the same application.

Store A build
└── Store A native billing SDK

Store B build
└── Store B native billing SDK

Development build
└── Mock commerce provider

The source code stays shared, but the binaries do not need to expose the same native capabilities.

I keep the build target explicit:

export type CommerceTarget = "mock" | "storeA" | "storeB";

export function resolveCommerceTarget(
  value: string | undefined,
): CommerceTarget {
  switch (value) {
    case "storeA":
    case "storeB":
      return value;

    default:
      return "mock";
  }
}

The application uses that value to select the TypeScript provider.

The native build configuration uses the same target to decide which marketplace SDK is allowed to autolink.

The exact configuration depends on the React Native and Expo versions in the project, so the useful lesson is not one copy-paste configuration file. The useful part is where the decision is made.

A Store A build should not simply avoid calling Store B's SDK.

It should avoid linking Store B's SDK.

That keeps the binary easier to reason about:

no unused billing SDK in the final artifact
fewer Gradle dependency interactions
fewer store-specific manifest changes
less native initialization surface
clearer release debugging
fewer questions about which billing lifecycle owns the app

It also gives failures a smaller search space. If a Store A build breaks, I want to inspect Store A's native integration, not Store A plus an unrelated billing SDK that should never have been there.

The architecture after separating those two decisions

Once runtime provider selection and native build isolation are treated separately, the overall shape becomes much clearer:

                         React Native UI
                               │
                               ▼
                        Commerce Service
                               │
                               ▼
                       IAP Provider Contract
                          /             \
                         /               \
                Store A Provider   Store B Provider
                        │                 │
                        ▼                 ▼
                  Native SDK A       Native SDK B
                        │                 │
                        ▼                 ▼
                  Store A Build       Store B Build

The shared contract belongs to the application.

The native SDK belongs to the binary.

That separation is the important part.

One repository can still produce different native runtimes

This became more important once OTA updates entered the picture.

If two store builds contain different native billing modules, they are not equivalent runtimes just because they were produced from the same Git repository.

Consider these two binaries:

Binary A
└── Native Billing SDK A

Binary B
└── Native Billing SDK B

Now publish JavaScript that assumes SDK A exists.

That JavaScript is valid for Binary A. It may be invalid for Binary B.

This is where runtime fingerprinting starts to matter beyond being another release setting. Native dependency differences are part of compatibility.

If a native module changes, or if a build links a different native module entirely, the OTA boundary should reflect that.

For a multi-store app, I prefer separate update channels, or equivalent release boundaries, for each marketplace build, backed by a runtime policy that includes native changes.

The rule I use is straightforward:

If two binaries do not have the same native capabilities, they should not automatically receive the same OTA update.

That also changes how I think about "one app."

From the product side, it is one app.

From the repository side, it is one codebase.

From the native release side, it can still be two different binaries with different capabilities and different compatibility boundaries.

Those statements can all be true at the same time.

Native patches are part of the build, not a local workaround

The second place where this became obvious was native compatibility patching.

Sometimes a billing package is close to what the current React Native or Expo version expects, but not quite. A small patch can make the integration work.

The unsafe version of that approach is a postinstall script that searches for some text and rewrites whatever package version happens to be installed.

That is convenient until the dependency publishes a new patch version and the same script edits code it has never been reviewed against.

For native patches, I prefer to be deliberately strict.

A patch should know which package version it was written for and should refuse to run when that assumption changes.

Conceptually:

type PatchContract = {
  packageName: string;
  expectedVersion: string;
  expectedSourceHash: string;
};

export function assertPatchContract(
  contract: PatchContract,
  actualVersion: string,
  actualSourceHash: string,
): void {
  if (actualVersion !== contract.expectedVersion) {
    throw new Error(
      `Review the patch before using ${contract.packageName}@${actualVersion}`,
    );
  }

  if (actualSourceHash !== contract.expectedSourceHash) {
    throw new Error(
      `Source changed for ${contract.packageName}; refusing to patch it blindly`,
    );
  }
}

I also want the patch to be idempotent.

Running install twice should not produce two different native trees. A clean local install and a clean cloud build should reach the same result.

This is one of those cases where a failed build is better than a "successful" build with an unreviewed native modification.

There is another release consequence here: a native patch can change the runtime fingerprint.

Changing one file inside a native dependency may look tiny in Git, especially if the patch is applied after install. From the binary's point of view, it is still native code changing underneath the JavaScript bundle.

So I treat native patches as part of the release architecture, not as a developer-machine trick.

Keep local and cloud builds boring

Once multiple store variants and native patches are involved, reproducibility matters more than clever build logic.

I want the following inputs to be explicit and repeatable:

lockfile
build target
store configuration
native patch version
environment variables
update channel
runtime fingerprint

A clean install should be meaningful.

If npm ci on my machine and the dependency install inside the cloud builder produce different native trees, that is a release problem even if the JavaScript bundle is identical.

This is also where dependency version ranges deserve more attention.

For most packages, a compatible patch update is exactly what semver is supposed to make easy.

For a native package coupled to a reviewed compatibility patch, an automatic patch update can be the opposite of what I want. The package manager may consider the new version compatible while the patch script correctly considers it unknown.

In that situation, pinning the reviewed version is not about being afraid of upgrades. It is about making the upgrade explicit:

install the new version
inspect the native source
review or remove the patch
run the integration tests again
move the release forward

That is much easier to debug than discovering the change halfway through a store build.

Test the binary, not only the TypeScript abstraction

The provider interface makes unit tests straightforward, but a passing interface test does not prove that the correct native SDK ended up in the APK.

I treat the release matrix itself as something worth testing:

Build	Native billing capability	TypeScript provider
Development	None / mock	`MockIAPProvider`
Store A	SDK A only	`StoreAProvider`
Store B	SDK B only	`StoreBProvider`

The commerce contract should behave consistently across providers:

export async function getOwnedProductIds(
  provider: IAPProvider,
): Promise<Set<string>> {
  const purchases = await provider.restorePurchases();

  return new Set(
    purchases.map((purchase) => purchase.productId),
  );
}

The build target should select the expected provider.

The native build should contain the expected SDK and exclude the other one.

And finally, the real purchase flow still needs a release-like device test.

For each marketplace build, I want to verify at least:

launch
→ connect to billing
→ load products
→ start a purchase
→ handle cancel or success
→ restore ownership
→ relaunch

Mocks are useful for application behavior.

They cannot prove that Gradle, autolinking, the marketplace client, and the native billing lifecycle agree with each other.

That proof has to happen on the actual binary.

Closing

The provider abstraction was still the right first step. It kept marketplace-specific billing code out of the rest of the application and gave the product one stable commerce API.

The part I had underestimated was the boundary below it.

Selecting a provider in TypeScript is an application decision. Deciding which billing SDK exists in the binary is a build decision. OTA compatibility, native patches, and release testing all follow from that difference.

For the next multi-store React Native app, I would structure it the same way: keep the purchase contract shared, make the marketplace an explicit build target, and let each binary contain only the native billing capability it actually needs.

That keeps the cross-platform part genuinely shared without pretending the native part is identical when it is not.

Reliable Form Submissions: Dirty State, Fingerprints, and Idempotency

mohammad rostami — Fri, 21 Aug 2026 07:07:30 +0000

A disabled Submit button protects the UI. It does not protect the data.

It is tempting to treat this as enough protection against duplicate submissions:

<button type="submit" disabled={isSubmitting}>
  Submit
</button>

The button is worth disabling. It gives the user immediate feedback and prevents an obvious second click. But it only controls one interaction in one browser tab.

It cannot tell us whether a request was retried by the client, whether two requests crossed the network at nearly the same time, or whether the server completed a write before the response disappeared.

Consider a small order form:

type OrderFormValues = {
  firstName: string;
  lastName: string;
  amount: number;
  price: number;
};

A straightforward submission might look like this:

await fetch("/api/orders", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify(values),
});

Now imagine that the server creates the order, but the response never reaches the browser. The UI sees a network error. The user tries again. Without any other protection, the second request can create a second order.

The difficult part is not the second click. The difficult part is deciding whether the second request represents a new operation or a retry of the first one.

The mental model I use separates two identities:

A fingerprint identifies the content of the request.
An idempotency key identifies the operation the user intended to perform.

They solve different problems, and neither is a replacement for the other.

Content identity starts with normalization

Two form values can be different in JavaScript while representing the same business input.

These names are not byte-for-byte equal:

"Sara"
" Sara "

But if the application trims names before saving them, that whitespace is not a meaningful change. The same issue appears with values such as "150" and 150, or 150 and 150.0.

I prefer to make those rules explicit before creating a fingerprint:

function normalizeOrder(values: OrderFormValues) {
  return {
    firstName: values.firstName.trim(),
    lastName: values.lastName.trim(),
    amount: Number(values.amount),
    priceInCents: Math.round(Number(values.price) * 100),
  };
}

function canonicalizeOrder(values: OrderFormValues): string {
  return JSON.stringify(normalizeOrder(values));
}

Converting the price to cents is part of the example's business normalization. It avoids using small floating-point differences as evidence that two prices are different.

For local comparisons, the canonical string is already a useful fingerprint:

const fingerprint = canonicalizeOrder(values);

For storage or comparison across system boundaries, I would usually hash that canonical value:

async function createOrderFingerprint(
  values: OrderFormValues,
): Promise<string> {
  const payload = canonicalizeOrder(values);
  const bytes = new TextEncoder().encode(payload);
  const digest = await crypto.subtle.digest("SHA-256", bytes);

  return Array.from(new Uint8Array(digest), (byte) =>
    byte.toString(16).padStart(2, "0"),
  ).join("");
}

The normalization rules must come from the domain. If array order has no business meaning, sort the array before hashing it. If order is meaningful, sorting it would create the wrong identity. A fingerprint is only as correct as the canonical representation behind it.

Dirty state is also a domain question

Form libraries usually expose an isDirty flag. That flag is useful, but it normally compares raw form values with the original defaults. It does not know which differences matter to the business.

A business-aware check can compare the initial and current fingerprints instead:

const initialFingerprint = canonicalizeOrder(initialValues);
const currentFingerprint = canonicalizeOrder(currentValues);

const isMeaningfullyDirty =
  currentFingerprint !== initialFingerprint;

If the user changes "Sara" to " Sara ", the raw form may be dirty while isMeaningfullyDirty remains false.

If the user changes amount from 2 to 3, the fingerprint changes. If they change it back to 2, the fingerprints match again and the form is no longer meaningfully dirty.

This is also why UI-only state should stay out of the fingerprint. A search query, an expanded panel, or the selected tab may change the component state without changing the order that will be sent to the server.

For example, customerSearch does not belong in the normalized payload:

type OrderPageState = OrderFormValues & {
  customerSearch: string;
};

function normalizeOrderPage(values: OrderPageState) {
  return normalizeOrder(values);
}

Using the same canonicalization rules for Dirty State and submission gives both features the same definition of a meaningful change.

Operation identity belongs to the idempotency key

A fingerprint tells us that two payloads contain the same business data. It does not tell us whether the user intended one operation or two.

A user may intentionally create two identical orders. Those orders have the same fingerprint, but they are still separate operations. This is why I would not derive the idempotency key from the fingerprint:

// Incorrect: identical payloads can still be separate operations.
const idempotencyKey = fingerprint;

Instead, the client creates a random key for a new operation and reuses it only when retrying that operation with the same fingerprint.

type PendingOperation = {
  fingerprint: string;
  idempotencyKey: string;
};

let pendingOperation: PendingOperation | null = null;

async function submitOrder(values: OrderFormValues) {
  const fingerprint = canonicalizeOrder(values);

  const operation =
    pendingOperation?.fingerprint === fingerprint
      ? pendingOperation
      : {
          fingerprint,
          idempotencyKey: crypto.randomUUID(),
        };

  pendingOperation = operation;

  const response = await fetch("/api/orders", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Idempotency-Key": operation.idempotencyKey,
    },
    body: JSON.stringify(values),
  });

  if (!response.ok) {
    throw new Error("Order submission failed");
  }

  const result = await response.json();

  // A later submission now represents a new operation,
  // even if the user enters the same values again.
  pendingOperation = null;

  return result;
}

There are two deliberate choices in this code.

First, a failed attempt does not immediately discard the key. Retrying the same payload should reuse the identity of the pending operation.

Second, a successful response clears that identity. If the user intentionally submits the same values again later, the client generates a new key and the server is allowed to create another order.

Disabling the button still makes sense, but the key is what allows the server to recognize a repeated operation.

The server has to bind the key to the payload

The client can help manage operation identity, but the guarantee must exist on the server.

For each idempotency key, the server needs to store at least:

type IdempotencyRecord = {
  key: string;
  fingerprint: string;
  status: "processing" | "succeeded";
  response?: {
    orderId: string;
  };
};

The server should calculate the fingerprint itself. Trusting a fingerprint supplied by the browser would allow a modified client to claim that two different payloads are identical.

The key also has to be claimed atomically. A separate find() followed by insert() leaves a race in which two requests can both observe that the key is missing.

The storage API can expose that atomic decision directly:

type ClaimResult =
  | { kind: "new" }
  | { kind: "mismatch" }
  | { kind: "processing" }
  | {
      kind: "completed";
      response: { orderId: string };
    };

async function createOrder(request: Request) {
  const key = request.headers.get("Idempotency-Key");

  if (!key) {
    return new Response("Idempotency key is required", { status: 400 });
  }

  const values = (await request.json()) as OrderFormValues;
  const fingerprint = await createOrderFingerprint(values);

  const claim: ClaimResult = await idempotencyStore.claim({
    key,
    fingerprint,
  });

  if (claim.kind === "mismatch") {
    return new Response("Key reused with a different payload", {
      status: 422,
    });
  }

  if (claim.kind === "completed") {
    return Response.json(claim.response);
  }

  if (claim.kind === "processing") {
    return new Response("Operation is already processing", {
      status: 202,
    });
  }

  const order = await orderRepository.create(normalizeOrder(values));
  const response = { orderId: order.id };

  await idempotencyStore.complete({ key, response });

  return Response.json(response, { status: 201 });
}

In a relational database, a unique constraint on the key is the minimum protection against concurrent claims:

CREATE UNIQUE INDEX idempotency_key_unique
ON idempotency_records (key);

The exact persistence model depends on the operation, but the invariant should remain the same:

The same key and the same fingerprint refer to the same operation.
The same key with a different fingerprint is rejected.
A new key represents a new operation, even when its fingerprint matches an older one.

The mistakes I would avoid

The first mistake is treating isSubmitting as a data-integrity mechanism. It is UI state, and it cannot protect the server from concurrent or repeated requests.

The second is using a fingerprint as the idempotency key. That incorrectly merges separate operations that happen to have identical payloads.

The third is hashing raw form state. Whitespace, numeric representation, property order, or UI-only fields can create different hashes for the same business input. Canonicalization has to happen before hashing.

The final mistake is implementing the guarantee only in the browser. The browser can choose and reuse a key, but only durable, atomic server-side storage can enforce it.

The compact version of the model is:

Dirty State compares the current content with the initial content.

A fingerprint identifies that content.

An idempotency key identifies the operation performed with it.

Once those responsibilities are separate, the Submit button can remain what it should be: a useful interaction detail, not the last line of defense against duplicate writes.

Why Your Zod Validation Fails Before It Even Runs (And How to Fix It)

mohammad rostami — Thu, 11 Jun 2026 08:43:43 +0000

If you're using Zod with react-hook-form, you've probably seen this at least once:

Invalid input: expected number, received NaN

At first glance, it looks like a simple validation issue.
It’s not.

The real problem

When working with form inputs:

All values come in as strings
z.coerce.number() tries to convert them
Empty input ("") or invalid values → NaN

And here’s the catch:
Zod fails before your .min() / .max() validations run.

So instead of your custom message, you get a generic (and not very helpful) error.

It gets trickier

If you're using TypeScript:

z.input<typeof schema> ≠ z.output<typeof schema>
react-hook-form works with the input type
Zod gives you the output type after parsing

This mismatch can lead to confusing type errors and wrong assumptions about your data.

The fix

You need to handle invalid input before Zod tries to validate it:

readTime: z.preprocess((val) => {
  if (val === "" || val === undefined) return undefined;

  const num = Number(val);
  return isNaN(num) ? undefined : num;
},
z.number()
  .min(2, 'Minimum read time is 2 minutes')
  .max(60, 'Maximum read time is 60 minutes')
)

What this solves

Empty input → handled properly
Invalid numbers → no more NaN issues
Custom validation messages → actually shown
Cleaner UX overall

Takeaway

If you're using z.coerce.number() in forms, don't rely on it blindly.
Always normalize your input first.

Because sometimes the bug isn't in your validation rules…
it's in how your data arrives before validation even starts.

Technical Deep Dive: How React Server Components Work and Where the Vulnerabilities Appear

mohammad rostami — Mon, 15 Dec 2025 20:42:52 +0000

Hi everyone
In a recent, I examined CVE-2025-55182, a critical vulnerability in React Server Components caused by an unsafe deserialization path that could lead to unauthenticated remote code execution. That issue highlighted how deeply framework internals can influence the security posture of applications built on top of them.

Shortly after that disclosure, an additional set of security vulnerabilities was published affecting the same architectural layer in React Server Components (RSC) and Next.js. While these issues do not result in immediate remote code execution, they introduce significant risks, including Denial of Service (DoS) and unintended exposure of server-side source code and internal implementation details under specific conditions.

This article builds on that context and focuses on the underlying execution model of React Server Components, explaining how these issues emerge at the framework level and why they matter for production deployments.

To understand why the recently disclosed issues in React Server Components (RSC) lead to Denial of Service and source code exposure, it helps to look at how the RSC execution pipeline actually works on the server.

React Server Components: Server-Side Execution Flow

A simplified but accurate RSC request lifecycle looks like this:

1 - Incoming request reaches the RSC endpoint

In Next.js, this typically maps to an internal route such as /_rsc
The request is processed before authentication and before application middleware

2 - Request body parsing and protocol decoding

The payload is parsed according to the React Flight protocol
This includes decoding serialized component references, props, and execution hints
At this stage, React assumes the payload shape is valid enough to be processed

3 - Component graph reconstruction

React reconstructs the Server Component tree from the serialized input
Module references are resolved and loaded
Async boundaries and Suspense segments are registered

4 - Server rendering and streaming

Components are executed on the server
Output is serialized again and streamed back to the client in chunks
Error boundaries and partial results are flushed incrementally

5 - Error and recovery

If an exception occurs mid-stream, React attempts to recover gracefully
Metadata, stack traces, and module identifiers are still available internally
Each of these phases is sensitive to malformed or adversarial input.

How Denial of Service Is Triggered

The DoS issue arises primarily in steps 2 and 3, before any application logic is involved.
A malicious request can:

Inflate the serialized payload size
Introduce deeply nested or cyclic references
Force excessive async boundary resolution

Conceptual example:

POST /_rsc
Content-Type: application/json

{
  "type": "ServerComponent",
  "props": {
    "children": {
      "children": {
        "children": {
          ...
        }
      }
    }
  }
}

Even if the payload is syntactically valid, React will:

Attempt to deserialize it
Build an in-memory component graph
Schedule execution and streaming work

This leads to:

High CPU usage during decoding
Memory pressure during graph reconstruction
Worker or event-loop saturation

Crucially, this happens without hitting user-defined code and without authentication.

This makes traditional defensive assumptions at the application layer largely ineffective.

How Source Code Exposure Can Occur

Source code exposure is a side effect of how React handles errors during steps 4 and 5.
When a rendering or serialization error occurs mid-stream:

React still holds references to internal module paths
Stack traces include resolved file locations
Component metadata is partially serialized

In certain edge cases, this information may:

Leak into the streamed response
Appear in error payloads
Be flushed before the stream is properly aborted

Example of leaked information:

Error: Failed to resolve Server Component
  at /app/src/components/admin/UserList.server.tsx
  at react-server-dom-webpack/server

This reveals:

Project directory structure
Server-only component boundaries
Internal module layout and naming

While not a standalone exploit, this materially reduces the effort required for targeted attacks.

Why Server Actions Are Not Required

A common misconception is that these risks only apply when using Server Actions.
In reality:

Server Actions are an API surface
RSC is a runtime and protocol

Even a simple page like:

export default async function Page() {
  return <Dashboard />;
}

Still triggers:

Request deserialization
Component graph reconstruction
Server execution and streaming

The vulnerable logic executes regardless of whether Server Actions are defined.

Key Takeaways

React Server Components introduce a fundamentally new server-side execution model that combines request deserialization, component graph reconstruction, and streaming-based rendering into a single framework-managed pipeline.
As a result, the effective attack surface exists before authentication, before application middleware, and before any user-defined business logic is executed.
Malformed or adversarial RSC requests can lead to:
Denial of Service, through excessive CPU usage, memory pressure, and worker or event-loop saturation during deserialization and component graph reconstruction
Accidental disclosure of server-side implementation details, including internal file paths, component boundaries, and module layout, as a side effect of streaming error handling
These issues are not caused by misconfigured applications or unsafe user code. They are framework-level vulnerabilities in the React Server Components runtime itself and cannot be mitigated reliably through application-layer defenses alone.

Official advisories and patches

Denial of Service and Source Code Exposure in React Server Components

Next.js security update

A Deep Dive into Nested ScrollView Behavior in React Native: Root Causes and Practical Solutions

mohammad rostami — Mon, 24 Nov 2025 21:24:08 +0000

Hi everyone

During the development of a recent screen in one of our applications, I faced a scenario where a section of the content needed to scroll independently, while the entire page itself was wrapped inside a parent ScrollView. At first glance, this seems like a straightforward layout. In practice, however, the behavior of nested scroll containers became unexpectedly challenging, especially when tested across platforms.

Observed Behavior Across Platforms

On iOS, the internal ScrollView generally behaves as expected without requiring additional configuration.

On Android, the situation is different. The inner scroll often fails to activate, gets interrupted by the outer scroll, or reacts inconsistently. This occurred not only on lower-end devices but on high-end models as well.

The issue becomes even more noticeable when:

The two scroll layers have different directions (for example, vertical parent and horizontal child)
The inner content has dynamic height or width
Multiple simultaneous gestures are triggered during rapid scrolling

It quickly became clear that this was not simply a styling conflict, but a deeper issue related to gesture priority and event handling at the platform level.

Root Cause Analysis: What Actually Happens Behind the Scenes

After reviewing React Native’s gesture responder system and native scroll behavior in both iOS and Android, several key points emerged:

On Android, the parent ScrollView receives gesture priority by default
It attempts to determine whether the gesture belongs to itself before allowing the child ScrollView to respond. This decision is not always accurate, which often prevents the inner scroll from initiating.
On iOS, gesture separation is more precise
The system determines the appropriate scroll target early and allows both parent and child scroll views to operate smoothly.
Mixed-direction scrolling increases complexity
When the parent scrolls vertically and the child scrolls horizontally, the system must re-evaluate gesture direction multiple times. On Android, this frequently results in jumps, unexpected direction changes, or the parent taking control prematurely.
Dynamic layout measurement affects gesture routing

Incorrect or late size calculations can cause the inner ScrollView to lose gesture ownership too early.

Practical Solutions Based on Testing

Several solutions helped achieve consistent, reliable behavior for nested scrolling:

Enable nestedScrollEnabled on the inner ScrollView (Android)

<ScrollView>

     <ScrollView nestedScrollEnabled>

        {/* content */}

     </ScrollView>

</ScrollView>

This is the foundational setting required to ensure the child scroll can properly receive gestures.

Use flexGrow for proper content measurement

contentContainerStyle={{ flexGrow: 1 }}

This ensures the inner ScrollView’s content is measured correctly, reducing gesture conflicts with the parent view.

Handle mixed-direction scrolling intentionally

When the parent and child scroll in different directions, it is often beneficial to temporarily enable or disable one of the scroll containers based on the detected gesture direction.

This approach helps the system correctly determine which layer should receive the gesture and prevents unintended handoffs during scroll.

Complete Example

// https://www.linkedin.com/in/mohammadrostami/
import React from 'react';
import { ScrollView, View, Text, StyleSheet } from 'react-native';

export default function NestedScrollExample() {
  return (
    <ScrollView style={styles.parentScroll}>
      <View style={styles.container}>

        <Text style={styles.title}>Parent ScrollView</Text>

        <ScrollView
          nestedScrollEnabled
          style={styles.childScroll}
          contentContainerStyle={{ flexGrow: 1 }}
        >
          <View style={styles.childContent}>
            {Array.from({ length: 25 }).map((_, i) => (
              <Text style={styles.item} key={i}>
                Child Item {i + 1}
              </Text>
            ))}
          </View>
        </ScrollView>

        <View style={styles.footer}>
          <Text style={styles.footerText}>Footer Content</Text>
        </View>

      </View>
    </ScrollView>
  );
}

const styles = StyleSheet.create({
  parentScroll: {
    flex: 1,
    backgroundColor: '#fafafa',
  },
  container: {
    padding: 16,
  },
  title: {
    fontSize: 18,
    marginBottom: 12,
  },
  childScroll: {
    height: 250,
    borderRadius: 8,
    borderWidth: 1,
    borderColor: '#ccc',
  },
  childContent: {
    padding: 12,
  },
  item: {
    paddingVertical: 10,
    fontSize: 16,
  },
  footer: {
    marginTop: 30,
    padding: 12,
    backgroundColor: '#eee',
    borderRadius: 8,
  },
  footerText: {
    fontSize: 16,
  },
});

Conclusion

Nested ScrollViews introduce a set of platform-specific challenges in React Native, particularly in Android where gesture routing differs significantly from iOS. Understanding how gestures are prioritized, how mixed-direction scrolling is handled, and how layout measurement affects scroll behavior is essential for creating smooth, predictable user experiences.
Properly configuring nestedScrollEnabled, managing dynamic content sizing, and intentionally controlling scroll interactions are key to resolving these issues in production-grade applications.