Conversation
Bumps the billing client from 8.0.0 to 9.1.0 and RevenueCat (test app) to 10.14.1. Billing 9 removes the SkuDetails APIs, so this drops the deprecated SuperwallBillingFlowParams.Builder.setSkuDetails and the unused internal SWProduct wrapper, and switches buildQueryPurchaseHistoryParams over to QueryPurchasesParams. See https://developer.android.com/google/play/billing/migrate-gpblv9
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Add custom store products, new purchase controller method
Update Google Play Billing Library to 9.1.0
…input When reroute_back_button is enabled in Paywall settings, a system back press previously did nothing unless the host app set the PaywallOptions.onBackPressed callback — otherwise the paywall dismissed as if the setting were off. Back presses the app callback doesn't consume are now injected into the webview as the paywall-js back_button_input message. The paywall either navigates its flow back one page or posts the existing close message, which dismisses through the standard manual-close path (Declined / ManualClose), so back-at-root behaves exactly like a native dismissal. The press/consume decision is extracted into backPressBehavior() and unit tested; the JS bridge payload is covered in PaywallViewTest. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017vi3SWn6yXT5kTBj7NEb3m
…lity probe Multi-page flow paywalls were closing entirely on system back instead of navigating back a page. Forwarding is now the default for every paywall, not just those with reroute_back_button enabled — that setting now only controls whether the PaywallOptions.onBackPressed app callback gets first refusal. Because published paywalls pin their built runtime, blindly forwarding would strand users on paywalls whose runtime lacks the back_button_input consumer. The SDK therefore probes the webview for window.paywall.supportsBackButtonInput first; when absent (older runtime, still loading, crashed webview) it falls back to the native dismiss, preserving today's behavior exactly. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017vi3SWn6yXT5kTBj7NEb3m
…is ENABLED Forwarding by default changes implied behavior for existing multi-page paywalls, so gate it behind the existing per-paywall dashboard setting while the default story is decided (possibly a new setting). DISABLED and unset paywalls dismiss on back exactly as before. The capability probe stays: even ENABLED paywalls on older runtimes keep the native dismiss. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017vi3SWn6yXT5kTBj7NEb3m
Team decision: this ships as an accepted breaking change. Every system back press the app callback doesn't consume is forwarded into the paywall as back_button_input — the paywall navigates its flow back one page or posts close (Declined/ManualClose) at the root. The reroute_back_button setting now only controls whether the PaywallOptions.onBackPressed callback is consulted first. Native dismissal remains only when no PaywallView is attached to the activity. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017vi3SWn6yXT5kTBj7NEb3m
The message's arrival is the signal — only presses are ever sent, so the boolean carried no information. Matches the simplified paywall-js schema. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017vi3SWn6yXT5kTBj7NEb3m
The Unreleased section this entry was written under became 2.7.23 on develop; the change ships with 2.8.0. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017vi3SWn6yXT5kTBj7NEb3m
Adds PaywallMessage.BackButtonPressed and handles it via the standard pass()/accept64 pipeline instead of a hand-rolled evaluate in PaywallView, reusing the established main-thread dispatch, error logging, and encoding. Removes BackButtonInputEvent and reverts the gameControllerJson rename it motivated. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017vi3SWn6yXT5kTBj7NEb3m
Forward system back presses into the paywall as `back_button_input`
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
2.8.0
Enhancements
PurchaseController, bypassing Google Play Billing entirely — checkproduct.isCustomProductto fulfill them via your own payment flow, and grant their entitlements withSuperwall.instance.setSubscriptionStatus(...)on success. Requires configuring the SDK with aPurchaseController.PurchaseController.purchase(activity, product: StoreProduct, basePlanId, offerId)method that handles both Google Play and custom store products. For Play products, the underlyingProductDetailsare available viaproduct.rawStoreProduct.transaction_start/transaction_complete,subscriptionStart/freeTrialStart) with an SDK-generated transaction identifier exposed asStoreProduct.customTransactionId, and free-trial eligibility for custom products is derived from the customer's entitlement history.TestStoreProducttoApiStoreProduct, now shared between test mode and custom store products.Breaking Changes
SuperwallBillingFlowParams.Builder.setSkuDetails(SkuDetails). Billing Library 9 removesSkuDetailsentirely, so this method can no longer exist. UsesetProductDetailsParamsList(...)withProductDetailsinstead.com.superwall.sdk.billing.SWProduct, which wrapped the now-removedSkuDetails.QueryPurchasesParams— Billing Library 9 removes the purchase-history APIs (queryPurchaseHistoryAsync,QueryPurchaseHistoryParams).SkuDetails,SkuDetailsParams,querySkuDetailsAsync,queryPurchaseHistoryAsync,BillingClient.SkuType, or the no-argenablePendingPurchases()), it will no longer compile once it picks up Billing 9 through this SDK. Migrate those call sites to theProductDetailsAPIs before upgrading; the migration guide has a mapping of every removed API to its replacement.Google Play Billing Library 9 requires Android 6.0 (API 23), so the SDK's
minSdkis now 23 (previously 21). If your app'sminSdkis below 23, you'll need to raise it to pick up this release — devices on Android 5.x will no longer receive app updates that include this SDK version.Deprecations
PurchaseController.purchase(activity, productDetails, basePlanId, offerId)in favor of theStoreProduct-based method above. Existing implementations keep working unchanged — the new method's default implementation routes Google Play purchases to the deprecated one — but purchasing custom store products requires implementing the new method.