feat!: v6-only paywall API (remove v5) + single native module

[kherembourg]

Summary

Migrates the React Native SDK to the v6 paywall API as the single, only paywall surface and unifies the native layer into one module per platform.

What this PR now does (updated — the branch evolved past the original "façade alongside v5" approach):

• v5 paywall API removed (not deprecated). Paywalls are displayed and intercepted exclusively through the builders: PurchaselyBuilder (start), PresentationBuilder → PresentationRequest (preload / display / close / back) with a 5‑field PresentationOutcome, and typed interceptAction. There is no dual/soft‑transition mode.
• Core SDK is unchanged and version‑agnostic: user management, products, subscriptions, attributes, restore, event listeners, presentSubscriptions, client‑presentation tracking, and the embedded PLYPresentationView all keep their existing API.
• Single native module per platform:
  • iOS — the v6 bridge category was merged into PurchaselyRN.m; PurchaselyRNV6.h/.m are deleted. One Objective‑C bridge.
  • Android — PurchaselyV6Bridge was merged into PurchaselyModule.kt; the v6/ package is gone. One Kotlin module.
• No "v6" naming left in the code. Now that v6 is the only API, the v6 branding was removed everywhere (TypeScript src/v6/ folder dissolved into src/, bridge method/event names renamed, internal identifiers and log tags cleaned). v6 survives only as the SDK version (6.0.0-beta.0) and in the migration guide. The public API names are unchanged.
• Example app rewritten to the builder/PresentationBuilder/interceptAction API.
• Migration guide added: MIGRATION-v6.md maps every removed v5 paywall method to its replacement (the Purchasely AI plugin/skills can assist the migration).

Breaking changes

The v5 paywall methods are removed: start({...}), fetchPresentation, presentPresentation*, presentProductWithIdentifier, presentPlanWithIdentifier, show/hide/closePresentation, setPaywallActionInterceptor(Callback), onProcessAction, setDefaultPresentationResultCallback/Handler, readyToOpenDeeplink. See MIGRATION-v6.md for the old → new mapping. Core (user/products/subscriptions/attributes/listeners) is not affected.

Architecture

• One RN module named Purchasely per platform (PurchaselyRN / PurchaselyModule); the paywall bridge logic lives directly inside it.
• The JS↔native wire (method + event names) is synchronized across TypeScript, iOS and Android and verified by the façade integration tests.

iOS limitations (until the native iOS 6.0.0 SDK ships)

1. closeReason is not yet surfaced by native iOS (absent/button).
2. back() (goBackToPreviousScreen) is a no‑op + warning log — the legacy iOS SDK exposes no back() primitive.
3. webCheckoutProvider enum mapping is written against the 6.0.0 pod and will only compile once that pod is published (see CI note below).

Test plan

• yarn typecheck — 0 errors
• yarn lint — 0 errors
• yarn test — 133/133 pass (5 suites; v5 paywall tests removed, default() contract tests added)
• build-android / build-ios — blocked by an external dependency, not by this PR: the native Purchasely 6.0.0 SDKs are not published yet, so Gradle cannot resolve io.purchasely:core:6.0.0 and the iOS pod is missing the v6 symbols (PLYWebCheckoutProvider*, asDictionary). These jobs have failed identically on every commit of this branch (pre‑existing) and will go green once the native 6.0.0 SDKs are released. The native changes here were verified structurally (single @implementation/module, balanced braces, wire‑name sync) since they cannot be compiled in CI yet.
• Native iOS XCTest + Android JUnit suites (require example app context)

Reference

• Migration guide: MIGRATION-v6.md
• Changelog: packages/purchasely/CHANGELOG.md

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR introduces the v6 cross-platform contract on top of the existing React Native Purchasely SDK: a new PresentationBuilder/PresentationRequest JS façade, typed interceptAction, a PurchaselyBuilder start chain, an Android bridge (PurchaselyV6Bridge), and an iOS bridge (PurchaselyRNV6.m/.h).

• New v6 JS façade (src/v6/) exports PresentationBuilder, PresentationRequest, typed interceptors, and PurchaselyBuilder — all co-existing alongside v5 exports.
• Android (PurchaselyV6Bridge) wires native v6 DSL APIs with ConcurrentHashMap state, a 30 s interceptor timeout, and @JvmStatic delegation from PurchaselyModule. Several v5 presentation methods (fetchPresentation, presentPresentation, and five others) have been replaced with immediate rejections on Android, contradicting the stated "no removal yet" policy and breaking existing v5 callers at runtime.
• iOS (PurchaselyRNV6.m) implements the contract as a category on PurchaselyRN, with @synchronized(kV6StateLock) guards on shared mutable state. The interceptor callback store has no timeout — unlike Android's 30 s guard — so a JS bridge reload before v6CompleteInterceptor is called permanently freezes the native SDK action.

