Overview

Hello, My Apple Developer Program enrollment has been stuck on "Review Under - Please contact us to continue" for a while now. I have already submitted the support form multiple times, but I have not received any response or update yet. Furthermore, since I am operating from Pakistan, the standard "Call Back" phone support option is completely unavailable/greyed out in my region, leaving me with no direct way to contact the team. I have already provided all my verified identity information during the initial process. Could an Apple admin or support specialist please look into this case or escalate it to the enrollment verification team? Case ID: 103006700501 Any help to clear this roadblock would be highly appreciated. Thank you! Hoping to get some guidance from Quinn the Eskimo or any other Apple Admin on this issue.

Hello, I am unable to use TestFlight for any app (existing or new), while production uploads work normally. All TestFlight actions fail with: ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING There are no pending agreements in App Store Connect. This is an older account that previously used TestFlight successfully. This appears to be a missing or detached TestFlight Beta contract on Apple’s backend. Could this be manually reattached or re-provisioned? This is time-sensitive, as I need a TestFlight external testers link to submit an app for an upcoming hackathon. Apple Support case ID (for reference): 102817552619 Thank you.

Please contact me. Critical design issue affecting Duo. Time sensitive.

I’m blocked debugging a watchOS app on a physical Apple Watch. The iPhone connects to Xcode normally (wired), but the Watch either fails to connect with a tunnel timeout or disappears entirely from Xcode after I unpaired it inside Devices & Simulators. Environment Mac: macOS 26.x (Apple Silicon Mac) Xcode: 26.2 iPhone: iOS 26.1 Apple Watch Ultra: watchOS 26.2 (build 23S303) Connection: iPhone connected to Mac via USB (trusted). Watch paired to iPhone and working normally in the Watch app. Issue A (when Watch is visible in Xcode) In Xcode → Window → Devices and Simulators, the Watch shows up but is not usable and fails to connect. Error: “Previous preparation error: A connection to this device could not be established.” “Timed out while attempting to establish tunnel using negotiated network parameters.” In some attempts the Watch shows “Capacity: Unknown” / limited details, and then fails during preparation. Issue B (after unpairing Watch in Xcode only) I unpaired/removed the Watch in Xcode (Devices & Simulators). I did not unpair the Watch from the iPhone. Now: iPhone appears in Xcode and works normally for builds. Watch is still paired to the iPhone and works normally. Watch no longer appears anywhere in Xcode Devices & Simulators (no paired watch section, no watch run destination). What I’ve tried Reboots of Mac, iPhone, Watch (multiple times) Watch unlocked, awake; iPhone unlocked and close to Watch Verified Watch is paired and connected in iPhone Watch app Developer Mode enabled on iPhone and Watch Wi-Fi and Bluetooth ON (Mac/iPhone/Watch), tried toggling both Tried on home Wi-Fi and also with iPhone hotspot (same result) Resetting trust prompts / reconnecting iPhone via USB, re-trusting Mac Apple Watch: “Clear Trusted Computers” Xcode: removing/re-adding devices; clearing derived data; restarting Xcode Watch Developer networking test: Responsiveness = Medium (430 RPM) Questions 1. Is this a known issue/regression with Xcode 26.2 + watchOS 26.2 tunneling (CoreDevice / devicectl)? 2. Is there an Apple-supported way to force Xcode to re-discover a paired Watch after it was removed from Xcode Devices & Simulators (without unpairing the Watch from the iPhone)? 3. Any recommended logs or diagnostic steps I should collect (Console logs, sysdiagnose, specific Xcode/CoreDevice logs) to include in a Feedback report? If helpful, I can provide the full error text from Xcode’s Devices window and any logs you recommend. Thank you in advance,

Hello Apple Developer Community, I'm running macOS 27.2 on Apple Silicon with Python 3.13.17 installed from the official python.org installer. I am investigating an inconsistency in macOS code-signing and trust verification. What I have observed: In the normal graphical Terminal, code-signature checks for /usr/bin/true and the installed Python 3.13 executable succeed. In an earlier, different execution context, trust verification reported CSSMERR_TP_NOT_TRUSTED. The Mac's date and time are configured automatically. The exact cause of the difference between execution contexts remains unknown. My questions: What could cause macOS trust evaluation to differ between execution contexts? Which read-only diagnostics could identify the cause? How can I investigate this without modifying Keychain trust settings, disabling system security or purchasing a paid developer membership? I can provide sanitized diagnostic logs if needed. Thank you for your help!

