An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

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.

’m experiencing two problems with the new Asset Library / Header and Search Results features in App Store Connect. These are search-results creative videos, rather than traditional App Preview videos. Videos fail processing or remain stuck Several uploaded videos initially appeared to be processing, then showed a red error: Your file couldn’t be saved. Try again. If the problem persists, contact us. The App Store Connect API reports FAILED with POST_PROCESSING_FAILED for affected assets. Some also have a failed poster frame. This has occurred across multiple localizations, including the default product page and a custom product page. Waiting another 10 minutes did not resolve the failed assets. One example uses: MP4 container with H.264/AVC video 3840 × 2560 resolution 30 fps 16-second duration No audio The videos play and decode successfully locally. The original exports were approximately 2 MB. To test whether aggressive compression was involved, I also uploaded a higher-quality 19.2 MB export using H.264 High profile, Level 6.0, 8-bit YUV 4:2:0 and BT.709 colour settings. That latest upload remains at UPLOAD_COMPLETE after 10 minutes, without a processed video or poster frame. It has not yet reported a failure. Are there additional codec, profile, level, bitrate or colour-space requirements specifically for these new search-results videos? Is there a known processing issue, or a way to obtain a more detailed failure reason? Failed assets cannot be deleted after review withdrawal The app version was submitted and then withdrawn. It is now Developer Rejected and editable. After removing the video placements from both the default and custom product pages, some unused assets still cannot be deleted from Asset Library. The API returns HTTP 409: STATE_ERROR.ASSET_PREVIOUSLY_SUBMITTED_FOR_REVIEW The asset was previously submitted for App Review and can no longer be deleted. Other assets deleted successfully, but these remain locked even though the submission was withdrawn and their placements were removed. Is this deletion restriction expected after withdrawal? How can failed, unused assets be removed or reset? Does this require Apple Developer Support to clear them? Has anyone successfully uploaded videos through the new Search Results creative feature, or encountered either of these issues? I tried to manually delete the video from appstore connect but got this warning:

I'm an individual developer in Guam (US territory). My account country is United States, which is correct and is locked. In App Store Connect > Business > Edit Legal Entity, the State or Province list contains the 50 states, Washington DC and the three Armed Forces entries, but not Guam (GU). The closest option, Armed Forces Pacific, fails address verification with a Guam ZIP code (969xx), so the legal entity cannot be saved and the Paid Apps Agreement cannot be signed. This leaves no way for a developer in Guam to sell an app or offer in-app purchases. Presumably the same applies to the other US territories that are not in the list. I contacted Apple through Contact Us > Reports and Payments > Paid Agreement Setup on 6 and 7 October and have had no reply yet. My app is a typhoon and weather alert app for Guam; it is built and in TestFlight, and this is the only thing blocking release during an active storm season. Could someone from Apple either add Guam to the State list or correct the state on my legal entity directly? I can give my Team ID and case details privately. Has any other developer in Guam, the Northern Mariana Islands, American Samoa or the US Virgin Islands found a way through this?

Hi everyone, Our first app submission has been in "Waiting for Review" for 8 days now, and I'm wondering if others are seeing similar delays right now. Details: App: Pogne (iOS), version 0.1.0, build 15 Submitted: September 30 Status: Waiting for Review (it has never moved to "In Review") Expedited review requested: October 6 Contact case ID: 102984777071 (phone support currently shows as unavailable) Also emailed App Review support twice, no reply yet. Everything on our side looks complete: agreements, tax and banking are all Active, and there are no messages in App Review or the Resolution Center. Demo account credentials are provided in the review notes. A few questions for the community: Are others seeing longer than usual wait times this month? Is there anything else we can do besides waiting, without resubmitting? (We'd rather not lose our place in the queue.) For those who requested an expedited review recently, how long did it take to hear back? Thanks a lot for any insight. And if anyone from App Review sees this, we'd really appreciate a look at the case above. Patrice

