Navigate the App Store landscape. Share strategies for app submission, distribution, marketing, and user acquisition. Discuss best practices for getting your app discovered and downloaded.

All subtopics
Posts under App Store Distribution & Marketing topic

Post

Replies

Boosts

Views

Activity

Locate the In-App Purchases and Subscriptions Section in App Store Connect
App Store Connect displays the In-App Purchases and Subscriptions section on your app's version page when your app has an In-App Purchase or subscription with a Ready to Submit status. To locate the In-App Purchases and Subscriptions section: In Apps, select the app you want to view. In the sidebar, select the app version. On the version page, scroll down to the In-App Purchases and Subscriptions section. For more information, see Submit an In-App Purchase.
0
0
2k
Jun ’26
New app stuck in “Waiting for Review” since August 4, 2026
Hello, My first submission for a new app has been in “Waiting for Review” for 7 days, with no status change and no message in App Store Connect. Details: • App Apple ID: 6794950418 • Version: 1.0 (build 11) • Submitted: August 4, 2026 at 13:51 CEST • Submission ID: 24fe4981-11a7-4425-8694-93cae015b2cd • Current status: Waiting for Review (never moved to In Review) There is no rejection, no request for additional information, and nothing in the Resolution Center. Review notes include everything needed to test the app, and the build has been running fine in TestFlight. Is there anything on my side that could be holding this submission in the queue, or is this simply the current backlog? Any guidance would be appreciated. Thank you.
0
0
26
1h
Waiting for Review since July 30, 2026 — Express Evaluations iOS 1.0 (12+ days)
Hello App Review Team, Our iOS app has been stuck in "Waiting for Review" for more than 12 days with no status change and no Resolution Center messages. App name: Express Evaluations Developer: Express Evaluations, Inc Platform: iOS Version: 1.0 Current status: Waiting for Review Submitted: July 30, 2026 at 11:52 AM We opened an App Review Status case on August 10, 2026 and have not received a reply yet. Case ID: 20000133168856 This delay is blocking our planned release and is affecting stakeholder trust in our launch timeline. Could someone from App Review please check whether this submission is stuck in the queue and advise on the current status? Thank you for your help.
1
1
211
1h
App Store search rewrites our brand name "Kaiho" to "kaiju": app unreachable by name on the France storefront
Our app cannot be found by its own name on the France App Store, because search silently rewrites the query. App: Kaiho: Arrêter de fumer / Kaiho: Quit Smoking Coach Apple ID: 6760356299 Feedback Assistant: FB24267557 WHAT HAPPENS Searching "Kaiho" on the France storefront returns kaiju monster games. The page reads "Affichage des résultats pour « kaiju »" ("Showing results for kaiju") with a "Rechercher « Kaiho » à la place ?" link underneath. Our app is not in the results at all. The first item served is a paid ad for an unrelated app, then KAIJU N° 8 THE GAME. THIS IS NOT A RANKING QUESTION The app is correctly indexed on that same storefront: searching "kaiho arreter de fumer" returns it as the #1 result. The substitution happens before ranking the term itself is replaced. TWO APPLE SYSTEMS DISAGREE While typing, the App Store's own autocomplete proposes "kaiho: arrêter de fumer" as its first suggestion, and offers "kaiho in Developers". After submitting, the results engine rewrites the term to "kaiju". The suggestion service and the results engine hold contradictory views of the same query. REPRODUCIBLE ACROSS STOREFRONTS The search response exposes the substitution explicitly. MZSearch with term=kaiho returns "spellCorrection": "kaiju" on X-Apple-Store-Front 143442 (France), and "kahoot" on 143459 (Switzerland), 143443 (Germany) and 143450 (Italy). Storefronts 143441 (US), 143446 (Belgium), 143455 (Canada) and 143454 (Spain) return no spell correction and do return the app. Measured 2026-08-11. WHY IT MATTERS "Kaiho" is our French trademark (No. 5255039, INPI, classes 9, 41, 42) and the only term under which we ask people to look for us. France is our home market and the source of nearly all our iOS installs. Anyone told to "search for Kaiho on the App Store" lands on monster games instead. I have filed FB24267557 and opened a Developer Support case under Distribution > App Store search and visibility. QUESTION FOR THE COMMUNITY Has anyone managed to get Apple to drop a spell correction on their own brand name? I have seen the same pattern reported for "Myseum" being corrected to "Museum" (thread #780657) with no resolution posted. If you got it fixed, what actually moved it? Feedback Assistant, a support case, Search Ads volume on the exact term, or simply time?
0
0
14
1h
Apple Developer Enrollment On Hold for 1 year
Hello, My enrollment in the Apple Developer Program has been "On Hold" for over a year. I am applying for an individual account and urgently need access to complete my setup. I contacted Apple Support two weeks ago and received a single response stating they would look into it, but I have not received an update since. Any assistance or guidance from the community or forum staff on how to resolve this would be greatly appreciated. Thank you!
2
1
153
2h
MacOS failed notarise app
I tring to notarise my app for long time the error "Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions.", I tried to contact support only email available, I got response only one time they ask for documents I sent and for then they disappear no response any more I tried to open new ticket for no response either. What can I do?
0
0
16
3h
Urgent: Expedite App Review
Our app Broons Tea Room (App ID: 6795576807) has been waiting for review for more than 10 days. We have also submitted an expedited review request, but we haven't received any update yet. Could you please check the status of our app and help expedite the review if possible? Please let us know if you need anything from our side. Thank you for your help.
0
1
25
3h
App Review Taking Over 10 Days
Hello Apple App Review Team, Our app Broons Tea Room (App ID: 6795576807) has been waiting for review for more than 10 days. We have also submitted an expedite review request, but we haven't received any update yet. Could you please check the status of our app and help expedite the review if possible? Please let us know if you need anything from our side. Thank you for your help.
0
0
12
3h
App Store Connect: Can't change Primary Locale to nl-NL — 19 historical versions blocked by missing screenshots, API returns 409
I'm trying to change an app's Primary Language in App Store Connect from de-DE to nl-NL and hitting a state I can't resolve through any interface available to me. Environment App Store Connect (web UI) and App Store Connect API v1 Problem UI: App Information → Primary Language → nl-NL → Save fails with: "Primary Locale couldn't be saved because you must first provide all the required screenshots for each version in this language." API: PATCH /v1/apps/1669670490 with attributes.primaryLocale = "nl-NL" returns HTTP 409: ENTITY_ERROR.ATTRIBUTE.INVALID.INVALID_STATE.MISSING_SCREENSHOTS_PRIMARY_LOCALE Error detail contains an unsubstituted placeholder: "...you must first provide all the required @@LANGUAGE_VALUE@@ screenshots..." What I've verified Current live version (3.7.6) and current editable version (3.7.11) both have complete nl-NL screenshot sets for all required device sizes (6.9" iPhone, 13" iPad). No Watch app, iMessage extension, Custom Product Pages, In-App Events, or IAPs. Enumerated all 23 versions via the API (1.0 → 4.1.0). 19 of them have an nl-NL appStoreVersionLocalization (with real historical description/keywords/support URL) but zero nl-NL screenshots attached. Tried POSTing an nl-NL screenshot set to one historical version (4.1.0) directly via the API to confirm this isn't just a UI restriction. Also returns 409 ENTITY_ERROR.ATTRIBUTE.INVALID.INVALID_STATE — historical versions are locked against edits (including screenshots) at the API level, not just the UI. Question Since these historical versions can't be edited through any supported interface, is there a documented way to satisfy or bypass the "screenshots for each version" check for locked historical versions when changing Primary Locale? Filed as case 20000130035264 with Developer Support, who pointed me here for the technical side.
5
0
301
3h
Which App Store Connect API should submit an Apple-hosted asset pack for external TestFlight review?
Hello, Apple’s documentation appears inconsistent about which App Store Connect API should be used to submit an Apple-hosted Background Asset version for external TestFlight review: In WWDC25 “Discover Apple-Hosted Background Assets”, Apple says that the asset pack version can be submitted using the POST /v1/betaBackgroundAssetReviewSubmissions. In Uploading and versioning Apple hosted background assets, the external beta review instructions link to “Submit an app for beta review,” which uses POST /v1/betaAppReviewSubmissions. These two resources have different behavior. betaBackgroundAssetReviewSubmissions I called the public API with the same resource structure used by the App Store Connect web UI: POST https://api.appstoreconnect.apple.com/v1/betaBackgroundAssetReviewSubmissions { "data": { "type": "betaBackgroundAssetReviewSubmissions", "relationships": { "backgroundAssetVersion": { "data": { "type": "backgroundAssetVersions", "id": "<BACKGROUND_ASSET_VERSION_ID>" } } } } } The public API returned 404 PATH_ERROR: The resource 'v1/betaBackgroundAssetReviewSubmissions' does not exist. However, the App Store Connect web UI uses the private endpoint below with the same payload and receives HTTP 201: POST https://appstoreconnect.apple.com/iris/v1/betaBackgroundAssetReviewSubmissions The public endpoint is also absent from the current App Store Connect OpenAPI specification. betaAppReviewSubmissions I also tested the public POST /v1/betaAppReviewSubmissions endpoint. When I supplied a backgroundAssetVersion relationship, the API returned 409: 'backgroundAssetVersion' is not a relationship on the resource 'betaAppReviewSubmissions'. You must provide a value for the relationship 'build'. The build relationship only accepts the builds resource type, not backgroundAssetVersions. Therefore, betaAppReviewSubmissions can submit an app build but cannot submit a Background Asset version. Could Apple please clarify: Which public API should be used to submit a Background Asset version for external TestFlight review? Is betaBackgroundAssetReviewSubmissions intended to be exposed through the public App Store Connect API? Is the link to betaAppReviewSubmissions in the Background Assets documentation incorrect? When will the public documentation and OpenAPI specification be updated? Thank you.
0
0
7
3h
TestFlight builds expired across multiple apps; new builds cannot be installed (“Requested app is not available or doesn’t exist”)
Hi, I’m experiencing a TestFlight issue affecting multiple apps in my account. Issue summary: • Several TestFlight builds across all of my apps expired at the same time. • After uploading new replacement builds, neither I nor my testers are able to install them. • Installation fails with the message: “Could not install {App Name}. The requested app is not available or doesn’t exist.” • The build shows as processed and available in App Store Connect. • Testers are already invited and active. • No redeem code is required. I am seeing the same issue on my own device as well. What I’ve tried: • Uploading new builds (incremented version + build number). • Confirmed builds are visible and available in App Store Connect. • Removing and re-adding testers. • Logging out of the app. • Deleting the app from the device. • Restarting the device. • Reinstalling directly from TestFlight. • Restarting TestFlight. Despite this, installation consistently fails with the “requested app is not available or doesn’t exist” error. Expected behavior: • New TestFlight builds should be installable once processed and available. • Testers (and the developer) should be able to install directly from TestFlight. • Expired builds should not block installation of newly uploaded builds. Additional context: • This started immediately after multiple TestFlight builds expired across my apps. • All affected apps were previously installing and testing without issue. • Apple Developer Support has been contacted, but I wanted to check whether others are seeing the same behavior or if there is a known workaround. Has anyone else encountered TestFlight builds becoming unavailable across multiple apps at once, or an install failure after replacing expired builds
8
1
1.5k
3h
BETA_FEEDBACK_SCREENSHOT_SUBMISSION_CREATED webhook not dispatched
Hi! I'm observing a problem with ASC webhooks. I have a webhook with all event triggers enabled, and I verified it works: events such as buildUploadStateUpdated and buildBetaDetailExternalBuildStateUpdated are delivered. However, when a screenshot feedback is submitted from an external testing group, no webhook is dispatched (confirmed it does not appear in "Recent deliveries"). The screenshot feedback is submitted successfully, the screenshots appear in the ASC dashboard. Basing on the documentation, I think this event should trigger the BETA_FEEDBACK_SCREENSHOT_SUBMISSION_CREATED webhook.
0
0
21
3h
App Stuck in Review for 15 Days With No Response
Hi Apple Developer Community, Our app has been waiting for App Review for around 15 days, and we still haven't received any update or response from the App Review team. The app was submitted for review on July 26, 2026, and it has remained in the "Waiting for Review" status since then. We have also tried contacting the appropriate support/contact team, but unfortunately, we haven't received a response there either. This is blocking our production release and affecting our customers who are waiting for the app. Could anyone advise what we should do in this situation or how we can escalate the review? Bundle Ids: com.sanisetu.supervisor / com.sanisetu.worker Submission Date: July 26, 2026 Current Status: Waiting for Review Time Waiting: ~15 days Any guidance would be greatly appreciated. Thank you.
0
0
27
3h
Version 1.0.0 stuck in "Waiting for Review" for ~2 weeks after an automated Guideline 2.5.1 message about the Family Controls entitlement
Our app — a screen-time / focus app — has had no App Review activity for two weeks, and we believe the trigger was an automated Guideline 2.5.1 check that froze an otherwise actively progressing review. (This forum account is linked to the developer account in question; we can provide the App ID, bundle IDs, submission IDs, and support case numbers through any private channel on request.) Context: Jul 2–5: Our first submission (Version 1.0.0) was under active review. We went through several ordinary metadata / paywall-related iterations, and the reviewer responded within roughly 24 hours each time. Nothing related to Screen Time was raised in these human reviews of builds 9 and 10. Jul 8: After we submitted build 11 — which addressed the remaining human-review feedback — we received an automated Guideline 2.5.1 (Performance: Software Requirements) message stating that the app uses the Screen Time API but has not been submitted with the Family Controls entitlement, and that review of the submission cannot proceed. All reviewer activity stopped at that point, and there has been none since. What we verified: The Family Controls (Distribution) entitlement is granted to our account and assigned to all four bundle IDs (the main app plus its DeviceActivityMonitor, ShieldAction, and ShieldConfiguration extensions). We verified with codesign that com.apple.developer.family-controls = true is present in the code signature and embedded provisioning profile of every one of the four executables in the submitted IPA — so the entitlement named in the automated message is present in the flagged build. For context: builds 9 and 10, with an identical Screen Time API surface and identical entitlements (verified at the binary level with nm against the submitted artifacts), had been human-reviewed on Jul 2–5 with no Screen Time-related objection. We recognize those builds may simply not have reached the automated analysis stage before being superseded, so we do not draw firm conclusions from that. What we did anyway (build 12, submitted Jul 9): In case the automated check actually concerns the separate com.apple.developer.family-controls.app-and-website-usage entitlement (which we do not request and do not need), we removed every reference from our main app to the APIs associated with it: AuthorizationStatus.approvedWithDataAccess, ManagedSettings.Application.bundleIdentifier, ManagedSettings.Application.localizedDisplayName, ManagedSettings.ActivityCategory.localizedDisplayName, and ManagedSettings.WebDomain.domain. We verified with nm that none of the four executables in the build 12 IPA reference these APIs. The app does not use FamilyActivityData, DeviceActivityReport, app usage events, web usage events, or App and Website Usage data access. No automated message has appeared for build 12. What has happened since: Jul 9–14: No reviewer activity on build 12. We filed an expedited review request and opened two Developer Support cases (Jul 8 and Jul 14). No response to any of them. Around Jul 15: Hoping to clear the frozen state, we cancelled and resubmitted the same Version 1.0.0 / build 12. Around Jul 17: Filed a second expedited review request for the new submission. Jul 22 (today): The new submission has been in "Waiting for Review" since Jul 15, with no reviewer activity and no reply to either support case or either expedite request. What we are asking: Could someone check whether the Jul 8 automated flag is still attached to the app record and blocking reviewer assignment, and help get the current submission assigned to a reviewer? If the automated check flags build 12 again, could the message specify which entitlement and which binary / API references triggered it, so we can address it precisely? We can provide codesign output, entitlement plists, provisioning profile dumps, and nm symbol listings on request. Thank you.
3
2
595
3h
Matchup Sport (6782085896) — DSA trader verification "In Review" since August 8, 2026
Hello, Our Digital Services Act trader verification has been showing "In Review" in App Store Connect since August 8, 2026. App name: Matchup Sport Apple ID: 6782085896 Account type: Individual, based in Austria Business > Agreements > Compliance > Digital Services Act: In Review, last updated August 8, 2026 (27 countries or regions) The trader declaration is set at both levels: the account-level declaration was submitted on August 8, and the app-level setting under App Information > App Store Regulations & Permits shows that the developer has identified itself as a trader for this app. Our planned launch territories are 13 countries, 12 of which are in the EU, including our home market of Austria. While this verification remains pending, the app cannot be distributed in any of them even once App Review completes. My questions: Is any document or information still outstanding from our side to complete the verification? Is there an expected timeframe for trader verification at present? Is there an escalation path if the status does not change? I have not been able to reach anyone on this specific topic through the standard support form. Any guidance would be appreciated. Thank you.
0
0
4
3h
Matchup Sport (6782085896) — "Waiting for Review" since August 2, 2026
Hello, Our app has been in "Waiting for Review" since August 2, 2026 with no status change and no communication. App name: Matchup Sport Apple ID: 6782085896 Bundle ID: app.matchupsports.matchup Build: 1.0.0 (38), uploaded July 29, 2026 Submitted: August 2, 2026 Support case: 20000129837883 (opened August 6, no resolution) What we have already verified on our side: Build 38 shows Validated and passed beta review for external TestFlight; it is currently distributed to external testers with sessions logged and no crashes reported All metadata is complete: description, keywords, screenshots, promotional text Support URL and Marketing URL are live and reachable A working demo account is provided in App Review Information along with review notes Export compliance is answered (App Uses Non-Exempt Encryption: No) Paid Apps Agreement and Free Apps Agreement are Active; tax forms are Active DSA trader status is declared at both account and app level This is the first submission on this developer account. I would like to confirm that nothing is blocking the submission from entering review, and whether any action is required from our side. Thank you.
0
0
5
3h
App stuck on “Waiting for Review” for 10 days
Hi everyone, My app has been stuck in “Waiting for Review” for about 10 days, and I’m wondering if anyone has experienced something similar recently. Details: Submission ID: 0f5f47ab-fa7e-4def-a1ae-d1d23665289c Submitted: August 1, 2026 There hasn’t been any update or message from App Review so far. Is this kind of delay normal, or should I contact Apple Developer Support? I’m also wondering if cancelling and resubmitting would help, or if that could make the wait even longer. Thanks for any advice or experience you can share.
2
0
90
3h
Apple taking too long to review my brand new app
Hello Developer Community, We have submitted our brand new app to the app store that many people worked really hard on. We have been waiting anxiously to see what apple says. However, the app never leaves the "waiting to be reviewed" state, and it has been more than a week since we have uploaded it. We know Apple put back to the queue if we update build and we haven't made any update. Why its taking too long. We have committed a date our clients it will on App Store by 5th Aug (submitted on 30th July) but no work from Apple yet. Now its creating question on crediblity us from our clients.
9
4
198
3h
Locate the In-App Purchases and Subscriptions Section in App Store Connect
App Store Connect displays the In-App Purchases and Subscriptions section on your app's version page when your app has an In-App Purchase or subscription with a Ready to Submit status. To locate the In-App Purchases and Subscriptions section: In Apps, select the app you want to view. In the sidebar, select the app version. On the version page, scroll down to the In-App Purchases and Subscriptions section. For more information, see Submit an In-App Purchase.
Replies
0
Boosts
0
Views
2k
Activity
Jun ’26
App Store Connect not accepting Builds from Xcode 27 Beta 5
I keep getting the following error message when trying to upload a build to TestFlight using Xcode 27 Beta 5 (running under macOS 27 Beta 5): This bundle is invalid. Apple is not currently accepting applications built with this version of Xcode. n/a (ID: 5CFNDXXPXFP2H4DVQPPGHA2YUE) Is anyone else running into this?
Replies
2
Boosts
0
Views
248
Activity
1h
New app stuck in “Waiting for Review” since August 4, 2026
Hello, My first submission for a new app has been in “Waiting for Review” for 7 days, with no status change and no message in App Store Connect. Details: • App Apple ID: 6794950418 • Version: 1.0 (build 11) • Submitted: August 4, 2026 at 13:51 CEST • Submission ID: 24fe4981-11a7-4425-8694-93cae015b2cd • Current status: Waiting for Review (never moved to In Review) There is no rejection, no request for additional information, and nothing in the Resolution Center. Review notes include everything needed to test the app, and the build has been running fine in TestFlight. Is there anything on my side that could be holding this submission in the queue, or is this simply the current backlog? Any guidance would be appreciated. Thank you.
Replies
0
Boosts
0
Views
26
Activity
1h
Waiting for Review since July 30, 2026 — Express Evaluations iOS 1.0 (12+ days)
Hello App Review Team, Our iOS app has been stuck in "Waiting for Review" for more than 12 days with no status change and no Resolution Center messages. App name: Express Evaluations Developer: Express Evaluations, Inc Platform: iOS Version: 1.0 Current status: Waiting for Review Submitted: July 30, 2026 at 11:52 AM We opened an App Review Status case on August 10, 2026 and have not received a reply yet. Case ID: 20000133168856 This delay is blocking our planned release and is affecting stakeholder trust in our launch timeline. Could someone from App Review please check whether this submission is stuck in the queue and advise on the current status? Thank you for your help.
Replies
1
Boosts
1
Views
211
Activity
1h
App Store search rewrites our brand name "Kaiho" to "kaiju": app unreachable by name on the France storefront
Our app cannot be found by its own name on the France App Store, because search silently rewrites the query. App: Kaiho: Arrêter de fumer / Kaiho: Quit Smoking Coach Apple ID: 6760356299 Feedback Assistant: FB24267557 WHAT HAPPENS Searching "Kaiho" on the France storefront returns kaiju monster games. The page reads "Affichage des résultats pour « kaiju »" ("Showing results for kaiju") with a "Rechercher « Kaiho » à la place ?" link underneath. Our app is not in the results at all. The first item served is a paid ad for an unrelated app, then KAIJU N° 8 THE GAME. THIS IS NOT A RANKING QUESTION The app is correctly indexed on that same storefront: searching "kaiho arreter de fumer" returns it as the #1 result. The substitution happens before ranking the term itself is replaced. TWO APPLE SYSTEMS DISAGREE While typing, the App Store's own autocomplete proposes "kaiho: arrêter de fumer" as its first suggestion, and offers "kaiho in Developers". After submitting, the results engine rewrites the term to "kaiju". The suggestion service and the results engine hold contradictory views of the same query. REPRODUCIBLE ACROSS STOREFRONTS The search response exposes the substitution explicitly. MZSearch with term=kaiho returns "spellCorrection": "kaiju" on X-Apple-Store-Front 143442 (France), and "kahoot" on 143459 (Switzerland), 143443 (Germany) and 143450 (Italy). Storefronts 143441 (US), 143446 (Belgium), 143455 (Canada) and 143454 (Spain) return no spell correction and do return the app. Measured 2026-08-11. WHY IT MATTERS "Kaiho" is our French trademark (No. 5255039, INPI, classes 9, 41, 42) and the only term under which we ask people to look for us. France is our home market and the source of nearly all our iOS installs. Anyone told to "search for Kaiho on the App Store" lands on monster games instead. I have filed FB24267557 and opened a Developer Support case under Distribution > App Store search and visibility. QUESTION FOR THE COMMUNITY Has anyone managed to get Apple to drop a spell correction on their own brand name? I have seen the same pattern reported for "Myseum" being corrected to "Museum" (thread #780657) with no resolution posted. If you got it fixed, what actually moved it? Feedback Assistant, a support case, Search Ads volume on the exact term, or simply time?
Replies
0
Boosts
0
Views
14
Activity
1h
Apple Developer Enrollment On Hold for 1 year
Hello, My enrollment in the Apple Developer Program has been "On Hold" for over a year. I am applying for an individual account and urgently need access to complete my setup. I contacted Apple Support two weeks ago and received a single response stating they would look into it, but I have not received an update since. Any assistance or guidance from the community or forum staff on how to resolve this would be greatly appreciated. Thank you!
Replies
2
Boosts
1
Views
153
Activity
2h
MacOS failed notarise app
I tring to notarise my app for long time the error "Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions.", I tried to contact support only email available, I got response only one time they ask for documents I sent and for then they disappear no response any more I tried to open new ticket for no response either. What can I do?
Replies
0
Boosts
0
Views
16
Activity
3h
Urgent: Expedite App Review
Our app Broons Tea Room (App ID: 6795576807) has been waiting for review for more than 10 days. We have also submitted an expedited review request, but we haven't received any update yet. Could you please check the status of our app and help expedite the review if possible? Please let us know if you need anything from our side. Thank you for your help.
Replies
0
Boosts
1
Views
25
Activity
3h
App Review Taking Over 10 Days
Hello Apple App Review Team, Our app Broons Tea Room (App ID: 6795576807) has been waiting for review for more than 10 days. We have also submitted an expedite review request, but we haven't received any update yet. Could you please check the status of our app and help expedite the review if possible? Please let us know if you need anything from our side. Thank you for your help.
Replies
0
Boosts
0
Views
12
Activity
3h
App Store Connect: Can't change Primary Locale to nl-NL — 19 historical versions blocked by missing screenshots, API returns 409
I'm trying to change an app's Primary Language in App Store Connect from de-DE to nl-NL and hitting a state I can't resolve through any interface available to me. Environment App Store Connect (web UI) and App Store Connect API v1 Problem UI: App Information → Primary Language → nl-NL → Save fails with: "Primary Locale couldn't be saved because you must first provide all the required screenshots for each version in this language." API: PATCH /v1/apps/1669670490 with attributes.primaryLocale = "nl-NL" returns HTTP 409: ENTITY_ERROR.ATTRIBUTE.INVALID.INVALID_STATE.MISSING_SCREENSHOTS_PRIMARY_LOCALE Error detail contains an unsubstituted placeholder: "...you must first provide all the required @@LANGUAGE_VALUE@@ screenshots..." What I've verified Current live version (3.7.6) and current editable version (3.7.11) both have complete nl-NL screenshot sets for all required device sizes (6.9" iPhone, 13" iPad). No Watch app, iMessage extension, Custom Product Pages, In-App Events, or IAPs. Enumerated all 23 versions via the API (1.0 → 4.1.0). 19 of them have an nl-NL appStoreVersionLocalization (with real historical description/keywords/support URL) but zero nl-NL screenshots attached. Tried POSTing an nl-NL screenshot set to one historical version (4.1.0) directly via the API to confirm this isn't just a UI restriction. Also returns 409 ENTITY_ERROR.ATTRIBUTE.INVALID.INVALID_STATE — historical versions are locked against edits (including screenshots) at the API level, not just the UI. Question Since these historical versions can't be edited through any supported interface, is there a documented way to satisfy or bypass the "screenshots for each version" check for locked historical versions when changing Primary Locale? Filed as case 20000130035264 with Developer Support, who pointed me here for the technical side.
Replies
5
Boosts
0
Views
301
Activity
3h
Which App Store Connect API should submit an Apple-hosted asset pack for external TestFlight review?
Hello, Apple’s documentation appears inconsistent about which App Store Connect API should be used to submit an Apple-hosted Background Asset version for external TestFlight review: In WWDC25 “Discover Apple-Hosted Background Assets”, Apple says that the asset pack version can be submitted using the POST /v1/betaBackgroundAssetReviewSubmissions. In Uploading and versioning Apple hosted background assets, the external beta review instructions link to “Submit an app for beta review,” which uses POST /v1/betaAppReviewSubmissions. These two resources have different behavior. betaBackgroundAssetReviewSubmissions I called the public API with the same resource structure used by the App Store Connect web UI: POST https://api.appstoreconnect.apple.com/v1/betaBackgroundAssetReviewSubmissions { "data": { "type": "betaBackgroundAssetReviewSubmissions", "relationships": { "backgroundAssetVersion": { "data": { "type": "backgroundAssetVersions", "id": "<BACKGROUND_ASSET_VERSION_ID>" } } } } } The public API returned 404 PATH_ERROR: The resource 'v1/betaBackgroundAssetReviewSubmissions' does not exist. However, the App Store Connect web UI uses the private endpoint below with the same payload and receives HTTP 201: POST https://appstoreconnect.apple.com/iris/v1/betaBackgroundAssetReviewSubmissions The public endpoint is also absent from the current App Store Connect OpenAPI specification. betaAppReviewSubmissions I also tested the public POST /v1/betaAppReviewSubmissions endpoint. When I supplied a backgroundAssetVersion relationship, the API returned 409: 'backgroundAssetVersion' is not a relationship on the resource 'betaAppReviewSubmissions'. You must provide a value for the relationship 'build'. The build relationship only accepts the builds resource type, not backgroundAssetVersions. Therefore, betaAppReviewSubmissions can submit an app build but cannot submit a Background Asset version. Could Apple please clarify: Which public API should be used to submit a Background Asset version for external TestFlight review? Is betaBackgroundAssetReviewSubmissions intended to be exposed through the public App Store Connect API? Is the link to betaAppReviewSubmissions in the Background Assets documentation incorrect? When will the public documentation and OpenAPI specification be updated? Thank you.
Replies
0
Boosts
0
Views
7
Activity
3h
TestFlight builds expired across multiple apps; new builds cannot be installed (“Requested app is not available or doesn’t exist”)
Hi, I’m experiencing a TestFlight issue affecting multiple apps in my account. Issue summary: • Several TestFlight builds across all of my apps expired at the same time. • After uploading new replacement builds, neither I nor my testers are able to install them. • Installation fails with the message: “Could not install {App Name}. The requested app is not available or doesn’t exist.” • The build shows as processed and available in App Store Connect. • Testers are already invited and active. • No redeem code is required. I am seeing the same issue on my own device as well. What I’ve tried: • Uploading new builds (incremented version + build number). • Confirmed builds are visible and available in App Store Connect. • Removing and re-adding testers. • Logging out of the app. • Deleting the app from the device. • Restarting the device. • Reinstalling directly from TestFlight. • Restarting TestFlight. Despite this, installation consistently fails with the “requested app is not available or doesn’t exist” error. Expected behavior: • New TestFlight builds should be installable once processed and available. • Testers (and the developer) should be able to install directly from TestFlight. • Expired builds should not block installation of newly uploaded builds. Additional context: • This started immediately after multiple TestFlight builds expired across my apps. • All affected apps were previously installing and testing without issue. • Apple Developer Support has been contacted, but I wanted to check whether others are seeing the same behavior or if there is a known workaround. Has anyone else encountered TestFlight builds becoming unavailable across multiple apps at once, or an install failure after replacing expired builds
Replies
8
Boosts
1
Views
1.5k
Activity
3h
BETA_FEEDBACK_SCREENSHOT_SUBMISSION_CREATED webhook not dispatched
Hi! I'm observing a problem with ASC webhooks. I have a webhook with all event triggers enabled, and I verified it works: events such as buildUploadStateUpdated and buildBetaDetailExternalBuildStateUpdated are delivered. However, when a screenshot feedback is submitted from an external testing group, no webhook is dispatched (confirmed it does not appear in "Recent deliveries"). The screenshot feedback is submitted successfully, the screenshots appear in the ASC dashboard. Basing on the documentation, I think this event should trigger the BETA_FEEDBACK_SCREENSHOT_SUBMISSION_CREATED webhook.
Replies
0
Boosts
0
Views
21
Activity
3h
App Stuck in Review for 15 Days With No Response
Hi Apple Developer Community, Our app has been waiting for App Review for around 15 days, and we still haven't received any update or response from the App Review team. The app was submitted for review on July 26, 2026, and it has remained in the "Waiting for Review" status since then. We have also tried contacting the appropriate support/contact team, but unfortunately, we haven't received a response there either. This is blocking our production release and affecting our customers who are waiting for the app. Could anyone advise what we should do in this situation or how we can escalate the review? Bundle Ids: com.sanisetu.supervisor / com.sanisetu.worker Submission Date: July 26, 2026 Current Status: Waiting for Review Time Waiting: ~15 days Any guidance would be greatly appreciated. Thank you.
Replies
0
Boosts
0
Views
27
Activity
3h
Version 1.0.0 stuck in "Waiting for Review" for ~2 weeks after an automated Guideline 2.5.1 message about the Family Controls entitlement
Our app — a screen-time / focus app — has had no App Review activity for two weeks, and we believe the trigger was an automated Guideline 2.5.1 check that froze an otherwise actively progressing review. (This forum account is linked to the developer account in question; we can provide the App ID, bundle IDs, submission IDs, and support case numbers through any private channel on request.) Context: Jul 2–5: Our first submission (Version 1.0.0) was under active review. We went through several ordinary metadata / paywall-related iterations, and the reviewer responded within roughly 24 hours each time. Nothing related to Screen Time was raised in these human reviews of builds 9 and 10. Jul 8: After we submitted build 11 — which addressed the remaining human-review feedback — we received an automated Guideline 2.5.1 (Performance: Software Requirements) message stating that the app uses the Screen Time API but has not been submitted with the Family Controls entitlement, and that review of the submission cannot proceed. All reviewer activity stopped at that point, and there has been none since. What we verified: The Family Controls (Distribution) entitlement is granted to our account and assigned to all four bundle IDs (the main app plus its DeviceActivityMonitor, ShieldAction, and ShieldConfiguration extensions). We verified with codesign that com.apple.developer.family-controls = true is present in the code signature and embedded provisioning profile of every one of the four executables in the submitted IPA — so the entitlement named in the automated message is present in the flagged build. For context: builds 9 and 10, with an identical Screen Time API surface and identical entitlements (verified at the binary level with nm against the submitted artifacts), had been human-reviewed on Jul 2–5 with no Screen Time-related objection. We recognize those builds may simply not have reached the automated analysis stage before being superseded, so we do not draw firm conclusions from that. What we did anyway (build 12, submitted Jul 9): In case the automated check actually concerns the separate com.apple.developer.family-controls.app-and-website-usage entitlement (which we do not request and do not need), we removed every reference from our main app to the APIs associated with it: AuthorizationStatus.approvedWithDataAccess, ManagedSettings.Application.bundleIdentifier, ManagedSettings.Application.localizedDisplayName, ManagedSettings.ActivityCategory.localizedDisplayName, and ManagedSettings.WebDomain.domain. We verified with nm that none of the four executables in the build 12 IPA reference these APIs. The app does not use FamilyActivityData, DeviceActivityReport, app usage events, web usage events, or App and Website Usage data access. No automated message has appeared for build 12. What has happened since: Jul 9–14: No reviewer activity on build 12. We filed an expedited review request and opened two Developer Support cases (Jul 8 and Jul 14). No response to any of them. Around Jul 15: Hoping to clear the frozen state, we cancelled and resubmitted the same Version 1.0.0 / build 12. Around Jul 17: Filed a second expedited review request for the new submission. Jul 22 (today): The new submission has been in "Waiting for Review" since Jul 15, with no reviewer activity and no reply to either support case or either expedite request. What we are asking: Could someone check whether the Jul 8 automated flag is still attached to the app record and blocking reviewer assignment, and help get the current submission assigned to a reviewer? If the automated check flags build 12 again, could the message specify which entitlement and which binary / API references triggered it, so we can address it precisely? We can provide codesign output, entitlement plists, provisioning profile dumps, and nm symbol listings on request. Thank you.
Replies
3
Boosts
2
Views
595
Activity
3h
API Keys cannot be created due to an invalid Program License Agreement. Please update this agreement and try your request again.
API Keys cannot be created due to an invalid Program License Agreement. Please update this agreement and try your request again. i don't see any pending license agreement in the business section
Replies
1
Boosts
0
Views
166
Activity
3h
Matchup Sport (6782085896) — DSA trader verification "In Review" since August 8, 2026
Hello, Our Digital Services Act trader verification has been showing "In Review" in App Store Connect since August 8, 2026. App name: Matchup Sport Apple ID: 6782085896 Account type: Individual, based in Austria Business > Agreements > Compliance > Digital Services Act: In Review, last updated August 8, 2026 (27 countries or regions) The trader declaration is set at both levels: the account-level declaration was submitted on August 8, and the app-level setting under App Information > App Store Regulations & Permits shows that the developer has identified itself as a trader for this app. Our planned launch territories are 13 countries, 12 of which are in the EU, including our home market of Austria. While this verification remains pending, the app cannot be distributed in any of them even once App Review completes. My questions: Is any document or information still outstanding from our side to complete the verification? Is there an expected timeframe for trader verification at present? Is there an escalation path if the status does not change? I have not been able to reach anyone on this specific topic through the standard support form. Any guidance would be appreciated. Thank you.
Replies
0
Boosts
0
Views
4
Activity
3h
Matchup Sport (6782085896) — "Waiting for Review" since August 2, 2026
Hello, Our app has been in "Waiting for Review" since August 2, 2026 with no status change and no communication. App name: Matchup Sport Apple ID: 6782085896 Bundle ID: app.matchupsports.matchup Build: 1.0.0 (38), uploaded July 29, 2026 Submitted: August 2, 2026 Support case: 20000129837883 (opened August 6, no resolution) What we have already verified on our side: Build 38 shows Validated and passed beta review for external TestFlight; it is currently distributed to external testers with sessions logged and no crashes reported All metadata is complete: description, keywords, screenshots, promotional text Support URL and Marketing URL are live and reachable A working demo account is provided in App Review Information along with review notes Export compliance is answered (App Uses Non-Exempt Encryption: No) Paid Apps Agreement and Free Apps Agreement are Active; tax forms are Active DSA trader status is declared at both account and app level This is the first submission on this developer account. I would like to confirm that nothing is blocking the submission from entering review, and whether any action is required from our side. Thank you.
Replies
0
Boosts
0
Views
5
Activity
3h
App stuck on “Waiting for Review” for 10 days
Hi everyone, My app has been stuck in “Waiting for Review” for about 10 days, and I’m wondering if anyone has experienced something similar recently. Details: Submission ID: 0f5f47ab-fa7e-4def-a1ae-d1d23665289c Submitted: August 1, 2026 There hasn’t been any update or message from App Review so far. Is this kind of delay normal, or should I contact Apple Developer Support? I’m also wondering if cancelling and resubmitting would help, or if that could make the wait even longer. Thanks for any advice or experience you can share.
Replies
2
Boosts
0
Views
90
Activity
3h
Apple taking too long to review my brand new app
Hello Developer Community, We have submitted our brand new app to the app store that many people worked really hard on. We have been waiting anxiously to see what apple says. However, the app never leaves the "waiting to be reviewed" state, and it has been more than a week since we have uploaded it. We know Apple put back to the queue if we update build and we haven't made any update. Why its taking too long. We have committed a date our clients it will on App Store by 5th Aug (submitted on 30th July) but no work from Apple yet. Now its creating question on crediblity us from our clients.
Replies
9
Boosts
4
Views
198
Activity
3h