App Store receipt signing certificate changes in 2023
February 7 2023 receipt signing certificate changes for the App Store
Are you using a hardcoded WWDR intermediate certificate for App Store receipt validation? Surprise. You now have 1.5 months to update your app before the old one expires on February 7th. This is what you should do right now:
What’s changing?
On December 20, 2022 Apple announced changes to the App Store receipt signing certificate. Specifically, they announced that from January 18th the App Store receipt signing certificate will use a new WWD intermediate certificate. From February 7, the previous certificate will expire and no longer function.
That’s less then 2 months for those affected to make the necessary change, right before the holidays. Ah, the joys of mobile development…
In all fairness, the Intermediate Certificate’s expiration date is literally coded into the certificate, but that 2023 date seemed so far away back when you implemented it.
What will happen to apps that don’t update their App Store receipt signing certificate
Validation will fail when your app tries to use the expired WWDR Certificate to validate the iTunes App Store Certificate in the PKCS #7 container that holds the actual receipt data.
Your app now has some freedom in responding to that failed validation, but – most likely – it’ll assume the user shouldn’t have access to the associated content, and will tell users so via the UI.
The result? Paying users that don’t have access to the content they paid for, a lot of uncomfortable questions to your support channels, bad app store reviews, and general misery all around.
How to check if you’re affected by the change
First of all, most likely, you’re not affected. The scenario in which this change actually impacts your app is relatively narrow:
- You’re not using the
AppTransaction
andTransaction
APIs to verify your App Store transactions - You’re not using the
verifyReceipt
web service endpoint - You use on-device receipt validation with a hardcoded intermediate certificate
Or, in other words, you did the thing RevenueCat CEO Jacob told you not to do when he explained the process for validating App Store receipts on-device:
If that’s you, you now have a few weeks to prevent any negative impact for your (paying) users.
How to update your App Store receipt signing certificate
Apple’s suggested solution is to update your code to match the recommended validation process outlined in their Validating Receipts with the App Store docs here. If you’re currently using on-device validation of App Store receipts, following these guidelines involves passing the binary encrypted file through the verifyReceipt
endpoint, via a secure server.
🚨 Calling the App Store server from your app is a no-go, as you won’t control either end of that connection: It’ll be impossible to build a trusted connection between the App Store and a user’s device.
If you haven’t already set up such a server, Apple’s suggested method is likely to take you days of work to implement. Luckily, this isn’t your only option, and with the time left to make this change, you might opt for a faster alternative:
Update the hardcoded certificate
Simply replace the old certificate with the new one 🤷♀️
Don’t do this. It’s faster than switching to the intended trust chain, but will put you in the same predicament again when something else changes to the certificates used by Apple.
Switch to a non-hardcoded certificate
Our very own Josh Holtz wrote about how this is done as part of his iOS in-app subscription tutorial with StoreKit 2 and Swift. Unfortunately, if you’re still on StoreKit 1, things are a little more complex than described in that article.
Your best bet is to follow one of the many on-device receipt validation tutorials out there, like this one or this slightly older one.
Or…
Switch to RevenueCat
The solution recommended by 9 out of 10 doctors developers: Switch to RevenueCat.
By simply following the iOS Purchases SDK installation instructions, you should get yourself that shiny secure server that Apple recommended, and then some.
You’ll be able to:
- Host and configure products remotely from your dashboard
- Analyze your subscription app’s most important metrics in one place
- See customer transaction histories, LTV charts, and grant promotional subscriptions
- Use webhooks to trigger other services based on real-time events
- Do all of that across platforms, easily
Some final thoughts
Constantly playing catchup with the changing rules, technical requirements, and peculiarities of the iOS and Android platforms and app stores, is a burden that drains the time and energy you should be spending on your app’s core value.
In this instance, the impact of this certificate expiring is relatively limited, but it’s one of countless examples of the constant ‘noise’ developers need to address to operate in the App Store.
It’s why we built RevenueCat.
Give it a try – for most apps, it’ll be free.
Or reach out and let’s chat about how we can help.
You might also like
- Blog post
Implementing in-app purchases and monetizing your Roku app: A step-by-step guide
A comprehensive guide to implementing and monetizing your Roku channel, from choosing the right strategy to technical tips and integration best practices.
- Blog post
How we built the RevenueCat SDK for Kotlin Multiplatform
Explore the architecture and key decisions behind building the RevenueCat Kotlin Multiplatform SDK, designed to streamline in-app purchases across platforms.
- Blog post
Inside RevenueCat’s engineering strategy: Scaling beyond 32,000+ apps
The strategies and principles that guide our global team to build reliable, developer-loved software