App: Flow Connections (iOS puzzle game) Submitted: October 1, 2026 Expedited review request filed: October 6, 2026 Announced release date: October 9, 2026 TLDR: We kindly request that you please move Flow Connections into review, and please do the same for the other developers who have been waiting. We did our part. They did theirs. Full Version: Flow Connections has been sitting in "Waiting for Review" for 5 days. We submitted on time, we filed an expedited review request, and we did everything a small developer is supposed to do. Nothing has moved, and nobody has said why. We tried to reach someone. The developer support phone lines are shut off. The forums are full of review requests going unanswered; today alone, 12 new posts went up asking for help with stuck reviews, most waiting about a week, several over a month, some reporting 80 days. When we contacted Apple support and asked to be connected to anyone in the Developer Program, including Susan Prescott, Vice President of Worldwide Developer Relations, we were told there is no one we can speak to and no one we can email, and that the only option is a letter in the mail. Two support representatives did try to pass a message along, and we're grateful for that. We've heard nothing back, so far. We have been in the Developer Program for 15 years. That's $1,485 in program fees, before the Macs and iPhones it takes to build for this platform. Our release date was announced to the press and advertised at quite an expense; our TikTok release-date video is approaching 250,000 views, which may not seem big to one of the largest tech companies in the world but it is enormous for a studio our size. Press releases timed to the launch were ready to go. All of that is stalled, and the advertising money behind it is likely gone. This is our livelihood. It is the livelihood of every developer in those 12 threads, and of everyone else who have been waiting. We need our apps released on the dates we commit to, and we need to know whether the Developer Program is still a program for developers like us. If Apple is turning it into a program for the big publishers and the proven indies only, then tell us, so we can stop spending money on it. otherwise, please, we kindly ask that you review our apps, answer these threads, and turn the phones back on.

Hello, We would appreciate some guidance regarding an unexpected StoreKit currency result in a TestFlight build. Our iPhone language and region are both set to France. The Sandbox tester is also configured for France, and our subscription products have French availability and pricing configured in App Store Connect. In the TestFlight build we diagnosed, StoreKit reports the current storefront as France with EUR: storefront=FRA/143442/EUR However, all 10 subscription products are returned with USD product metadata: products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE Example: formatCurrency=USD locale=fr_US_currency_USD localeCurrency=USD display=1,99 $US price=1.99 We first observed this through Flutter's in_app_purchase integration. To determine whether the Flutter plugin was involved, we added a native StoreKit 2 diagnostic to the same TestFlight build. The native result was identical: receipt=sandboxReceipt storefront before=FRA/143442/EUR storefront after=FRA/143442/EUR products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE The issue appears specific to the TestFlight distribution. When the application is installed directly from the development computer, prices are returned in euros on the same device. We also tested with the regular Media & Purchases account signed out and a French Sandbox tester connected. Once the products loaded successfully, StoreKit still returned USD metadata. In another configuration, the application displayed the USD price while Apple's purchase sheet displayed the price in euros. We are using the price and formatting information returned directly by StoreKit. We do not want to infer the currency from the device region or perform a client-side currency conversion, because StoreKit should remain the authoritative source. Could you please help us understand: Is it expected for Storefront.current to report FRA/EUR while Product.priceFormatStyle.currencyCode, its locale currency, and Product.displayPrice use USD? Could a TestFlight or App Store Connect configuration cause product metadata to use a different currency from the current storefront? Is there another account, availability, pricing or distribution setting that we should verify? Is there a recommended way to refresh or invalidate the product metadata used by a TestFlight installation? We have already filed Feedback Assistant report FB24723329, which is currently under investigation. Thank you very much for any clarification or additional diagnostic steps you can suggest.

I currently have multiple macOS app icons configured in my project: AppIcon.icon AppIcon-Development.icon AppIcon-Beta.icon In Xcode, I can assign different app icons for Debug and Release configurations, which works well for local development and production builds. However, I cannot find any equivalent way to specify a dedicated app icon for TestFlight distributions. I would like TestFlight builds to automatically use AppIcon-Beta.icon. Where is this configured, or what is the recommended approach? Is there a specific build setting, archive configuration or App Store Connect mechanism for this, or do I need to handle it manually using build configurations or schemes? Thanks.

Hello, My app, Dungeon Crawl 94: What Was Taken, has remained in “Waiting for Review” since September 21, 2026. Apple Account of the App: 6802649282 Version: 1.0 Build: 5 Submission ID: 12b50a1f-29be-4d34-8498-0e4e0e359cd7 On September 28, Apple approved my request for an expedited review and confirmed that the submission would be expedited. However, the app has still not entered review. I also contacted App Review Status support on September 30 (Case ID: 102981140624), but the submission remains in “Waiting for Review” and I have not received a response. The game launched on Steam and Google Play on September 30 as part of a coordinated multiplatform release. The iOS version is now several days behind the other platforms. Could someone from the App Review team please check whether there is a queue or routing issue preventing this submission from entering review? If anything is required from me, I am ready to provide it immediately. Thank you for your help.

