Overview

Hello Apple Developer Community, I’m looking for guidance regarding an unusually long App Review process for my first iOS app, Zivoo. The overall review and resubmission process has now been ongoing for more than a month. During the previous reviews, we received feedback from App Review. In response, the application was completely redesigned and the latest version contains a substantially revised core experience. The latest build is: App: Zivoo Platform: iOS Version: 2.1.4 (34) Submitted: August 10, 2026 Current status: Waiting for Review The App Store description, screenshots, metadata, and Review Notes have also been fully updated to reflect the redesigned application. Detailed testing instructions have been provided for App Review. After more than a month of working through the review process, responding to feedback, redesigning the application, and preparing a new submission, the latest build is still waiting for review without any visible progress. I have also contacted App Review Status support to confirm whether any additional action is required from our side. Could someone from Apple please check whether this submission is progressing normally or whether it may require additional attention? I would also appreciate hearing from other developers who have experienced a similar delay after substantially redesigning an application following App Review feedback. Thank you for any guidance or assistance.

Hello everyone, I'm going through a very stressful situation at the moment. TL;DR: Apple blocked my developer account and won't let me renew it. I complied with every request. I sent every document on time. I did nothing wrong. Team ID: QHC9NAUWK3 My membership expires on August 24. If this isn't resolved soon, my apps will be removed from the App Store, and I will lose my entire income. I enrolled in the Apple Developer Program in August 2025. Since then, I've been dedicated to building apps for the App Store full-time. On June 30, 2026, I received an email from Apple requesting documents to confirm my identity. If I didn't provide them within two weeks, my developer account would be suspended. I provided all the required documents on July 1. I received an automated email confirming that the documents were received and that I should hear back within two days. I never did. Two weeks later, my developer account was suspended. No warnings, no emails, nothing. I opened a support case with Apple. After receiving no response for four days, I got on a call with an Apple advisor. They told me that Apple had never received my documents. Weird, considering I have a confirmation email from Apple proving that wasn't the case. The case was escalated to the Operations team. A week went by without a response. I sent a follow-up email. Five more days went by without a response. I sent another email explaining that my membership expires soon and that I can't renew it. I kept receiving the same template response: "This may take an undetermined amount of time. We can't let you renew your membership during this time. The case is with another team, and we can't do anything else." Apple broke my account and blocked me from renewing it. A few more emails went back and forth without any progress. On August 12, I had another call with a senior Apple advisor. They looked over my case and mentioned that the situation was strange and that the review was taking unusually long. They acknowledged that I had provided everything and that this wasn't my fault. They then "re-escalated" the case to the Operations team. I am quite desperate at the moment. I don't know what else to do. It sucks to lose everything I dedicated the past year of my life to building. I found several other people on the forums dealing with similar problems. More than 50,000 people have read my story on X, and many have shown their support. Apple's own timelines no longer make sense. If they can't verify someone's documents within two weeks, it should at least not disable that person's account.

I'm using the Leaks instrument in Xcode 26.2 to investigate a memory leak. After attaching Instruments to target process and starting a recording, it detected 29 leaks. However, I'm unable to view the allocation call stacks because each leak shows "Call stack limit reached." May I know if anyone has a solution for this? I’ve tried “Hide System Libraries,” “Invert Call Tree,” and “Flatten Recursion,” but unfortunately, none of them seem to work.

