Engineering

WWDC 2022 Recap

Everything you need to know about this year's updates

WWDC 2022
Josh Holtz
Josh HoltzJune 16, 2022

Apple’s week-long Worldwide Developer Conference (better known as WWDC 2022) has come to an end. This time of year is always exciting for Apple platform developers, since we get to hear about the new features Apple has planned, along with improvements to existing features and services. 

Last year, the big announcement was StoreKit 2 — a brand-new API for interacting with in-app purchases and subscriptions written entirely with Swift. This was a major improvement from StoreKit 1, and we’ve been busy updating our SDK since it was released.

We weren’t expecting anything quite as big for WWDC 2022 (like a StoreKit 3), but we were hoping for some announcements about improvements to the StoreKit 2 experience. We got a bunch of things we wanted and more! 

Read on to learn more about these announcements and why we’re excited about them.

StoreKit 2

Why we’re excited: StoreKit is the foundation that our iOS and macOS SDK is built on. The updates that were announced at WWDC this year will allow us to provide 100% accurate information through our SDK and improve our testing experience.

Impact for RevenueCat customers: Our users will get some of these updates for free (by updating our SDK), and some of these are new APIs that will complement what the RevenueCat SDK does. Fortunately, there are no breaking changes, so the developer and user experience will only improve with these changes!

New Properties

StoreKit 2 models are getting some new properties:

Price Locale

The Price locale can be used to format numbers based on the numerical price of a product. For example, you could use this to show the price per month for an annual subscription: take the annual price, divide it by twelve, and format it for display using the new price locale property. 

Server environment

The new App Store server environment will return the environment the transaction took place in. (These values can be Xcode, sandbox, or production.)

Recent subscription start date

The recent subscription start date will show the most recent start date of a continuous subscription with no more than a 60-day gap. This can help you determine customer loyalty.

These properties will be backwards-compatible to iOS 15 but only if the app is built with Xcode 14. Xcode 14 will compile these new properties into your app.

(Even though these properties are new to StoreKit 2, the RevenueCat SDK has been providing these properties to our users for a while now!) 

SwiftUI API

Apple is all-in on SwiftUI and has created two new view modifiers for StoreKit-related functions. 

The first is offerCodeRedemption. This will open up an offer code redemption sheet over your current screen. RevenueCat’s SDK currently offers similar functionality with Purchases.shared.presentCodeRedemptionSheet(). But if you want to use SwiftUI, you can replace this with the new offerCodeRedemption. We plan to add similar SwiftUI view modifiers like this to the RevenueCat SDK soon!

The second is requestReview. This is accessed through @Environment(\.requestReview) and makes it really easy to ask for a review. However, you may still want to add some custom logic to prompt for a review only after the user has a positive interaction with your app.

StoreKit Messages API

This is a really cool one that we weren’t expecting but are excited about! There are times when Apple needs to communicate with an app user (for example, if there’s a price increase for an app subscription), and providing an in-app experience is the best way to do it. Historically, Apple could only communicate price increase agreements through email. This new StoreKit Messages API will allow Apple to send messages directly to your app subscribers — right in your app. 

With this update, Apple will automatically display a message to notify users of app updates when your app is in the foreground. This is nice because you won’t have to do any work, but you may want to control the experience — especially if your user is in some critical flow that you don’t want to interrupt. StoreKit offers an API that listens for messages, which you can add to a queue and display whenever it is most convenient for your user.

AppTransaction API

The all-new AppTransaction API lets you verify the purchase of the app itself. This is useful for apps migrating from the paid to freemium model. Now you’ll be able to verify that the app was purchased and see the transaction history, which will let you know which parts of the app the user should have access to after the move to in-app purchases.

App Store Connect API

Why we’re excited: Before now, RevenueCat had no way of interacting with our customers’ in-app purchases and subscriptions in App Store Connect. Our customers had to manually add all of their products. We don’t have anything concrete planned for this update yet, but we’re doing a lot of brainstorming about how we can use it to make using RevenueCat even easier for our customers.

Impact for RevenueCat customers: Nothing yet, but stay tuned for an improved RevenueCat experience!

The App Store Connect API was introduced at WWDC 2018 as an official way to automate with App Store Connect. It already had the ability to update metadata, upload screenshots and videos, configure and send out TestFlight builds, submit apps for approval, and much more. But it was missing one major thing, and we finally got it this year: the App Store Connect API is getting the ability to manage in-app purchases and subscriptions.

