“We are unable to process your request”

I'm seeing it take 1-5 minutes on launch on Xcode 26.4 (most often around 2m). As suggested, when turning off debug executable, it launches as expected. FB22353872. I've added the requested traces. This also happens when running unit tests via Cmd-U (which is also configured with debug executable).

I'd like you to try something — go into your scheme, and uncheck Debug Executable from the Run tab. When you click Run, Xcode will run your app with going through the process to attach LLDB. Does the launch performance after this look more like you're expecting? If so, we'd really appreciate getting diagnostics so we can look into the root cause of this slow down. Add the following to your ~/.lldbinit file, and the restart Xcode to ensure this is enabled: log enable gdb-remote packets --timestamp -f /tmp/log_packets.txt Before you launch your app, run the following in Terminal: sample lldb-rpc-server 60 --wait -file /tmp/sample.txt Attach both of those files that those commands placed in /tmp on your bug report, and let me know here when that's done. I also suggest removing the log line from ~/.lldbinit so it's not always logging debugger packets. @Code4Food, it'd be helpful if you could run the same tests and collect the same data, and attach them to your own bug report. Please post the FB number he

I've found a solution. I need to delete subscription products with status Developer Action Needed and create a new one. This needs changing product id and fixing app for new ids... Apple, fix your process, it's buggy.

What I’m trying to understand is whether Apple supports any path for this on macOS that does NOT require restricted entitlements or paid-program-only capabilities. So, let me lay out the state of things that you listed: Both DriverKit and Core HID require restricted entitlements. All DriverKit entitlements have Development Only variants which allow those entitlements to be used in development signed builds without any approval (they're added through the portal like any other entitlement). Virtual Core HID does not currently have a development variant, but that's an issue I'm looking into correcting (r.173531752). In both cases, that means using these entitlements currently requires joining the paid program. If you'd like to see us expand these to the free account as well, please file a bug asking for that and then post the bug number back here. Also, to be clear, that is a serious request - I'd like to look at expanding the availability of these entitlements, but that's hard to justify without a bit

This has been happening to me as well. I have 7 apps. Everything was fine and then last week, all apps (builds) were removed from TestFlight. No explanation, just gone. Each new build I upload now shows in TestFlight but I cannot install any of them: “The requested app is not available or doesn't exist”. I have attempted to contact Apple through the “unhelpful” portal but no response. i have tried calling various Apple support lines but they all tell me there is nothing they can do. I need to contact Apple Developer Support. They dont have a number, It must be done through the portal. Super Frustrating!

Same for me. This process is definitely broken or unclear.

I suspect it was a FILE_NOTIFY_CLOSE. Are you sure it isn't an auth event? Also, are you using separate es_client_t's for your notify and auth events? The timing issue I outlined is theoretically possible in both cases, but MUCH easier to do with auth events. It would be insightful to know if APFS triggers that or related ES events when decompressing a file. Open is what typically triggers decompression; however, in this case, revisiond was actually deleting a file (by calling remove on its path), so it's pretty likely that they had closed it just prior to the remove call. I will submit unified logs that cover the period in question, but your point remains. I'll try and take a look, but I'm not necessarily optimistic. Frankly, these issues generally have a high degree of uncertainty about them, so my comment there was really about acknowledging that reality. Not that our ES hooks are directly causing the deadlock, but that by hooking certain OS events and quickly acting on them, we're exercising the file syst

Given that you'd move the Core Data store to a group container, I'd assume that the store will be shared across different processes, such as your main app and its extension (a widget, for example). In that case, I'd like to start with pointing you the following threads: Core Data Light Migration Crash When Widget is Installed (Error 134100). CoreData error=134100 Failed to open the store. These threads made it clear that: After a user installed your new version app, depending on what extension you have, the app and extension can open and migrate the store simultaneously, and so you will need to implement a mechanism to make sure that the store is only migrated once. Consider having your main app in charge of the the synchronization, as discussed in Avoid synchronizing a store with multiple persistent containers. Now to your questions: Store relocation vs schema migration Is it advisable to perform store relocation and schema migration in a single step, or should these be separate releases? If combine

ive been having this for 2-3 months now all i get is the same error after receiving the TestFlight invite, i get the Code, redem the code, App shows up, but when i try to install it, i get ERROR message. ( Could Not in Stall APP NAME. The Request App is Not Avalible or Doesn't Exist.) Even though it an new APP i just created. i have like 25 Apps with install next to the APP Name and each app Gives me the Same Error Message. I think Apple/TestFlight needs to Address this issue. this happens on my Iphone and Tablet.

Hi, this will reproduce it. It is not limited to just this GPS coordinate, all our GPS coordinates being polled are now failing. curl -vvv -H Authorization: Bearer YOUR_OWN_TOKEN_HERE https://weatherkit.apple.com/api/v1/weather/en/43.741667/-79.373333?dataSets=currentWeather&timezone=UTC&units=si Here's what the output is: * Host weatherkit.apple.com:443 was resolved. * IPv6: (none) * IPv4: 23.58.127.73, 23.58.127.72, 23.58.127.75, 23.58.127.81, 23.58.127.80, 23.58.127.74, 23.58.127.83, 23.58.127.120, 23.58.127.82 * Trying 23.58.127.73:443... * Connected to weatherkit.apple.com (23.58.127.73) port 443 * ALPN: curl offers h2,http/1.1 * (304) (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/cert.pem * CApath: none * (304) (IN), TLS handshake, Server hello (2): * (304) (IN), TLS handshake, Unknown (8): * (304) (IN), TLS handshake, Certificate (11): * (304) (IN), TLS handshake, CERT verify (15): * (304) (IN), TLS handshake, Finished (20): * (304) (OUT), TLS handshake, Finished (20): * SSL connec