Our app crashes when compiled with the iOS 27 beta 3 SDK and run as an iOS app on Mac, on both macOS 26 and macOS 27, as soon as a UISearchBar receives focus. The crash is due to this exception: *** Assertion failure in BOOL _screenBasedFocusUnsupported(void)(), UIScreen.m:3.725 Accessing the focus system through UIScreen is no longer supported. ( 0 CoreFoundation 0x000000018bea31c0 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x000000018b91e91c objc_exception_throw + 88 2 Foundation 0x000000018e092644 -[NSMutableDictionary(NSMutableDictionary) initWithContentsOfFile:] + 0 3 UIKitCore 0x00000001c5dae8ec _screenBasedFocusUnsupported + 272 4 UIKitCore 0x00000001c5dae960 -[UIScreen _preferredFocusedWindow] + 24 5 UIKitCore 0x00000001c4ea3a60 -[UIScreen _mainSceneReferenceBounds] + 200 6 UIKitCore 0x00000001c4ea3914 -[UIScreen _mainSceneBoundsForInterfaceOrientation:] + 40 7 UIKitCore 0x00000001c5708134 +[UINavigationBar defaultSizeForOrientation:] + 76 8 UIKitCore 0x00000001c6222c88 -[_UISearchPresentationController _layoutPresentationWithSize:transitionCoordinator:] + 704 9 UIKitCore 0x00000001c622296c -[_UISearchPresentationController containerViewWillLayoutSubviews] + 84 10 UIKitCore 0x00000001c549304c block_destroy_helper.13 + 25112 11 UIKitCore 0x00000001c549344c block_destroy_helper.13 + 26136 12 UIKitCore 0x00000001c4ea26a8 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1648 13 QuartzCore 0x0000000196103dbc _ZN2CA5Layer15perform_update_EPS0_P7CALayerjNS_17LayerUpdateReasonEPNS_11TransactionE + 460 14 QuartzCore 0x000000019610390c _ZN2CA5Layer17update_if_needed_EPNS_11TransactionENS_17LayerUpdateReasonE + 692 15 QuartzCore 0x0000000196035d2c _ZN2CA7Context18commit_transactionEPNS_11TransactionEdPd + 608 16 QuartzCore 0x0000000195e69520 _ZN2CA11Transaction6commitEv + 652 17 AppKit 0x0000000190fe116c __37+[NSDisplayCycle currentDisplayCycle]_block_invoke.7 + 44 18 CoreFoundation 0x000000018be34ad0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 19 CoreFoundation 0x000000018be34a10 __CFRunLoopDoBlocks + 396 20 CoreFoundation 0x000000018be33e54 __CFRunLoopRun + 2356 21 CoreFoundation 0x000000018bf06234 _CFRunLoopRunSpecificWithOptions + 532 22 HIToolbox 0x0000000198c1f560 RunCurrentEventLoopInMode + 320 23 HIToolbox 0x0000000198c228bc ReceiveNextEventCommon + 488 24 HIToolbox 0x0000000198dac14c _BlockUntilNextEventMatchingListInMode + 48 25 AppKit 0x00000001909163d0 _DPSBlockUntilNextEventMatchingListInMode + 228 26 AppKit 0x000000019026a084 _DPSNextEvent + 576 27 AppKit 0x0000000190dff96c -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 28 AppKit 0x0000000190dff678 -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:] + 72 29 AppKit 0x000000019025d13c -[NSApplication run] + 368 30 AppKit 0x00000001902357b0 NSApplicationMain + 880 31 AppKit 0x000000019047c958 +[NSWindow _savedFrameFromString:] + 0 32 UIKitMacHelper 0x00000001aa2651bc UINSApplicationMain + 972 33 UIKitCore 0x00000001c4e1aed4 UIApplicationMain + 144 34 UIKitCore 0x00000001c548bda0 block_destroy_helper.31 + 8880 35 DigitalConcertHall.debug.dylib 0x0000000106e41bd8 $sSo21UIApplicationDelegateP5UIKitE4mainyyFZ + 128 36 DigitalConcertHall.debug.dylib 0x0000000106e41b4c $s18DigitalConcertHall11AppDelegateC5$mainyyFZ + 32 37 DigitalConcertHall.debug.dylib 0x0000000106e4afc0 __debug_main_executable_dylib_entry_point + 28 38 dyld 0x000000018b9ac4e4 start + 6992 ) I could not test with the iOS 27 beta 4 SDK due to this blocking issue: https://developer.apple.com/forums/thread/839012 However, when I tried to set up a simple sample project, I could not reproduce the issue. Does anybody know what might be causing this? I filed feedback FB24201508

