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, Our first submission was previously reviewed and we received feedback under Guideline 2.1 because the reviewer was unable to access the app due to a forced update issue. We fixed the issue completely, uploaded a new build, and resubmitted on Friday. The submission has now been in Waiting for Review for approximately 4–5 days with no further messages or requests. Could someone please confirm that the submission is correctly queued and that nothing else is required from our side? App: KIBAKI: Persian Community Submission ID: d1f921a3-9001-4ef2-a392-657860c437cd Current status: Waiting for Review Thank you.

Hi everyone, We are experiencing an App Store Search query interpretation issue affecting our app, Afizzy. In the U.S. App Store, when a user searches for the exact app name “afizzy”, the App Store displays: “Showing results for frizzy” and provides “Search for afizzy instead?” as a separate option. The search field itself continues to display “afizzy,” so this does not appear to be device-level keyboard autocorrection. Instead, the App Store search results page is interpreting the submitted query as a different term. This is also not a ranking issue. The query substitution occurs before results for the exact term “afizzy” are displayed. We have already contacted Apple Developer Support and submitted this issue through Feedback Assistant: Developer Support Case: #102970470188
Feedback Assistant: FB24936985 We can consistently reproduce the issue on the U.S. storefront, and we have provided a screenshot showing the behavior. Has anyone encountered a similar issue where the App Store automatically rewrites an exact app or brand name to another term? If so, was there a particular process or Apple team that helped correct the search interpretation? We would greatly appreciate any guidance from Apple engineers or developers who have encountered a similar case. Thank you!

Hello App Review Team, I’m following up regarding our latest submission, which is currently in Waiting for Review. We have addressed the issues identified in the previous review and submitted a new build with the necessary fixes. We also submitted an expedited review request because we are hoping to make the updated version available to our users as soon as possible. Could you please check the status of our submission and let us know if anything else is required from our side? Thank you very much for your time and consideration. Best regards, Ninja Rift Team

Hello, I’m looking for clarification and guidance regarding a recent App Store Connect upload validation change that is preventing us from delivering an important bug-fix update to existing users on legacy iOS versions. Our production iOS app has historically supported iOS 11 and later. On August 28, 2026, we successfully uploaded a build with: MinimumOSVersion = 11.0 The upload completed successfully, with warnings only. One of the warnings stated: “MinimumOSVersion too low. This app has a MinimumOSVersion of 11.0. Starting later this year, all iOS apps must have a MinimumOSVersion of 13.0 or later in order to be uploaded to App Store Connect or submitted for distribution.” No specific enforcement date was provided. The same upload also displayed another warning stating: “Starting in Spring 2027, all iOS apps must have a MinimumOSVersion of 15.0 or later…” We subsequently uploaded another build targeting iOS 11 around September 8, and that version was successfully released on the App Store on September 10, 2026. I no longer have a screenshot of the warning from that particular upload, but the build itself was accepted and the corresponding version was released successfully. However, on September 17, 2026, when attempting to upload our next bug-fix build with the same MinimumOSVersion of 11.0, Apple’s server-side validation rejected the build with: Error 90068 “This bundle is invalid. The value provided for the key MinimumOSVersion '11.0' is not acceptable.” This means that the server-side enforcement appears to have changed sometime after our successful upload around September 8 and before September 17. What is especially confusing is that: the previous warning only said that iOS 13 would become mandatory “later this year”, without providing a specific enforcement date; iOS 11 builds were still being accepted in early September, including the build that was released on September 10; the same validation dialog stated that iOS 15 would become mandatory only in Spring 2027; the upload now fails completely before the build reaches App Store Connect or TestFlight. Because validation fails during upload, we cannot submit this build to App Review or request an expedited review. We have already completed a final bug-fix release for our existing legacy iOS users. Our intention is not to continue supporting iOS 11 indefinitely. We plan to increase the minimum supported iOS version after this release. We are only trying to deliver one final bug-fix update to users who already have the application installed on legacy iOS versions. The fix is ready, but affected production users currently have no way to receive it. I opened Apple Developer Support Case ID 102966589079 on September 17, 2026 and sent a follow-up on September 21. So far I have only received automated acknowledgements. The Developer Support case history also shows: “Email with Apple Developer Support — September 19, 2026” but I did not receive any email from Apple on that date. I checked Inbox, Spam/Junk, and Trash. Phone support for this case currently shows: “Phone support is currently unavailable due to high call volumes.” I have attached screenshots showing: the successful August 28 upload with the iOS 13 / iOS 15 warnings; the current Error 90068 rejection; the support case history. Could Apple please clarify: On what exact date did the MinimumOSVersion 13 requirement begin being enforced? Was this enforcement date announced anywhere before it became a hard upload requirement? Is there any supported way to upload one final bug-fix build for existing legacy iOS users? Could Case ID 102966589079 please be routed to the appropriate App Store Connect / Distribution team? Thank you.

