Explore testing in-app purchases

♪ ♪ Hemant: Hi, I am Hemant, a Commerce Developer Advocate for the App Store. I'm excited to discuss App Store's tools to help you test and validate your in-app purchase experience. I'll cover benefits for each of these tools and when it's best to use which. I will also cover all the great new features we are introducing this year for testing in-app purchases. So let's get started. App Store offers three tools to help you test in-app purchases. There is StoreKit Testing in Xcode, where you can test in-app purchases locally, and then there's sandbox, which uses products you have set up in App Store Connect, and TestFlight for performing end-to-end beta testing and to gather feedback from testers. These tools are available to help you build, test, and optimize your app's in-app purchase experience. I'll briefly describe each of these tools to help you determine the appropriate tool for your in-app purchase testing.

Starting with StoreKit Testing in Xcode. We introduced StoreKit Testing in Xcode at WWDC20. It enables you to test in-app purchases without setting up your products in App Store Connect. You can test your in-app purchases fully offline, without requiring a server. It provides you with the ability to create and manage your in-app purchases in the StoreKit configuration file. So you can test your code changes locally and in real-time. As you began your StoreKit integration, you can test your in-app purchase experience using simulator or a device. You can build automations to continuously test your in-app purchases by using a dedicated StoreKitTest framework. In addition, you can sync your in-app purchase products from App Store Connect to Xcode. This alleviates the need to set up a StoreKit configuration file manually. And you have ability to test advanced subscription use cases, such as offer code redemptions, price increase sheet, and subscriptions entering and exiting billing retry, all locally without having any dependency on a server. And one unique capability is the flexible subscription renewal rates, where you have option to choose a rate that fits your needs, from real-time to every two seconds. And now we have new options available with Xcode 15, giving you a set of renewal rates that are static and independent of the subscription duration. So a monthly product or annual product would renew at that same rate. You can simulate StoreKit errors that your app may encounter, which will help you build error handling into your app, errors such as if a product is not available for sale or if a user cancels the purchase. And now, if you are running multiple instances of your app, the transaction manager will display transactions for each app instance, allowing you to test on multiple devices. Transaction manager has added the ability to buy in-app purchases directly, all without opening your app, so you can test how your app handles external transactions. These new capabilities are available with Xcode 15. For more details, please see WWDC23 session "What's new in StoreKit 2 and StoreKit Testing in Xcode." Now, let's take a look at App Store sandbox. The App Store sandbox enables you to test and validate your end-to-end in-app purchase implementation on both client and server. This is important when building and qualifying your complete app experience and ensuring you are successfully delivering content to your users. To test in-app purchases in sandbox, your developer account needs to have a paid application agreement. You can test the app and in-app purchases on a registered device with your developer account. To make a purchase in sandbox, you'll first need to create a sandbox Apple ID in the Users and Access section of App Store Connect. To run your app on an iOS device running iOS 16 or greater, you will need to enable developer mode in Privacy Settings. The installed app is intended to be used for development and testing.

Sandbox helps you validate your logic to handle production-like scenarios such as purchases, restores, and subscription offer and provides you confidence to launch your app in production. To test your app in sandbox, you need a device, and you can distribute your app using two options, such as you can tether your device to your Mac and download the app on the device or using either of the distribution method like Release Testing, Debugging, and Custom to generate an IPA file. These methods help you deliver the app for testing purposes to your teams without a need to provide source code. We have been listening to your feedback and we understand sandbox is important to you for testing the customer experience. We continue to improve sandbox and add new testing features, and this year, we added support to simulate scenarios around involuntary churn such as subscription billing problem messaging and billing grace period. Later this year, we are releasing support for testing Family Sharing in-app purchases, and we have added new options to the iOS sandbox Account Settings page. Let's deep-dive into all of these features. Billing problem message simulation is available to you in sandbox, and later this year, it will be presented to customers in production when they enter billing retry. Billing problem messaging helps customers to resolve the payment issue without leaving your app and stay subscribed to your content and service. The billing problem sheet uses StoreKit 2 message API with reason billingIssue. The StoreKit message API is displayed by default when the customer launches your app or brings it to the foreground. Your can choose to defer or suppress the message by implementing a message listener in views, where a billing problem sheet presentation might confuse the customer. You can simulate the message API reason billingIssue in sandbox to test how your app handles the message presentation. To learn more about implementing StoreKit 2 Message API, please see WWDC22 session "What's new with in-app purchase." Now, let's review the steps for simulating a billing problem message in sandbox. To test billing problem message, your sandbox Apple ID needs to be subscribed to an auto-renewable subscription with status active. Then you can simulate billing issue by navigating to your sandbox account settings page on device in App Store settings and disable the switch "Allow Purchases & Renewals." Disabling the switch will simulate billing issue for the Sandbox Apple ID, and the existing auto-renewable subscriptions will fail to renew as per the configured subscription renewal rate and will go into billing retry state. And when you navigate back to your app, App Store will send the billingIssue message once the subscription fails to renew, and the billing problem message will appear. When you tap the Continue button, it will open the iOS sandbox Account Settings page, and you can now toggle ON the "Allow Purchases & Renewals" switch to successfully renew the subscription. Once the subscription renews successfully, you will no longer get the billing problem message. This helps you simulate a customer recovering from billing issue without leaving your app when they update their payment method for their Apple ID. Enabling grace period allows customers to retain full access to your app's paid content and service while Apple attempts to collect the payment. This also helps you as a developer to avoid interruption to your paid days of service if an auto-renewable subscription is recovered within the grace period. To enable and simulate billing grace period in sandbox, navigate to your App Subscriptions section in App Store Connect. In the Billing Grace Period section, click "Set Up Billing Grace Period." This will open a dialog, which will allow you to configure billing grace period for your app. You can than select from available grace period durations. Remember, these durations apply to production only, so when testing in sandbox, the duration of billing retry and billing grace period are pre-set according to your sandbox account's renewal rate. You can also select the eligible subscriber for billing grace period and select the environment. You can choose to enable it first in sandbox or choose to enable in both sandbox and production, then click Confirm. You'll see your selection visible in App Store Connect. And now let's discuss Family Sharing. Family Sharing is a powerful tool that makes it easy for customers to share their digital purchases with their family members. Enabling Family Sharing for your auto-renewable subscriptions and non-consumable products can help you attract new customers, increase user engagement, and improve retention. We wanted to provide you with an ability to test Family Sharing in-app purchases in sandbox.