I’m working on an app that deals with a list of text items, so I started with the document app template in Xcode. I have the app basically doing what I want it to do, but I want to be a good ecosystem citizen, so I’d like to conform to app intents. I think that app intents will able to do what I want - accepting text and passing it back out - but I can’t figure out how to access the document outside of my content view and associated subviews. Any guidance would be appreciated. Thank you, Don Carlile

Estou com problemas para inserir um compilador a um grupo de tester externo. Ela da um erro que tenho que renovar mas não esta vencido. Before you can use TestFlight to distribute beta builds of your app, you must renew your Apple Developer Program membership.

TN3135 describes the exception that lets a watchOS app use low-level networking while it holds an active audio session. I have that working, and the app functions — but the network path is withdrawn and restored on a strikingly regular cycle, and I would like to know whether that is expected behaviour rather than something I am doing wrong. Setup Apple Watch Series 10 (Watch7,9), watchOS 26.5. Reproduced on a Series 6 (Watch6,2). UIBackgroundModes: [audio]; AVAudioSession category .playAndRecord, mode .spokenAudio; activated with the async activate(options:completionHandler:). NWConnection with NWProtocolWebSocket to a WebSocket relay over TLS. The app streams 16 kHz mono PCM continuously while transmitting and holds the socket open otherwise. Symptom NWPathMonitor reports .unsatisfied, then .satisfied about two seconds later, over and over. Measured with the iPhone powered off, so the watch was on its own Wi-Fi: Uptime between drops Outage 36.4 s 2.1 s 36.7 s 1.9 s 36.9 s 2.1 s The regularity is what prompts the question — uptime varies by ±0.3 s and the outage is consistently 2.0 s. That reads as a timeout expiring rather than radio behaviour. What I have ruled out Not the network or the server. A browser client on the same relay, same TLS, same wire protocol, holds a WebSocket indefinitely. Not the interface. Identical cadence over the companion ipsec1 tunnel with the iPhone present, and over the watch's own en0 with the iPhone powered off. Pinning requiredInterfaceType = .wifi while the iPhone is reachable fails outright — the path offers only ipsec1. Not audio-session interruption. I observe interruptionNotification, routeChangeNotification, mediaServicesWereResetNotification and silenceSecondaryAudioHintNotification. None fire at a drop. At the moment the path goes .unsatisfied, the engine is running and the player node is actively playing. Not session idleness. Playing continuous silence for the whole session, rather than only while reconnecting, made no difference — still 36.4 s. The control that surprised me To test whether this affects any long-lived watch socket or only audio-unlocked ones, I built a second app with no AVAudioSession at all, no audio background mode, holding a URLSessionWebSocketTask and kept alive by a WKExtendedRuntimeSession so screen sleep was not a factor. It never connected. NWPathMonitor reported .unsatisfied once and never changed, across a 30 s run, and every request failed with "The Internet connection appears to be offline." I had expected URLSession to be permitted regardless. Questions Does the audio-session networking exception in TN3135 have a defined lifetime, and is a periodic revoke/re-grant cycle expected? If so, is there a supported way to hold it continuously — or is the correct design simply to expect the interruption and reconnect through it? Is it expected that an app with no audio session gets no network path at all on watchOS, including via URLSession, even in the foreground with an extended runtime session?

My app has been stuck in “Waiting for Review” status since August 6th, over a week now. I’ve submitted multiple expedited review requests and haven’t received any response or update on any of them. This delay is holding up my launch and affecting my ability to plan around it. I understand expedited review isn’t guaranteed, but getting no reply at all, even a decline, makes it hard to know whether the request was seen or if something else is holding up the review. Could someone look into my case and let me know what’s going on? Best regards, App Name: Ratiō - AI Calorie Tracker Apple ID: 6790632661

