Use this page with AI

Copy this into your coding assistant and add your request.

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

Versions & Release Channels

Quickly scan the latest OpenIAP ecosystem versions using the badges and release links below. This page updates in lockstep with each library release train.

Client Protocol#

The Client Protocol is the purchase API an app calls. It is defined once as a GraphQL contract and published as @hyodotdev/openiap-client-protocol, currently v1.0.0. Every type an SDK exposes is generated from it.

openiap-apple, openiap-google, and the six framework libraries implement this protocol. None of them defines it, and none may extend the contract locally — a new API starts as a schema change in the protocol.

Commerce Protocol#

The Commerce Protocol is the server-side contract: purchase verification, entitlements, and lifecycle events exchanged between backends. It ships as @hyodotdev/openiap-commerce-protocol, currently v0.3.1. See the Commerce Protocol section for the specification itself.

Any backend may implement it. IAPKit is one such implementation: it serves every profile and both bindings, and declares which capabilities it supports per store in its capability descriptor, so the gaps are published rather than implied.

The wire contract carries a second number, and it is not the package version. A descriptor declares commerceProtocolVersion: "1.0" and every event body carries eventVersion, both as MAJOR.MINOR; the REST binding lives at /commerce/v1 because the major is 1. Those describe the contract on the wire. The npm version above describes the files that distribute it, and moves on its own release cadence. Consumers pin on the wire major, never on the package version.

OpenIAP Google Library#

The Google Play Billing implementation ships through Maven Central. Use the badge below to monitor the currently published artifact.

Maven Central status for openiap-googleio.github.hyochan.openiap:openiap-google
  • Latest stable release badge reflects Maven Central publication.
  • The library versions independently of the Client Protocol; check the tag notes on GitHub for API surface changes.

OpenIAP Apple Library#

StoreKit 2 support is distributed via Swift Package Manager and CocoaPods. Both channels are updated in lockstep.

Swift PackageCocoaPods version for openiap
  • SPM packages are tagged with the same semantic versions as docs.
  • CocoaPods specs are pushed immediately after SPM releases.

OpenIAP npm packages#

These packages version independently of the native SDKs. Each badge reads the published npm latest tag.