More specifically, you’ll be able to:

  • Create, edit, and delete in-app products
  • Manage pricing
  • Submit products for review
  • Create offers and promo codes

Having the ability to automate this will improve workflows for apps that generate a lot of products or services that manage in-app purchases and subscriptions. This update will be released in summer 2022.

StoreKit Testing

Why we’re excited: We know how critical our SDK is for our customers, so we take testing very seriously. Previously, some of our testing could only be done through the sandbox environment in a sample app. Now Apple is giving us the ability to test directly through Xcode, which will improve both the speed and quality of our testing.

Impact for RevenueCat customers: This update will make testing easier for developers that use our SDK!

There were A LOT of new StoreKit testing abilities announced in the What’s new in StoreKit testing session. 

StoreKit configuration files (which are used locally to mock in-app purchases on the App Store) can now be generated and synced directly from App Store Connect. This is a huge improvement! Previously, you had to manually add all of your in-app products in the StoreKit configuration file. This new ability will save developers a lot of time.

Xcode 14 also received a new transaction inspector. The transaction inspector shows all of the information about a transaction, including when it expires, upcoming renewals, the product identifier, and which group it belongs to. Now the transaction inspector also allows you to filter transactions by multiple properties, which will make finding the transaction your app is currently using even easier.

Once you’ve found your transaction, you can also perform some helpful tests, like messaging for a subscription price increase with StoreKit Messages, billing retries, and grace periods.

The sandbox environment also got some improvements! Now, fewer fields are required to create a sandbox test user on App Store Connect, and sandbox users can also test billing failures from the sandbox account settings. Plus, sandbox billing failures will be verifiable through the App Store Server API, which will improve the end-to-end testing experience.

Swift-DocC

Why we’re excited: We recently migrated our Apple docs to DocC, and we’re loving it! Any improvements Apple makes to DocC will just make the developer experience that much better for our customers. 

Impact for RevenueCat customers: Clear, organized documentation that makes it easy to find exactly what you’re looking for. 

Apple just released some DocC updates, including:

  • The ability to document Objective-C and C APIs alongside Swift
  • A navigation sidebar
  • The ability to search for APIs 

The RevenueCat SDK has already been updated to use the new DocC. Check out the docs!

SKAdNetwork

Why we’re excited: Being able to measure campaign conversion rates can help you determine what works and what doesn’t — and ultimately make you more money. (And we love helping developers make more money!) 

Impact for RevenueCat customers: No platform or SDK changes, but this should help developers better understand acquisition and grow their business.

Apple announced SKAdNetwork 4.0, which includes several much-needed improvements that should meaningfully improve ad measurement. SKAdNetwork can be a bit complicated, so let’s discuss the 3 biggest things Apple highlighted:

  1. Hierarchical IDs and conversion values. Apple will send more or less data in the postback depending on the anonymity of the conversion values. This means that larger apps with lots of conversions will get significantly more data for ad optimization. Smaller apps with fewer conversions will still get some data.
  1. Multiple conversions. Apple will now send multiple conversions over time instead of a single conversion with a timer that can be extended. The second and third postbacks will have less granularity, but this will help apps better optimize for events that happen later in the customer journey — without having to sacrifice getting some upfront data faster.
  1. Adding Web to SKAdNetwork. Ads on the web will now be able to send impression data to SKAdNetwork so that developers can advertise their apps on the open web and still attribute that conversion once the user opens the app. Previously, apps were mostly advertised inside other apps because the IDFA allowed fine-grain tracking. Now that web ads will work withSKAdNetwork, this opens up a whole new channel for advertising apps. 

Unfortunately, there are also 3 big caveats:

  1. Apple announced that SKAdNetwork 4.0 will ship “later this year” — their way of saying not with iOS 16 this fall. And it could get pushed into 2023.
  2. We don’t know this for sure yet, but it appears that SKAdNetwork 4.0 will be tied to iOS 16, meaning the exciting new features Apple just announced will only apply to users who have upgraded to iOS 16. Unfortunately, people are often slow to upgrade, and Apple bumped the minimum requirements to iPhone 8 and 8 Plus, which will further delay (and limit) the full impact of SKAdNetwork 4.0.
  3. While it’s great that Apple has added two more postbacks that can be sent up to 35 days after the initial install, there’s still no way to trigger postbacks without the user opening the app. This is a huge limitation for subscription apps, since many important signals happen outside of the app. For example, users can cancel a free trial in Settings/App Store without opening the app, and cancellation events are the strongest negative signal a subscription app has for ad optimization.

    Similarly, free trial conversions are the strongest positive signal a subscription app has for ad optimization, and the sooner that signal is received, the better. Allowing multiple postbacks up to 35 days after install is great, but it doesn’t solve this.

