How to determine if a user is eligible for an introductory offer or promotional offer or neither when they just view the subscription page in APP without submitting a subscription? We are using apple server notifications V2. My goal is to display different offer pages to different users on the subscription page according to their eligibility. But currently, we can only recognize the user's eligibility after they have submitted a subscription order.

Hey everyone! I’m currently working on a new app called Kept – a simple and elegant journaling app designed to help you capture your thoughts and ideas effortlessly. However, I’ve hit a bit of a snag with the TestFlight distribution of the app. When I test the in-app purchases locally, everything works perfectly. But once the app is pushed to TestFlight, users only see "Loading products..." indefinitely and are unable to make purchases. Here are the details: The app works locally with sandbox accounts. Product identifiers and configurations have been double-checked. All in-app purchases are correctly set up and approved in App Store Connect. Using correct sandbox account settings on the device.

According to the following document, when the AppStore Server API is executed and the account does not exist, the response "errorCode: 4040001" is returned. If this response is returned, is it safe to assume that the account has been deleted and treat the subscription as cancelled? Also, please let us know if there are any other error codes other than this error code that can be used to determine that the subscription has been cancelled. https://developer.apple.com/documentation/appstoreserverapi/accountnotfounderror

I'm migrating my app to Store Kit V1, to Store Kit V2, and, due some legacy circumstances I'm implemented in past using a synchronous method, calling verify receipt on my server to validate receipt and do the needed business logic, but due to the deadline I changed the entire app integration and some questions starting to appear in my mind. First of all, when I processing the purchase when basically I will receive the notification? When the Store Kit calls the transaction.finish or after the purchase was successful I always will receive this notification?

Hi, I am trying to determine if an in-app purchase will be required within the app we are developing. We provide a web platform where the user can sign in and offer/search services correlated to entertainment world (showman, catering, DJ, live food lesson, etc.). The web app has 2 target: consumer users and business user. Consumer users can search services that tay want and chat business users owner of that services. Business users can create their ownpages in order to be visible to the consumer users in the community. Business users can also access too specified premium features for visibility. We are now designing a mobile app with only few features: Register login section Search business pages The users are the same and there is no differences in the mobile features (no hide premium functionalities). For these small features we have to implement the in-app purchase? The idea is to provide initially a small "companion" app to search business pages. Fo the next releases, where we want to provide more features, premium functionalities for business user we will integrate in-app and we already have plans to implement it. Thanks in advance!

I'm offering a free trial period for each of four auto-renewable subscriptions. Does anyone know the best way to detect whether a customer is still in the trial period, and to calculate the remaining trial days? I'm using Storekit 2. I've seen vague answers about using the Transaction purchaseDate and expiry date, but the documentation is incredibly vage as to what those values actually represent when it comes to a free trial period. What does purchase Date actually mean when you're in a free trial? Any help greatly appreciated.

Is it possible - in appstore - to create a subscriptions model similar to what microsoft teams and google workspace has for team memberships? We want to have a subscription price per user per month (or year). Administrator should be able to add additional users (and add a subscription for the new users) - It doesn't seem to be possible - only option is to have prefix subscriptions with 5 users, 10user, 15 users etc. (we've also looked into consumables - but the lack the option to be reoccurring payments) Thanks in advance?

My app is currently in review (review completed). I'm using the Get Transaction info API with a sandbox purchase transaction ID. "x": "Invalid response: Client error: GET https://api.storekit-sandbox.itunes.apple.com/inApps/v1/transactions/2000000632750685 resulted in a 401 Unauthorized response", However, when using the production url "Invalid response: Client error: GET https://api.storekit.itunes.apple.com/inApps/v1/transactions/2000000632750685 resulted in a 404 Not Found response:\n{"errorCode":4040010,"errorMessage":"Transaction id not found."}\n", Should I generate my JWT differently for sandbox vs production? If not, what else could cause this issue? Is there any missing congigration?

