Use this page with AI

Copy this into your coding assistant and add your request.

Read https://openiap.dev/docs/updates/announcements 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 →

📢 Announcements

Important news and updates about OpenIAP

Amazon Fire OS and Vega OS support

We are now backed by Amazon Developer!

🔗

August 19, 2026

Today marks a meaningful milestone for our team: We're thrilled to share that OpenIAP is now backed by Amazon Developer through open-source sponsorship and technical contributions.

This support helps us to enable In-App Purchasing (IAP) capabilities for apps on Fire TVs through the OpenIAP ecosystem.

For context, more than 300 million Fire TV devices have been purchased around the world. They are used for streaming shows, playing games, and watching live events. For example, if you have ever rented a streaming movie, you have gone through an IAP payment flow.

Fire TV sports interface displayed on a living room TV

Image credit: Amazon News

There are two operating systems that power the Fire TV experience across these millions of streaming media players: Fire OS and Vega OS. OpenIAP supports both through its SDK and runtime integrations: Fire OS uses the Android amazon flavor backed by the Amazon Appstore SDK, while Vega OS uses a separate Kepler runtime path for react-native-iap and compatible expo-iap apps.

Key Points

  • The Amazon Store Setup guide shows how Fire OS apps can select the Android amazon flavor, including modules.amazon.fireOS for Expo and Gradle flavor selection for bare React Native, Flutter, KMP, and MAUI where supported.
  • The same Amazon Store Setup guide also covers Vega OS as a Kepler runtime target, not a Fire OS Android flavor. Expo uses modules.amazon.vegaOS and bare React Native for Vega uses Kepler dependencies plus manifest.toml.
  • Amazon Appstore IAP: OpenIAP maps Amazon types of purchases including consumables, entitlements, subscriptions, purchase updates, and fulfillment into the OpenIAP API standard.
  • Catalog identity: Product IDs stay aligned across Amazon Appstore, Amazon App Tester, app code, and Kit entitlement checks.

Note: OpenIAP will continue to operate independently with the same commitment to developer experience and cross-platform compatibility. Our core libraries remain MIT licensed and free to use.

OpenIAP 3: Xcode 27, Flutter SwiftPM, and a cleaner API

🔗

July 29, 2026

Xcode 27-ready. Flutter SwiftPM. The legacy clutter is gone.

OpenIAP 3 connecting purchase experiences across device platforms

OpenIAP 3 is our biggest contract cleanup yet. It connects Flutter's SwiftPM path to openiap-apple 3.0.0, adds guarded Xcode 27 and StoreKit 27 support, and removes the deprecated APIs, duplicate fields, legacy request shapes, and compatibility aliases that made cross-platform integrations harder to reason about.

What lands in OpenIAP 3

  • Guarded Xcode 27 and StoreKit 27 support brings subscription bundles and suites, verified offer-code redemption results, and new transaction metadata without dropping the documented older-OS fallbacks. Xcode 27-built UIKit hosts must also adopt UIScene; the release notes link the host migration checklist and the device examples exercise it.
  • Flutter 3.44+ resolves the OpenIAP Apple 3.0.0 native dependency through SwiftPM; older or SwiftPM-disabled projects retain the CocoaPods path.
  • The legacy surface is gone: purchase, verification, offer, billing-program, and platform-request models now use one canonical vocabulary across the supported SDKs.
  • IAPKit receipt verification, scoped keys, client payloads, catalog reads, and inbound App Store and Google Play webhooks keep their existing wire contracts.

Advance notice: deprecated APIs leave in the next majors

🔗

July 24, 2026

OpenIAP is defining one predictable removal window for its deprecated APIs and compatibility shims. Nothing is removed in a patch or minor release: the OpenIAP specification, openiap-apple, and openiap-google remove their deprecated OpenIAP-owned surfaces in 3.0.0. Framework libraries remove the same generated surfaces and their own shims only when each library reaches its independently versioned next major.

  • react-native-iap 16.0.0 and expo-iap 5.0.0
  • flutter_inapp_purchase 10.0.0
  • godot-iap 3.0.0 and kmp-iap 3.0.0
  • OpenIap.Maui 2.0.0

Flutter users should migrate custom Android payload fixtures and adapters to the canonical dataAndroid key now. The 9.6.1 retained originalJsonAndroid only as a temporary input fallback for the remainder of Flutter 9.x; the alias is not a public Purchase field and is removed in 10.0.0.

maui-iap

maui-iap is Now Available!

🔗

May 7, 2026 - maui-iap v1.0.0

We're excited to announce maui-iap, an official OpenIAP implementation for .NET MAUI! Starting from maui-iap v1.0.0, C# apps can use the same OpenIAP product, purchase, subscription, and listener model already used by the React Native, Expo, Flutter, Godot, and Kotlin Multiplatform libraries.

  • Native C# API - MAUI-friendly interface following the OpenIAP specification
  • Cross-platform - Supports iOS, Android, and macCatalyst from a single codebase
  • Type-safe - Generated C# records and enums for better IDE support and fewer runtime errors
OpenIAP meets MAUI
📦

All Framework Libraries Are Now in the OpenIAP Monorepo

🔗

April 6, 2026

All framework libraries are now managed in the OpenIAP monorepo. This consolidation brings unified versioning, shared CI/CD, and consistent development experience across all platforms. With this transition, all libraries now follow the OpenIAP Spec 2.0.0, ensuring a single unified specification across every platform.

Each library retains its own example apps, CI/CD pipelines, and publishes to its respective registry (npm, pub.dev, Maven Central, Godot Asset Library). The individual repositories will be archived and point to the monorepo going forward.

Documentation for versions prior to the ones listed above can be found in the archived individual repositories:

Why Monorepo?

  • Single source of truth — GraphQL schema, native modules, framework SDKs, generated types, documentation, and CI/CD all live in one repository. A spec change propagates across every platform in one commit.
  • Faster development cycle — Developers can work across native modules and framework SDKs simultaneously using local source references, without waiting for intermediate releases during development.
  • AI-friendly codebase — With all code co-located, AI assistants can navigate the full dependency graph, understand cross-platform implications, and make consistent changes across Swift, Kotlin, TypeScript, Dart, C#, and GDScript simultaneously.
  • Unified CI/CD — One set of release workflows with consistent versioning, prerelease support (rc), and GitHub Release creation across all platforms.

Notable Changes

  • Expo users: Use expo-iap instead of react-native-iap. The Expo example in react-native-iap has been removed — expo-iap is the recommended library for Expo projects.
  • DuplicatePurchase error code: Now an official part of the OpenIAP spec. Previously react-native-iap only, now available across all platforms.
  • expo-iap naming fix: isEligibleForIntroOfferIOS parameter renamed from groupID to groupId to follow the OpenIAP Id (not ID) naming convention.
  • Spec & Docs v2.0.0: The OpenIAP specification (openiap-gql) and documentation have also been bumped to v2.0.0 to align with the monorepo transition as a fresh start.
Showing 1-5 of 11 items