Hello! I am a new developer trying to launch my first app, and I am looking for some guidance or an internal escalation if a moderator is available. App Name: Nextsession App ID: 6811482002 Initial Submission Date: September 20, 2026 Latest Build Submission Date: September 29, 2026 Support Case ID: 102988060825 My initial submission was rejected with a request for video recordings and some additional information. I thoroughly compiled these materials. I also had to submit a new build to resolve a few minor bugs. I have attached the requested video recordings and fully filled out the App Review Information notes with the test credentials on the latest build. I also submitted an App Review Status Query but have not received a response. The app status has been stuck on "Waiting for Review" for nearly 10 days now. Because it is my first app, I want to ensure I haven't missed a critical step or if it is just stuck in a queue loop due to the new build upload. Any help or visibility from the moderation team would be greatly appreciated. Thank you!

Hello everyone, In our iOS app, we offer multiple auto-renewable subscription tiers within the same subscription group: Lite (Monthly / Yearly) Basic (Monthly / Yearly) Plus (Monthly / Yearly) Pro (Monthly / Yearly) We are using Apple's native Offer Code redemption sheet (SKPaymentQueue.default().presentCodeRedemptionSheet() / AppStore.presentOfferCodeRedeemSheet). The Issue We Are Facing: The user navigates to our subscription screen and selects the Pro Plan. The user taps our in-app "Redeem Offer Code" button, which presents Apple’s native redemption sheet. The user inputs an offer code that was created in App Store Connect specifically for the Basic Plan. When the user taps "Continue", Apple accepts the code and immediately presents the Apple Pay / Face ID confirmation to charge/subscribe the user to the Basic Plan. Because presentCodeRedemptionSheet() does not take any product ID parameter, Apple accepts the code for whichever product it was created for, regardless of the tier the user had selected on our paywall. By the time our transaction observer receives the transaction callback (paymentQueue(_:updatedTransactions:)), the payment/purchase has already been finalized by Apple. Questions: Can we restrict the native sheet to a specific Product ID? Is there any way with StoreKit 1 or StoreKit 2 to pass an expected productID to the redemption sheet so Apple only accepts codes eligible for that specific product? Can we intercept or validate the code before payment? Is there any delegate callback or hook when the user taps the "Continue" button on the "Redeem Offer" sheet so we can validate if the code matches the selected plan before the transaction is charged? What is Apple's recommended best practice? If a user redeems a code for a different tier (e.g., Basic instead of Pro), is the recommended approach to automatically switch and activate the redeemed plan on our backend since Apple has already completed the purchase, rather than rejecting it? Any guidance from Apple engineers or developers who have handled this multi-tier scenario would be greatly appreciated!

Xcode version 26.6 (17F113) MyOwnKeyboard-PAD app looks OK using simulator iPad Air 11-inch(M4). It automatically reformats to all orientations using only left and right landscape selected in General, Deployment Info. The submitted app 1.9 (4) had the portrait checked which was an error. I tried to update to version to 1.10 without portrait and upside down, but Validation states it must have all orientations needed. I tried setting all orientations and the simulator cuts off the sides. I am using a new mini M4 with Tahoe 26.6.2 Converted from an older developer mini using Migration Assistant. After conversion Xcode could not find xcspace files and apps locked up. I had to create new apps with different bundles which got conflicted in AppConnects causing rejects. When new versions are submitted, old versions cannot be removed because of submission states. Causing similar binaries, design and scam. I got trapped in the process! I have replied to AppConnect ref. binaries, design and scam. I hope someone can straighten this mess out. The good new is the free MyOwnKeyboard-PHONE analytics look OK with 4,000 impressions and 38 downloads and 172 product page reviews. It's a start! Thank you. Charlie Coupe Designer/Coder 2026sep16

