We updated our app with a new feature (video generation) and we also offer IAP to purchase tokens to generate videos. We sent it to review in App Store Connect. Besides us, no one else had access to this feature. Today, our app went to review. Suddenly, we saw a huge increase in API requests over many hours which has costs us around $200+ (video generation is expensive). The only person who had access to this feature was the person who reviewed the app. I am not talking about making 3-4 requests to test the app or its functions/features. I am talking about 60-70 requests to make videos over the duration of a couple of hours. This person used test-purchases to get tokens and then used these tokens to generate videos for his own good. This wasn't just a review or testing. This was abuse. In the backend, we can see it all has been done by one person, and the only person who had access to this feature was the app reviewer. The only reason it stopped was because we saw the abuse and disabled the feature. Just 5 minutes after disabling the feature, our app update was approved & ready for distribution. What is going on? Could someone from Apple escalate this situation?

Hi Apple Team, I'm a Nigerian developer building an app for local users, and I’m facing a major challenge: Due to CBN regulations, most Nigerian cards can’t make international payments and do not support Dynamic currency conversion, which means In-App Purchases (IAP) don’t work for most Nigerians. My app involves real-world services with external rewards and users would have to subscribe to be members, yet it’s unclear whether IAP is still mandatory. If I am forced to use IAP, most Nigerian users simply can’t pay, and I lose nearly all revenue. Questions: Can developers targeting Nigeria use local gateways like Paystack or Flutterwave instead of IAP ? Will Apple provide alternatives or guidance for regions where IAP is effectively unusable? This is a critical issue for many local developers. I’d appreciate any official clarification. Thanks, Joseph (Nigerian Developer)

I’m trying to upload my iOS app, but I keep getting this error during validation: Invalid Executable. The executable 'AppName.app/Frameworks/OpenSSL.framework/OpenSSL' contains bitcode. 🔍 What I’ve Tried Set "Enable Bitcode" = NO in both the project and target build settings Tried different Xcode versions and OpenSSL builds Added a script in the post_install section of the Podfile to strip bitcode manually: post_install do |installer| bitcode_strip_path = xcrun -find bitcode_strip`.chomp! def strip_bitcode(bitcode_strip_path, framework_path) path = File.join(Dir.pwd, framework_path) system("#{bitcode_strip_path} #{path} -r -o #{path}") end [ "Pods/YourPathTo/OpenSSL.framework/OpenSSL" ].each do |path| strip_bitcode(bitcode_strip_path, path) end end` But the bitcode error still appears during archive validation.

I have a React Native app that is complete. Works fine on device when debugging. When I archive and upload I receive an error that says I have missing DSYMs for Hermes. I check bundle contents and my app's dsyms are present but none for Hermes. I have tried everything ai suggests and I cannot figure it out. How can I get the Hermes dsyms included in my archive so I can upload my app to Apple store? Thank you

