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.

Hello, My app sat in "Waiting for Review" with no status change for over nine days, and I would appreciate any guidance on whether my submission is properly queued. Details: App ID: 6759439888 App name: PLUed Submission type: new app (first submission), submitted together with a first in-app purchase Original submission: August 19, 2026 Resubmitted: August 29, 2026 with a new build (1.0, build 82), in case the original submission was stuck Current status: Waiting for Review, unchanged; the build has never moved to "In Review" at any point What I have already checked: Agreements, Tax, and Banking are current with no pending items Export compliance answered (ITSAppUsesNonExemptEncryption declared in the build) App Privacy and age rating questionnaires complete Review notes include full access instructions for the reviewer The in-app purchase is attached to the same review submission (both items show Waiting for Review) No rejection, no Resolution Center message, and no request for additional information at any point Contacted Apple Developer Support — case ID 20000148679022, awaiting response The app is part of a coordinated September 1 launch and is already live on other platforms, so I am trying to determine whether this is normal queue depth for a first submission or a submission that is stuck. Could someone confirm whether this submission is queued correctly? Thank you. Clay

Hey, I have the following issue with my App Store Connect / Developer Account which prevents me from adding new apps. App Store Connect tells me there is a new license agreement available that needs to be accepted with the following message: The Apple Developer Program License Agreement has been updated and needs to be reviewed. In order to update your existing apps and submit new apps, the Account Holder must review and accept the updated agreement by signing in to their account. When I go to my Developer Account, there is no updated / new agreement available. It just shows my active and accepted agreement from August 18th. This is not a local caching issue. I had this issue for weeks now. I cleared my browser cache several times, I logged out and back in multiple times, I even tried different browsers and operating systems on different hardware (some of which I never used once to log in to my account before). I also know where and how to accept a new agreement in Developer Account as I did that recently on August 18th when an updated agreement actually was available. And this latest agreement shows as accepted in my Developer Account. But that didn't change a single thing on my App Store Connect status. It still shows the banner and tells me there is a new agreement available. I also have been in contact with support on this topic, but it's just frustrating. After weeks of explaining this over and over again, I'm still being told to clear my browser cache, to check if JavaScript is activated or to "just click on the yellow banner" to be redirected to the right section where I can accept the agreement. I am absolutely stuck with what I can do. I obviously don't know exactly how the backend on Developer Account and App Store Connect work and how data is synced between these two, but my take is that there is something preventing App Store Connect from correctly fetching the license agreement from Developer Account or some kind of data mismatch that throws an error in the background, because of the following: A few weeks ago I needed to update my company information (legal name and address). I've used the membership update form provided in Developer Account and the data had been updated a few days later in my Developer Account. However, App Store Connect still showed my old company data, with the old company name listed as the business entity. I reached out to support because of that for the first time and they escalated the case to the technical team to manually update the data in App Store Connect. They removed one of the old "deprecated" entities in App Store Connect and updated everything with the new data. My company information is now correct in both Developer Account and App Store Connect. However, since these changes were made, I am stuck with that banner in App Store Connect telling me that there is a new agreement available. My guess is that it has something to do with these manual changes from technical support. Some kind of orphaned database entry or a misassigned ID preventing the sync between App Store Connect and Developer Account. I have explained this over and over again to support, but it seems I can't get in touch with anyone who's willing to take a closer look at this.

Hello Apple App Review Team, We are urgently seeking assistance regarding our Apple Developer account. Our application was successfully reviewed and approved by Apple on August 23. Shortly afterward, however, the application unexpectedly became unavailable on the App Store, and access to important sections of App Store Connect, including Distribution and TestFlight, disappeared. We have not received a clear explanation of what caused this restriction. We immediately contacted Apple and opened Case ID 20000149095871, but more than 72 hours have now passed without a response or any information about the status of the case. We fully respect the App Store Review Guidelines and have always cooperated with the App Review team. In the past, when reviewers raised concerns, we communicated directly with App Review, clarified how our application works, and promptly made any requested changes. If there is currently an issue with our application or developer account, we are completely ready to cooperate, provide any information required, make any necessary corrections, or speak with the App Review team by phone. This situation is having a serious impact on our business and our users, while we currently have no information about what happened or what action is required from us. Could an Apple App Review staff member please check Case ID 20000149095871 and advise whether the case can be reviewed or escalated to the appropriate team? We would greatly appreciate any assistance. Thank you.

