Platform-native implementation selector

One capability. Four runtimes. Six lifecycle states.

Choose the exact mobile path you are shipping. The matrix preserves current version evidence, exposes missing overview coverage, and makes the host application—not the provider UI—the owner of durable state.

Select a path Run the stateful host

selection-required

Feedback UI for React Native

Documentation: v2.0.0
Component: Not listed in current overview
Version: Selection required
State model: draft

The current React Native v2.0.0 overview does not list Feedback UI. This is a selection-required gap, not evidence that the capability is impossible or that another platform package is compatible.

Open first-party evidence Read as JSON

Coverage, without parity theatre

Twenty paths. Every gap visible.

“Not listed” means the current overview does not establish a package. It does not mean the capability is impossible, and it never licenses reuse of another platform’s package.

Six-state adapter contract

Make every return, cancellation, and late callback explainable.

The generated scaffold deliberately stops at an application-owned candidate. Your repository decides whether and how that candidate becomes durable.

Application screen

idle

No provider controller, route, Promise, delegate, or listener is active.

Platform adapter

launching

One generation ID binds configuration, owner, and launch time.

Provider widget under host lifecycle

active

Background, recreation, close, and duplicate-launch behavior are observable.

Platform adapter

returned / cancelled / failed

Exactly one typed terminal result wins; late results are ignored.

Application domain

candidate

Validate and normalize application feedback draft and attributable submission/reconciliation identity before committing.

Application repository

committed

Persist the normalized selection/draft with version, actor, source, and audit event.

React Native host adapter boundary

type PlaceSelection = { version: 1; mapplsPin: string; label: string };

interface MapplsPlaceWidget {
  selectPlace(): Promise<unknown>;
}

async function choose(widget: MapplsPlaceWidget, generation: number) {
  const value = await widget.selectPlace();
  if (!isFocused() || generation !== currentGeneration()) return;
  if (!isPlaceSelection(value)) throw new Error("invalid_widget_result");
  commitCandidate(value); // Store normalized data, never the opaque native object.
}

function isPlaceSelection(value: unknown): value is PlaceSelection {
  const item = value as Partial<PlaceSelection> | null;
  return item?.version === 1 && /^[A-Za-z0-9]{6}$/.test(item.mapplsPin ?? "") && typeof item.label === "string";
}

State ownership

The widget is a collaborator, not your database.

One focused screen owns the native Promise, bridge generation, AppState changes, cancellation, and normalized JavaScript result.

Parse unknown bridge data into a versioned TypeScript value; do not store an opaque native result object.

Promise rejection, native cancellation, screen blur/unmount, bridge reload, and malformed data are typed separately.

The durable record is application feedback draft and attributable submission/reconciliation identity; never retain a provider view/controller or opaque bridge result.

Production gate

Test the lifecycle you cannot demo.

Happy-path selection proves almost nothing about a production mobile integration.

Public repository and developer-documentation version drift is resolved before dependency pinning

Peer native SDK versions are compatible

Only the focused mounted screen accepts a Promise result

Bridge data is schema-validated

Fast Refresh and native recreation do not double-commit

Permission/configuration denied

Offline and slow provider response

Cancel before and after a candidate appears

Host edit invalidates a stale selection

Duplicate callback/Promise result commits once

Accessibility, focus return, and a non-widget fallback