Hi all, we are building a custom controller for ATDECC, which is a layer 2 protocol standardized by IEEE in 1722.1. Our controller can work on multiple network interfaces at the same time . It uses the interface's MAC address to identify, on which interface a certain AVB / ATDECC device was discovered. It then sends replies for this device only to this interface. This controller worked fine up to and including macOS 26, but when running the same code on macOS 27, we cannot get the MAC addresses for the local interfaces anymore, but we receive 02:00:00:00:00:00 for each of them. This seems to indicate that the MAC address was redacted (looks like the same MAC address, that is being returned since iOS 11 due to privacy reason). Is this a bug or is macOS going to redact the MAC addresses also in the final release? If MAC addresses are being redacted, would it help to request access to the new entitlement called com.apple.developer.networking.topology-observation? I attached a little code snippet, that returns actual MAC addresses on macOS 26, but redacted ones on macOS 27. Build with clang++ -std=c++23 -o ifprobe ifprobe.cpp and then run it with ./ifprobe. ifprobe.cpp

Following up on TN3135 and the resolution in https://developer.apple.com/forums/thread/773362 — that thread solved establishing a low-level connection on watchOS (the asynchronous AVAudioSession.activate(options:completionHandler:) instead of the synchronous setActive()). This question is about a connection staying established, which I could not find discussed anywhere. Environment: Apple Watch, watchOS 26.6 (23U67). Audio app, WKBackgroundModes = ["self-care"]. Real device, TestFlight build, not the simulator. What works Opening an NWConnection WebSocket to my own server is reliable — 8 attempts out of 8 reached .ready in 0.28–0.98 s, and an echo frame round-tripped in 27–89 ms. Interestingly, in my measurements it opens under BOTH activation variants: the asynchronous activate(options:completionHandler:) AND the synchronous setActive(true). The two are within ~0.2 s of each other. I mention it only because the thread above concluded the synchronous one is insufficient; on 26.6 I cannot reproduce that difference for establishment. What fails The connection goes quiet after roughly half a minute, and an NWPathMonitor running alongside it shows why: the path transitions to .unsatisfied. Four runs: +34.0 s (cellular) +34.6 s (cellular) +36.0 s (Wi-Fi) +34.3 s (companion link only — availableInterfaces ["other", "other"]) The server sends a heartbeat frame every 5 s and closes the socket on a schedule, so I can tell "the peer closed" from "we stopped receiving". The client receives beats 1–6 (5 s … 30 s) and then nothing; the scheduled close never arrives. What I ruled out Server side. The same client construction run on macOS against the same endpoint receives all 8 heartbeats and the scheduled close at 45.1 s. Both audio-session activation variants — no difference, as above. Network type — cellular, Wi-Fi and companion-link-only all drop at ~35 s. The app being suspended. The app keeps logging densely throughout, and in the last run it held a WKExtendedRuntimeSession (delegate reported extendedRuntimeSessionDidStart) and was actively playing audio through AVAudioEngine from the first second — i.e. the audio-streaming condition TN3135 describes — for the entire window. The path dropped anyway, at +34.3 s. An idle socket. Server traffic arrives every 5 s until the drop. The comparison that puzzles me The same app, on the same watch, the same afternoon, relays the same realtime audio session over plain HTTPS (URLSession) instead — and that runs for 64 s continuously without a stall, including straight through a WatchConnectivity "reachability settled: unreachable" transition. So a high-level URLSession request stream survives a period in which a low-level NWConnection's path is reported unsatisfied. That is consistent with the note in thread 773362 that "on watchOS every session is kinda like a background session, where the actual work is done out of process" — but it leaves me unsure what the intended behaviour is. Questions Is a ~35 s path lifetime the expected behaviour for low-level networking on watchOS, or does it indicate something wrong on my side? Does the TN3135 audio-streaming exception cover only the establishment of a low-level connection, or is it also supposed to keep the path available for the duration of the audio streaming? If it is supposed to persist: is there something beyond an active audio session, flowing audio and a WKExtendedRuntimeSession that an app must do to keep the path alive? If ~35 s is the expected ceiling, is a WebSocket a supported transport for a multi-minute conversational audio session on watchOS at all — or is relaying over URLSession the intended approach despite the guidance to prefer Network framework? Happy to file a bug with a sysdiagnose and a reduced sample project if that is more useful — please say the word and I will attach the numbers above.