I am an account holder for my Team ID. I have paid Apple Developer Program too! Unfortunately, I see "Join the Apple Developer Program" and getting "Your Apple Account is already associated with the Account Holder of a membership." message. Also, I am getting "Unable to find a team with the given Team ID to which you belong. Please contact Apple Developer Program Support. https://developer.apple.com/support" error when I go to Certificates, IDs & Profiles. Help!!! Give me fix!!

Hello everyone, I've seen quite a few recent threads from developers stuck in long review queues, so greetings to all of you in the same boat. Our iOS app has remained in "Waiting for Review" since its initial submission, with no movement, feedback, or messages in App Store Connect. Timeline: Submitted: Aug 20, 2026 Submission ID: 8ae4090b-e099-4eb1-8868-fc34af838cb2 App ID: 6783428217 Current status: still "Waiting for Review" (9+ days) Steps already taken: Verified all agreements are accepted and there are no pending compliance items or messages on the submission Opened a support case on Aug 27 (Case ID: 20000148931150) — no response yet Filed an expedited review request, as our planned Aug 30 launch date is at risk We haven't received any rejection or request for additional information. Could the App Review team please check whether this submission is stuck in the queue, and advise if any action is needed on our side? Has anyone made it through a similar delay recently? What ended up unblocking it for you? the support case, an expedited request (if you had a planned release date?), or posting here? I'll keep this thread updated with every step we take and every response we get, so others hitting this have a reference.

I'm trying to submit my app's first-ever subscriptions for review, and I'm stuck in a loop between two different App Store Connect submission flows that seem to conflict with each other. Setup: App: HeyFlat (bundle au.com.heyflat) Subscription group "HeyFlat Casa" with 3 auto-renewable subscriptions (monthly/semiannual/annual), all status "Ready to Submit" App version 1.0 has been rejected multiple times (most recently for Guideline 2.1(b) — "In-App Purchase products have not been submitted for review") What I've tried: On the Subscriptions page, I click "Add for Review" on the subscription group → it opens a "Draft Submission" panel (breadcrumb "Submissions") listing the group as an item ready to submit. That panel shows: "Unable to submit for review — Add an app version for the selected platform." I uploaded a brand-new, never-before-submitted build (build 31, version 1.0) via CI and manually attached it to the App Store version page (Distribution → App Store Version 1.0 → Build). Went back to the Draft Submission — same error persists, plus a new one: "New subscription groups must be submitted with an auto-renewing subscription from that group." The item listed is just the subscription group itself, not the individual subscriptions. Separately, the legacy per-version thread (App Review → iOS Submission) now shows build 31 as "Ready for Review" — but that thread only lists 1 item (the app version itself), no subscriptions attached, even though they're marked "Added for Review." So I have: a subscription group with 3 ready subscriptions, and a fresh unreleased build attached to the app version — but no path in the UI actually lets me submit them together. This exact same "In-App Purchases not submitted" rejection has now happened twice, with the subscriptions in this same "ready" state both times. Has anyone run into this specific mismatch between the "Submissions" draft flow and the legacy per-version "App Review" thread? What's the correct way to get a first-time subscription group submitted alongside an app version right now?

My first app submission has been in "In Review" since August 19, 2026 at 08:56 (CEST) — 9 days now, with no status change and no message of any kind. Details: Apple ID: 6799895164 Version: 1.0 (build [1]) Submission ID: 412ca140-f582-42a5-9714-e50a254e260b Platform: iOS Submitted: August 18, 2026 In Review: August 19, 2026 at 08:56 (CEST) The submission contains 1 app version and 3 in-app purchases: 2 auto-renewable subscriptions and 1 non-consumable lifetime unlock. All items show as included in the submission. Everything on my side appears complete: review screenshots for each IAP, price schedules, localizations, privacy policy URL, EULA, age rating declaration. Restore Purchases is implemented and visible on the paywall. Account status: Paid Applications Agreement: [Active] Digital Services Act trader status: [Verified] MRDP compliance: [Active] Bank and tax details: [Active] There is no rejection, no request for additional information, and nothing in Resolution Center. A support case is open as well. I have seen several recent threads describing the same pattern — in some cases requiring someone at Apple to move the IAP status forward on the backend. Could someone from App Review please check whether this submission is progressing normally, or whether something on my side is blocking it? Happy to provide any further details. Thanks in advance.

