I'm submitting a new version of my app, and after click "submit for Review", it show that: A few more items are needed in order to submit for review The items listed below are required for submission:There are still screenshot uploads in progress. I didn't met this problem before. Is that mean I haven't upload all the screenshot required or it's still uploading the screenshots to App Store Connect's server? Cause before there is a "save" button after you drag images to the screenshots area, now you don't. And I think I have uploaded all the screenshots needed and I waited a day to try submit again, still the same. What should I do?

Our app has had its Digital Services Act (DSA) trader status showing as "In Review" since 22 August 2026, which is now over a month. As a result, the app is unavailable to download across all 27 EU countries. A few details: The trader information was submitted and has been "In Review" the entire time, with no change in status. There is no option in App Store Connect to edit, resubmit, or view further detail on the trader status — it simply shows "In Review" with no action available on our end. Our other compliance item (Directive on Administrative Cooperation - 7th Amendment) shows as "Active" without issue, so the account-level details appear to be in order. I have contacted Apple Support by email (no response yet), and the callback option is showing as unavailable. Has anyone experienced a DSA trader review taking this long, or found a way to get it unstuck? Is this a known delay on Apple's side, or is there something we might be missing that we can action? Any guidance would be appreciated, as the EU restriction is affecting our users.

Dear Apple Developer Support Team, I am writing to urgently escalate my Apple Developer Program enrollment issue regarding Case Number 20000132030420. I have been trying to enroll in the Apple Developer Program for almost two months, but my enrollment is still pending. I have contacted Apple Support multiple times and followed the instructions provided, but unfortunately, I have not received any meaningful update or resolution. More than a month ago, I was asked to submit my government-issued ID for verification, which I submitted as requested. Since then, I have received no update regarding the status of my enrollment. I have also attempted to contact support regarding this case, but my messages have not received a response. This prolonged delay is extremely frustrating and is preventing me from moving forward with my development work and publishing plans. I have been patient and have followed every step requested by Apple, but after nearly two months without a resolution, I am requesting that this case be urgently escalated to the appropriate team and that my enrollment status be reviewed. Please provide me with: An update on the current status of my enrollment. Confirmation that my submitted government ID has been received and reviewed. The reason for the continued delay, if applicable. A clear timeline for when my Apple Developer Program enrollment will be completed. I sincerely hope @Apple @Support can look into this matter and resolve it as soon as possible. This is now my last option to reach out again for support, as I have already spent considerable time trying to resolve this through the existing support channels. I would greatly appreciate a prompt response and resolution to Case #20000132030420. Kind regards,

Hello Apple Developer Team, I've followed the AppStoreConnect API documentation and created the following: I've created a API Key in App store > Integrations > Teams key, gave the role as admin. Created a valid JWT token When fetching the GET v1/apps, I can see the list of apps. Also I was able to make GET v1/users as well successfully. I've the valid bundle Id and capabilities enabled in the developer portal. Facing an issue while creating an app in App Store using AppStoreConnect API using POST call: This is my ruby script: response = api_request( method: :post, path: "/v1/apps", token: token, body: { data: { type: 'apps', attributes: { name: APP_NAME, primaryLocale: LOCALE, sku: "SKU#{Time.now.to_i}", bundleId: BUNDLE_ID, platform: 'IOS' } } } ) It gives me below error: { "errors": [ { "id": "09b465fc-316f-47b4-9bc3-9c340cb966aa", "status": "403", "code": "FORBIDDEN_ERROR", "title": "The given operation is not allowed", "detail": "The resource 'apps' does not allow 'CREATE'. Allowed operations are: GET_COLLECTION, GET_INSTANCE, UPDATE" } ] } Did anyone was able to successfully create the app in App Store via AppStoreConnect API? Could you please help me identify the root cause for the above issue and provide some inputs so that I could work on resolving them and move forward in the deployment process. Appreciate your help in reviewing this. Thank you, Santosh

The Screenshot specifications page lists iPhone Duo as an iPhone screenshot size: Outer display: 1398 × 2034 and 2034 × 1398 Inner display: 2007 × 2853 and 2853 × 2007 https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications I cannot find a way to upload them. In App Store Connect, the App Previews and Screenshots device selector on my app's version page does not list iPhone Duo. The only iPhone options are the existing display sizes. In the App Store Connect API, ScreenshotDisplayType has no Duo case. The largest iPhone case is still APP_IPHONE_67. I checked the current reference: https://developer.apple.com/documentation/appstoreconnectapi/screenshotdisplaytype My questions: Where in App Store Connect do I upload iPhone Duo screenshots? If the option is not open yet, is there a ScreenshotDisplayType case for Duo that I should use through the API instead? Thanks.