I'm stuck on what looks like a backend / account-level TestFlight issue and want to ask if anyone has seen the same pattern. Symptoms (reproduced across three consecutive builds) App Store Connect ingests and processes each build successfully; it shows as "Testing" in TestFlight with no compliance warnings. Internal TestFlight install fails instantly on every tester device with: ▎ "The requested app is not available or does not exist." Device console (itunesstored) at install time: FAILED: TFBundleInstallation serverFailureReason="Error Downloading Install Data" userFailureReason="Requested app not available or does not exist" buildGroup=(null) phase=Failed previousPhaseDescription=ProcessingInstallInitiateResponse serverCode 200 Submitting the same build for external Beta App Review returns: 422 ENTITY_UNPROCESSABLE code: BETA_CONTRACT_MISSING buildGroup=(null) for builds that visibly show as "Testing", plus a persistent BETA_CONTRACT_MISSING, suggests the beta-contract / build-group record for the app is missing or corrupted on the backend. Already verified clean on the developer side Distribution certificate and provisioning profile valid; entitlements match the binary; codesign --verify --deep --strict passes. Free and Paid Apps Agreements both Active; no pending tasks (Banking, Tax complete). App Information, Pricing & Availability, Age Rating, Content Rights, Test Information all complete; build page shows no warnings. Reproduced with multiple testers on multiple iOS 17+ devices, in a fresh internal testing group, after device-side cleanup (sign-out / reinstall TestFlight). Re-uploading a fresh build does not clear it — so it is not bound to a specific binary. Questions Has anyone seen Error Downloading Install Data + buildGroup=(null) + BETA_CONTRACT_MISSING together on a single app? How did you resolve it? 2. Why does ProcessingInstallInitiateResponse return serverCode 200 while still failing with "app not available", for a build that shows as "Testing"? 3. Is there a documented path to request that engineering regenerate a corrupted beta-contract / build-group record, beyond a standard support case? Any pointers appreciated — happy to share device logs / sysdiagnose if useful.

Hello Apple Developer Community, I submitted my first iOS app for App Review, but it has been stuck in “Waiting for Review” for 5 days, and the review has not started yet. I also contacted Apple Developer Support and opened a support ticket because I wanted to understand if there was an issue with my submission, but I have not received a response yet. I would like to ask other developers if anyone is currently experiencing the same issue. App Information App Name: AksiyonSoft Tools -Calculator Bundle ID: com.aksiyonsoft.calculator Platform: iOS Status: Waiting for Review Submitted: August 9, 2026 Waiting time: 5 days This is our first iOS app submission, so I would especially appreciate hearing from developers who have recently experienced a similar situation. Is there currently a delay in the App Review queue, or could there be an issue with my submission that is preventing the review from starting? Has anyone else been waiting for 5 days or longer for their app to enter review recently? Any information or recent experience would be greatly appreciated. Thank you.

Just submitted my app on 8/9 and also echoing what others have posted. My issue isn't the wait time, but simply the lack of communication and status. Is this normal? I'm a newer iOS developer and really have nothing to compare it to. Just wild to me to pay for a service and not really have any way to communicate with support. I've escalated via a ticket, which was simply a form, and I also called and waited on hold for more than 2.5 hours before giving up. Any guidance or help would be appreciated. Should I resubmit? I'd hate to lose my place in the queue, but I don't know if I did anything wrong.

Is this typical? I submitted my app for review last Tuesday. When I search for how long App Review takes, the general answer is 24-48 hours. I have received no feedback or anything. I had support call me via "Contact Us" for app review and sat on hold for over 3 hours yesterday only to apparently get transferred to regular Apple support after 5:15pm ET. They didn't know what App Review was and then the line hung up after 15 minutes of being on hold while they figured it out. Currently I'm sitting at 3 hours again on hold for the same. This is a free app with no ads or default permissions which I have to pay them to publish. Is this how Apple operates?