Hello, We first submitted this app, Instrumentalist: Play by Ear (iOS 1.0.0), for App Store review on September 30, 2026. The current build (31) has been in "Waiting for Review" since October 19, 2026, which is 9 days with no change. App Store Connect shows no message from App Review, no rejection and no request for information on this submission, and the status has not changed. The Android version has been live on Google Play since October 6, 2026, so iOS is the only platform still blocked, which is holding back our launch and marketing. App: Instrumentalist: Play by Ear Apple ID: 6813047197 Version and build: 1.0.0 (31) Submission ID: 7ee66efd-9378-4678-b455-56a7ec0301c8 First submitted: September 30, 2026 Current build in review since: October 19, 2026 The last message we received from App Review was a request on October 15 to confirm the Ensemble subscription price. We confirmed it the same day. We then moved to the current build (31) on October 19, and the review has shown no activity since. We have already requested an expedited review, most recently on October 21, and received no response. We respect that review times vary, but 9 days with no activity on the current build, almost a month after our first submission, looks more like an anomaly than a normal queue. Question 1: Is there a known reason a submission can stay in "Waiting for Review" this long, for example an extra verification step, or a routing or queue issue? Question 2: Is any action needed from our side, or should we leave the submission untouched so we do not lose our place in the queue? Question 3: What is the recommended escalation path beyond an App Review status inquiry and an expedited review request? For context, the app is free with optional subscriptions. The free tier uses Sign in with Apple or Google, and our App Review notes explain the reviewer can use Sign in with Apple with no credentials from us, and the paid test path needs no sign in. If an Apple team member could check whether the submission is correctly queued, we would be very grateful. Thank you.

Hello, Our first app submission has been in "Waiting for Review" since 17 October 2026 with no status change. App name: Gather Expense Apple ID: 6820869711 Version: 1.0 (build 12) Resubmitted for review: 17 October 2026, after answering a Guideline 2.1 Information Needed request with a screen recording and full details (also added to App Review Notes) TestFlight external beta: approved 20 October 2026 (same build) Developer Support case: 103007371511 (24 October 2026) Current status: Waiting for Review There is nothing new in App Review messages, and agreements, tax and banking are all active. Could someone confirm whether this submission is progressing normally or whether it is held? If anything further is needed, I'll provide it immediately. Thank you.

Hello Apple App Review Team, My app has been awaiting approval since October 26, 2026. For reference: App name: Legion of Paradise: Idle RPG App ID: 6815461133 Pending approval since: October 26 Support Case ID: 103009283878 Thank you, Best regards,

On October 21, 2026—8 days ago—I submitted an application via App Store Connect, and it is still stuck in the "Waiting for Review" status. I have already opened two support tickets, but I have not received a response. ID: 5dc7573a-8e33-4ef1-ac48-f2aff8627635

Hi all, It seems like there are a ton of us stuck in a "Waiting for Review" traffic jam, with Apple providing essentially no information on their end. Immensely frustrating. Given that, would people be up for posting their time submitted and (once they receive a review) editing to include the time it took? It would be good to get a sense of how long everyone is waiting. I'll go first: Submitted: October 8 Status: Waiting for review I'll update this post when I hear back.

Hello, I'm trying to enroll my company in the Apple Developer Program as an organization, but my enrollment has been blocked since October 24. During web enrollment, the "Confirm your personal information" step returned "The address you provided is not valid" for my address in Turkey. Since then, both the website and the Apple Developer app only show "Please contact us to continue your enrollment." I opened case 103007482908 on October 24 and sent a follow-up on October 28, but I haven't received a response yet. Phone support has shown "temporarily unavailable due to high call volume" every time I tried. Company: NEXVA TEKNOLOJI VE BILISIM LIMITED SIRKETI D-U-N-S: 321525056 Country: Turkey Could someone from Developer Program Support please look at my case? I'm happy to provide any documents needed. Thank you.

