Apple is wrapping up that WWDC week, its annual developer conference, and there is a lot to share about In-App Purchases and Subscriptions.
This piece of software developed by Apple is responsible for a $100 billion transactions last year and moving such a critical piece is neither an easy move for Apple nor for app editors. With what Apple just announced every aspect of IAP is affected :
- New version of StoreKit (StoreKit 2);
- New version of the server to server notifications;
- New verification system;
- New API.
If you are a customer of Purchasely you can calmly read that article we will handle all that for you and make sure you are always up to date and more. For others here is what you are going to have to do in the coming weeks or months.
Purchasely is the only platform to help App Editors easily and quickly monetize their Apps that are published on Apple, Android, Amazon and Huawei.
New version of Store Kit
Apple introduced StoreKit 2, a new API that completely changes the way to get sellable products, make purchases, restore and view your subscriptions.
From the logic and patterns (delegate vs async/await) to the models everything is different, including local receipt validation.
This is a major breakthrough for indie developers. If you are building an app that is only available on iOS and doesn't have a website where you use your purchases, you will no longer need a server to unlock your content. Apple has developed an easy and secure way to check the subscriptions and non-consumables that your customer has made.
Prior to StoreKit 2 you could do that but using obscure and complex cryptography methods.
Both version will live along side for a while but migration is on your way sooner or later so you'd better get ready.
💡 Checkout our blog in the coming days, we will post detailed articles about StoreKit 2. You can also subscribe to our newsletter and be sure not to miss them.
New version of the server to server notifications
Apple is changing its notifications, introducing new events, removing others, changing keys, adding values and changing formats.
These ARE breaking changes because it will require every editor to:
- Use the new events and change their subscription logic
- Migrate to the new receipt formats
- Test it
- Make the switch to the new API from App Store Connect
Apple will let you choose when you want to migrate and will also offer 2 URLs for your S2S, one for the sandbox and the other one for the production ensuring a smooth and tested migration.
We don't know yet when the v2 will be available. Both S2S v1 and v2 will be living along side but for how long?
💡 Checkout our blog in the coming days, we will post detailed articles about these new events and logic to be implemented. You can also subscribe to our newsletter and be sure not to miss them.
New verification system
Good bye to our old friend
/verifyReceipt it's been an amazing decade working together but you are no use to us anymore with v2 API.
Apple has introduced a receipt verification system based on JWS so you no longer need to do an external API call each time you receive an S2S notification or a purchase receipt.
It is much more than saving an API call, this is a massive improvement at scale. Priori to JWS you had to make an API call to Apple each time you received a receipt. This JWS validation will save you that synchronous call by a synchronous local check. It will make your entire infrastructure more robust and faster to process.
➡️ Read our step-by-step guide: How to handle JWS signature for Apple In-App Purchases written by our CTO Romain Salles:
* What is JSON Web Signature (JWS)
* How to decode Signed Transactions
* How to validate and check the data contained within
* How to encrypt every request made to the new App Store Server API
💡 Our customer success team will soon get in touch with you to get your keys and start preparing for the migration.
Speed up implementation and deployment for developers from months to just days.
New App Store Server API
Once again that old friend /verifyReceipt will be useless in the future. That endpoint used to dump every transactions the user has made and that list could be very long while you rarely needed that much information.
Apple now offers App Store Server API that allows you to request data more precisely about user transactions and subscriptions.
These changes will be affecting all developers and app editors at some point. Newcomers will enjoy the ease while current users will experience multiple migrations that will need to be executed perfectly.
Not all these changes will need to occur at the same time:
- Your mobile code will be able to live as is as long as Apple doesn't force you to migrate or offer you that one feature you were expected only on v2
- The v2 API can wait a little bit and you will be able to continue on
- The S2S v2 can also wait a bit but for how long ?
Start now, build a prototype, test it and see how this affects your existing infrastructure and code and start planning your migration. This new API will surely brings new features you will want to use one day... and the old one will be trashed at some point.
This new infrastructure offers great opportunity to simply code on the front end, create more robust code on the backend even if the work that remains to be done is important.
This might also be a time to think if this is your job to do such a heavy work of maintaining a mobile subscription stack and discuss with us: we can save you that time and open opportunities to make more money with our funnel as a service. Let's get in touch: firstname.lastname@example.org.