I just upgraded MacOS to Tahoe 26.6.1, and upgraded XCode too. Then Xcode crashes on every launch and is completely unusable. Translated Report (Full Report Below) ------------------------------------- Process: Xcode [1718] Path: /Applications/Xcode.app/Contents/MacOS/Xcode Identifier: com.apple.dt.Xcode Version: 26.6 (24959) Build Info: IDEApplication-24959000000000000~2 (17F113) Code Type: ARM-64 (Native) Role: Background Parent Process: launchd [1] Coalition: com.apple.dt.Xcode [917] User ID: 502 Date/Time: 2026-08-13 11:26:33.1318 +0800 Launch Time: 2026-08-13 11:26:33.0308 +0800 Hardware Model: Mac16,8 OS Version: macOS 26.6.1 (25G76) Release Type: User Crash Reporter Key: ED18B1CA-EA9C-0657-0CF1-1EFA8C60919E Incident Identifier: 8350CBBA-0B41-4A77-B262-CD0662709FB1 Time Awake Since Boot: 47 seconds System Integrity Protection: disabled Triggered by Thread: 0, Dispatch Queue: com.apple.main-thread Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6 Terminating Process: Xcode [1718] Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x1843745e8 __pthread_kill + 8 1 libsystem_pthread.dylib 0x1843af8d8 pthread_kill + 296 2 libsystem_c.dylib 0x1842b5978 abort + 148 3 libsystem_c.dylib 0x1842b5a94 abort_report_np + 84 4 Xcode 0x102624ed0 main.cold.1 + 36 5 Xcode 0x102624e1c main + 340 6 dyld 0x183fe44e4 start + 6992 Thread 0 crashed with ARM Thread State (64-bit): x0: 0x0000000000000000 x1: 0x0000000000000000 x2: 0x0000000000000000 x3: 0x0000000000000000 x4: 0x0000000000000073 x5: 0x000000000000002e x6: 0x000000016d7db278 x7: 0x0000000000000000 x8: 0x61cbe9e2533f85e8 x9: 0x61cbe9e3a3e16468 x10: 0x0000000000000002 x11: 0x00000000fffffffd x12: 0x0000000000000000 x13: 0x0000000000000000 x14: 0x0000000000000000 x15: 0x0000000000000000 x16: 0x0000000000000148 x17: 0x00000001f242f400 x18: 0x0000000000000000 x19: 0x0000000000000006 x20: 0x0000000000000103 x21: 0x00000001f0dee260 x22: 0x0000000102d5cbe0 x23: 0x00000001f0df5908 x24: 0x0000000000000001 x25: 0x000000016d7db6d0 x26: 0x00000001f0defa70 x27: 0x0000000000000000 x28: 0x0000000000000000 fp: 0x000000016d7db3f0 lr: 0x00000001843af8d8 sp: 0x000000016d7db3d0 pc: 0x00000001843745e8 cpsr: 0x40000000 far: 0x0000000000000000 esr: 0x56000080 (Syscall) Binary Images: 0x102624000 - 0x102627fff com.apple.dt.Xcode (26.6) <8025d4bb-71ea-3f57-bade-2e3c847b6cf3> /Applications/Xcode.app/Contents/MacOS/Xcode 0x18436b000 - 0x1843a82e7 libsystem_kernel.dylib (*) <7cfb3a10-adb2-32c4-99b5-922a111b3224> /usr/lib/system/libsystem_kernel.dylib 0x1843a9000 - 0x1843b5b3b libsystem_pthread.dylib (*) <12342372-0084-37a5-9ea6-2e4dc940c685> /usr/lib/system/libsystem_pthread.dylib 0x18423d000 - 0x1842be1e7 libsystem_c.dylib (*) <fdc4e366-5c14-3a1e-bc35-d933d28cdcf3> /usr/lib/system/libsystem_c.dylib 0x183fc4000 - 0x1840774ff dyld (*) <df42dd9d-ad11-33a7-8849-9ad5df30a274> /usr/lib/dyld 0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???