Confidence Score: 4/5

Safe to merge with caution — two active defects need resolution before shipping to existing v5 consumers or enabling the interceptor on iOS.

The Android bridge hard-removes v5 presentation methods that the JS deprecated wrappers still delegate to, meaning any app that hasn't migrated will receive runtime rejections on Android today. The iOS interceptor callback store has no timeout, so a bridge reload while an action is pending will freeze the native SDK action permanently — unlike the Android bridge which already has a 30 s guard.

packages/purchasely/android/src/main/java/com/reactnativepurchasely/PurchaselyModule.kt (v5 method removal) and packages/purchasely/ios/PurchaselyRNV6.m (missing interceptor timeout).

Important Files Changed

Filename	Overview
packages/purchasely/android/src/main/java/com/reactnativepurchasely/v6/PurchaselyV6Module.kt	New v6 Android bridge: preload/display/close/interceptor wiring with ConcurrentHashMap state, 30s interceptor timeout, and color-parsing guards. Solid implementation with prior review items addressed.
packages/purchasely/android/src/main/java/com/reactnativepurchasely/PurchaselyModule.kt	v5 presentation methods (fetchPresentation, presentPresentation, etc.) now hard-reject with 'v6_migration_required' — contradicting the PR's stated 'no removal yet' policy and silently breaking existing Android v5 consumers.
packages/purchasely/ios/PurchaselyRNV6.m	New iOS v6 bridge (665 lines): presentation lifecycle, interceptor, and start options implemented as a category on PurchaselyRN. Missing timeout on interceptor callbacks (unlike the Android 30s guard), which can permanently block native SDK actions.
packages/purchasely/src/v6/presentation.ts	PresentationBuilder/PresentationRequest JS facade: clean lifecycle event binding, subscription cleanup, and display() Promise semantics. No issues found.
packages/purchasely/src/v6/interceptor.ts	Action interceptor JS layer: per-kind registry, native registration/unregistration, and async handler dispatch. Dead branch in normalizePayload (P2 style).
packages/purchasely/src/v6/types.ts	Well-typed v6 contract types — Presentation, PresentationOutcome, ActionPayload union, InterceptorHandler. No issues found.
packages/purchasely/src/v6/startBuilder.ts	PurchaselyBuilder chain for v6 start: maps string enums to legacy ordinals and delegates to existing native start() + new v6ApplyStartOptions(). Clean implementation.
packages/purchasely/src/tests/v6.integration.test.ts	10 new integration tests covering preload, display, interceptor lifecycle, and timeout. Good event-driven mock harness.

Sequence Diagram

sequenceDiagram
    participant JS as JS (React Native)
    participant Bridge as Native Bridge (Android/iOS)
    participant SDK as Purchasely SDK

    Note over JS,SDK: display() flow
    JS->>Bridge: v6Display(requestId, payload, transition)
    Bridge-->>JS: Promise.resolve(true)
    Bridge->>SDK: prepared.display() / fetchPresentationFor:
    SDK-->>Bridge: onPresented(presentation)
    Bridge-->>JS: PURCHASELY_V6_PRESENTED event
    JS->>JS: onPresented callback
    SDK-->>Bridge: onDismissed(outcome)
    Bridge-->>JS: PURCHASELY_V6_DISMISSED event
    JS->>JS: resolve(PresentationOutcome)

    Note over JS,SDK: interceptAction() flow
    JS->>Bridge: v6RegisterInterceptor(kind)
    Bridge->>SDK: "setPaywallActionsInterceptor / interceptAction<T>"
    SDK-->>Bridge: action triggered
    Bridge-->>JS: PURCHASELY_V6_ACTION_INTERCEPTED (callbackId)
    JS->>JS: "handler(info, payload) -> result"
    JS->>Bridge: v6CompleteInterceptor(callbackId, result)
    Bridge->>SDK: complete(PLYInterceptResult)

Loading

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
packages/purchasely/android/src/main/java/com/reactnativepurchasely/PurchaselyModule.kt:293-320
**v5 presentation methods hard-removed on Android despite "no removal yet" claim**

`fetchPresentation`, `presentPresentation`, `presentPresentationWithIdentifier`, `presentPresentationForPlacement`, `presentProductWithIdentifier`, `presentPlanWithIdentifier`, `setPaywallActionInterceptor`, and `onProcessAction` all now immediately reject with `"v6_migration_required"` on Android. The PR description explicitly states _"v5 APIs remain (`@deprecated`). Once the iOS native fixes land we'll cut a 6.0.0 GA and remove v5."_, but the Android native implementation has already removed these methods. Any app calling the `@deprecated` JS wrappers (which still delegate to `NativeModules.Purchasely.fetchPresentation(...)`) will receive a runtime rejection on Android, silently breaking existing integrations that haven't migrated yet.