Our app has a parent account that can view their child's account activity for the free version but we have in-app subscriptions and trying to figure out how the parent can choose to purchase or pay for their child's in-app subscription from their apple Id account. Gifting? Family Sharing? Redeem Code? All keep showing up in my research but I am struggling with how to best execute this? Any advie or insight is helpful!!

We are wondering if it is possible to distinguish between purchases made through our app and those made directly from the App Store in the subscription process. Does the API information such as Server notifications v2 and Get All Subscription Statuses contain information that can distinguish between these cases? If not, we are thinking of using the appAccountToken included in JWSTransaction to distinguish between them. We are aware that appAccountToken is set when an appAccountToken or applicationUsername is given to an app when purchasing a subscription. Therefore, we believe that the appAccountToken of JWSTransaction is not set when you purchase a subscription directly from the App Store. We think that by setting the appAccountToken for purchases made through our app, we can distinguish whether the subscription was purchased directly from the App Store or not, but is this an appropriate way to do so? Please let us know if there is a case where the appAccountToken is set even if the subscription was purchased directly from the App Store. https://developer.apple.com/documentation/appstoreserverapi/appaccounttoken

I'm fairly new to Swift, so I'm unsure as to what's going wrong with my code and how to fix it. After switching to Swift 6, the view I have with requestReview throws: "Cannot form key path to main actor-isolated property 'requestReview'" As I understand it, this is potentially due to the changes made to @MainActor. However, I am unsure how to go about fixing this error.

Apple added price field on StoreKit's Transaction with Xcode 15.1 and I adopted immediately. What I saw was that when the app was run in debug or TestFlight, the values for price were the same as they were displayed to the user e.g. $29.99 would be returned as 29.99 but in production I got values multiplied by 1000. They do multiply values by 1000 for App Store Server Notifications and APIs though but it is not documented as such for StoreKit's Transaction price field. I am afraid to make this change again and deploy it to production. Has anybody experienced anything like this?

