Apple In-App purchase update: StoreKit 2 Migration

Overview

Apple has introduced StoreKit 2, the latest framework for handling in-app purchases across iOS, iPadOS, macOS, tvOS, and watchOS. To stay compliant with Apple’s guidance and ensure long-term support, Frisbii has updated the Transform platform to support both StoreKit 1 and StoreKit 2.

Why this matters

• Ensures compliance with Apple’s latest platform requirements

• Provides future-proofing as Apple phases out StoreKit 1

• Maintains compatibility with older devices that still use StoreKit 1

What’s new

Transform now supports transactions initiated via StoreKit 2, in addition to existing StoreKit 1 support. 🟢 Note: No re-onboarding or contract changes are required.

This includes:

• Subscription purchases

• Renewals

• Restores

These processes now work seamlessly across both frameworks.

To enable StoreKit 2

Update your integration to the latest version of our API with this technical guide.

Migration Steps:

1. Configure an In-App Purchase Key at https://appstoreconnect.apple.com/access/integrations/api/subs

2. Enter the key in the Transform settings without activating them

• The credentials will be validated against the Apple servers, but will not have any effect on opterations.

• The settings consist of Default Bundle ID, IssuerId, Key ID, and Private Key

3. Enable "Use V2 API" in Transform.

• Once active, this setting cannot be disabled again without contacting support.

• Existing receipts will be gruadually converted to use the V2 API on their next refresh (for active subscriptions this will happen over the next 24 hours)

• The /check endpoint accepts both V1 (Base64-Receipt) and V2 (TransactionId) data, so you can migrate the clients to V2 gradually at your own pace.

• We will continue processing V1 notifications for both V1 and V2 purchases.

4. Switch the notification settings in Apple to use V2.

• This remains compatible with V1 purchases

• Only make this change after Apple V2 has worked successfully in your system for some time.

Consequences for your client applications:

1. /check requests will be significantly slower for customers with a lot of Apple transactions, because the V2 API is paginated and requires multiple requests to fetch all transactions. So if you have configured a short request timeout, you should raise it.

2. StoreKit V2 /check requests contain the TransactionId instead of the Base64 encoded receipt used by V1

What the new /checkAPI call looks like:

POST /api/v1/ExternalSubscriptions/check
{
     "Type": "AppleIap",
     "AppleIapTransactionId":"...", // required
     "AppleIapBundleId":"...", // optional, defaults to "Default Bundle ID" from the settings
}

The workflow remains the same as before:

1. Send provider specific data to /check endpoint, and get ExternalSubscriptionIds in response (potentially slow, since it talks to Apple)

2. Create an order, using an ExternalSubscriptionIds from step 1

3. Commit the order from Step 2

Test your in-app purchase flows to ensure they work correctly with both StoreKit 1 and 2.

Benefits for your customers

• More reliable purchase and subscription flows

• Faster restoration of purchases across Apple devices

• Improved security and transaction verification

• Continued compatibility with future Apple OS versions