Hello Apple Developer Community, I am experiencing a TestFlight issue with my iOS app and would appreciate any guidance. App Information: App ID: 6801854699 Bundle ID: az.idrak.liseyi App Version: 1.0.9 (14) Platform: iOS Team ID: W24294ZD96 Apple Developer Program membership: Active until December 11, 2026 Free Apps Agreement: Active Paid Apps Agreement: Active Issue: I uploaded build 1.0.9 (14) to App Store Connect using Codemagic. The build processes successfully and appears in the internal testing group. However, when an internal tester opens TestFlight and attempts to install the app, TestFlight displays: “The requested app is not available or doesn't exist.” At the same time, Codemagic reports the following API error: POST betaAppReviewSubmissions returned 422: Beta contract is missing for the app App Store Connect also previously displayed a message saying that I needed to renew my Apple Developer Program membership when attempting to create an external testing group. However, my membership is active until December 11, 2026, and all required agreements are active. Steps to reproduce: Upload build 1.0.9 (14) to App Store Connect using Codemagic. Wait for the build to finish processing. Add/select the build for TestFlight internal testing. Open TestFlight on an iPhone using an internal tester account. Attempt to install the app. TestFlight displays: “The requested app is not available or doesn't exist.” Codemagic reports: “Beta contract is missing for the app.” This issue appears to be related to a backend synchronization or Beta Contract problem. Apple Developer Support has already escalated this case to their technical team under case number 20000139248466. Has anyone experienced the same Beta Contract / TestFlight availability issue, or knows how this can be resolved? Thank you.

Hi all, My app has been stuck in the "Waiting for Review" status since August 13 (US Time), and today is August 23. It has been 10 days without any status updates or messages from the App Review team. App ID: 6800282515 Submission Date: Aug 13, 2026 Developer Support Request Submitted: Aug 19 (No response yet) Expedited Review Requested: Aug 20 (No response yet) Current Status: Waiting for Review Since both support inquiries and expedited requests haven't received a reply after several days, I am concerned there might be an internal system hold or communication breakdown regarding this submission. Could someone from Apple please look into this or advise if any additional documentation/action is needed from my side? Thanks for your help!

Hello, Our app has been in "Waiting for Review" since August 18, 2026 at 6:51 PM, and has never entered "In Review." It has now been 10 days. Apple ID: 6768989011 Version: 1.0 Platform: iOS Submitted: August 18, 2026 Current Status: Waiting for Review I have already confirmed the following on our side: No messages or requests for additional information in Resolution Center Agreements, Tax, and Banking are all Active Age Rating questionnaire and Export Compliance are complete App Review Information includes demo credentials and detailed review notes No in-app purchases pending review I understand review times can vary, and I can see from recent posts in this forum that other developers are experiencing similar delays with first submissions. Could someone from the App Review team please check whether this submission is progressing normally, or escalate it if necessary? Thank you for your time.

Hello, Could App Review please confirm the submission is still progressing? App: GrapeMap: Winelands Guide Apple ID: 6802603098 Submission ID: 43018af6-1ff8-43c7-9831-d10f95837a1f 18 Aug - Submitted (v1.0, new app); received Guideline 2.1 Information Needed same day 19 Aug - Replied with all seven requested items, including a screen recording from a physical device; demo credentials are in App Review Information 26 Aug - Sent a follow-up; no response or status change since 19 Aug Free travel guide app, no purchases or regulated activity. Thank you, Riaan Theron