App Store Server API

Why we’re excited: The RevenueCat backend is built around the App Store Server API — it’s how we validate receipts and update customers’ entitlements based on subscription status. Improvements to the App Store Server API can improve the performance and reliability of our backend.

Impact for RevenueCat customers: Potentially nothing, since our backend currently updates subscription statuses in near real time, but things might be slightly faster!

The App Store Server API fetches and validates customers’ purchase history outside of the native app environment. This API is crucial for unlocking app features when a customer purchases an in-app product and locking features when they cancel their subscription or it expires. This year’s App Store Server API updates will make testing, performance, and quality even better.

New Fields

Apple announced two new fields for transactions: environment (which can be either “Production” or “Sandbox”) and recentSubscriptionStartDate. As you may have noticed, these are similar to the new fields that were added to the StoreKit models. The only difference is that “Xcode” is not a valid value for transactions. This is because transactions made via StoreKit configuration files don’t process on Apple’s servers — they happen entirely in Xcode.

Get Transaction History

This isn’t a new endpoint for the App Store Server API, but it did get some updates for sorting and filtering the transactions that are returned. This endpoint can now be filtered by:

  • In-app product type
  • Product identifier
  • Subscription group identifier
  • Purchase date range
  • Family sharing status
  • Exclude revoked transactions

Check out the updated documentation for this endpoint here.

You can also now sort transaction histories by last modified date (descending). This means you can get the most recently updated transactions first.

These updates are huge for improving your server performance when interacting with the App Store Server API. Now you no longer need to fetch all transactions and filter/sort them locally. (Of course, if you use RevenueCat, you never had to worry about this in the first place. 😉)

App Store Server Notifications

The App Store Server can notify your server of notable events like purchases, subscription renewals, and billing issues. Apple made two big announcements about App Store Server Notifications V2 at WWDC 2022.

The first is a new way to test the connection to your notification endpoint. In the past, you would have to create a new sandbox tester and make a test purchase through your app. It was a time-consuming process, and there was no easy way to find out what went wrong if the notification wasn’t received.

Now there are two new endpoints to help you with this: one for requesting a test notification and another for getting the status of the notification! After you request the notification, you can check to see if it was received and see an error message if it was unsuccessful.

The second update is for querying your server notification history. App Store Server Notifications will retry production notifications up to five times, with longer waits between each one. However, there may be times where your server is done for longer and then those notifications would be gone. But now there is a new server notification history endpoint! The App Store Server Notifications V2 API will keep a six-month rolling history of notifications that your server can replay.

This new endpoint can be filtered by purchase type and subtype, as well as by specific user. These new tools will help you update your customers’ product and subscription statuses much more efficiently.

Wrapping It Up…

These are just some of the changes Apple announced at this year’s WWDC. We’re excited to implement these new features and updates in RevenueCat to provide an even better experience for our customers!

Want to learn more? Check out our community post about this year’s WWDC announcements and be sure to tune in to our WWDC TLDR webinar on Friday, June 17th.

Subscribe to our monthly newsletter

Related posts

Google Play class action developer lawsuit
Engineering

Google Play Billing Library 5.0, an overview

Everything you need to know about Google Play Billing Library 5

Rik Haandrikman

Rik Haandrikman

November 25, 2022

Engineering

How RevenueCat’s SDK team uses Release Trains

How we automate the releases of our SDKs

Cesar de la Vega

Cesar de la Vega

October 31, 2022

Stripe for In-App Purchases
Engineering

Can You Use Stripe for In-App Purchases?

Learn about when you can use Stripe and opportunities to save money on fees.

Corey Rabazinski

Corey Rabazinski

October 31, 2022

Want to see how RevenueCat can help?

RevenueCat enables us to have one single source of truth for subscriptions and revenue data.

Olivier Lemarie, PhotoRoomOlivier Lemarie, PhotoRoom
Read case study