Attempts to purchase an SKProduct or restore all completed transactions via the usual method calls in StoreKit leads to failure in the beta environment with the following error: Error Domain=SKErrorDomain Code=0 "An unknown error occurred" UserInfo={NSLocalizedDescription=An unknown error occurred, NSUnderlyingError=0x300b10210 {Error Domain=ASDErrorDomain Code=500 "(null)" UserInfo={NSUnderlyingError=0x300b10090 {Error Domain=AMSErrorDomain Code=301 "Invalid Status Code" UserInfo={NSLocalizedDescription=Invalid Status Code, AMSURL=https://sandbox.itunes.apple.com/WebObjects/MZBuy.woa/wa/inAppBuy?REDACTED, AMSStatusCode=500, NSLocalizedFailureReason=The response has an invalid status code}}}}} We've tried with existing sandbox user accounts, and created fresh ones which also fail in a similar way. Our beta testers report the same thing. Nothing has changed in our IAP code, and this started happening about 24-48 hours ago. It seems to be a server-side error - please can someone verify on Apple's side?

I've added .storeButton(.visible, for:.policies) to my SubscriptionStoreView, and the buttons do appear, but when I tap on them I get a sheet that just says "Terms of Service Unavailable / Somethng went wrong. Try Again.". (similar for Privacy Policy). Is this expected in development? Will these start working correctly in production? (and, more importantly, in App Review?) The docs say that these use the values (i.e. URLs) set in App Store Connect, but that I can override those. This is a new app. Is that wrong, do I need to set the URLs explicitly? Edited to add: the console reports: Failed to fetch terms of service and privacy policy: Error Domain=NSURLErrorDomain Code=-1011 "(null)"

Before I launched my app, I ran a TestFlight beta program and also included a one time purchase in the TestFlight build to test the functionality. Now that the app is available in the App Store, I had closed the TestFlight program, but am looking to reopen it again to test iOS 18 specific features. The issue is, the beta testers that previously purchased the IAP on TestFlight but didn't actually purchase the IAP on the App Store version would be able to use the paid features of the app for free as long as they have the TestFlight build. Therefore I would like to revoke all the purchases made via the TestFlight build. Is there any way to do that?

We recently reduced the subscription price for new customers in the USA from $9.99 to $4.99. However, existing customers are also seeing the new price of $4.99, but when they attempt to purchase the subscription, they are charged the original price of $9.99. Actual Behavior: Existing Customers: See the price as $9.99 and are charged $9.99. New Customers: See the price as $4.99 and are charged $4.99. Can anyone assist with resolving this issue? Thank you!

In the XCode 16 beta, it isn't possible to create a new StoreKit configuration file because the templates list doesn't contain that option. Adding the storekit extension to a file crashes XCode or doesn't have an effect at all. But, loading an existing file still works.

Hi, I am new to StoreKit and IAP. I am developing the 1.0 version of my app, and I plan to offer non-consumable items in version 1.0, with plans to offer auto-renewable subscriptions in the future 2.0 version. According to the App Store's review requirements, when I add a new type of item in the app, I need to submit the app version for review as well. What I want to know is, after I add auto-renewable subscription items in App Store Connect for use in version 2.0, will these new items be returned when my 1.0 version queries product information through the StoreKit interface? If they are returned, since version 1.0 does not support auto-renewable subscriptions, do I need to add compatibility code to ignore the unsupported items? Ideally, according to the App Store's requirement to submit a new app version along with the type of products, StoreKit would help filter out product types that are not supported by older app versions, but I wonder if this is the case?

Hi all. Our application uses server-side validation of user subscriptions. After purchasing a subscription, the server keeps track of the subscription renewal statuses. But for the second week already, when requesting information on subscriptions, the server receives 403 Forbidden error. At first we decided that our ip was blocked somewhere and tried to change the ip to a new one. But changing the ip address did not give any results. We keep getting 403 Forbidden error on all requests to check subscriptions from our server. The request goes to the following address /verifyReceipt This method is deprecated and it is necessary to change the method of verification to a new one, but it can't be done quickly. At the moment, there is no information when verifyReceipt will be disabled. And we need to verify subscriptions. Maybe someone has encountered a similar problem? Thanks for the help!

We have configured multi-language support for subscription content in App Store Connect. We are using Apple's provided SubscriptionStoreView from StoreKit to display subscription information. When my Mac system language is set to English or other languages, the localized content within the app displays correctly, but the configuration data fetched by SubscriptionStoreView is always in Chinese. We have reviewed many official documents but have not found a corresponding solution. Since we cannot modify the API within the provided SubscriptionStoreView, even though we have localized and configured accordingly in App Store Connect, users in other language regions cannot view localized content when using our software. The following is the code I referenced from Apple's official demo (Backyard Birds: Building an App with SwiftData and Widgets). @ViewBuilder var subscriptionStoreView: some View { SubscriptionStoreView( groupID: passGroupID, visibleRelationships: .all ) { PassMarketingContent(storeConfigure: storeConfigure) .offset(y:35) .containerBackground(for: .subscriptionStoreFullHeight) { SkyBackground() } } .frame(width: 800, height: 750) .subscriptionStoreControlIcon { _, subscriptionInfo in Group { Image(systemName: "bird") .foregroundColor(.yellow) }.onAppear(perform: { print("subscriptionInfo:\(subscriptionInfo)") }) .foregroundStyle(.black) .symbolVariant(.fill) } #if !os(watchOS) .backgroundStyle(.clear) .subscriptionStoreButtonLabel(.multiline) .subscriptionStorePickerItemBackground(Color(.subscriptionStorePickerItem)) .subscriptionStorePickerItemBackground(.yellow) .storeButton(.visible, for: .policies) .subscriptionStorePolicyDestination(url: URL(string: storeConfigure.storePolicy.privacyPolicy)!, for: .privacyPolicy) .subscriptionStorePolicyDestination(url: URL(string: storeConfigure.storePolicy.termsOfService)!, for: .termsOfService) .subscriptionStorePolicyForegroundStyle(.white) .tint(Color(.blackAppearance)) #endif } This could be due to an API bug, missing configuration, or an issue with the API design itself. I am unsure where to start to solve this problem. Thank you for your help.