Submission ID: 4f64fd8d-529d-4829-9f29-07bbc53b3afb · Review date: August 26, 2026 · Version 1.0 (47) I never wanted to build a dating app. I wanted to build the thing I couldn't find: a place where you say what you're actually looking for, a partner, a friend, someone to travel with, people for a Tuesday-night board game, and see the people who are looking for the same thing. Not a deck of strangers dealt to me by an algorithm that profits from dealing slowly. My name is Gleb and for the past 13 months, in Barcelona, with my partner, who did the art direction, I built Tekero. No investors. No revenue. Nothing to monetize. I haven't built a paywall, because the first thing I'd have to sell is the thing every other app sells: your loneliness, rationed back to you. Here's what's different, and why it's different: Every mechanic in Tekero is aimed at a specific thing that hurts people. Ghosting: if you're sitting on a pile of likes you haven't answered, you drop out of the feed. Why should you be shown to more people when you're not responding to the ones you have? Inbox overload: your active chats are capped. Want a new conversation? Finish an old one, or keep it deliberately by adding that person as a friend. The app only unlocks that once you've built up friendship progress, a separate feature that measures how much two people (or more, in a group chat) have actually said to each other. Pay-to-reveal-likes: gone. Every like arrives openly, immediately, free. No slot machine. Both sides filter each other, the person who posted the announcement and the person browsing. So anything you see in the feed is someone who was also looking for you. Couples and friends can browse together and post together, because meeting people doesn't stop being useful once you've met someone. There's a trust score that costs you points for treating people badly: ignoring them, being toxic, attempting screenshots of private data (chat messages or private photos). It gives you points for treating people well, for communicating, for making friends. Screenshotting a private photo isn't a clever move here: it saves a black frame, sends a notification to the person you betrayed, and raises a ticket on the reports desk, which can lead to a block if the trust score is already low. The blank first message: most apps hand you a stranger and a cursor. Tekero gives you openers, including one called Game, where you both answer three psychological questions and start from something real instead of "hey". The first exchange is designed to be worth having, not to be survived. The dropdown that doesn't fit you: most apps give you two options and call it a profile. Tekero gives you 72 non-binary gender identities alongside the binary ones, the full range of orientations rather than the four everyone ships, and gender expression as a separate field: feminine, masculine or androgynous. How you present isn't the same question as who you are. This isn't a diversity checkbox. The whole app runs on both sides filtering each other honestly, and filtering can only be as true as the vocabulary people are given to describe themselves. Precision here isn't decoration, it's what makes the matching real. In Tekero, we want everyone to be themselves. I gave it to testers. It's hard to recruit them while the app is TestFlight-only, people aren't keen on multi-step installs. Still, apart from minor improvement requests that I resolved as they came in, testers were genuinely excited about the mechanics. The two things I heard most often: Tekero reinvents dating and It's not just dating AppStore Connect Submission Last week Apple rejected it under Guideline 4.3(b): my app "primarily includes dating features that duplicate the content and functionality of similar apps that are already widely available," and "there are already enough of these apps on the App Store." The same letter also states that my app "may include features or characteristics that distinguish it." Taken together, those two statements suggest the distinguishing features weren't assessed against the standard, and that assessment is what I'm asking for. In June, Apple rewrote that guideline to name dating outright: no new submissions unless they offer a "meaningfully different or improved experience." That test has two limbs, and the second one is "improved". Tekero isn't a variant of what's already there. Every mechanic above exists because something in the current experience is failing the people using it. I'm not asking for an exemption from the rule. I'm asking for the half of it that says "improved." What's next The appeal is with the Review Board. Get familiar with Tekero here, if interested: tekero.io, there's a walkthrough video on the site (posting the address as plain text, since external links aren't permitted here). If you've gotten out from under 4.3(b) — I'd really like to know how.

