So I ran a promo for my app that got me 30k downloads or so. The app was free for a day and so it got lots of "purchases". There were two errors from StoreKit2 that I can't explain (I'll detail the other one in another post) This one: StoreKit.StoreKitError.systemError(Error Domain=NSCocoaErrorDomain Code=4097 "connection to service with pid 19497 named com.apple.storekitd" UserInfo={NSDebugDescription=connection to service with pid 19497 named com.apple.storekitd} There are various theories online that the display name of the purchase could be an issue. Another was that this indicates that this indicates that a helper process has crashed. Generally my guidance was to restart the device and that seemed to resolve it for most if not everyone. But not everyone reached out and it rained bad reviews and I was accused of a bait and switch and so on. Is there any way to mitigate this? Any way to address it? It doesn't happen for everyone but it happens very frequently still.

Guideline 3.1.1 - Business - Payments - In-App Purchase We found in our review that your app or its metadata provides access to mechanisms other than in-app purchase for purchases or subscriptions to be used in the app, which does not comply with the App Review Guidelines. Specifically: Your app's Thanks window includes the following call-to-action and/or URL that directs users to external mechanisms for purchases or subscriptions to be used in the app: After generating icons, a "Buy me a coffee" button is presented that goes to a website to make a purchase. I literally just want my app to be able to take "tips" without going through apple in app purchases, because the cut they take is INSANE

Hello Developers, I’m encountering an issue while setting up and testing subscriptions for my iOS app. Here’s a detailed breakdown of the situation: I have configured a 1-Year Premium Membership subscription in App Store Connect. The subscription is currently in the Waiting for Review status. To properly test this subscription in the Sandbox environment, it seems the subscription needs to be approved first. However, to get it approved, I need to submit it with my app, creating a frustrating loop. My app currently doesn’t feature the subscription on its UI, as I want to thoroughly test its functionality before integrating it fully. Steps Taken: Configured metadata for the subscription in App Store Connect (e.g., localized name, description, and price). Submitted the subscription for review. Verified product IDs and linked them correctly in my paywall configuration. Key Questions: Is it mandatory for the subscription to be integrated into the app for the initial review? Can I successfully test a subscription in the sandbox environment while its status is still Waiting for Review? What’s the best practice to handle this situation and break the testing-review loop? Any insights or guidance would be greatly appreciated. Thank you for your time!

So I've run a promo for my which offerred a free purchase for a while. Some people - and it looks like mostly in Germany - ran into an issue that the purchase would fail with SKError.Code.unknown. One user noted that if you cover FaceID and use your password when making the purchase it would succeed. That was then my guidance and it seemed to have worked for everyone. Is there a way from my side to prevent that error?

I'm trying to follow the instructions from https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/submit-for-review's "Submit an in-app purchase for the first time" section. However, I can't get the “Add In-App Purchases or Subscriptions” dialog to open - there isn't a clickable link in the In-App Purchases and Subscriptions section. My IAPs seem to be set up properly, they're all in the "Ready to Submit" state.

Hello, my indie app has somewhat significant traction in China (both downloads and subscription purchases), but I also have high refund rate there, like multiples of other countries... Perhaps even as 80 % or more of my refunds are in China although the share of downloads and purchases is way lower. I am curious if someone else also has this issue? My app has the "Blinkist trial" onboarding which shows the timeline and has notification on day 5 (for weekly trial), that paid subscription starts soon. However even after stopping showing this onboarding in China for new users I still have most of my refunds from China. I am trying to understand whether this may be broader "phenomenon" or maybe something super specific to my app. As far as I know Apple doesn't share the refund request reasons with developers and I did not get any support emails that would hint at why people are asking for refund. Thanks! Since Apple can terminate your developer account if you have "high" refund rate, I would like to get to the bottom of this.

I am somewhat of a beginner in mobile app development. I have some questions about IAP and commissions. One of my clients has a website that basically acts as the middle man which connects the trainers and participants. Basically, the trainers pay my client a subscription fee and they can list the kind of trainings they have to offer (ex. cardio, weight lifting, ...etc.). These trainings can be one-to-one, one-to-many, or one-to-few depending on the trainers. When the participants see something that they like, they would make a payment directly to the trainers via the website. To save time, we will probably do some kind of webview app. Having said all these, my questions are as follows, As far as the IAP is concerned, can the payments between the trainers and the participants use third party payment method and ONLY the subscription fee from the trainers to the client use the storeKit/Apple IAP plugin? If the answer to the question above is Yes (i.e. using Apple IAP for subscription only but use a third party payment for the transactions between the trainers and the participants), does it mean that the commissions ONLY apply on the subscription fees and NOT the payments between the trainers and the participants? If the answer to Question 1 is No (i.e. ALL the payments have to go through Apple IAP), the commissions would apply to both the payments between the trainers and the participants and the monthly subscription payments, right? In this case though, to my understanding, when using the Apple IAP plugin, essentially, all the payments go to Apple temporarily. After taking out the commissions, the payments would be released to the bank account on file with the App Store within 45 days of the last day of the fiscal month in which the transaction was completed. Am I correct? And if so, as far as the business model on the App is concerned, my client would collect the money released from Apple and then distribute the money to the appropriate trainers. Am I correct?

In one of My Apps I want have a "tip" option for users, so they can support the developer if they like the App. As a small tank you, "tipping" will unlock a small bonus feature (nothing essential, but nevertheless nice to have). According to the Guidelines this is perfectly fine and explicitly allowed. So a created a few IAP options with different prices as non-consumable one-time purchases and the same number of consumable one-time-purchases with the same prices (so no subscriptions at all). The idea is: users should be able to tip multiple times if they want to (actually many users of the old App version have asked for this) Non-consumable IAP items can only be purchased once, but these can be restored (for example when switching to a new device). Consumable IAP items can not be restored, but these can be purchased multiple times. The idea is to combine both, so it is possible to tip multiple times (via consumable IAPs) and to allow the restore of previous purchases (to unlock the bonus feature). To do this, the App would at first only offer the non-consumable IAP items in its "tipping" screen. Only after these were purchased, the App would then only offer the consumable IAP items. Users tipping only once would always purchase the non-consumable item that can be restored. Users who have tipped multiple times would also have purchased the non-consumable IAP once and in addition the consumable item, so they all can restore and unlock the bonus feature. And no one is confused about any internal differences (consumable vs non-consumable), because the users will always see only one tipping option. I've created these IAP items and send them to Apple for review together with this explanation. All the non-consumable items got approved, all the consumable items got rejected with the following bizarre and unhelpful note from the review board: 3.1.1 - new IAP type New type: Consumable Previous type: Non-Consumable Recommend: Download The binary of the app is new (more than 14 days). What exactly does this mean? I've read section 3.1.1 of the guidelines and nothing indicates anything which would allow any rejection here. And what does "the binary of the app is new" mean? Sure the App is new (currently the new version is tested via TestFlight), but what does this have to do with the IAP? With normal "Appstore rejections" there was always a link provided which allowed to contact the review team. But there's absolutely nothing available here. Just this bizarre note which doesn't give any clue what's wrong. Does anyone have an idea what's wrong, or what I need to do to get this approved? How can I contact the review team that is responsible for this IAP review? BTW: I've tried to get this approved again after changing the description/names of the localization a bit (because these are the only things which are marked in red), but the same strange note came back. And the localization title and description can not have a long text, so there're not that many possible variations available which describe the IAP correctly.

I've noticed that some new users are able to redeem promotional offers. However, Apple's documentation states: "Promotional offers can be effective in winning back lapsed subscribers or retaining current subscribers. You can provide lapsed or current subscribers a limited-time offer of a discounted or free period of service for auto-renewable subscriptions on macOS, iOS, and tvOS." (Source) Could someone clarify whether promotional offers are intended solely for lapsed or current subscribers, or can new subscribers also redeem them under certain conditions?

Hello everyone, I want to set up subscriptions but I'm having problems testing them. Indeed, when I use the storekit file to view the subscriptions it works, I see the subscriptions and I can subscribe in XCODE mode. However, I'd like to go further and test with server notifications. So I removed the storekit file from the scheme, but I can't retrieve the products. The application doesn't retrieve any products.. I've been stuck on it for 2 weeks... I checked the contracts and put in all the information last Friday and everything is validated. I tested it in testflight mode, and it doesn't recognize any products! Just so you know, I use the original API for maximum compatibility.

Starting a few months ago, we noticed that we are receiving sign-ups to our application using Sandbox accounts. These accounts were not created by us, and certainly do not show up under Sandbox users on App Store Connect. When we setup In App Payment, our server side validation followed the guidance to always allow sandbox receipts (see https://developer.apple.com/documentation/appstorereceipts/verifyreceipt). I think we assumed that only Sandbox users that we setup in App Store connect would be allowed to be used with our app. Another assumption was that Apple reviewers could create Sandbox accounts to use to test our IAP sign-up during app review. How are other developers preventing fraudulent sign-ups from sandbox accounts? Has something changed with In App Payments this year related to sandbox accounts?

Hi, I have 6 subscriptions in a subscription group. Each subscription has 2 active promotional offers configured. One is with a 25% offer for a month and another one is a 50% offer for a month. My doubt is, can users access both promotional offers in a single subscription? Not at a time First 25% offer and then 50% offer

any solution to integrate apps with revenuecat ?

I need to decode a Base64-encoded receipt from an In-App Purchase and extract the transaction ID from it. However, I want to avoid using the verifyReceipt endpoint since it is deprecated. Can anyone guide me on how to achieve this manually? Are there any specific libraries, steps, or code samples I should follow to parse the receipt data and retrieve the transaction ID? Any help or insights would be greatly appreciated!

The in-app purchase products we submitted have been in "Waiting for Review" status for over 24 hours, despite our app being approved. What could be the reason for this? After submitting the first version, we also submitted a second version, which was approved as well, yet our in-app products are still pending review. App apple id : 6499263256 bundle id : com.zoviz App name : Zoviz

I'm developing a B2B team collaboration app. My customers are businesses, and I plan to charge them on a per-user per-month basis. Payers are companies, not individual users, and the company pays for all its employees simultaneously. Implementing the logic mentioned above using in-app purchases looks quite challenging; I will need someone from the company to pay for the whole company and constantly upgrade/downgrade the subscription level as the team size changes. So, is my app required to have in-app purchases in this case? According to guidelines, I may allow users to access externally purchased subscriptions. Does it mean I don't have to implement in-app purchase logic in my app? 3.1.3(c) Enterprise Services: If your app is only sold directly by you to organizations or groups for their employees or students (for example professional databases and classroom management tools), you may allow enterprise users to access previously-purchased content or subscriptions. Consumer, single user, or family sales must use in-app purchase. I would be grateful for any help and advice.

In an application feature where users can purchase resources to enhance the exposure, visibility, or engagement of specific content (such as boosting videos, posts, or other user-generated content), the price needs to adjust dynamically based on the user-selected budget. How can this type of In-App Purchase flow be implemented in iOS Swift? Also checked link for tax category: https://developer.apple.com/help/app-store-connect/manage-app-information/set-a-tax-category

I have implemented In App Subscription in my app i have tested subscription module on sandbox and testflight but whenever i am uploading it for apple's app review team they says due to App Completeness your app is getting rejected and on their side after clicking on buy subscription the in app module takes too much time to open but on sandbox and testflight it works fine.

Hello, as a new iOS developer, I am developing an Apple app with IAP (In-App Purchase) for the first time. During the initial app review submission, I included the IAP along with the app. However, after the app was rejected, the IAP status also showed as rejected. Following online advice, I resubmitted the IAP for review. After multiple revisions, my app has now been approved, but the IAP review is still in the "waiting for review" stage. As a result, my app is now live on the App Store, but users cannot see any products available for purchase within the app. This situation is quite awkward for me. I would like to ask what I should do now. Do I need to wait for the IAP review? How long does the IAP review process typically take? Thank you in advance for your assistance.

Currently, I have an app running locally on my computer, and there is also a web app. To create an account, users need to pay through the web app, which handles the payment process smoothly. My question is: Do I need to implement In-App Purchases (IAP) if the payment is only for account creation? Let me elaborate on my question. I know the typical answer is yes, but what if users in the mobile app cannot create an account or pay within the app itself? Instead, account creation is only possible via the web app, and only users who have paid outside the mobile platform can access and join the mobile app. This approach is similar to what Netflix and Spotify do – they do not allow account creation inside their mobile apps and do not provide any redirects or buttons indicating alternative payment methods (they do not have IAP).