We have been using this API call to set the In-App Provisioning capability for 2+ years and it just recently started returning errors. To set the In-App Provisioning capability we had been using the App Store Connect API directly: curl "https://api.appstoreconnect.apple.com/v1/bundleIdCapabilities" -X POST --header "Authorization: Bearer #{appleApiToken}" --header "Content-Type: application/json" -d '{"data": {"type": "bundleIdCapabilities", "attributes": {"capabilityType": " IN_APP_PASS_PROVISIONING"}, "relationships": {"bundleId": {"data": {"id": "#{appStoreBundleIdentifier}", "type": "bundleIds"}}}}}' The IN_APP_PASS_PROVISIONING capability type is shown, by getting the bundle ID capabilities, when In-App Provisioning is set on a bundle ID: curl "https://api.appstoreconnect.apple.com/v1/bundleIds/#{appStoreBundleIdentifier}/bundleIdCapabilities" --header "Authorization: Bearer #{appleApiToken}" After manually setting the In-App Provisioning capability via the Apple Developer portal you will see the new capabilityType: {     "type" : "bundleIdCapabilities",     "id" : "##########_IN_APP_PASS_PROVISIONING",     "attributes" : {       "settings" : null,       "capabilityType" : "IN_APP_PASS_PROVISIONING"     },     "relationships" : {       "bundleId" : {         "links" : {           "self" : "https://api.appstoreconnect.apple.com/v1/bundleIdCapabilities/##########_IN_APP_PASS_PROVISIONING/relationships/bundleId",           "related" : "https://api.appstoreconnect.apple.com/v1/bundleIdCapabilities/##########_IN_APP_PASS_PROVISIONING/bundleId"         }       }     },     "links" : {       "self" : "https://api.appstoreconnect.apple.com/v1/bundleIdCapabilities/##########_IN_APP_PASS_PROVISIONING"     }   } The problem now is Apple has recently (within the last week) removed support for setting the IN_APP_PASS_PROVISIONING capability type via the bundleIdCapabilities API endpoint. {   "errors" : [ {     "id" : "c6644913-d1c5-4eda-9faa-7766adf25c39",     "status" : "409",     "code" : "ENTITY_ERROR.ATTRIBUTE.TYPE",     "title" : "An attribute in the provided entity has the wrong type",     "detail" : "'IN_APP_PASS_PROVISIONING' is not a valid value for the attribute 'capabilityType'. Expected one of: 'ICLOUD', 'IN_APP_PURCHASE', 'GAME_CENTER', 'PUSH_NOTIFICATIONS', 'WALLET', 'INTER_APP_AUDIO', 'MAPS', 'ASSOCIATED_DOMAINS', 'PERSONAL_VPN', 'APP_GROUPS', 'HEALTHKIT', 'HOMEKIT', 'WIRELESS_ACCESSORY_CONFIGURATION', 'APPLE_PAY', 'DATA_PROTECTION', 'SIRIKIT', 'NETWORK_EXTENSIONS', 'MULTIPATH', 'HOT_SPOT', 'NFC_TAG_READING', 'CLASSKIT', 'AUTOFILL_CREDENTIAL_PROVIDER', 'ACCESS_WIFI_INFORMATION', 'NETWORK_CUSTOM_PROTOCOL', 'COREMEDIA_HLS_LOW_LATENCY', 'SYSTEM_EXTENSION_INSTALL', 'USER_MANAGEMENT', 'APPLE_ID_AUTH'",     "source" : {       "pointer" : "/data/attributes/capabilityType"     }   } ] } How do we set the In-App Provisioning (IN_APP_PASS_PROVISIONING) capability type via the Apple API on bundle IDs that have been approved by Wallet Entitlements?

Hello, I am thinking of developing a parental control app but I do not know if I need to request the api for using "Time Screen API". In positive case, where it should be? Is there anyway to use this for educational centers? Not just for families? Kind regards.

Hi everyone, I'm trying to submit the first app for Beta Review to do Beta in Testflight, created a separate workflow for Beta Build and stuck at the step of filling in the "Information for Beta Review" form. After filling in all the fields and clicking "Save" it just shows me an empty popup with "Close" button, and I see that request for https://appstoreconnect.apple.com/ci/api/teams//testflight/information-v2?product_id=ACTUAL_ID_REPLACED_HERE is failing with 404. Does anyone have any idea what I might be doing wrong? Thanks and appreciate the help

Looking at some of the latest release notes, it appears that lowest supported version is iOS 15.0 for all versions of Xcode 16. Considering that Xcode 16 is the minimum version for submitting apps to the App Store, I would assume that means that Apple expects apps to be on 15.0+. However, knowing that you can manually override this setting in Xcode, there seems to be a lack of clarity on what the true minimum is. Looking at the App Store, it appears there are some apps that can go back as far as iOS 12.0. Is there a definitive way to know what is the true minimum that the App Store accepts?

In https://appstoreconnect.apple.com/business I only see the Free Apps Agreement which I already accepted, but the Paid Apps Agreement is not there. I am the account holder and already signed the new Apple Developer Program License Agreement, so those are not the reasons for this issue. I need to find and accept the Paid Apps Agreement because I have a subscription app on testflight which I want to publish to app store soon. Thanks in advance!

in review for long time Apple ID: 6742814997

I'm using App Store Connect API to automate onboarding/off-boarding user invitations for my team members when they start working on my app. Once devs join the team, I'd like to invite them to the specific app's beta test group. This requires some additional work after the user has joined the team because unlike visibleApps, there's no way to initially indicate the beta test groups that a user should have access to. One challenge I'm finding is that people don't immediately join the team on time so polling feels a bit excessive/wasteful. Is there some recommended mechanism for adding users to the internal test flight group, or is there a way to trigger a webhook when the list of users is updated. I noticed that there's a new /v1/marketplaceWebhooks API so I imagine this is the recommended format for registering callbacks. Any assistance here would be greatly appreciated.

Hello all, One of my app submission got rejected saying deletion feature wasnt available. We allow de-activate our user accounts after our customer support representative speaks with customer to confirm and then delete the account. But while submitting our app for release we got this message?? The app only offers to deactivate the account. Temporarily deactivating accounts is not sufficient to meet the account deletion requirement. Any help how to overcome this issue pls? Thanks K

