Testing in-app purchases in TestFlight

I’m thinking about how to answer the question regarding testing in-app purchases via TestFlight before release. This doesn’t require any code changes, so I’ll focus on clear, concise steps for iOS and App Store Connect IAP testing.

I want to include details like using StoreKit configuration files for local testing in Xcode and the importance of creating Sandbox Apple IDs under Users and Access. TestFlight testers can use their Apple IDs for a sandbox environment purchase, but it seems TestFlight operates in a production environment, which is a little confusing.

Explaining TestFlight IAP Process

I’m considering the process for testing in-app purchases (IAPs) with TestFlight. Historically, payments go through a sandbox environment, where you need to sign in with a Sandbox Apple ID in the Settings under App Store. For iOS 15+, that option is located under App Store > Sandbox Account.

Also, I need to ensure that the app has approved IAPs marked as "Ready to Submit." Internal testers can skip the review, but external testers will need Beta App Review, which means I must attach IAPs to the current app version in App Store Connect.

Clarifying IAP Testing for TestFlight

I’m looking into how to test in-app purchases (IAPs) in TestFlight. According to Apple docs, each IAP must be submitted with the build for external testers, even in beta. They can be marked as "Cleared for Sale" before submission. Internal testers can test IAPs without review, but they must be configured and at least in the "Ready to Submit" state.

To provide options, I can suggest local StoreKit testing with StoreKit Config in Xcode 15/16, or using Sandbox via TestFlight for internal/external testers. I'll include steps to create Sandbox tester accounts, install the TestFlight build, and sign out of the App Store on the device.

Outlining IAP Testing Steps for iOS

I’m focusing on how to test in-app purchases (IAPs) in modern iOS. Thankfully, you don’t need to sign out of the App Store anymore; the sandbox login for IAPs will prompt you instead. It's crucial to ensure the device's App Store region aligns with the price and availability.

I need to provide clear steps: First, confirm that IAPs are created in App Store Connect with the correct Product IDs and marked as "Cleared for Sale" or in "Ready to Submit." For external testers, you must submit the IAPs with the TestFlight build by navigating to My Apps > your app > TestFlight > Builds > select build > "Manage" under In-App Purchases, then select and submit them for beta app review. Alternatively, add them directly from the App Version page in the "In-App Purchases" section and click "Submit for Review" for beta.

Detailed Testing Steps for TestFlight IAPs

For external testing of IAPs in TestFlight, you need to select "Submit for Review" for both the app and the IAPs. According to Apple's documentation, internal testers don't require review, but external testers do, so the IAPs must be included with the build.

Here’s how to proceed: First, ensure the IAPs are "Ready to Submit" in App Store Connect. Then go to TestFlight, select the desired build, and include the necessary IAPs before submitting for beta review.

Next, create sandbox testers using unique email addresses. On the device, sign in to the sandbox account in the App Store settings. After installing the TestFlight build, testers can launch the app and initiate purchases, which will be charged at $0.00 in the sandbox environment.

If IAP management is needed, use StoreKit or settings to reset purchases. Lastly, be mindful that receipt verification should automatically handle sandbox vs. production, ensuring proper handling of sandbox receipts for any server verification. I'll need to check if they use StoreKit 2 by looking at their repo.

I'm outlining steps for testing in-app purchases (IAPs) before release.

First, for Option A, I can suggest using a local StoreKit configuration in Xcode, creating a configuration file with product IDs, setting the scheme to utilize it, and testing purchases directly on a simulator or device.

Next, for Option B, I can explain how to leverage TestFlight, ensuring the bundle ID matches, uploading a build, adding myself as an internal tester, and signing in with a Sandbox Tester Apple ID to validate the IAPs.

Clarifying testing process for IAPs

I'm thinking about the steps for testing in-app purchases (IAPs). For StoreKit, we need to enable the In-App Purchase capability in Signing & Capabilities, which should already be set up, but I want to remind myself of that.

When initiating a purchase, I should see a confirmation popup with "Environment: Sandbox." Next, I need to verify that a success alert appears and that transaction.finish is called.

For external testers, I need to add IAPs to the build in TestFlight and submit for beta review, remembering that they’ll still be using a sandbox environment.

Examining tester account options

I’m considering how Apple provides "Sandbox Tester" accounts for developers, but I realize external testers likely don’t have these. According to Apple’s documentation, only sandbox testers can make sandbox purchases, which means external testers wouldn't be able to purchase unless they’re added as sandbox testers. However, that doesn't seem practical. I think I need to do a quick web search to confirm the details and ensure my understanding is accurate before proceeding!

It seems external testers don’t need sandbox accounts since the device automatically uses a sandbox environment now. However, for safety, I should advise the following:

For internal testers, using a sandbox Apple ID is optional. iOS will prompt for a sandbox sign-in if no account is configured. External testers should ensure in-app purchases are included in the build and approved for beta without charges. Also, remember to enable In-App Purchase capability in the app and address any price/loading issues in the SettingsView.

Linking to code and IAP setup

I need to include links to the code that verifies IDs and related aspects. The TipJar enum spans lines 604-608, fetchProducts runs from lines 625-636, and purchase transactions are covered in lines 642-661. The SettingsView uses these elements starting at line 664.

Additionally, I should describe the steps in App Store Connect for linking in-app purchases (IAPs) to a build. Testers must use the TestFlight app and verify that purchase sheets indicate a "Sandbox" label. Since the Tip Jar is consumable, there’s no need for a restore purchases UI, and "restore purchases" isn’t applicable here.

Clarifying submission steps

I’m considering edge cases for the "Ready to Submit" status. It’s fine for internal testers, but external testers need their apps submitted for beta review. The steps involve going to the app's iOS version page and adding in-app purchases (IAPs) to that version. I think I need to click "Submit for Review" for beta review, although I might not have it exactly right. I should search for authoritative documentation from Apple to confirm this information.