StoreKit 2
StoreKit 2 delivers powerful, Swift-native APIs for in-app purchases and auto-renewable subscriptions. Learn how you can easily implement in-app purchases and subscriptions, and discover APIs for retrieving product information, handling transactions, determining product entitlements and customer status, as well as comprehensive testing support in Xcode.
The Refund API doesn’t let you programmatically issue a refund to your customers. It merely lets you show a sheet to customers, so they can request a refund from Apple. They hear back within 48 hrs.
This makes it look like Devs control the refund. So we get all the ire, even more. With no control.
When Apple really doesn’t want to do something but is pressured into offering a “sweet solution,” you can just feel the contempt they have for the people asking for the full thing
On the plus side, it does look like StoreKit 2 makes lots of things easier.
Google Play does what?? 🤯
“You may get an automatic refund if you uninstall a paid app shortly after first buying it”
Previously:
- Whitelisted Developers
- Receipt Validation and AirPlay 2
- Apple Support Tells Customers to Ask Developer for Refund
Update (2021-06-13): Jacob Eiting:
This is huge. You are now able to get to IAP transactions IDs from the customer order ID present in customer emails.
This will help a ton with the evergreen “I purchased this thing, where is my content” support ticket.
Update (2021-10-20): Michael Love:
Bunch of new StoreKit stuff they didn’t mention at all, though it appears they still aren’t allowing developers to actually initiate refunds likely due to the fact that the whole backend is made out of tin cans + string.
“Invoice Lookup” is nice, but only works if the user has a receipt, which they usually don’t - Google has supported search by email from the beginning and they’ve done it safely/anonymously (have to enter it exactly + they don’t display it).
StoreKit 2 introduces powerful new Swift-based APIs that make supporting in-app purchases and subscriptions easier than ever. You can now easily determine product entitlements and eligibility for offers, quickly get a user’s history of in-app purchases, find out the latest status of a subscription with one simple check, provide a way to request refunds and manage subscriptions from within your app, and more. StoreKit 2 also uses Swift concurrency and JSON Web Signature to simplify how you retrieve product information and handle transactions.
“Wow, StoreKit2 is going to kill RevenueCat”
The reality:
Update (2022-10-13): Craig Hockenberry:
You know what would be great? The TestFlight sandbox working with StoreKit2 as well as Xcode does.
I have never seen it return
currentEntitlementsand that’s a hell of a thing to be missing if you want to test behavior for PAYING customers.At this point, I’d prefer TestFlight to use the production App Store backend.
Let testers pay for real or hand out promo codes as needed.
The current situation achieves nothing.
Could not agree more. Getting paid is about as crucial a function of shipping an app as can be, and yet we’re still ultimately left to cross our fingers and ship to the general public before we know for certain it’s working properly.
Update (2024-02-01): Luc Vandal:
Is it just me or StoreKit 2 is far from reliable on macOS? Products or subscriptions not loading, app unable to connect to the StoreKit service (XPC), etc. It’s pretty flawless on iOS. 🦗🦗🦗 from the StoreKit team or on Apple Dev forums (which is not surprising).
Update (2024-05-07): Luc Vandal:
Working with StoreKit 2 is frustrating. Production often differ from debug, dealing with Family Sharing adds another layer of complexity. Hopefully, we’ll see significant improvements this June. It’s frustrating to debug production issues blindly, so a more robust solution would be highly welcomed.