Hi there, Recently I've created a beautiful drink logging app, Abvy. You log what you drink and it shows an estimate and a possible range of the alcohol in your system over the evening. It has plenty of disclaimers that the measurements are only estimates and to never use them for driving decisions Since 26 August I've had the same rejection six times: "marketed as a blood alcohol content calculator but does not have associated hardware... apps that rely solely on software... are not appropriate." Meanwhile Beta App Review approved all the builds submitted. I had an App Review appointment today. The rep read the same paragraph back to me and said to appeal, which I've done. It was really frustrating. The published 1.4 doesn't mention blood alcohol at all, and university and public-health apps with the same kind of estimate are on the store today (Stay in the Blue from the University of Michigan, Virtual Bar from the Foundation for Advancing Alcohol Responsibility). Not to mention dozens of other, apps who do the exact same thing but are approved. Has anyone actually got past this on the App Store side? What changed for you? What can I do to fix this? Really care about Abvy and think it's an amazing app.

SUMMARY TestFlight installation and external beta review submission are blocked for ITNRY. External submission returns ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING through both the App Store Connect website and the public App Store Connect API. Apple Developer Support case: 102968975728 Submitted: 19 September 2026 I have not yet received a response. APP AND BUILD DETAILS App: ITNRY: Private Trip Planner App Store Connect app ID: 6747810116 Bundle ID: com.c0defr1ft.ITNRY Version 5.5, build 1: Build ID: ace0e146-a828-49cd-8773-351f12dfc4b0 buildAudienceType: APP_STORE_ELIGIBLE processingState: VALID expired: false Version 5.5, build 2: Build ID: 4cb01458-8df0-44f5-810c-5a9769a2980d buildAudienceType: INTERNAL_ONLY processingState: VALID expired: false The external review submission described below uses build 1, NOT the internal-only build 2. STEPS TO REPRODUCE — APP STORE CONNECT Open ITNRY → TestFlight. Add version 5.5, build 1 to an external testing group. Complete the requested test information. Select Submit for Review. Actual result: “There was an error processing your request. Please try again later.” The failed network response contains: HTTP 422 ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING “Beta contract is missing for the app.” STEPS TO REPRODUCE — PUBLIC API Send an authenticated request to: POST https://api.appstoreconnect.apple.com/v1/betaAppReviewSubmissions Request body: { "data": { "type": "betaAppReviewSubmissions", "relationships": { "build": { "data": { "type": "builds", "id": "ace0e146-a828-49cd-8773-351f12dfc4b0" } } } } } Actual response: HTTP 422 { "errors": [ { "id": "d916bbd9-4cff-4a05-8f0c-7432ec8db5d3", "status": "422", "code": "ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING", "title": "Beta contract is missing for the app.", "detail": "Beta Contract is missing." } ] } Request ID: EYMVAZWCULILULIFKLQDUQ5DXI Timestamp: 19 September 2026, 17:32:43 UTC ADDITIONAL SYMPTOM — INTERNAL TESTFLIGHT The build is visible in TestFlight, but installation fails with: “The requested app is not available or doesn’t exist.” The iPhone’s Media & Purchases account matches the account assigned as an internal tester. TestFlight has also displayed an old email address previously associated with the same Apple Account. It is unclear whether this is related to the contract error. DIAGNOSTIC CHECKS ALREADY COMPLETED GET /v1/apps/6747810116/betaLicenseAgreement returns HTTP 200 and the following betaLicenseAgreements resource: 8289bafa-8347-4a7a-a2b4-86b580758220 Listing betaLicenseAgreements filtered by this app also returns that resource. Its agreementText was initially empty. As a troubleshooting attempt, I successfully populated it through the API and verified that the change persisted. External submission still returned the identical BETA_CONTRACT_MISSING error afterward. This establishes that the per-app betaLicenseAgreement resource exists. It does not establish whether that resource is the contract referenced by the submission error. EXPECTED RESULT An authorized internal tester should be able to install the assigned build. An eligible external build should submit for beta review, or App Store Connect should identify a specific outstanding requirement and provide an actionable way to resolve it. IMPACT AND REQUEST The issue blocks TestFlight installation and external beta review submission. Please investigate the contract validation/provisioning state for this app/account, identify which contract is reported missing, and advise whether any developer action is required. Please also determine whether the internal installation failure shares the same cause. Please link this report to Developer Support case 102968975728.

