Use this page with AI

Copy this into your coding assistant and add your request.

Read https://openiap.dev/docs/updates/releases and https://openiap.dev/llms.txt. Follow the reading instructions, detailed reference, and linked guides relevant to my task before making changes.
Inspect my existing project and reuse its framework and conventions. Ask me for missing product decisions. Implement the requested behavior and run the applicable checks.
Show the working result, the commands and actual test results, and any remaining limitations. Keep your explanation brief.

My request: [describe what customers should be able to do]
See an example request →

Releases

Release notes for OpenIAP packages and framework libraries.

October 25, 2026 - Any verification service in the purchase flow#

IAPKit and on-device confirmation are now two confirmers built on the purchase flow's public contract, so any other verification service plugs in the same way; see Validation. Apps keep calling confirmWithIapkit and confirmOnDeviceIOS.

The native SwiftUI example now displays available subscription prices and purchase options correctly.

On Vega, react-native-iap and expo-iap no longer infer renewal from access; active paid terms remain listed with renewal unknown.

Protocols and native packages
  • Client Protocol 1.3.0: purchase-flow keeps its existing callback contract. Existing helpers and verification types remain available but deprecated until Client Protocol 2.0.
  • openiap-google 4.0.6: Amazon reports unknown renewal preferences without dropping active paid subscriptions. The legacy isAutoRenewing hint stays false when renewal is unknown; autoRenewingAndroid stays null.
Framework libraries
  • react-native-iap 17.2.1: corrects plan and renewal labels and Google Play prepaid plan changes in the subscription example.
  • expo-iap 6.3.0: deprecates the low-level helpers and verification types under expo-iap/build/purchase-flow and expo-iap/src/purchase-flow until Expo 7.0. Root imports remain supported.
  • flutter_inapp_purchase 11.2.0: deprecates createIapkitConfirmation, createDeviceConfirmationIOS, toIapkitVerificationProps, and readIapkitVerification. Example purchase cards use reported renewal preferences and preserve unknown values.
  • godot-iap 4.2.0: PurchaseFlow deprecates create_iapkit_confirmation, create_device_confirmation_ios, to_iapkit_verification_props, and read_iapkit_verification.
  • kmp-iap 4.2.0: createIapkitConfirmation, createDeviceConfirmationIOS, toIapkitVerificationProps, and readIapkitVerification remain public and deprecated, preserving their existing function types.
  • OpenIap.Maui 3.2.0: IapkitConfirmation and DeviceConfirmationIOS remain public and obsolete, preserving their existing signatures. The example purchase list now shows active Amazon subscriptions.
Migration notes

Existing calls and import paths keep working through patch and minor releases. Rebuild native apps after updating the framework SDKs to link the matching native packages. Replace the deprecated helpers with the SDK's confirmWithIapkit or confirmOnDeviceIOS (confirm_with_iapkit and confirm_on_device_ios in godot-iap), or pass another service's confirmer as confirmWithBackend. Removal is scheduled for each package's next major; see Scheduled removals.

Use active subscription status to determine access on Amazon. A null renewal preference does not expire a paid term.

Package Releases

October 24, 2026 - One purchase flow in every framework#

Every framework library now ships the same purchase flow. Give it a way to confirm a purchase and the list of consumables, and it confirms, finishes, and recovers every purchase the store delivers, on the App Store, Google Play, Amazon Appstore, and Meta Horizon, and reports each outcome. Apps without a backend confirm with IAPKit directly. The libraries also ship openiap-google 4.0.5 and openiap-apple 4.0.4, so Google Play prepaid plans accept payment methods that complete later; the October 22 release describes those purchases. See the purchase flow guide.

Hosted changes in this train are recorded in the IAPKit weekly history.

Request parsing and showcase validation use patched dependencies that prevent excessive memory use on malformed input. Development tooling also picks up the corresponding security fixes.

