Native bindings missing: StoreKit 2 (iOS) + Google Play Billing Library (Android)

[proggeramlug]

Summary

Perry currently exposes no TypeScript bindings for StoreKit 2 on iOS or for the Google Play Billing Library on Android. Apps that want to do in-app purchases for subscriptions on those platforms have no way to drive the native flow today; they must either go through Stripe-card on iOS / Android (rejected by Apple's review process for digital subscriptions) or skip native IAP entirely.

This is a feature request, not a bug — there is nothing to reproduce because the surface doesn't exist.

What's needed (server-driveable shape)

A small TypeScript surface that wraps the platform calls. Sketch:

// perry/iap (proposed)
export type Product = {
  productId: string;
  title: string;
  description: string;
  priceMicros: number;
  priceCurrencyCode: string;
};

export type PurchaseResult = {
  productId: string;
  transactionId: string;     // StoreKit transactionIdentifier or Play purchaseToken
  purchaseDate: string;      // ISO 8601
  receipt: string;           // base64 — server validates against Apple/Google
};

// iOS StoreKit 2:
export function loadProducts(productIds: string[]): Promise<Product[]>;
export function purchase(productId: string): Promise<PurchaseResult>;
export function restorePurchases(): Promise<PurchaseResult[]>;

// Android Play Billing Library:
// (same surface — implementation differs)

Server-side receipt validation is plain HTTPS against Apple's verifyReceipt / Google's Play Developer API and doesn't need a native binding.

Reference implementations

• iOS: StoreKit 2 (Swift) — Product.products(for:), Product.purchase(), Transaction.currentEntitlements
• Android: androidx.billing:billing-ktx — BillingClient, queryProductDetailsAsync, launchBillingFlow
• Both have well-documented async APIs that map cleanly to Promise-returning TS functions.

Why we filed

Our app spec calls for a Free / Pro / Business plan tier with subscriptions. Stripe-card works on macOS / web and (via SFSafariViewController) on iOS for organizations, but Apple requires StoreKit for individual subscriptions. We can ship the macOS/web flow today; the iOS flow is blocked.

Workaround

We will gate iOS/Android subscription UI behind a feature flag and ship without IAP for v1. Server endpoints for receipt validation can land independently (plain HTTPS).

Environment

• perry 0.5.503
• Targets: ios, android (binding for both platforms)

[proggeramlug]

First-pass StoreKit 2 binding shipped at https://github.com/PerryTS/storekit (commit ffe8b0f). It will land on npm as perry-storekit once publish is run.

What's in v0.1.0

• Built against perry-ffi = "0.5" (declares perry.nativeLibrary.abiVersion: "0.5").
• Six FFI exports — js_storekit_load_products / purchase / restore / has_subscription / get_jws / start_listener — wired to a Swift bridge that calls StoreKit 2 (Product.products(for:), Product.purchase(), AppStore.sync(), Transaction.currentEntitlements, Transaction.updates).
• Apple targets (ios 16+, macos 13+) build the Swift bridge via crate-ios/build.rs; non-Apple targets fall back to crate-stub so calling code can use the same imports without #ifdef-style platform checks.
• TypeScript exports the typed Product / PurchaseResult / HasSubscriptionResult / JwsResult / RestoreResult shapes alongside the raw FFI declarations. Sketch from the issue is honored, with one practical adjustment: PurchaseResult.jws carries the App Store-issued JWS instead of a base64 receipt — that's what the App Store Server API expects on the StoreKit 2 path.
• README has a copy-pasteable typed wrapper (loadProducts, purchase, hasSubscription, getJWS, restorePurchases).

Verified: both crates build clean against perry-ffi 0.5.625. iOS device (aarch64-apple-ios) and macOS (aarch64-apple-darwin) targets export all six js_storekit_* symbols with the Swift bridge linked in.

Still open (the Android half of #537)

This binding only covers iOS/macOS. Google Play Billing (androidx.billing:billing-ktx) for Android is a separate package — same TypeScript surface, different native side. Could either ship as a sibling perry-play-billing repo or fold into this one with Android crate-jni. Happy to take direction on which.

[proggeramlug]

Reopening — only the iOS/macOS half landed in @perryts/storekit v0.1.1. The Android Google Play Billing Library binding is still missing.

Working on it next. Will likely ship as a sibling @perryts/play-billing package at https://github.com/PerryTS/play-billing — same typed Product / PurchaseResult shape from #537's sketch, native side is a JNI bridge over androidx.billing:billing-ktx (BillingClient, queryProductDetailsAsync, launchBillingFlow, Purchase).

(Per-platform packages, not a unified @perryts/iap. Apple-only and Google-only IAP have meaningfully different lifecycle quirks — acknowledgement flows, JWS vs. purchase tokens, subscription proration — and bundling them just so callers save one import would force a lowest-common-denominator API. Apps that need both will branch by __platform__ the same way the searchbird mobile app already does for storekit-vs-Stripe.)

[proggeramlug]

Android half is shipped — @perryts/play-billing@0.1.1 is live on npm with provenance. Repo: https://github.com/PerryTS/play-billing.

What's in v0.1.1

• Six FFI exports — js_play_billing_load_products / purchase / query_purchases / has_subscription / acknowledge / start_listener — wired through a JNI bridge over com.android.billingclient:billing-ktx:7.1.1.
• Rust crate (crate-android/) using perry-ffi 0.5 + jni 0.21. JNI_OnLoad captures the JavaVM; each FFI export creates a JsPromise, hands the raw pointer to a Kotlin static method, and resolves via Java_com_perryts_playbilling_PlayBillingBridge_nativeOnComplete.
• Kotlin bridge (PlayBillingBridge.kt) shipped as a precompiled AAR (play-billing-bridge.aar, 25 KB) committed to the repo — host APKs add one implementation(files(...)) line plus the two transitive deps (billing-ktx + kotlinx-coroutines-android). v0.2.0 will publish the AAR to Maven Central and remove the transitive-dep boilerplate.
• TypeScript surface models Play Billing natively rather than forcing it into StoreKit's shape: purchaseToken (not jws), orderId, purchaseState, acknowledged flag, subscriptionOffers with full pricing-phase info. README has a side-by-side cross-platform example showing the __platform__ branch for Apple vs. Google flows.
• Non-Android stub crate so the same import works on every other target — calls resolve with "not available on this platform" JSON.

Server-side validation

Out of scope for the binding (plain HTTPS against the Play Developer API using a service account). README walks through the recommended client/server flow including the 3-day acknowledge window.

Closing #537

Both halves shipped: @perryts/storekit@0.1.1 (Apple, PerryTS/storekit) + @perryts/play-billing@0.1.1 (Google, PerryTS/play-billing). Closing this issue. Followups (offer selection for subs, subscription proration, Maven Central publication for the AAR) will land as separate issues.