I have a very embarrassing problem. that I can't transfer my macOS app to another account. and above is wrong picture. I already tried to delete the apps group. but it doesn't work. this transfer is very important for our team. if anyone can tell me how to do, I will be very grateful.

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

Hi, Since mid-September 2026 TestFlight is completely blocked for my account, even though my app is live on the App Store and all agreements are active. Symptoms No tester (internal or external) can install any build. TestFlight shows: "Could not install Beavo. The requested app is not available or doesn't exist." A newly added internal tester sees "No Builds Available" in App Store Connect. Submitting any build to Beta App Review fails with HTTP 422: { "errors" : [ { "status" : "422", "code" : "ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING", "title" : "Beta contract is missing for the app.", "detail" : "Beta Contract is missing." } ] } Request UUID: 911b4c7a-1c7f-5b75-5c49-bcf26292fb18 (24 Sep 2026, 16:16 GMT) What I've verified Paid Apps Agreement: Active (Jun 2026 – Jun 2027) Free Apps Agreement: Active (regenerated Aug 19, 2026) Bank account, W-9 tax form and DSA compliance: Active I'm the Account Holder / Admin Builds (1.4.0 (13) through 1.5.0 (20)) are VALID, not expired, min iOS 26.0 ITSAppUsesNonExemptEncryption = NO is in Info.plist (no Missing Compliance) Test Information complete (description, feedback email, marketing and privacy policy URLs, Beta App Review contact) The last builds approved for external testing were in July 2026; nothing since then can be submitted This looks like the same backend issue reported in threads 814565 and 815885, where the Beta Contract entity was not re-provisioned after the agreements were regenerated, and it was fixed by an Apple engineer manually. App details App: Beavo – Apple ID 6781859321 Bundle ID: com.invntio.beavo Team ID: P4C48NFAHR I've also opened a case with Developer Support. Could someone from Apple please re-provision the Beta Contract for this account/app? Thanks!