Protocols and native packages
  • Client Protocol 1.2.0: the purchase flow
    • accepts Amazon and Meta Horizon purchases, not only Apple and Google Play, and recovers each store's unfinished ones, including a listed consumable and every purchase from a store that reports no acknowledgment;
    • listens for purchases itself, including iOS redeliveries, and publishes an outcome through subscribe once per confirmation and again for each later delivery of a purchase it already settled, which it answers without confirming again. A failed confirmation is retried on the next delivery or recovery. It stops on dispose, including a recovery pass in progress;
    • takes wasRequested, which the SDKs answer from their own requestPurchase calls: a delivery counts as the user's own when it was bought after the request, give or take ten minutes of device clock drift (PURCHASE_REQUEST_CLOCK_SKEW_MS), or is the plan change the request asked for. A purchase error or dispose forgets the requests. Only the user's own purchase offers buying again after an invalid verdict;
    • confirms with IAPKit from the app through createIapkitConfirmation, which calls your grant before a consumable is consumed and leaves a purchase unfinished on any answer that may be a configuration error, and on the device through createDeviceConfirmationIOS for App Store purchases StoreKit still lists as unfinished and valid;
    • marks an entitled purchase whose plan change has not applied yet with changePending, which describePurchaseFlowStatus reports as the new guidance key change_pending. A Record<PurchaseFlowGuidanceKey, string> copy map needs the new key;
    • passes { isConsumable } to confirmWithBackend, and no longer finishes an acknowledged Google Play non-consumable again during a restore.
    The package publishes the shared test cases every library runs as purchase-flow-vectors.
  • openiap-google 4.0.5: initConnection on a connected Google Play client with a different billing program or Billing Choice renderer now rebuilds the client with it instead of ignoring it, and an explicit empty config returns it to the standard client; programs queued with enableBillingProgramAndroid stay. A call without a config keeps the live connection, and after a service drop or a failed connect reconnects with the program the app chose last; only endConnection forgets it. A rebuild is refused with developer-error while a purchase is in progress, and every library then stays connected and reports the error. A purchase requested while a rebuild is being prepared fails with service-disconnected, and a failed rebuild leaves the store disconnected. Both natives report Client Protocol 1.2.0; the natives the libraries shipped before reported 1.0.3, so they rejected a community store provider built for Client Protocol 1.1.
  • openiap-apple 4.0.4: reports Client Protocol 1.2.0.
Framework libraries
  • react-native-iap 17.2.0 and expo-iap 6.2.0
    • createPurchaseFlow needs only confirmWithBackend and isConsumable, also on Amazon Vega; confirmWithIapkit confirms with a publishable key and confirmOnDeviceIOS on the device.
    • Upgrading from react-native-iap 17.1 or expo-iap 6.1: a flow created with your own finishTransaction keeps the manual delivery, where your purchase listener calls processPurchase. A flow created without store functions listens for purchases itself, so drop processPurchase from your listener, keep one live flow, and call dispose() when the account changes.
    • useIAP({ purchaseFlow, onPurchaseFlowOutcome }) recovers unfinished purchases once connected and when the flow changes, reports each outcome, and refreshes ownership after it; restorePurchases confirms every owned purchase again.
    • useIAP no longer lets a store read that answers late overwrite newer availablePurchases or activeSubscriptions, and expo-iap refreshes both after every purchase, as react-native-iap does.
    • expo-iap replaces a product or subscription fetched again with its new details instead of keeping the stale entry.
    • When expo-iap cannot read iapkitApiKey from the app config, verifyPurchaseWithProvider says so and keeps the underlying error as its cause, instead of always reporting that expo-constants is missing.
  • flutter_inapp_purchase 11.1.0: createPurchaseFlow with an outcomes stream, confirmWithIapkit, confirmOnDeviceIOS, and PurchaseConfirmation.fromJson. On Android, initConnection with a config now reaches openiap-google even when connected; without one it keeps the connection. initConnection and endConnection run in call order, and a failed connection attempt leaves the store disconnected. endConnection after a dropped or failed connection still reaches openiap-google, so it forgets the billing program. The new exports include generic names such as PurchaseFlow and PurchaseEntitled; hide them on import if your app declares the same names.
  • godot-iap 4.1.0: create_purchase_flow, confirm_with_iapkit, confirm_on_device_ios, and a typed purchase_received signal; a grant callback must return true. While a flow exists, the iOS purchase listener also delivers StoreKit replays, including to your own purchase_updated handlers. On Android, verify_purchase_with_provider no longer blocks the frame. Android purchase_updated dictionaries now match the purchase queries (isAcknowledgedAndroid is filled in). Trace logs are off unless debug_logging is true; errors still print. init_connection with a different config, including an empty one, reconfigures the live connection instead of failing, and errors from non-purchase calls such as get_storefront carry a method key. A subscription request without an offer token, such as any Amazon Appstore subscription, no longer fails with subscriptionOffers must match the requested skus.
  • kmp-iap 4.1.0: KmpIAP.createPurchaseFlow on the app's existing instance, with an outcomes flow that ends on dispose, confirmWithIapkit, and confirmOnDeviceIOS. On Android, initConnection with a config now reaches openiap-google even when connected; without one it keeps the connection. On iOS, getAvailablePurchases and verifyAppOwnership with a boolean option such as onlyIncludeActiveItemsIOS or refresh no longer fail with "The data couldn't be read because it isn't in the correct format".
  • OpenIap.Maui 3.1.0: OpenIapClient.CreatePurchaseFlow, ConfirmWithIapkit, ConfirmOnDeviceIOS, and PurchaseConfirmationRequest.FromPurchase. InitConnectionAsync and EndConnectionAsync run one at a time in call order, and RequestPurchaseAsync records the requested products so the flow can tell a purchase from a redelivery. OpenIapClient.Query and OpenIapClient.Mutation replace casting the client to the resolver interfaces, which still works, and ObserveOnCurrentContext() delivers listener streams on the UI thread. iOS and Mac Catalyst trace logs are off unless OpenIapClient.DebugLogging is true.