Hello App Review, Our iOS app was rejected under Guideline 5.6 (Developer Code of Conduct). The message states that the app appears to contain features intentionally hidden during review, and that this pattern is commonly associated with fraudulent activity. We want to address this correctly, but the current note does not identify the specific flow, screen, or behavior that was observed. Without that, we cannot investigate the exact issue. Could a member of App Review please follow up in App Store Connect with more concrete detail, or advise what we should check? @WWDR App name: Prime Cedi Loan Apple ID: 6808185084 Version: 1.1.0, Build 2 Guideline: 5.6 We have already replied in Resolution Center and are ready to provide test accounts, a demo video, or a phone call if that would help. Thank you.

Has anyone successfully appealed an Apple Developer account termination under Section 3.2(f)? My individual developer account (about 50 live apps, all my own work, all revenue through StoreKit subscriptions) was terminated effective August 24, 2026 under Section 3.2(f) of the ADP Agreement. I believe it was triggered by internal tooling I built to automate my own App Store Connect workflow — metadata, build uploads, submissions — only on my own apps. I've filed an appeal through the official form, replied to the termination notice, and written to appstorenotices. For anyone who has been through this: Did your appeal succeed, and how long did Apple take to respond? Was the response you received a form letter or specific? Were you able to recover the withheld balance from legitimate sales, and through what channel? Is there any official channel I've missed beyond the appeal form, the termination-notice reply, and appstorenotices? Any firsthand experience would mean a lot. Thank you.

Hi everyone, I'm hoping someone from Apple or another developer has seen this before because I'm completely blocked from submitting my first auto-renewable subscription. Setup First app submission App version: 1.0 (Build 34) One auto-renewable subscription Five consumable IAPs Everything configured in App Store Connect StoreKit works correctly in TestFlight Subscription purchases complete successfully in TestFlight RevenueCat configuration has been verified Subscription review screenshot is uploaded and processed successfully Problem App Store Connect shows: "There are errors with one or more of your items. To fix them, you need to remove the items and add them again to your submission." The draft contains: App Version 5 Consumable IAPs 1 Subscription When I submit through the App Store Connect API I receive: STATE_ERROR.SUBSCRIPTION_SUBMISSION_REQUIRES_GROUP_VERSION A subscription must be submitted with its subscription group version when the group has no prior approved version. That makes sense because this is my first subscription. However, when I attempt to create a subscription group version I receive: STATE_ERROR.ALREADY_EXISTS Version already exists. There is already an inflight version with id: bf2f7b5b-7fbd-44fc-9c67-af1297f3d76a So I then attempted to add that existing SubscriptionGroupVersion to the review submission. Apple responds with: STATE_ERROR.SUBSCRIPTION_GROUP_VERSION_NOT_SUPPORTED Subscription group version bf2f7b5b-7fbd-44fc-9c67-af1297f3d76a is using an older format that is not supported for review submission. Please update before submitting. and also: STATE_ERROR.SUBSCRIPTION_GROUP_VERSION_INVALID_STATE Subscription group version bf2f7b5b-7fbd-44fc-9c67-af1297f3d76a cannot be submitted. Only versions in Prepare for Submission or Developer Rejected can be submitted. The issue I'm now stuck because: Apple says I must submit a SubscriptionGroupVersion. Apple says one already exists. Apple will not allow me to create a replacement. Apple will not allow me to submit the existing one. Apple says the existing one is using an older format. I cannot find any way in App Store Connect to update, replace or delete this SubscriptionGroupVersion. Things I've already verified Build 34 is attached correctly. Subscription Product ID is correct. RevenueCat configuration is correct. StoreKit loads the subscription successfully. Purchases work in TestFlight. Subscription review screenshot exists and is COMPLETE. Localizations, pricing and availability are all configured. The issue occurs both in App Store Connect and when submitting via the App Store Connect API. Question Has anyone encountered this before? Is there a way to regenerate or migrate a SubscriptionGroupVersion into the new format from App Store Connect, or is this something Apple Developer Support has to reset on the backend? Any advice would be greatly appreciated. Thanks!

We have 5 consumable in-app purchase products (Product IDs: localshadows_support_099, _499, _999, _2499, _4999) currently in "Prepare for Submission" status. Our app's first version (1.0) has also not yet been submitted for App Review. Question: Does sandbox testing of these consumable IAPs require the app to be fully approved through App Review first, or is it sufficient for the products to be attached to a version that has been submitted (even if still pending review)? What we've tried: We're using react-native-iap v16.4.1 for a real native StoreKit 2 purchase flow (not RevenueCat, which was masking this issue via its Test Store simulation mode). Calling fetchProducts() for these SKUs returns an empty array, and calling requestPurchase() for them results in an indefinite hang with no error. We want to complete sandbox testing before deciding on our actual App Review submission timeline.