I'm hoping someone from Apple engineering can help, as support tickets and callbacks have not resolved this issue. The problem: My app "Brutal Time - Typographic Clock" does not appear in App Store search results at all — not even when searching for its exact name "Brutal Time." This has been ongoing for over six weeks. Additionally, the app does not appear in Apple Search Ads when I try to set up a campaign — suggesting this is a backend indexing issue, not a ranking issue. Timeline: Dec 17, 2025: App launched, initially searchable Dec 31, 2025: Transitioned to freemium model, became invisible in search. Jan 5, 2026: Fixed the issue, submitted update (v2.02), approved same day Jan 14, 2026: Submitted metadata update (v2.03) to improve discoverability, approved same day Feb 8, 2026: Tried removing from sale and re-adding to force re-index — no effect Feb 10, 2026: Still not appearing in any search results What I've tried: Submitted multiple support tickets (most recent: Case #102797235758) Each ticket generates an automated reply stating Apple will respond within 2 business days — they never have Requested and received callbacks multiple times, was told it would be escalated to US engineering team. But no follow-up, no resolution, no explanation Removed from sale and re-added to attempt to force re-indexing — didn't work App shows "Ready for Distribution" in App Store Connect Direct link works fine: https://apps.apple.com/us/app/brutal-time-typographic-clock/id6756289461 Response from Apple Support: "The behavior you observed is expected. App Store charts and search results change regularly and we don't guarantee app placement." This response misses the point entirely. I'm not asking about rankings — I'm asking why the app is completely invisible in search, including for its own branded name. This is not an isolated issue. Other developers have reported the same problem with the same non-response from Apple: https://developer.apple.com/forums/thread/803937 https://developer.apple.com/forums/thread/73981 https://developer.apple.com/forums/thread/74110 Has anyone found a resolution? Is there any way to trigger a proper re-index, or escalate to someone who can actually investigate?

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?

Hello Apple App Review team and fellow developers, I’m looking for some guidance regarding a Guideline 4.3(b) rejection for my app, VIVA Khoja. VIVA Khoja is not intended to be a general-purpose dating app. It was created specifically for the Khoja Shia Ithna-Asheri community, a relatively small and geographically dispersed community worldwide, with the goal of helping members find serious matrimonial connections within their community. We have invested several months of work, significant development time, resources and money into this project. The app was initially rejected under Guideline 4.3 earlier this year, around June. Following that feedback, we did not simply resubmit the same product. We spent months substantially improving and differentiating the application, its onboarding, its features and the overall matrimonial experience. Among other things, VIVA now includes: A limited number of profiles presented per day instead of unlimited swiping A structured Send Interest process instead of a casual swipe-based experience Mandatory identity/profile verification A dedicated focus on serious matrimonial introductions within a defined community Community-specific profile and compatibility information A dedicated matchmaker interface, allowing matchmakers to participate in the matrimonial process The possibility for users to display testimonials/recommendations from relatives or trusted people directly on their profile, adding a family and community dimension that is very different from a conventional dating app One aspect of the latest review was particularly confusing for us. The app remained in Waiting for Review for a relatively long period. When we eventually received the notification indicating that the app was being reviewed, the rejection followed only a few minutes later. Because of how quickly this happened, we checked our own application/server activity to better understand the review process. Based on the information available to us, we could not identify evidence that the reviewer had gone through the application or tested the main features during that review window. I completely understand that Apple reviewers may have internal tools or review methods that are not visible to developers, so I do not want to make assumptions about the process. However, after spending several months significantly modifying the product following the previous 4.3 rejection, receiving another 4.3 decision so quickly was understandably frustrating, because we are unsure whether the new experience and features were actually evaluated. I fully understand and respect Apple’s concern regarding saturated categories under Guideline 4.3(b). I am not looking to repeatedly resubmit the application without addressing the underlying concern. I genuinely want to understand what Apple expects from us. Could someone from App Review please help clarify: What specifically would VIVA need to change for Apple to consider the experience “meaningfully different or improved” under Guideline 4.3(b)? Would features such as community-specific matchmaking, a dedicated matchmaker experience, family/trusted-person testimonials, mandatory verification and limited daily introductions be considered meaningful differentiation? Is there a way to request a more detailed review of the actual application experience and its new functionality? Given that VIVA is designed for a defined global community rather than the general public, would Unlisted App Distribution be a more appropriate model? I have already submitted an appeal and contacted Developer Support. I am completely willing to make further meaningful product changes if necessary. My main objective is to understand the correct path toward compliance and to ensure that the current version of the app and its new features are properly evaluated. Thank you very much for any guidance or assistance.

Hi everyone, I would like to ask if anyone else has experienced a longer-than-usual "In Review" phase recently. Here is the timeline for our app, App ID: 6800282515: Submitted for Review: Sep 14 at 05:00 Pacific Time Checked and found status in "In Review": Sep 14 at 19:00 Current Status: Still "In Review" (as of Sep 17, 19:00+) It has been in the "In Review" state for over 3 full days without any updates, rejection notices, or requests for additional info. Has anyone run into a similar issue lately? Is there any recommended way to handle this, or should we just wait a bit longer? Any advice would be greatly appreciated!

Hi Apple Developer Community, I'm hoping someone from the App Review community or Apple can help me understand what may be happening with our app. Our educational app has now been rejected multiple times under Guideline 5.6 — Developer Code of Conduct. The problem is that we have not received a specific explanation identifying which feature, behavior, or part of the app is considered a violation. We have carefully reviewed the rejection and made sure that there are no features intentionally hidden from App Review. The functionality available to the reviewer is available to normal users as well. We have already: Replied to the App Review rejection asking for the specific reason. Submitted an appeal explaining the situation. Asked Apple to identify the specific feature or behavior that triggered Guideline 5.6. However, we have not received a response to either the appeal or our message in the App Review/Resolution Center yet. About the app: This is an educational application used by students for exam preparation. The upcoming examination period is approaching, and students are currently waiting for access to the application and its preparation materials. This makes the situation particularly time-sensitive for us. We are willing to make any changes required by Apple, but without knowing what behavior triggered 5.6, we don't want to keep making random changes and repeatedly resubmitting the same app. My questions are: What kinds of situations typically result in a 5.6 rejection when Apple does not specify a particular feature? Is there anything specific we should check in our app or review configuration? Is there a way to obtain clarification on the exact 5.6 concern while the appeal is pending? Should we wait for the appeal response before submitting another build? We would really appreciate any guidance. We are not trying to bypass App Review — we simply want to understand the specific issue so we can fix it correctly and provide students access before their exams. Thank you.

Hello! I have a new organization-level Apple Developer account and I'm stuck on the Tax Forms step in App Store Connect (https://appstoreconnect.apple.com/business). The system is showing me U.S. Form W-9 as the only option, but in my case filling out a W-9 would be incorrect — and I'd appreciate guidance from anyone who has resolved this. My setup: I am a non-US individual (not a US citizen, not a US resident, never lived in the US). I am the sole owner of a single-member LLC registered in the US (set up via Firstbase specifically to distribute a mobile app). For US federal tax purposes, this LLC is a disregarded entity — it's not treated as a separate taxpayer from its owner. Why W-9 is not the correct form in my case: The IRS instructions for Form W-9 explicitly state: "If the owner of the disregarded entity is a foreign person, the owner must complete an appropriate Form W-8 instead of a Form W-9. This is the case even if the foreign person has a U.S. TIN." Form W-9 also requires me to certify, under penalty of perjury, that I am a US person — which I am not. The LLC itself doesn't certify anything on a W-9 because it's disregarded; the IRS looks through to the beneficial owner, who in my case is a foreign individual. The correct form for me should be W-8BEN (Certificate of Foreign Status of Beneficial Owner — Individuals). What I've already tried: I opened two support cases 4 days ago and have not received a substantive response yet: Apple Developer Support — Case ID: 20000112974233 Ack Tax / Tax category settings — Team ID: 7YYWN3MYCY, Case ID: 19944616 My questions: Has anyone in the same situation (non-US individual, sole owner of a US single-member LLC) successfully switched the tax form from W-9 to W-8BEN inside App Store Connect? If so, how? Is there a specific path in the Business / Tax Forms section to declare the beneficial owner as a foreign individual that I might be missing? Is there an escalation channel beyond the standard support cases for tax-form issues that are blocking onboarding? Thanks in advance for any pointers.

Hello, Isochrome: Retro Film Camera (App ID 6800230242) has been live since 7 September 2026. Its direct App Store link works, but on 16 September an exact ‘Isochrome’ search in the Australian iPhone App Store did not return it. App Store Connect shows Ready for Distribution and 175 configured regions. Apple Developer Support is reviewing this under case 102961258239; its latest reply was 22 September. Could an Apple engineer help determine whether this is an App Store search-indexing issue and advise how to escalate it to the team responsible? I can provide screen recordings and storefront/device details privately. Has anyone else seen a live app absent from exact-name search? Direct listing: https://apps.apple.com/au/app/id6800230242

I have been trying for 24 hours to upload app, and first time this has happened in 8 years and 100+ uploads. Please help. Validate App and Upload both hang indefinitely at "Preparing" in Xcode Organizer. No error is ever returned — the progress bar freezes and the operation never completes or times out. Transporter 1.4.5 fails identically. Key detail: archive 2.4.3 (build 123), which Apple accepted and processed on Sept 10, 2026, now hangs the same way when validated. Same machine, same Xcode, same Apple ID. This rules out the archive, its signature, and its provisioning profile. Already ruled out: two independent networks (home Wi-Fi and iPhone cellular hotspot); the archive itself (known-good build 123 fails identically); Xcode install (27.0 / 27A266a, xcode-select verified correct); Apple ID session (signed out and back in three times); full reboot. macOS 27.0 (26A428) on MacBookPro18,4. Last successful upload Sept 10, 2026. 100+ prior archives uploaded without incident over several years. macOS has updated twice since Sept 10. Separately: Transporter 1.4.5 crashes on macOS 27.0 with an unhandled exception in TransporterKit while drawing its activity queue (EXC_BREAKPOINT via +[NSApplication _crashOnException:]).

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.

Hello, I am trying to package and distribute a Safari Web Extension using the web-based Safari Web Extension Packager in App Store Connect. My Apple Developer Program membership is active, and I have already completed the following: Created an explicit Bundle ID. Created an iOS app record in App Store Connect named Kuzey SGK. The app is currently in Prepare for Submission status. I can access the app's Xcode Cloud tab. I can also access Users and Access > Xcode Cloud. According to Apple's documentation: “After creating an app record, navigate to the Xcode Cloud tab. Under Safari Web Extension Packager, click Upload.” However, there is no “Safari Web Extension Packager” section at all under the Xcode Cloud tab for my app. The page only displays the standard Xcode Cloud information and “Get started in Xcode.” I am using App Store Connect from Windows in a web browser. My understanding from Apple's Safari Web Extension documentation is that the web-based packager should allow packaging an existing web extension without requiring a Mac or Xcode. I have not configured a standard Xcode Cloud workflow or connected a source repository, because the Safari Web Extension Packager documentation does not list those steps as prerequisites. Apple Developer Program Support reviewed my request and referred me to the Developer Forums because this appears to be a technical issue. My support case number is 102956602442. Could someone please clarify: Is there an additional step required to enable the Safari Web Extension Packager for a newly created developer account or app? Is a standard Xcode Cloud workflow required before the Packager becomes visible? Is the Packager currently available to all Apple Developer Program members? Thank you.

Radio Dad (App ID 6798412909, version 1.0) is an internet radio player: it reads the radio-browser.info directory and plays each station from the broadcaster's own public stream URL, on the listener's device, with nothing hosted or re-streamed by us. It also plays podcasts from their public RSS feeds via Podcast Index. It was rejected under 5.2.3 (Legal: Intellectual Property, Audio/Video Downloading) on 26 August and again on 21 September, each time with the request to "attach documentary evidence evidencing that you have all necessary rights or permissions to the third-party audio or video streaming, catalogs, and discovery services." We have attached, in the App Review Information section, a signed statement with exhibits: the directory's public-domain dedication and API terms permitting commercial use; Podcast Index's published terms; a survey of 2,000 stream addresses showing the broadcasters' own servers serve the streams unauthenticated (97.4%) and identify themselves in the transmission (84% name the station, 60% their own website, 44% set icy-pub: 1); the directory's owner mechanism, under which only the stream owner can change or delete a listing; and our own takedown path, actioned typically within 48 hours. The app cannot save, convert or download a radio stream, and accesses none of the services the guideline names. The reply to the second submission was "The issues we previously identified still need your attention", without saying what form of evidence would resolve them. For publicly broadcast streams there is no rights holder to obtain a licence from beyond the broadcaster, who publishes the stream for public reception. Submission ID 448bc0d6-d797-444b-934f-9f0d7c1a5a28. We have asked for an App Review Appointment in the Resolution Center. If App Review can say what document would satisfy 5.2.3 for this kind of app, we will provide it.