Package Releases

October 22, 2026 - Pending payments for Google Play prepaid plans#

Google Play prepaid plans now accept payment methods that complete later, for new plans, top-ups, upgrades, and downgrades. The purchase request resolves while payment is pending.

Protocols and native packages
  • openiap-google 4.0.4
    • A new prepaid plan waiting for payment arrives as pending.
    • A pending prepaid top-up, upgrade, or downgrade resolves the request with the existing purchased purchase and its pendingPurchaseUpdateAndroid, also after a network error, the purchase flow timeout, or an already-owned rejection.
    • Purchase-update listeners get each new pending update, even on a purchase they already received.
    • A purchased purchase with a pending update no longer reports the requested plan in currentPlanId.
    • A pending update left from an earlier session does not resolve a new request unless Play rejects it as already owned.
Integration notes

On Google Play, a purchased purchase with pendingPurchaseUpdateAndroid means the requested change is still unpaid. Keep the current plan's access only while it stays active, and start the change only when Play reports its own token as purchased (#552).

Package Releases

October 21, 2026 - KMP and MAUI purchase verification fixes#

kmp-iap and OpenIap.Maui now finish IAPKit verification when the request omits the store user id. Before, it failed after the store purchase succeeded, so apps that finish only after verification left the purchase unfinished.

Hosted changes in this train are recorded in the IAPKit weekly history.

Framework libraries
  • kmp-iap 4.0.4
    • Fills in the signed-in user when verifyPurchaseWithProvider gets only the Horizon SKU or Amazon receipt id, as the other SDKs do.
    • Verification errors report the specific cause, such as an invalid baseUrl, instead of "Invalid arguments provided to the API".
    • A Play subscription replacement rejected with DEVELOPER_ERROR shows openiap-google's replacement-mode guidance instead of only Play's debug message.
  • OpenIap.Maui 3.0.4
    • Links Meta's users-kotlin platform module and its abuse-report-kotlin dependency in Horizon builds, so verification without horizon.userId no longer throws NoClassDefFoundError.
    • StatusAsync, EntitlementsAsync and BindUserAsync are documented as retired: they throw KitApiError with status 410 (see the October 15 purchase-flow release); move binding and v2 reads to your authenticated backend.
Package Releases

October 18, 2026 - Expo subscription refresh recovery#

Expo IAP keeps post-purchase ownership queries running when another store query fails. Background refresh stops when its hook unmounts, while purchase delivery and transaction settlement stay independent. The Expo example also lets you reload a failed product catalog without another purchase or restore.

Hosted changes in this train are recorded in the IAPKit weekly history.

Package Releases
...
Showing 1-5 of 99 items