To test Family Sharing in sandbox, you will need to log in to App Store Connect and navigate to the subscription or non-consumable products for which you need to enable Family Sharing. Then you will need to organize sandbox Family Sharing Members in App Store Connect. And lastly, make a purchase with your sandbox Apple ID which is enabled for Family Sharing. Let's walk through the testing details. Once you have enabled your in-app purchase product to be family-sharable, you can now navigate to "User and Access" section of App Store Connect, and there, you will see a new section labelled "Family Sharing." In that section, you will be able to organize and view your sandbox family members for a storefront. Let's illustrate what the in-app purchase experience looks like in sandbox. Here, you initiate a purchase on device, just like any other normal sandbox purchase. As Family Sharing is enabled, transactions will be created for each family member. Your app will now see these new transactions upon launch or in real-time from StoreKit. At this point, you can test your app logic to make sure it validates and entitles service for the transaction. Additionally, you can also simulate a family member losing access to the service. For that, on iOS sandbox Account Settings, tap Family Sharing. This will present you a view of all the family members in sandbox, and you can choose to stop Family Sharing. The Family Sharing in sandbox will allow you to verify and validate use cases such as: merchandising family-sharable products using isFamilySharable property of StoreKit. Validate your app logic to entitle service to a family member, for a new or existing purchase. Each family member can turn off sharing, enabling you to test when family members lose access to a previously shared purchase. For a scenario when a purchaser stops Family Sharing, you will be able to validate revoking access to services by using revocationDate available in JWSTransactions. And lastly, you will receive App Store Server Notifications for family members. To learn more about implementing Family Sharing, please see Tech Talk session "Explore Family Sharing for in-app purchases." Later this year, we are adding options to iOS sandbox Account Settings. The iOS sandbox Account Settings is available once you have made an initial in-app purchase in your sandbox app. Your signed-in sandbox account is visible in App Store settings. Scroll down this page to view your Sandbox Apple ID. When you tap on Sandbox Apple ID, a dialog appears. Tap the Manage button, and you'll navigate to your sandbox Account Settings. Later this year, you'll see three options, which were earlier available in App Store Connect and are now available to you on-device for testing. Now through the Account Settings page, you'll be to adjust subscription renewal rate, test interrupted purchases, and clear purchase history. When you tap on Renewal Rate, you can adjust the subscription renewal rate for your sandbox account. And you'll also be able to clear purchase history of the sandbox Apple ID, to refresh your sandbox Apple ID and re-test your use cases. Lastly, let's take a look at TestFlight. TestFlight helps you to test your app's end-to-end experience, distribute your apps, and gather feedback from a wider tester audience. This helps you to validate and improve your app experience before releasing it on the App Store.

TestFlight allows you to distribute your app across all Apple platforms. You can add both internal and external testers, create multiple groups of testers, and add different builds to each group depending on the features you want each group to test. Testers can allow latest builds to be installed automatically, and each build remains available for 90 days after upload. For more information, please watch the Tech Talks session "Get started with TestFlight." When testing in-app purchases, testers need to download your app builds using the TestFlight app. When buying an in-app purchase for an app downloaded through TestFlight, it uses your Apple ID, which is signed in to Media & Purchases settings of the device. Similar to sandbox, you won't be charged for testing in-app purchases for an app downloaded through TestFlight. For testing auto-renewable subscriptions, the renewal rates in TestFlight are equivalent to default renewal rate of sandbox. And if your app has implemented showManageSubscription API of the StoreKit, it gives you the ability to test subscription cancellation or change subscription. This year, we are making it easier to manage testers in TestFlight. You can filter by tester data like status, sessions, and bulk select group of testers to add or remove from a group. And to streamline your TestFlight app distribution, a new method is added for you to distribute the build, Internal Only. Using this method ensures the build can be available to internal testers and cannot be submitted for the App Store review. To learn more, please see session "What's new in App Store Connect" and "Simplify distribution in Xcode and Xcode Cloud." Now that I have reviewed the tools available for testing in-app purchases, it's important for you to know that these tools have their own benefits and differences but also have a lot in common, such as they support testing all in-app purchase types, and the subscriptions renew at an accelerated rate. However, some of these tools may be ideal for specific feature implementations or use cases. For example, subscription offer code redemption and price increase sheet can be tested using StoreKit Testing in Xcode. Billing retry and grace period can be tested using both StoreKit Testing in Xcode and sandbox. To validate your server side implementation, both sandbox and TestFlight support App Store Server Notifications and App Store Server API, while TestFlight provides you with a streamlined process to receive feedback from internal and external testers about your app's performance and overall experience. Consider leveraging these tools for testing in-app purchases depending upon your use cases, feature implementation, and your organization's team structure. We have covered a lot today, and I hope this session helped you better understand all the available tools for you to test in-app purchases. To learn more, please see available documentation on developer.apple.com. And we would love to hear your feedback on how we can improve your in-app purchase testing experience. Please let us know through Feedback Assistant. Thank you for taking time to watch this session.