Hello, We are trying to extract our lifetime app star ratings data from the App Store Connect API but we couldn't find the resource anywhere. We were able to successfully get all app reviews data from this endpoint GET https://api.appstoreconnect.apple.com/v1/apps/{id}/customerReviews based on the official documentation. We validated that we received all reviews, these reviews also include the star ratings. However, the number of star ratings that we see on the App Store console is way less than the one we got from reviews API since star ratings can be submitted without a text review. Any idea where can we get the data of lifetime star ratings using the Connect API ? Thanks !

Hello, I apologise for posting here. I know this forum is not a support channel, and I would not have posted if I had another way to reach App Review. Apple ID: 6759336435 Submission ID: 59a73f4a-e83b-4fa4-96dc-4c4b6a0ebcc4 Version reviewed: 1.0 (3) In review since: August 10, 2026 Rejection received: August 20, 2026 Our first submission was rejected under Guideline 4.3(a), on the basis that the app shares a similar binary, metadata or concept with apps previously submitted by a terminated Apple Developer Program account. We have no connection to any terminated developer account. RocketIO is not related to any other app, including the other apps on our own account. It is a separate product that we have been designing and writing for several years, on a different technical foundation: 114,817 lines of Dart across 139 files in Flutter, plus the Swift we wrote for the iOS tunnel host and the Network Extension, 187 tests, and 32 fully translated languages. We believe the binary match is a false positive. RocketIO statically links a publicly available open-source proxy core, as every app in this category does. That core is the largest part of the compiled binary, so any two apps linking the same open-source library will share a large amount of identical compiled code no matter how different their own source is — exactly as apps linking OpenVPN or WireGuard do. We cannot remove it, because it is the reason the app exists. RocketIO is also a bring-your-own-configuration client rather than a VPN service. It ships with an empty server list and does nothing until the user supplies a configuration for infrastructure they already own. We operate no servers, sell no subscriptions and carry no traffic. Among the protocols we have implemented are several that very few clients support on any platform, including DNSTT (DNS tunnelling), AnyTLS, ShadowQUIC, Mieru and Juicity, some of them added only recently. We replied in Resolution Center with all of this in detail, and asked which app or account the similarity was matched against, so that we could respond to the specific finding rather than guess. We are still waiting for a response. We have deliberately not resubmitted. We did not want to place another submission in the queue while this conversation is open, and we did not want to send back something that could reasonably be read as unchanged. We have been waiting since August 10, and we will be honest that it has been a difficult wait. We put years of work into this app and we have users who are looking forward to it, and at the moment we cannot tell them anything, because we do not know what specifically we are being asked to change. Could someone from App Review please reply to us there? We are glad to provide our source repository and its full commit history, to take a call at any time convenient to you in English, and to demonstrate the app live. Thank you for your time.

Hello, We operate an app that grants users credits after a successful in-app purchase. Our current purchase-processing flow is as follows: A user completes an in-app purchase. Our app or server receives the purchase-related information. Our server sends a transaction verification request to the App Store Server API. After verifying the transaction, our service marks the purchase as completed and grants credits to the user. However, we are intermittently experiencing connection timeouts and unidentified server errors when retrieving transaction information through the App Store Server API. One example of the timeout error is: HTTPSConnectionPool( host='api.storekit.itunes.apple.com', port=443 ): Max retries exceeded with url: /inApps/v1/transactions/330003085668123 Caused by ConnectTimeoutError: Connection to api.storekit.itunes.apple.com timed out. (connect timeout=3) We also intermittently receive the following error response: { "code": 5000001, "message": "An unknown error occurred. Please try again." } When this issue occurs, the payment may have been successfully completed through the App Store, but our server is unable to immediately verify the transaction. As a result, the user may not receive the purchased credits in our app. We would appreciate your guidance on the following questions: What are the common causes of connection timeouts or error code 5000001 when calling /inApps/v1/transactions/{transactionId}? What retry strategy does Apple recommend when these errors occur? Please advise whether there are recommended timeout values, retry limits, or exponential backoff parameters. Is there another reliable method to confirm a completed purchase when the transaction lookup API does not return a response immediately? Does Apple recommend using App Store Server Notifications V2 to process completed purchases asynchronously rather than relying solely on an immediate transaction or receipt verification response? For an app that grants consumable digital credits, which value should be used as the primary identifier for purchase completion and duplicate-grant prevention: transactionId, originalTransactionId, or the information contained in signedTransactionInfo? When a temporary API error occurs, is it recommended to store the purchase as pending and perform transaction verification again from our server until a definitive result is received? We would appreciate Apple’s recommended implementation approach for reliable transaction verification and recovery, particularly to prevent cases in which a payment is successfully completed but the purchased credits are not granted due to a temporary API communication error. Thank you.