We build an internal on-call pager app for our engineers, distributed through TestFlight only. Our server sends a heartbeat push to each device every 4 hours. The Notification Service Extension uses it to re-arm a dead-man's-switch alarm on the device: if heartbeats stop arriving, the alarm goes off and the engineer knows the paging pipeline is down. The heartbeat has to be an alert push with mutable-content, because that is the only push type that reliably launches the extension, including when the user has swiped the app away. Background pushes don't work here: they are throttled and are not delivered to an app the user has force-quit, so the dead-man alarm would fire falsely. The problem is that every heartbeat leaves an entry in Notification Center. It carries nothing actionable, and it teaches on-call engineers to ignore notifications from a pager app. Real alerts are always shown, and the extension still shows a visible notification when a heartbeat detects a problem (missed alerts, failure to re-arm). We already send heartbeats with interruption-level passive and an apns-collapse-id, so it is a single quiet entry, but it is still there. com.apple.developer.usernotifications.filtering would solve this exactly. However, the request form requires picking one of four use cases (end-to-end encrypted messaging, earthquake warnings, education alerts, healthcare alerts), and ours is none of them. An earlier reply on this forum said other use cases are welcome to apply (https://developer.apple.com/forums/thread/676672), but the form no longer offers a way to describe one. Questions: Can an app whose use case is outside the four listed apply for the entitlement? If so, how should we fill in the required use-case field? If not, is there a supported way to have an alert push launch the extension without leaving an entry in Notification Center? For example, is it supported for the extension to remove its own delivered notification with removeDeliveredNotifications(withIdentifiers:) after calling the content handler? Thanks!

Reference environment: macOS 26.7.1, build 25G241, arm64, local APFS. Consistent capture of a source file We are evaluating NSFileCoordinator with the forUploading and withoutChanges options for a single regular file. Does the resulting snapshot guarantee byte contents corresponding to a single point in time, even if another process writes during capture without file coordination, using write/pwrite or a shared writable memory mapping? We need to establish the scope, conditions, and limitations of this guarantee. We do not require capturing an editor’s unsaved changes or application-level database consistency. If any of these concurrent writing methods are not covered, please identify them explicitly. Durability of the final filename after a rename We are evaluating the following sequence: a verified temporary file has successfully completed strong synchronization, and is then renamed using renameatx_np with RENAME_EXCL. The temporary and final names are in the same directory on the same volume. Next, fsync_volume_np is called with SYNC_VOLUME_FULLSYNC and SYNC_VOLUME_WAIT. Under what conditions does a successful return confirm that the final filename and its association with the prepared file contents will survive a system crash or power loss? We also need clarification on whether all relevant data and metadata write errors are propagated to the caller, or whether an earlier error might remain unreported by this operation. Please provide the documented scope and limitations for this environment.

If I create a BGContinuedProcessingTaskRequest, register it, and then "do work" within it appropriately reporting progress, and before my task has finished doing all the work it had to do, its expirationHandler triggers... does the task later try again? Or does it lose the execution opportunity until the app is next re-launched to the foreground? In my testing, I never saw my task execute again once expired (which suggests the latter?). I was able to easily force this expiry by starting my task, backgrounding my app, then launching the iOS Camera App. My example is just using test code inspired from https://developer.apple.com/documentation/backgroundtasks/performing-long-running-tasks-on-ios-and-ipados let request = BGContinuedProcessingTaskRequest(identifier: taskIdentifier, title: "Video Upload", subtitle: "Starting Upload") request.strategy = .queue BGTaskScheduler.shared.register(forTaskWithIdentifier: taskIdentifier, using: nil) { task in guard let task = task as? BGContinuedProcessingTask else { return } print("i am a good task") var wasExpired = false task.expirationHandler = { wasExpired = true } let progress = task.progress progress.totalUnitCount = 100 while !progress.isFinished && !wasExpired { progress.completedUnitCount += 1 let formattedProgress = String(format: "%.2f", progress.fractionCompleted * 100) task.updateTitle(task.title, subtitle: "Completed \(formattedProgress)%") sleep(1) } if progress.isFinished { print ("i was a good task") task.setTaskCompleted(success: true) } else { print("i was not a good task") task.setTaskCompleted(success: false) } } try? BGTaskScheduler.shared.submit(request) Apologies if this is clearly stated somewhere and I'm missing it.

MacOS 27 (or perhaps 26, I never used it) introduces two bugs in NSTableView (and delegate). It's always a pleasure when you find that your app no longer works properly. First, when the delegate responds to tableView:pasteboardWriterForRow:, no row can be selected by click & drag (even if the method returns nil). Which mean that clicking and dragging the mouse on rows that are not draggable simply does nothing (no selection), which is a frustrating user experience, especially considering that the same action selects rows on macOS 15. The second bug is that tableView.verticalMotionCanBeginDrag = NO is simply ignored. It doesn’t work. So, a click followed by an immediate vertical drag drags the clicked row instead of selecting rows if tableView:pasteboardWriterForRow: does not return nil. Again, it did select rows on macOS 15. That's what verticalMotionCanBeginDrag = NO is for. To work around the first bug, I implement respondsToSelector: in the delegate to return NO when the selector is tableView:pasteboardWriterForRow: and the clicked row is not draggable. This solution is not elegant, as theclickedRow property of the tableview always returns -1 when the method is called. Which means I need to determine the clicked row by other means (using the mouse location and stuff). (This solution should in principle allow working around the second bug, but I haven’t implemented it yet. It would require determining the delay between the click and the drag and the direction of the drag). So my question is: does anyone see a better workaround for these bugs?

I'm developing an Accessibility-enabled app that includes a helper app registered as a launch daemon using SMAppService. This daemon will connect to HID which requires both being root as well as having Accessibility (or Input Monitoring) permissions. I want this app to have as little friction for the user as I can manage. One friction I'd like to avoid is requiring the user to grant more than one application permission to use Accessibility features. So I'm wondering if I can set up the launch daemon so that it inherits the TCC permissions of its parent bundle. I'll note that the one way I've found that works is to not have the helper app have its own app bundle, but rather just have it be an executable placed alongside the main executable in enclosing bundle's Contents/MacOS directory. This has the disadvantage though of having the helper process and main process have the same name in Activity Monitor, which I think will be confusing to users. So in short, is there a supported way for a bundled application with its own CFBundleName / CFBundleDisplayName key to run as a launch daemon and also inherit Accessibility permissions from its parent app bundle?

Since we configured App Store Server Notifications V2 on 15 October 2026, every notification for our app is recorded as TIMED_OUT, with the attemptDate equal to the signedDate (same second), and no HTTP request ever reaches our server. 35 Sandbox notifications (TEST, SUBSCRIBED, DID_RENEW, EXPIRED): one attempt each, TIMED_OUT. 2 Production TEST notifications: retried 5–6 times over a week, all TIMED_OUT. Our endpoint is public, TLS 1.3, valid certificate, answers in < 400 ms, and processes the signedPayload correctly when we POST it ourselves. Today we pointed the Sandbox URL to a webhook.site URL and requested a test notification: TIMED_OUT within 10 s, nothing received on webhook.site either. The app (com.virginactive.revolution, appAppleId 1620160868) was transferred to our current developer account on 2 October 2026; notifications have never been delivered under the new team, so we suspect a server-side state issue after the transfer. Latest test tokens: Sandbox: be12b40b-19a7-4723-aebf-764db83b4690_1793289992274 (29 Oct 2026 16:06 UTC) Production: 80597167-2939-4cc9-a43c-2c3c29c6a161_1792741270174 (23 Oct 2026 07:41 UTC) Feedback Assistant: FB25363489 Is there anything on our side that could make the App Store server fail before attempting the connection, or does this need to be fixed on Apple's side?

I am posting here because I genuinely do not know what else to do. I paid the USD 99 Apple Developer Program fee on 13 October 2026. The payment went through immediately — I have the Apple Store invoice and the confirmation email sitting in my inbox. Sixteen days later, my enrollment still says **Pending**. In those sixteen days Apple has not asked me for a single thing. No ID verification, no document request, no email explaining what the hold-up is. Just Pending. I have opened two support cases. The most recent is **Case ID 103005173976**, now 7 days old. Both times I got the same automated reply telling me my request had been received and someone would get back to me as soon as possible. Nobody has. Not once, from either case. I check that inbox every morning before I do anything else, and every morning it is empty. I refresh the enrollment page more times a day than I want to admit. Apple's own documentation says enrollment usually completes within 48 hours and that support cases are answered within 48 hours. I am at 16 days and 7 days respectively, with no explanation for either. Where I am: - Individual enrollment, Sri Lanka - Paid 13 October 2026, USD 99.00, payment confirmed - Status: Pending, unchanged - Two support cases, latest 103005173976, zero human replies I am not posting to complain for the sake of it. I had a release date planned around this and I have had to push it, and I cannot give anyone a new date because I have no idea whether this resolves tomorrow or in another three weeks. Not knowing is the part that is wearing me down. So, honestly asking: 1. Has anyone had an individual enrollment sit in Pending this long with no communication at all? What finally moved it? 2. Is there any way to escalate an existing case ID, or any contact route that is actually staffed, rather than the email form that has now swallowed two of my requests? 3. Is there something I am supposed to be doing on my end that Apple simply has not told me about? If anyone from Apple reads this — I will send the invoice number, order number and Apple ID privately to whoever needs them. I just want someone to look at the account. Thank you to anyone who can point me somewhere.

Hi all. My first app, Stacy Maxxing (iOS 1.0), has been in Waiting for Review since October 16, 13 days now. It was rejected earlier for a camera permission button and an iPad issue. I fixed both and resubmitted the same day. Apple granted an expedited review on Oct 12 and again on Oct 28, and I have an open support case, but the status hasn't moved. Agreements, tax and banking are all active. Has anyone seen a submission sit this long after a fix, and did anything help, like resubmitting or contacting App Review again? Thanks.

Hello, I requested "Family Controls (Distribution)" for one of my apps. I received email that the entitlement is granted and I can use it: Hello XXXX The entitlement for Family Controls (Distribution) has been assigned to your account, and you can now configure this capability for eligible apps. If you’re enrolled as an organization, Admins on your team can also use this capability. However, on the identifiers page, the status still shows as "No Requests". Additionally, I see nowhere any other indicator. I opened a case with the ID 102999908799 but didnt receive any response. Anybody knows what to do? Thank you.