Overview

Our app supports Full Keyboard Access. We have a scroll view containing content that extends beyond the visible area. When navigating with the keyboard, focusable elements inside the scroll view are reached and the view scrolls to follow focus, but content that has no focusable elements (e.g. long blocks of static text, images, or footer content below the last control) can't be brought into view by the keyboard alone. Is there a supported way for Full Keyboard Access users to scroll a scroll view to see this off-screen, non-focusable content — e.g. a built-in scroll command, or an API to make the scroll view itself focusable/scrollable via the keyboard — without resorting to custom key handling?

Our app supports Full Keyboard Access. When an element is focused, the system-drawn FKA focus indicator (the ring/overlay) sits over the UI component. This overlay drops the content's colour contrast below the WCAG 2.1 minimums — 4.5:1 for text (1.4.3) and 3:1 for UI components and focus indicators (1.4.11) — causing the focused state to fail accessibility audits. Is there a supported way to completely remove this focus overlay on a view without breaking FKA keyboard navigation or VoiceOver?

I'm in need of some guidance regarding an issue I'm facing with the App Store review process. My app was recently rejected in the Kids Category due to the following error: Guideline 1.3 - Safety - Kids Category "We still noticed that you have not provided any publicly documented practices and policies for third-party contextual advertising in your Kids Category app." I'm somewhat perplexed by this rejection because a previous version of my app, which also included ads, was accepted without any problems. I'm using AdMob and have configured it to serve only child-appropriate ads while blocking any content that may not be suitable for children . The issue is that I'm not entirely sure what specific documentation or policies Apple is looking for in this regard. I would greatly appreciate any guidance or advice from the community on what I need to provide to address this concern and resubmit my app for review successfully. Has anyone experienced a similar situation, or can anyone offer insights into what might be required for compliance with this guideline? Your assistance and insights would be immensely helpful, and I'm committed to making the necessary adjustments to ensure my app meets the guidelines for the Kids Category. Thank you in advance for your support and suggestions.

Hello, I am trying to enroll in apple developer program and I get this generic error "Your enrollment could not be completed. Your enrollment in the Apple Developer Program could not be completed at this time." without any reason or clarification. I tried from my PC and from my iphone device both giving me same error. Can you check whats the problem here ? Thanks in advance!

Hello App Review Team, I am following up on my earlier post about our app (App ID: 6761247061), as our situation has unfortunately not improved. Our app was finally reviewed on May 22 and rejected under Guideline 2.1(a). We resolved the issue on the same day and resubmitted, but the resubmission has been stuck in "Waiting for Review" again for several business days with no progress. Due to these repeated delays, we have been unable to release a new version of our app to our users for nearly three weeks. If there is anything we are missing, or any issue with our submission that we should address, we sincerely ask for your guidance. We are fully committed to complying with the Review Guidelines and resolving any concerns you may have. Any guidance from your team would mean so much to us. Thank you so much for your time and patience.