Hello, I apologise for posting here. I know this forum is not a support channel, and I would not have posted if I had another way to reach App Review. Apple ID: 6799505220 Submission ID: 0a07b03d-56c9-45b4-b9b2-7ecbeb9ada0e Our submission was rejected under Guideline 4.3(a). We investigated and found the cause on our side: a server-side configuration fault meant the reviewed build was served the shared server pool used by our other apps, so it displayed a worldwide server list it was never designed to show. The finding was correct for that build. It was a defect, not the product. We have corrected it and verified the correction, and the corrected build is uploaded and attached to the version in App Store Connect. We have deliberately not pressed Submit for Review. We did not want to place another submission in the queue and take review time from other developers while this conversation is still open, and we did not want to send back something that could reasonably be read as unchanged. We would rather agree the right next step with App Review first. We replied in Resolution Center with all of this and are still waiting for a response. Could someone from App Review please reply to us there? Thank you for your time.

We manage provisioning for a large number of App IDs across multiple apps via CI, using the App Store Connect API (not session-based Spaceship/Xcode auth). Capability management works well end to end for everything we've tried — Push Notifications, App Groups, Associated Domains, Data Protection, etc. can all be created, updated, and deleted via POST/PATCH/DELETE on /v1/bundleIdCapabilities. Apple Pay is the one exception. We can enable the Apple Pay capability itself via the API the same way as anything else, but there's no way to associate that capability with a specific Merchant ID. /v1/merchantIds exists as its own resource, but nothing in the bundleIdCapabilities or bundleIds schema links to it — no relationship, no include, no dedicated endpoint. In practice this means every new Apple Pay-enabled App ID we provision needs someone to go into the Developer Portal by hand (Identifiers → App ID → Capabilities → Apple Pay → select Merchant ID) before the generated provisioning profile will actually build — otherwise Xcode fails with errors like "doesn't include the Apple Pay capability" / "doesn't support the Merchant ID". Every other capability we use is fully scriptable; this is the one manual step left in an otherwise automated pipeline. Has anyone found a documented (or undocumented) way to do this via the API? If this is a confirmed gap rather than something we're missing, I've filed it as FB24414090 — if you've hit the same thing, adding your own Feedback number to a report on the same gap seems to be one of the few things that actually helps get traction internally, so feel free to reference this thread if you file one too.

Hi Apple Developer Support, I have been trying to enroll in the Apple Developer Program for the past 3 weeks, but my enrollment is still pending and my web-based order is not being processed. I have contacted Apple Support multiple times, but the issue remains unresolved. Enrollment ID: 2829892W3Q Case #: 20000136812088 @Apple @AppleSupport, could you please review my enrollment and process my web-based order? I would really appreciate it if Apple Developer Support could look into this and help complete my enrollment as soon as possible. Thank you.

@Apple @AppleSupport I have been trying to enroll in the Apple Developer Program for over a month, but my enrollment is still not being processed. The payment has also NOT been deducted, and my enrollment/order remains incomplete. I have contacted Apple Support multiple times and followed everything the support team instructed me to do. Despite doing everything requested, I still cannot complete my enrollment. As a developer who has built an app and is ready to submit it to the App Store, this ongoing issue is extremely frustrating. I just want to enroll in the Apple Developer Program so I can publish my app. Apple, please review my case and help me complete my enrollment as soon as possible. Case ID: L544J6UGFS Enrollment ID: 20000135646296 I would really appreciate it if the Apple Developer team could look into this and provide a proper resolution. #Apple #AppleDeveloper #AppleSupport #AppStore #DeveloperProgram

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.

Last week I've submitted a new update for review doing the standard procedure for iOS, Mac and Vision. When submitting them both the Mac and Vision App switched to Waiting for Review state but the iOS one got stuck in Ready for Review state. I've tried a few times canceling the submission and submitting again and it always gets stuck in the "Ready for Review" state. Under the App Review section shows as Waiting for Review but on the general page shows Ready for Review. I've tried using the App Store Connect the API and the same thing happens. Any suggestions how to fix this?

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.

Dear Apple Developer Support Team, I recently renewed my Apple Developer Program membership on August 8, 2026. When checking my account portal at ⁠developer.apple.com/account⁠, my membership status shows as active with the new expiration date set to August 9, 2027, and all current agreements have been accepted. However, my App Store Connect dashboard still displays a banner stating that my membership has expired, and my apps remain unavailable. Could you please assist in manually refreshing or syncing the account status between the Developer Portal and App Store Connect?