With iPhone Duo media uploads now available in App Store Connect, what is the intended export format for App Preview videos of the outer (folded) and inner (unfolded) displays? The current screenshot specifications accept these portrait sizes: Outer display: 1398 × 2034 Inner display: 2007 × 2853 However, the App Preview specifications, the App Store Connect upload UI and the API's Duo preview specifications only list 886 × 1920 (portrait) or 1920 × 886 (landscape). These are much narrower portrait proportions than either Duo display. The documentation also labels the Duo device resolutions as having a 19.5:9 aspect ratio, which does not match the listed pixel dimensions. References: https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications https://developer.apple.com/help/app-store-connect/reference/app-information/app-preview-specifications What we tested on October 6, 2026, using recordings from the iPhone Duo simulator in Xcode 27.1: We uploaded two 30-second portrait previews preserving the captured display proportions: 1192 × 1734 for the outer display, and 1192 × 1696 for the inner display. Both uploads completed, but processing failed with POST_PROCESSING_FAILED. The API did not give a specific resolution error, so we cannot establish that dimensions alone caused these failures. As a diagnostic experiment only, we re-encoded the same footage to exactly 886 × 1920 with non-uniform scaling, deliberately stretching the image. Both H.264/AAC files, 30 seconds at 30 fps, were accepted, completed video processing without errors and could be assigned to the iPhone Duo preview group. In the App Store Connect editing interface, their thumbnails appear to be displayed at Duo-like proportions, visually masking much of the stretching. In App Store Connect's simulated App Store preview, the videos retain the narrow proportions of the 886 × 1920 file, and the distortion is clearly visible. This is an ASC preview observation, not a test of a published product page on a physical Duo. We have not submitted these experimental videos for review. What should developers do? Wait for App Store Connect to accept preview resolutions that preserve each Duo display's actual aspect ratio? Resize to 886 × 1920 by stretching the image, despite the resulting distortion? Preserve the original proportions inside an 886 × 1920 canvas by adding black bars? If so, is this padding acceptable for App Review, and is it the intended presentation? Filling the required frame by cropping would instead remove roughly a third of our captured interface's width, including important UI, so that is not a faithful representation either. Could someone from Apple clarify the intended export dimensions and aspect-ratio handling for BOTH displays, and whether the current preview specifications and the different ASC thumbnail/preview rendering are intentional? We would like to prepare faithful previews rather than distort or crop the app interface. Thank you!

Hello everyone, I am designing an in-app subscription and pass extension/upgrade system for an iOS app and want to ensure full compliance with App Store Review Guideline 3.1.1. Because pricing in our system depends on the user's historical purchase price rather than static store catalog prices, direct fixed-SKU purchases aren't sufficient on their own. Business Logic Overview Extensions: An extension costs 50% of the price the user originally paid for their plan. Example: If a user bought Plan A at $200, their extension cost is $100 (even if Plan A currently retails at $150). Upgrades: An upgrade charges the delta between the target plan's current price and the user's original purchase price. Example: A user bought Plan A for $200, and Plan B currently costs $250. The upgrade cost is $\max(0, 250 - 200) = 50$. Proposed Technical Solution User requests an extension or upgrade from the iOS client. The backend server calculates the exact delta amount based on user purchase history. The backend maps this calculated amount to a pre-defined Tiered StoreKit Product ID (e.g., com.app.tier_50). The iOS app receives the Product ID and executes the transaction via StoreKit 2 (Product.purchase()). The backend validates the transaction JWS signature with Apple and updates the user's access duration. Questions for the Community & Apple Engineers Has anyone implemented backend-resolved dynamic Tiered SKUs for top-ups or price deltas? Did this pass App Review without issues under Guideline 3.1.1? Are there recommended patterns when configuring price-point tier SKUs (Consumable vs Non-Renewing Subscription) in App Store Connect for variable delta payments? For auto-renewing subscriptions, is it preferred to handle extensions strictly via StoreKit 2 Promotional Offers rather than delta SKUs? Any feedback or real-world experience with similar pricing structures would be greatly appreciated!

Hi everyone, I'm hoping someone can shed some light on an App Review issue we're currently experiencing. We have submitted our Caffè Sabrina iOS app (version 1.0, build 5) for review. The app was previously reviewed by Apple and we were told that the demo account credentials we had provided were no longer valid. We immediately fixed this by creating a completely new demo account, testing it successfully, and updating the App Review information in App Store Connect. We then resubmitted the app. The submission has been sitting at “Waiting for Review” since Wednesday at 7:57 AM. The unusual part is that we have now requested expedited review twice, and Apple confirmed that the review would be expedited. However, the submission still hasn't moved to “In Review.” We've checked everything we can think of: Current build is correctly submitted. New App Review credentials have been tested successfully. App Review information has been updated. The latest build has been tested through TestFlight. The latest build has had installs and multiple sessions. There are no known crashes on the latest build. The current submission has not been cancelled or resubmitted again. We're now several days beyond the expedited request and are concerned that something may be preventing the submission from entering the review queue. Has anyone else experienced an expedited review being granted but the app remaining stuck on “Waiting for Review” for several days? If so, did Apple eventually move it into review automatically, or did you have to contact App Review again? Any advice would be greatly appreciated. Thanks, Michael Darling Tech Ltd

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?