I have an individual Developer Program account (Team ID 9KS979K27N) with an incorrect legal entity record, and no way to fix it myself. The record shows my name in a shortened form, "Balder Adelgaard", and a former address in Denmark. My actual legal name is Balder Berg Adelgaard — as it appears on my passport, my Hellenic Police residence registration, and my Greek tax filings — and I now live in Chania, Greece. In the Edit Legal Entity dialog, the Name and Country or Region fields are both read-only, so I cannot correct either. The consequences: DSA trader verification failed on 9 August. Developer Support told me the likely causes are insufficient documentation or mismatched information. My identity documents cannot match a record showing a different name and a different country. Until this clears, I can't distribute in the EU. The W-8BEN and U.S. Certificate of Foreign Status pull Country of Incorporation and Permanent Residence from this record, read-only. Submitting them would certify the wrong country of tax residence, and they can't be amended afterwards. So I can't complete tax forms, can't add banking, and Paid Apps stays in Pending User Info. I opened case 20000126301700 on 2 August requesting the address correction. Twelve days, no reply. The related DSA case is 20000126290870. Is there a route to get a legal entity record corrected when the fields are locked? Has anyone had this resolved, and through which channel?

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.

[Q] Is it a known issue that the Xcode static analyzer hallucinates past results? Basically, the issue I've been observing for a few releases of Xcode now (including 27b) is that if you run a static analysis, fixes the reported issues and re-run a static analysis, you will get exactly the same results as with the first run. It's as if Xcode did not take into account the fixes. If you clean the builds (cmd + shift + K), and run the analysis again, this time, you will get up-to-date results.

Is anyone else getting these assertion crashes on developer beta 3 of Golden Gate? I've gotten more than a dozen crash logs from users running macOS 27 (26A5378j) that all look like this: assertion failed: '<NSRemoteView: 0x79cb366700 com.apple.SafariPlatformSupport.Helper SPCompletionListServiceViewController> notified of <NSStatusBarWindow: 0x79cbef7480> but expected (null)' in -[NSRemoteView containingWindowWillOrderOnScreen:] on line 4221 of file /AppleInternal/Library/BuildRoots/4~CSuOugB1YCxzYMPRWEumvvfCTNtf98eItTmsbJU/Library/Caches/com.apple.xbs/TemporaryDirectory.N8fh9t/Sources/ViewBridge/NSRemoteView.m but with various windows from my app after "notified of". They're getting thrown when one of my windows is made frontmost, either using NSWindow.orderFrontRegardless or NSWindow.makeKeyAndOrderFront, or (in the case above) when my status item is shown. It's intermittent - I've been unable to reproduce it so far - but definitely happening repeatedly based on my Sentry crash logging. Is this a bug in Golden Gate b3, or am I doing something to provoke this? I've submitted it via Feedback Assistant (FB23642313). Thanks Jon P.S. Full stack trace attached for the exception thrown when the assertion fails for NSStatusBarWindow NSInternalInconsistencyException stack trace.txt

Greetings! We are experiencing an issue with Apple iPad 9th generation devices. A stationary iPad may lose connection with a 5 GHz Wi-Fi network. We ran an investigation and found that these iPads are getting stuck on access points when losing connectivity. Here is what we tested: We took 3 devices: iPad 9th generation running iPadOS 17.4.1 iPad 9th generation running iPadOS 26.5.2 iPad 11th generation running iPadOS 26.5.2 We walked around our space with Wireless Diagnostics enabled on the iPads. After some time, we compared the gathered logs. The iPad 9th generation, working on different iPadOS, when connected to a 5 GHz network, gets stuck on one AP. The 2.4 GHz network, on the other hand, works as intended regardless of the authentication method. The iPad 11th generation does not have this issue. Please confirm if this is a known problem. We would be glad to know if there are any fixes available. Attached you will find obfuscated wireless diagnostic logs. We can provide more detailed logs if needed. iPad_wireless_logs.txt