“We are unable to process your request”

[quote='820645021, Np_dev, /thread/820645, /profile/Np_dev'] Raised a feedback assistant request … FB22339653 [/quote] Thanks for that. A bug report is clearly the correct path forward here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’m not sure what’s causing the main error here, but let’s start with endpoints, and specifically my NWEndpoint History and Advice post. This explains the general landscape. NEAppProxyUDPFlow has read and write methods that use Network.NWEndpoint type. See here and here. These are the Swift async versions; there are also equivalent completion handler versions. In terms of how to handle endpoints, it’s best to approach this from the perspective of the client, that is, the DNS client that’s issuing DNS requests to resolve queries. And specifically a BSD Sockets client, which will: Open a socket. Optionally connect the socket to an endpoint (aka address). Send a datagram. If it connected the socket, it can call one of the send routines that doesn’t take an endpoint. If it didn’t connect the socket, it must supply an endpoint at this point. Receive a datagram, along with the source of that datagram. From your perspective steps 1 and 2 result in a new flow. If you want to know what endpoint the client con

[quote='820631021, Pavel, /thread/820631, /profile/Pavel'] Is it possible for a Network Extension … to act as a client for an XPC service hosted by a Launch Daemon … ? [/quote] Yes. The trick is to use an app group. Sign your client with an app group ID and then, in the MachServices property of the launchd daemon, set the XPC endpoint name to be a ‘child’ of that app group ID. See the discussion in App Groups Entitlement. App groups are a bit tricky on the Mac. See App Groups: macOS vs iOS: Working Towards Harmony for the full backstory. Given that your client is sandboxed, it must claim access to that app group ID. And in that case I strongly recommend that you authorise that claim via a provisioning profile. Your launchd daemon is (presumably) not sandboxed so it doesn’t need to claim access to the app group ID. However, if you decide to make that claim then my recommendation applies there as well: Authorise the claim with a provisioning profile. If you claim access to an app group and don’t authorise that

[quote='820695021, blackson, /thread/820695, /profile/blackson'] when NetworkExtension Activiate. [/quote] What do you mean by “NetworkExtension Activiate”? The Network Extension framework has many different subsystems, many of which can affect the Wi-Fi join process, so I need to understand which one is involved before I can offer any guidance. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I want to be clear about where things stand. My developer account renewal was processed and payment of £79 cleared my bank on 12 March. I have a bank statement confirming this. The account was therefore active and paid in full — I am not in arrears. Despite this, my app has been removed from App Store Connect and I am now being asked to pay again. This is unacceptable. I will not pay twice for the same membership period. I have two requests: Confirm receipt of the 12 March payment against my account (Team ID: AW699Z7G8H) and restore my app listing immediately. If Apple cannot locate the payment, I will provide my bank statement as proof of transaction and expect the app to be restored upon receipt. If neither of these is actioned, I will have no choice but to dispute the original charge with my bank and submit a formal complaint. I would prefer to resolve this without escalation — but four months of unresolved support and case 102841743378 still open leaves me with limited options. Please es

Same here. Updated xcode & simulator yesterday and out of sudden ios apps when started show a white screen for seconds before the main application screen (i.e. a splashscreen) appears. Added print() to trace but it looks the delay happens not in user code. Looks like loading libs during the startup process takes ages before user code starts running.

I can already tell you, nothing works for me anymore. I updated to macOS 26.4. This morning, it updated Xcode to 26.4 as well. As a result, I had to reinstall Codex, which I did. I logged in, and now nothing works at all. I can submit a request in the chat, sometimes I get a short response, and then it starts thinking about something and never stops. I think it is amazing what kind of unfinished mess Apple is delivering once again. This is absolutely unbelievable. I am furious that such a broken system is being provided to us developers. It would be the easiest thing for Apple to simply test Codex. If they are not even providing us with the latest Codex versions and instead releasing outdated versions with their Xcode, it is outrageous that we are given something so completely unfinished and nonfunctional. With macOS 26.3 and Xcode 26.3, I was at least able to program perfectly fine with Codex and developed several apps. Now I wake up in the morning, want to continue working on my apps, and great job

I have hit this exact crash pattern in my own ScreenCaptureKit audio capture pipeline. The EXC_BAD_ACCESS in swift_getErrorValue happens because the error object passed to didStopWithError is being deallocated before the delegate method can access it — it is a race condition in the XPC boundary between replayd and your process. The root cause in my case was that the SCStream object was being deallocated (or stopCapture was called) while a pending error was being delivered across the XPC connection. The error object lives in replayd's address space and gets bridged to your process, but if the stream tears down mid-delivery, you get a dangling pointer. Keep a strong reference to the SCStream instance beyond the point where you call stopCapture. Do not nil it out immediately. In your stream delegate, wrap the didStopWithError handler in a DispatchQueue.main.async to ensure the error is fully materialized before you access it: func stream(_ stream: SCStream, didStopWithError error: Error) { let

I ran into exactly this problem when building an audio pipeline that mixes system audio (via ScreenCaptureKit) with microphone input for real-time speech processing. The core issue is that mainMixerNode is connected to outputNode by default, which routes everything to speakers. You have two approaches: In manual rendering mode, AVAudioEngine does not play back to hardware — you pull rendered buffers on your own schedule. Enable manual rendering, attach a player node for your SCK audio, connect it to the main mixer, then call renderOffline() to pull mixed audio on demand. The catch: inputNode does not work in offline mode on macOS. The workaround is to capture mic samples separately (via AVCaptureSession or a tap on a separate realtime engine), then schedule those buffers into a second AVAudioPlayerNode. Keep the engine in realtime mode but prevent playback by setting mainMixerNode.outputVolume = 0. Then install a tap on mainMixerNode to capture the mixed audio without speaker feedback. I tried discon

@HenryToti Thanks — that output shows all of Apple's servers are reachable and not blocked at the network or DNS level, which is what I was looking for. Beyond that, we need the requested bug report and sysdiagnose for a much fuller view of the situation. — Ed Ford,  DTS Engineer