Hello, I am new for apple developer. I see the problem and I think apple show me very few error message and I do not know to start with it. I was created my app by python and build to .app then package it to pkg by the pkgbuild. I have problem to upload the pkg file to app store connect by transporter both CLI and GUI. when I try to upload it by GUI, I see this message. Cannot find the ITMSP file: (null). (11)` and when I upload my pkg by the CLI, I found more message but still cannot start with it as well. [2026-08-23 09:57:58 ICT] <main> DEBUG: Registered file for monitoring: /Users/xxxxxxxxx/.itmstransporter/temp/tx-xxxxxxxxx.pkg-swinfo.plist16166255377348903097.tmp with action CANCEL_ALL [2026-08-23 09:57:58 ICT] <main> DEBUG: Started file monitor for 1 file(s) [2026-08-23 09:57:58 ICT] <main> INFO: Starting upload for package b7ac46de-45fe-4fa6-b0f6-6fea35038d8f-tx-xxxxxxxxx.pkg-swinfo.plist16166255377348903097.tmp. [2026-08-23 09:57:58 ICT] <main> INFO: Computing total size of files to upload ... [2026-08-23 09:57:58 ICT] <main> DBG-X: adding file for % complete logging: tx-xxxxxxxxx.pkg-swinfo.plist16166255377348903097.tmp , size: 7704460 [2026-08-23 09:57:58 ICT] <main> DEBUG: Setting total size of files for upload to: 7704460 [2026-08-23 09:57:58 ICT] <main> INFO: Done computing total size of files to upload. [2026-08-23 09:57:58 ICT] <main> INFO: Starting checksum calculations for 1 file(s) using up to 1 thread(s)... [2026-08-23 09:57:58 ICT] <main> INFO: Checksum calculations are complete, elapsed time: 0 d 0h 0m 0s. [2026-08-23 09:57:58 ICT] <main> INFO: Creating reservations for build upload: b7ac46de-45fe-4fa6-b0f6-6fea35038d8f [2026-08-23 09:57:58 ICT] <main> DEBUG: creating upload file... [2026-08-23 09:57:58 ICT] <main> DEBUG: SMART-CLIENT: getCurrent(); using pinned data center = contentdelivery01.itunes.apple.com [2026-08-23 09:57:58 ICT] <main> INFO: Package upload progress: 0.00% completed [2026-08-23 09:57:58 ICT] <main> INFO: Transfer Metrics Summary: [2026-08-23 09:57:58 ICT] <main> INFO: bytes transmitted: 0 [2026-08-23 09:57:58 ICT] <main> INFO: tx-xxxxxxxxx.pkg-swinfo.plist16166255377348903097.tmp transfer metrics: [2026-08-23 09:57:58 ICT] <main> INFO: bytes transmitted: 0 [2026-08-23 09:57:58 ICT] <main> INFO: Starting checksum calculations for 1 file(s) using up to 1 thread(s)... [2026-08-23 09:57:58 ICT] <main> INFO: Checksum calculations are complete, elapsed time: 0 d 0h 0m 0s. [2026-08-23 09:57:58 ICT] <main> INFO: Creating reservations for build upload: b7ac46de-45fe-4fa6-b0f6-6fea35038d8f [2026-08-23 09:57:58 ICT] <main> DEBUG: creating upload file... [2026-08-23 09:57:58 ICT] <main> DEBUG: SMART-CLIENT: getCurrent(); using pinned data center = contentdelivery01.itunes.apple.com [2026-08-23 09:57:59 ICT] <main> DEBUG: Stopped file monitor [2026-08-23 09:57:59 ICT] <main> DEBUG: Transport HTTP failed after 0 bytes, trying next transport. Error: could not upload file: tx-xxxxxxxxx.pkg-swinfo.plist16166255377348903097.tmp [2026-08-23 09:57:59 ICT] <main> DEBUG: Upload phase transition: CLOSED -> INITIAL [2026-08-23 09:57:59 ICT] <main> ERROR: All transport types failed for file: tx-xxxxxxxxx.pkg-swinfo.plist16166255377348903097.tmp Package Summary: 1 package(s) were not uploaded because they had problems: /Users/xxxxxxxxx/xxxxxxxxx/../xxxxxxxxx_Image/xxxxxxxxx.pkg - Error Messages: All transport types failed for file: tx-xxxxxxxxx.pkg-swinfo.plist16166255377348903097.tmp [2026-08-23 09:57:59 ICT] <main> DBG-X: Returning 1 Not too sure if anyone ever see my issue and how you solved it?

Hi! I currently have a web extension sucessfully published to Firefox. And now I'm trying to make the same web extension available for Safari. But I am having some trouble. Steps to reproduce this issue: Through appstoreconnect I create a new app. Within the app I select the tab Xcode Cloud, and scroll down to the Safari Web Extension Packager. When I try to upload a .zip file of my extension I get the error message: "NetworkError when attempting to fetch resource." According to the docs this upload feature should be compatible with any browser. I'm using Firefox version 154 running on Linux Mint 22.3. Note to forum admins: I originally tried to post this under subtopic Web Extensions but for some reason I kept getting an error when hitting "Post". That's why I'm posting this issue under the sub-topic General.

Hello Apple Team, We are seeking assistance regarding our app 健康行動go (App ID: 1437488996, Case ID: 20000146721382). Timeline: August 14: We received feedback regarding Guideline 4.3(a). August 21: We resolved the issues by providing detailed business differentiation, UI comparison documentation, and submitting an updated build. Status: The submission has remained in "Waiting for Review" since August 21. Today, August 27, 2026, is our scheduled public release date with external commitments. Could an Apple representative please check if our submission is held in a specialized queue and assist in escalating it to the App Review team for review? Thank you very much for your time and support.

I’m trying to determine the supported submission path for the first non-consumable IAP in a watchOS-only app. Configuration The app uses a standard watch-only container: Container: com.seanfu.safe Watch app: com.seanfu.safe.watchkitapp ITSWatchOnlyContainer = true WKWatchOnly = true WKApplication = true It offers one non-consumable “Full Version” unlock and uses StoreKit 2: Product.products(for:) Product.purchase(options:) Transaction.currentEntitlements Transaction.updates The product ID in the Release binary exactly matches App Store Connect. Paid Apps agreements, banking, tax, pricing, and territory availability are active. The Release archive contains no local .storekit configuration or test bundle. TestFlight works, but App Review receives no product In TestFlight, using the real App Store sandbox and App Store Connect product configuration, Product.products(for:) returns the correct product, localized price, and title. The purchase sheet can be presented. During App Review, the same request repeatedly returns an empty array without throwing an error. The reviewer sees this application-defined diagnostic: IAP-L-01(empty x5) This is not an Apple or StoreKit error code. It means: Five separate Product.products(for:) calls completed without throwing. Every call returned an empty product array. The diagnostic appears only after the initial request and limited retries are exhausted. Thrown StoreKit errors use different diagnostics. The app does not locally filter a successfully returned product. Therefore, the screenshot means StoreKit returned no matching product in five consecutive requests. This has happened in multiple review attempts, while the same Release code path works in TestFlight. An App Review representative contacted us and explicitly stated that a watchOS-only app can be reviewed and tested with IAP. They suggested investigating our StoreKit integration, but our audit found no code path that could transform a non-empty response into this diagnostic. Submission behavior changed Earlier watchOS-only builds could be submitted with both: The app version The “Full Version” IAP Those submissions reached App Review, where the product was empty: Submission accepted → Review starts → Product array is empty For build 23, we explicitly added the In-App Purchase capability to the Watch target in Xcode. The project now records the IAP capability and explicitly links StoreKit.framework. This did not add an IAP entitlement to the signed app. The bundle IDs, watch-only packaging, product ID, StoreKit code, pricing, availability, agreements, banking, and tax status remained unchanged. After uploading build 23, App Store Connect no longer allows the app version and IAP to be submitted together. The draft contains: iOS App 1.0, build 23 The “Full Version” non-consumable IAP App Store Connect blocks the submission and says IAPs and subscriptions are not supported on Apple Watch and must be removed from the submission. The behavior is now: App version + IAP selected → Submission blocked before review This timing does not prove that adding the Xcode capability caused the change. App Store Connect may have changed its validation, or the new build may have caused its watch-only classification to be reevaluated. However, the transition is notable: earlier submissions were accepted but the product was unavailable during review; the current submission is blocked entirely. Contradictory documentation StoreKit documentation says the Swift IAP API is available on watchOS 8+: https://developer.apple.com/documentation/storekit/choosing-a-storekit-api-for-in-app-purchases The documentation for purchase(options:) specifically says to use it for apps running on watchOS: https://developer.apple.com/documentation/storekit/product/purchase(options:) However, App Store Connect documentation says IAPs are not supported on Apple Watch and must be removed before submitting an Apple Watch app version: https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/submit-an-in-app-purchase/ The same page says the first non-consumable IAP must be submitted with a new app version. This creates a circular requirement: The first non-consumable IAP must accompany an app version. An Apple Watch app version cannot include an IAP. A watchOS-only app therefore appears unable to submit its first IAP. Questions What is the supported path for submitting the first non-consumable IAP of a watchOS-only app? Can Apple review the first IAP separately, or apply a backend override, despite the requirement to include it with an app version? Is an iPhone companion app required, with watchOS IAP support intended only for Watch apps associated with a regular iOS app? Could the unsupported submission association explain why TestFlight sandbox returns the product while App Review receives an empty array? Why were earlier watchOS-only submissions accepted with the IAP attached, while build 23 is blocked despite unchanged bundle IDs and watch-only packaging? Does App Store Connect use the Xcode IAP capability or explicit StoreKit linkage when validating the submission? Clarification from a StoreKit or App Store Connect engineer would be greatly appreciated. The StoreKit documentation, App Store Connect validation, and guidance from App Review currently describe different behaviors.

Hi everyone, I submitted my new dating app and requested an expedited review because we have a launch event planned in a couple of days. Apple accepted the expedited review request, but the app is still “Waiting for Review.” If it isn't reviewed in time, we'll unfortunately have to cancel or postpone the event. Does anyone know if there is a way to contact the App Review team or a reviewer directly, or an email/support channel I can reach out to about the status of an already-approved expedited review?£ Thanks!