Hello, Adding our case to the long-running thread on this issue (https://developer.apple.com/forums/thread/118465). Our team is the latest to be hit by statusCode 7000 "Team is not yet configured for notarization", and we'd like to (a) document the data points in case it helps Apple correlate cases and (b) ask the community whether anyone has seen a faster resolution path than what's been reported here over the past 6 years. Our situation Team ID: A92X4FJ5HU Last successful notarization: 2026-05-18 11:23:26 UTC First rejection: 2026-05-18 17:19:15 UTC (~6 hours later, no apparent trigger on our side) Total rejections since: 22 submissions across 9 days, 100% rejected with statusCode 7000 Open support case: 102900780153 What we have already verified Apple Developer Program membership Active (Renewal Sept 17, 2026) Apple Developer Program License Agreement: Accepted Apr 15, 2026 Free Apps Agreement: Active (Apr 15, 2026 — Sept 16, 2026) Paid Apps Agreement: Active (Mar 17, 2026 — Sept 16, 2026) Banking and tax information complete Developer ID Application certificate valid (notBefore 2025-10-12, notAfter 2027-02-01) What we tested Variable Result API key A (Admin role, created 2025-10) Rejected, statusCode 7000 API key B (Admin role, created 2026-05-22) Rejected, statusCode 7000 Same Issuer ID, both keys Same rejection Bundle ID com.matrixai.app (one product) Rejected Bundle ID com.flowith.os.beta (different product) Rejected Locally-rebuilt clean DMG Rejected Pre-existing already-signed DMG Rejected The rejection happens server-side after upload completes — authentication, signing, hardened runtime, and timestamp are all confirmed correct (codesign verifies cleanly, both keys authenticate). The submission is accepted by the notary service, then rejected with statusCode 7000 after a few minutes of "In Progress". Sample submission IDs (all rejected, statusCode 7000) ac52531f-1b9e-4210-8123-54afea90f66f (2026-05-27 10:20 UTC) baba6420-e245-4597-b229-ec5af4b309c5 (2026-05-27 10:23 UTC) 72118f71-9f1d-4ce9-8068-3eca5017104d (2026-05-27 09:49 UTC) Question to the community I've read this entire thread (all 4 pages, 6 years of reports) and the related threads (749857, 813624, 825906, 827589, 130479, 130494, 741721, 809228). The consistent answer from DTS is "this is a Developer Program Support issue, escalate via official channels", but the threads also document wait times of 1 day to 3+ months with no SLA and no transparency. A few questions: Has anyone in 2025 or 2026 had this resolved in under 2 weeks? If yes, what (if anything) on your side accelerated it? Did anyone identify a specific account-level signal (recent agreement re-acceptance, banking change, AppID/Bundle ID conflict, recent role/Account Holder change, recent device verification, etc.) that correlated with the trigger date? Is there any escalation path beyond Case → DPS → "engineers are working on it" loop? Several users on this thread report 39 days, 3 months, 4 separate cases — and DPS still cannot give an ETA. I understand the official answer is "wait for Developer Program Support". Posting this here primarily so Apple has more correlated data points for the engineering team that owns notarization, and so other developers who hit this in the future can find one more datapoint. Thanks.

Hello, My app was submitted for review last week, but it is still showing the status Waiting for Review and has not moved into the review process yet. App details: App ID: 6751946791 Current status: Waiting for Review Submission time: Last week Additional context: Due to a time-sensitive launch schedule, I have submitted several expedited review requests, but the app status has not changed. I would like to ask: Could submitting multiple expedited review requests affect the normal review queue or delay the review process? Does staying in Waiting for Review for this long indicate any possible issue with the submission, metadata, account status, or review queue? If further follow-up is needed, should I contact the App Review team through the App Review contact form? Any guidance from Apple or developers with similar experience would be greatly appreciated. Thank you.

Hi, is there official information about iOS and iPadOS versions which no longer get security updates/support. I only know of an unofficial site "endoflife.com" and by their data there are no updates for iOS v18 but where can I verify that this information is legit. Our strict policy only allows that we deploy our app for OS version which still get security updates. Regards

Hello everyone, I need help understanding what's happening with my app, Driving Theory UK Test 2026 (App ID: 6760669990). There's a concerning pattern in my submission history that I can't explain. Here's what happened: May 5 at 2:40 PM → Submitted → Sat in queue for 7 days → Made updates to app & metadata → Resubmitted on May 12 May 12 at 6:30 PM → Resubmitted → Sat in queue for 6 days → Made further updates to app & metadata → Resubmitted again on May 18 May 18 at 11:56 AM → Current submission → Now stuck in "Waiting for Review" for over a week with no change So each time it sat waiting, I made improvements based on potential issues I could identify. I updated the app code, refined metadata, improved descriptions, adjusted screenshots—essentially addressing anything that could have been problematic. But now the current submission has been in "Waiting for Review" for over a week with no progress, no feedback, no indication of what might be wrong. I'm genuinely confused: Why does each submission sit for days before requiring resubmission? What's causing the delays if there's no rejection message or warning? Is there a hidden issue in the guidelines I'm missing? Is there something specific about this app that's preventing it from entering actual review? Will the current submission follow the same pattern? What I've verified: App meets all App Store Review Guidelines No metadata errors or warnings in App Store Connect Screenshots, descriptions, and assets all properly formatted App functionality tested thoroughly Contacted Apple Support (still awaiting response) This is an educational app for UK learner drivers preparing for their theory tests. The repeated delays are affecting our launch timeline significantly. Has anyone experienced this before? Any insights or advice would be genuinely appreciated. Thanks,

I was invited to join development team. so after receiving mail to my account I clicked accept invitation button in email. but the page of appstoreconnect shows that link is expired or invalid. however admin Is inviting me 2 min ago. how can I solve this problem? what should I do?

I submitted my application on April 30th, and they responded with various errors. I fixed each one and resubmitted it, but I received no response until May 14th. Thinking it might be stuck in their system, I canceled the process and resubmitted it, but it's still pending review after 13 days. In short, I haven't received a response from Apple for a month. I leave a callback, they call back, I wait an hour, and no one gets through. It's a terrible customer support system.

Hi, I'm an Android Developer at Radio France, and we're currently integrating Apple Music into our Android application. We noticed that the Android SDK artifacts are currently distributed as raw .aar files, such as: mediaplayback-release-1.1.1.aar musickitauth-release-1.1.2.aar For Android projects, publishing these libraries through a Maven repository would greatly simplify integration and maintenance. It would provide a cleaner setup for dependency management, versioning, and future updates through Gradle. A Maven distribution model such as: implementation("com.apple.music:mediaplayback:1.1.1") implementation("com.apple.music:musickitauth:1.1.2") would make adoption significantly easier for Android teams. Thanks for your work on the SDK and for considering this improvement.

Notarization has been rejecting every submission with statusCode 7000 ("Team is not yet configured for notarization") for over five weeks. I'd appreciate any Apple staff who can confirm the gate status or re-route this internally. Account: Team ID: ZLPP2G8NG3 Account type: Individual, ACTIVE membership Region: EU (Czech Republic) The submission is technically clean — this is rejected at the gate, not on content: Developer ID Application cert valid (expires 2031), full WWDR chain Signed with hardened runtime + secure timestamp codesign --verify --deep --strict passes notarytool uploads succeed, then Rejected in ~30-60s log shows "issues": null (the archive is never opened) Confirmed it is NOT app-specific: a 50 KB hello-world C binary, signed the same way, is rejected identically. Latest canary submission: 95833847-e70f-41fe-b61f-c9dc9ffd90ed (2026-05-27) -> 7000 Timeline: 2026-04-20 first 7000 rejection (app, after ~60h "In Progress") 2026-04-29 escalated to engineering (case 102873818441, advisor Ronan) 2026-05-13 advisor Ira (case 102887849530) requested government photo ID + address verification — uploaded same day via the official file-upload portal, autoreply confirmed receipt 2026-05-14 to 05-27 silence; case was closed on Apple side, issue NOT resolved 2026-05-27 still 7000 I've completed everything on my side: License Agreement accepted, Free Apps agreement Active, DSA trader designation done, and the identity-verification documents submitted on May 13. Two weeks later the gate is still down with no reply on either case. Question for Apple staff: can someone confirm whether the identity-verification documents from May 13 reached the team that flips the notarization flag, and whether anything further is needed from me? The support cases have gone quiet and I have no other channel to check status. Thank you.

In testing in-app push provisioning with a production TestFlight build built with Xcode Cloud (Xcode 26.4.1) the flow is failing when attempting to add cards. I start the flow by choosing the add to wallet button from within the app. I get to the stage “Add Card” and choosing continue fails with “Could Not Add Card” and a button “Set Up Later” Analysing the sysdiagnose logs reveals that the eligibility stage is failing with a HTTP 500 error. [9ix8SPBHSfWEcxLjj+j5bA] ProvisioningOperationComposer: Step 'eligibility' failed with error <PKProvisioningError: severity: 'terminal'; internalDebugDescriptions: '( "eligibility request failure", "Received HTTP 500" )'; underlyingError: 'Error Domain=PKPaymentWebServiceErrorDomain Code=0 "Unexpected error." UserInfo={PKErrorHTTPResponseStatusCodeKey=500, NSLocalizedDescription=Unexpected error.}'; userInfo: '{ PKErrorHTTPResponseStatusCodeKey = 500; }'; > FB22761556

QuickLookAR shares the actual USDZ model instead of the original website URL — critical copyright and data leak issue on iOS 26 Since iOS 26, QuickLookAR (or ARQuickLookPreviewItem) no longer preserves the original web URL when sharing a model. Instead of sending the link to the hosted file, the system directly shares the actual USDZ model file with the recipient. This is a critical regression and a severe breach of intellectual property protection, as it exposes proprietary 3D models that must never be distributed outside of the controlled web environment. In earlier iOS versions (tested up to iOS 18), QuickLookAR correctly handled sharing — the share sheet would send the website link where the model is hosted, not the file itself. Starting with iOS 26, this behavior has changed and completely breaks the intended secure flow for AR experiences. Our project relies on allowing users to view models in AR via QuickLook, without ever transferring the underlying 3D assets. Now, the share operation forces full file sharing, giving end users unrestricted access to the model file, which can be copied, rehosted, or reverse-engineered. This issue critically affects production environments and prevents us from deploying our AR-based solutions. Implement a standard QuickLookAR preview with a USDZ file hosted on your web server (e.g., via ARQuickLookPreviewItem). 2. Open the AR view on iOS 26. 3. Tap the Share icon from QuickLookAR. 4. Send via any messenger (Telegram, WhatsApp, etc.). 5. Observe that the actual .usdz model is sent instead of the original website URL. ⸻ Expected behavior: QuickLookAR should share only the original URL (as in iOS 17–18), not the file itself. This ensures that intellectual property and licensed 3D models remain protected and controlled by the content owner. ⸻ Actual behavior: QuickLookAR shares the entire USDZ file, leaking the model content outside of the intended environment. ⸻ Impact: • Violation of copyright and confidential data policies • Loss of control over proprietary 3D assets • Breaking change for all existing web-based AR integrations • Critical blocker for AR production deployment ⸻ Environment: • iOS 26.0 and 26.1 (tested on iPhone 14, iPhone 15) • Safari + QuickLookAR integration • Works correctly on iOS 17 / iOS 18 ⸻ Notes: This regression appears to have been introduced in the latest iOS 26 system handling of QuickLookAR sharing. Please escalate this issue to the ARKit / QuickLook engineering team as it directly affects compliance, IP protection, and usability of AR features across production applications. Additional Notes / Verification: Please test this behavior yourself using the CheckAR test model on my website: https://admixreality.com/ios26/ • If the login page appears, click “Check AR” and then “View in Your Space”. • On iOS 18 and earlier, sharing correctly sends the website URL. • On iOS 26, sharing sends the actual USDZ model file. This clearly demonstrates the regression and the security/IP issue.

Hello everyone, I enrolled in the Apple Developer Program, completed payment successfully, and received confirmation, but my developer account is still not activated after 5 business days. I’m currently unable to access developer tools or continue setup. I’ve also had difficulty getting through to Apple Developer Support directly, which has made it difficult to understand whether something is wrong with my enrollment or if this is simply an unusually long processing delay. I’ve already contacted Apple Support, but I keep getting redirected between support channels. Has anyone else experienced a similar delay recently? If so: How long did activation take for you? Was there anything specific you had to do? Did your enrollment eventually activate automatically? Any advice or shared experiences would be appreciated. Thank you.

My app "Fun Games - Mini Offline Games" (ID: 6761358642) has been in "Waiting for Review" for over a month. Apple Support told me on May 19 it was being expedited, but there's been no change for 8 days since. This is delaying our marketing campaign and causing financial loss. Could the App Review team please investigate or reach out? Thank you.

Hi everyone, We are experiencing a bizarre issue with one of our apps, BLOKX. Here is the quick timeline: March 26: First submission. No status change for 2 weeks. We canceled and resubmitted. April 27: Still zero movement. We updated our SDK and submitted again on May 15. On the exact same day, we submitted other app from our developer account. It got reviewed and approved. Only BLOKX gets completely ignored. May 20: Suspecting a technical glitch with the specific App ID, we created a brand new App ID and submitted BLOKX as a completely fresh app. Today (May 27): Still stuck in "Waiting for Review" with zero movement. The Support Loop: We have already contacted Apple Support multiple times regarding the old App ID (Case ID: 102871846091 and Case ID: 102875670447). The replies we are getting are incredibly frustrating and factually incorrect. Support keeps replying with a generic template stating that the app “was just submitted today” (matching the exact date of their email reply), completely ignoring the weeks it spent waiting. When we replied back with actual screenshots of our timeline and submission history proving otherwise, they simply copy-pasted the exact same response a few days later, just changing the date to the current day. • App name: BLOKX • Platform: iOS • Current status: Waiting for Review • Total waiting time: Almost 2 months (across both IDs) • Old App ID: 6761107868 • Current App ID: 6771268940 Has anyone faced something similar recently? How did you get Apple to notice? If any Apple engineering or forum moderator can check whether our submission is stuck in the review queue or if any action is required from our side, it would be very helpful. Thanks in advance!

I’m seeing a regression in Xcode 26.4 where Interface Builder will not allow connecting IBOutlets or IBActions. Symptoms: The usual gutter circle/dot does not appear next to IBOutlet / IBAction in the code editor Because of this, I cannot: drag from storyboard → code drag from code → storyboard The class is valid and already connected to the storyboard (existing outlets work) Assistant Editor opens the correct view controller file Important: The exact same project, unchanged, works perfectly in Xcode 26.3. I can create and connect outlets/actions normally there. ⸻ Environment Xcode: 26.4 macOS: 26.4 Mac Mini M4 Pro 64G Ram Project: Objective-C UIKit app using Storyboards This is a long-running, ObjC, project (not newly created) ⸻ What I’ve already tried To rule out the usual suspects: Verified View Controller Custom Class is correctly set in Identity Inspector Verified files are in the correct Target Membership Verified outlets are declared correctly in the .h file: @property (weak, nonatomic) IBOutlet UILabel *exampleLabel; Opened correct file manually (not relying on Automatic Assistant) Tried both: storyboard → code drag code → storyboard drag Tried using Connections Inspector Clean Build Folder Deleted entire DerivedData Restarted Xcode Updated macOS to 26.4 Ran: sudo xcodebuild -runFirstLaunch Confirmed required platform components installed Reopened project fresh ⸻ Observations In Xcode 26.4 the outlet “connection circles” are completely missing In Xcode 26.3 they appear immediately for the same code Existing connections still function at runtime — this is purely an Interface Builder issue ⸻ Question The gutter circles appearance has always been flaky in Xcode over the 13+ years I've been using it but now with 26.4 they have completely disappeared. Has anyone else seen this in Xcode 26.4, or found a workaround? At this point it looks like a regression in Interface Builder, but I haven’t found any mention of it yet.

Hi all — looking for any escalation path for two production-impacting submissions currently stuck in WAITING_FOR_REVIEW. Both apps' live App Store versions are broken for 100% of users; the submissions contain minimal, scope-limited fixes (no new APIs, entitlements, data collection, or UI). The Android equivalents are already live and verified working. MeetingMind: AI Note Taker (Apple ID 6757317991) — v6.1.2 / build 49, submission ID f88195d3-6c35-4e6d-a7a9-6f34b44bf0e7. Waiting since 2026-05-24 (3+ days). Bug: outbound phone calls fail to relay audio from the called party to the caller. Fix: ~5 lines in VoipService.swift. ReadAloudAI: Voice Reader (Apple ID 6757346255) — v7.9.1 / build 38, submission ID 21f4510f-4690-4d15-b559-437f89e037ca. Waiting since 2026-05-26. Bug: backend Cloud Run URLs retired, text-to-speech (core feature) fails for all users on v7.9 and earlier. Fix: configuration-only URL migration to Fly.io. Already done: expedited review filed via the contact form earlier today (no acknowledgment), email to appreview apple.com, Notes for App Review updated with reproduction + verification steps. Has anyone had success with another escalation channel in similar situations? Any Apple staff who could take a look would be deeply appreciated.