Hello we just submitted our app one week ago. First submission was rejected and we have resubmitted it after resolving issues with it. but it has been more than 5 days. And we still haven't got any feedback from apple team. We need to publish the app ASAP. Thanks in advance for your help. Looking forward to hearing back from you.

My app uses Apple IAP. With the recent US external payment changes (May 2025), I plan to use Stripe via Superwall. Superwall allows me to remotely toggle my paywall for US users between Apple IAP and Stripe checkout without a new app build. Is it permissible to activate Stripe for new US users on an already live app version (approved with only Apple IAP) without first submitting a new build for Apple to review the Stripe integration? Or does this dynamic switch create a risk of takedown/compliance problems? Concerned about new users hitting an unreviewed Stripe flow during any potential review period for a new build. Seeking clarity on Apple's stance or community experiences. Thanks!

I was contacted to develop an app for a company and I’d like some help to know if it has a chance of being approved on the App Store. The system will be entirely built in React Native and will use a SupaBase backend. One detail: before starting, I talked to another developer who ended up dropping the project because he thought it would be impossible for the app to be approved on the App Store due to the use of WebView and because it’s a simple app. How the app works: There’s a home screen showing all the company’s units. When you tap on a unit, it shows its details. On the details screen, there’s a button that opens an internal exam consultation system in a WebView. The rest of the app (navigation, data display, etc.) is all react native. The app also stores those informations offline. My questions: Can using WebView just for this exam consultation part be a problem for approval? Does adding offline storage really help increase the chances? Is there any way to distribute the app without going through the App Store? I appreciate any information you can share.

Hello The other day, my app was rejected by App Store. The person in charge told me, "Your app still provides the same feature set as other apps submitted to the App Store for review." Does this mean I can't publish my app anymore?

I want to clarify why both email and phone number are mandatory at registration, while still allowing users to log in with either method if one fails. Email Address (Collected at Registration) Account Creation & Verification: We use email to establish a unique, verifiable account for each user. This prevents duplicate or fraudulent profiles. Primary Communications: All booking confirmations, trip updates, support requests, and in-app chat messages between care seekers and carers are sent via email. This ensures users have a reliable record of every transaction and message. Phone Number (Collected at Registration) OTP-Based Security: We send a one-time password (OTP) via SMS during registration and login. This SMS-OTP step is critical to confirm that the user owns the provided phone number and to safeguard against unauthorized account access. Critical Trip Notifications: During a booked trip, carers and care seekers must receive time-sensitive alerts (e.g., gate changes, flight delays, check-in reminders) even if they’re not actively using the app. SMS ensures immediate delivery—even if a user’s internet connection is unavailable. Support & Emergency Contact: If there’s an urgent issue mid-trip (e.g., a missed flight, sudden cancellation, or a medical concern), our support team can reach users directly via phone to resolve issues in real time. Flexible Login Options Fallback Mechanism: If a user cannot access their email (e.g., server delay or no internet), they can request an OTP via SMS to log in. Conversely, if SMS delivery fails (e.g., network outage), they can choose to receive a OTP by email. This redundancy guarantees that users aren’t locked out due to a single point of failure. We believe both email and phone number are directly tied to our app’s security model, communication requirements, and overall user experience. All collection and usage details are transparently disclosed in our Privacy Policy (https://b4t.com/legal/privacy-policy) and User Terms and Conditions (https://b4t.com/legal/user-terms-and-conditions).

Hello, our submission rejected by the apple team and now we can't remove cancel the current submission. This is api response when we attempt remove: { "errors" : [ { "id" : "e069078e-4c57-4aa6-ab3b-913ddf9e6314", "status" : "409", "code" : "STATE_ERROR.ENTITY_STATE_INVALID", "title" : "Resource state is invalid.", "detail" : "Resource cannot be canceled at the moment, please try again later" } ] } We need to publish app asap and can't do anything because of this bug.

My application has been in "In Review" status since May 30, 2025, and it is still in that status today. Please check the status of my app, LS Tools. Our customers are waiting for the latest version

I’m trying to submit my app for review, but I’m currently blocked due to a recurring issue with in-app subscriptions. Both of my auto-renewable subscriptions (premium_monthly and premium_yearly) are marked as “Waiting for Review”. However, I am still seeing the blue box stating that “your first subscription must be submitted with a new app version.” Despite creating a new version (1.0.1) and uploading/selecting a new build , I am not seeing the “In-App Purchases and Subscriptions” section on the version page, and I therefore cannot link the subscriptions before submitting. This issue is blocking my ability to submit the app for review. Any help to resolve this would be greatly appreciated.