I have an App Store version stuck In Review. I need to cancel / remove it from review so I can submit a newer build. I contacted Apple Developer Support. They said they cannot manually remove the app from review and that I have to cancel it myself. I have tried everything on my side: App Store Connect web UI → Remove this version from review / Cancel Submission App Store Connect on iPhone App Store Connect API (canceled: true on the review submission, and removing the submission item) Every attempt fails. In the UI I get errors like “An error has occurred. Try again later” / “Your changes could not be saved. Try again later.” Via the API I get HTTP 409 STATE_ERROR.ENTITY_STATE_INVALID (“Resource cannot be canceled at the moment, please try again later” / “Cannot remove item because of state of reviewSubmission”). The version stays In Review. I’ve reproduced this in Chrome and Safari, and on the phone app, plus the API so it doesn’t seem like a browser-only issue. Has anyone gotten past this when Support says you must cancel it yourself but Connect won’t let you? Any workaround, or is waiting for Apple the only option?

I have submitted a few 5 seconds length video, in Product Page Optimization/ Header 1 day has passed, it seems like the message "The poster frame for this file is processing." still appearing. The Product Page Optimization has submitted and pending for review. Is such a message "The poster frame for this file is processing." a concern? Thank you.

Hi, I'm a new Apple Developer program member and over about a 10-day period, I have been blocked from beta testing my app. I have been getting repeated 422's about a TestFlight Beta contract not attached to app 6812131455 . I submitted a Feedback Assistant ticket, FB24795679, where an engineer replied and said things were unblocked. I believe that I was able to get one more build uploaded after that but then the problem recurred and completely blocked me from sharing the TestFlight External beta link with new testers. I am uploading using the Transporter App and then trying to attach in Appstore Connect. I emailed Apple Developer support and they sent me only basic information about what 4xx HTTP status codes were, so I followed up via phone to Developer Support under ticket 102964195981. I've been calling over the past 3 days and a Senior Advisor has not picked up the ticket yet. Diagnostic information is below, including a sanitized HAR file. The error is reproducible, even with new builds, even with going through and confirming all requested data input fields are filled out and agreements are signed (to the best of my knowledge). I am developing an ad-free, free app with a focus on accessibility for the visually impaired. Can someone help me find a durable solution here? Much appreciated--I see others have had this issue. Happy to capture further debug logs to assist in a fix. captured_at_utc source build_number method url http_status error_code error_id x-apple-jingle-correlation-key x-apple-request-uuid x-responding-instance 2026-09-24T15:07:48.547415+00:00 live 116 POST /iris/v1/betaAppReviewSubmissions 422 ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING 7ef85ee6-412e-4535-b8f7-16cb8da406c8 5QSUAQZ4MOELPIGMJXUJD4UBP4 ec254043-3c63-88b7-a0cc-4de891f2817f ac-gateway-api:ac-gateway-api-main-5d674cb558-bp79n:ac-gateway-api-main-5d674cb558-bp79n:-1::::prod failures-422.md failures.jsonl failures.md session.sanitized.har

Hello, Currently, when users search for "Kuvy" in the App Store, our app does not appear in the organic results. Instead, the App Store triggers an automated spell-check prompt stating "Search for Kuvy instead" in the top-left corner. If a user manually clicks that small blue link, our app finally appears. The core issue is that some users miss this small prompt, assume the app does not exist, and abandon the download. This is hurting our user acquisition. "Kuvy" is our official, trademarked brand name and not a typo. I opened a ticket with Apple Developer Support on September 17th. It has now been nearly three weeks, and despite calling and messaging, I have only received generic responses stating that the issue has been "escalated to the engineering team." Has anyone else dealt with this specific search redirection bug, or is there a way to get an update from the engineering team to whitelist our brand keyword? Thank you.

When saving in-app events in App Store Connect, I am geting "Country or Region Availability couldn't be saved. Try again later. " Have tried many times. But still stuck there. Any idea? Thanks.

Submitted my third brand new on 15 Sep. Three weeks later it's still sitting in "Waiting for Review". Sent an expedite request on the 27th, heard nothing. By now the build in review is already pretty outdated, and I might have to wait another two weeks after sending the newer version. But I don't want to pull it and end up at the back of the queue. Anyone else seeing waits this long right now? And if it gets approved, does an update usually go through faster, or should I swap the build while I'm waiting?