### Issue 2 of 3
packages/purchasely/ios/PurchaselyRNV6.m:506-514
**iOS interceptor callbacks have no timeout — SDK action can hang indefinitely**

The `kV6InterceptorCallbacks` dictionary stores each `callbackId → onProcessActionHandler` block with no expiry. If the JS side never calls `v6CompleteInterceptor` (e.g. the RN bridge is reloaded, the event listener is torn down, or the handler throws before completing), `onProcessActionHandler(proceed)` is never invoked and the Purchasely SDK action is frozen for the lifetime of the process. The Android bridge addressed this with `withTimeoutOrNull(INTERCEPTOR_TIMEOUT_MS = 30_000L)` that falls back to `NOT_HANDLED`. The iOS side needs an equivalent: a GCD `dispatch_after` (or an `NSTimer`) that fires after ~30 s, invokes the stored callback with `"notHandled"` and removes the entry from `kV6InterceptorCallbacks`.

### Issue 3 of 3
packages/purchasely/src/v6/interceptor.ts:49-60
Dead branch in the early-return guard — both the inner `if` and the fall-through return `null`, making the kind-check unreachable.

```suggestion
    if (!raw) {
        return null;
    }
```

_{Reviews (3): Last reviewed commit: "fix(v6): bound Android interceptor wait;..." | Re-trigger Greptile}

[kherembourg]

All 5 Greptile findings addressed in fbc99b6 (CI green locally: yarn typecheck ✓, yarn lint ✓, yarn test 149/149 ✓):

#	Sev	Finding	Resolution
1	P1	.gitignore merge corruption (.nx/workspace-datajest_dx/)	Split back into .nx/workspace-data + jest_dx/.
2	P1	Android onDismissed fired twice on display error	Removed the synthesized DISMISSED event; keep promise.reject() so the JS .catch settles once and still fires onPresented(null, error) — matching the iOS error path (parity preserved).
3	P1	iOS PresentationBuilder.default() always 400	v6ExtractTargetsFromPayload: now reads isDefault; v6Preload/v6Display route it to fetchPresentationWith:nil (legacy default-fetch path).
4	P1	iOS concurrent access to NSMutable* globals	Added kV6StateLock; all reads/writes of the three shared collections guarded by @synchronized. Interceptor callback invoked outside the lock.
5	P2	Android close() dismisses every presentation	Kept closeAllScreens() (no per-request close in native SDK yet; legacy closePresentation() does the same) + added a PLYLogger.w warning and an @remarks doc note on the public JS close().

Note on #2: I applied the inverse of the literal suggestion (drop event, keep reject rather than drop reject, keep event). Both eliminate the double-fire, but keeping the reject routes through the purpose-built JS .catch handler that also fires onPresented(null, error), keeping Android consistent with iOS. Details in the inline thread.

---

Generated by Claude Code

[kherembourg]

@greptileai review

---

Generated by Claude Code

[kherembourg]

@greptileai review

[greptile-apps]

iOS interceptor callbacks have no timeout — SDK action can hang indefinitely

The kV6InterceptorCallbacks dictionary stores each callbackId → onProcessActionHandler block with no expiry. If the JS side never calls v6CompleteInterceptor (e.g. the RN bridge is reloaded, the event listener is torn down, or the handler throws before completing), onProcessActionHandler(proceed) is never invoked and the Purchasely SDK action is frozen for the lifetime of the process. The Android bridge addressed this with withTimeoutOrNull(INTERCEPTOR_TIMEOUT_MS = 30_000L) that falls back to NOT_HANDLED. The iOS side needs an equivalent: a GCD dispatch_after (or an NSTimer) that fires after ~30 s, invokes the stored callback with "notHandled" and removes the entry from kV6InterceptorCallbacks.

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/purchasely/ios/PurchaselyRNV6.m
Line: 506-514

Comment:
**iOS interceptor callbacks have no timeout — SDK action can hang indefinitely**

The `kV6InterceptorCallbacks` dictionary stores each `callbackId → onProcessActionHandler` block with no expiry. If the JS side never calls `v6CompleteInterceptor` (e.g. the RN bridge is reloaded, the event listener is torn down, or the handler throws before completing), `onProcessActionHandler(proceed)` is never invoked and the Purchasely SDK action is frozen for the lifetime of the process. The Android bridge addressed this with `withTimeoutOrNull(INTERCEPTOR_TIMEOUT_MS = 30_000L)` that falls back to `NOT_HANDLED`. The iOS side needs an equivalent: a GCD `dispatch_after` (or an `NSTimer`) that fires after ~30 s, invokes the stored callback with `"notHandled"` and removes the entry from `kV6InterceptorCallbacks`.

How can I resolve this? If you propose a fix, please make it concise.