“DTiPhoneSimulatorErrorDomain Code 2”

While the code is being executed, a stop button appears, but after the code is finished, there is no undo button; it returns to the message screen shown in the previous message.

I'll start with the short answer, then follow with more details: Should offline media downloads generally be treated as “important usage” in the sense intended by this API? Yes, you should be using important. You might also look at the availability key, but mainly as a diagnostic tool to tweak your app’s behavior, not to fundamentally alter what you do. For example, if you're downloading very large files very quickly, it's possible for you to be adding new important data to the device faster than the device can delete cache data, which will cause available to spike to a low value. If that happens, simply waiting for a little while may resolve the issue. Similarly, if available and opportunistic are both low and your app stores large amounts of cached data, then you might want to delete your own cached data during/before you transfer in important data. but I still don’t fully understand the intended usage difference between: So, let me lay out the meaning of the three keys: volumeAvailableCapacityKey-> This

Thanks for posting and for sharing the repo — being able to look at the actual code makes a real difference here. The phone-restart class of crash matters. App-level Metal exceptions normally crash the app, not the device. A full phone reboot from a compute shader means whatever's failing crossed out of user-space into the GPU driver or kernel. That can happen two ways: A driver-side bug provoked by some specific user-space pattern, which would be a Metal/driver issue Apple needs to address. Memory corruption in your app — for example, an over-write of an MTLBuffer's contents past its allocated size, a stale gpuResourceID for a resource that's been freed, a race between threads populating argument-table entries, or wrong format/stride assumptions — that lands the GPU on garbage data and the driver panics. Allocator layouts and hardening change between iOS versions, so a dormant memory issue under beta 3 can become a reliable kernel panic under beta 4. The worked, then stopped working timing

Thank you Quinn for these additional details. In the meantime, we have been able to make some progress here. To recap, the error message we have been investigating is the following one when codesign command is executed on a host, let's say H2, to do adhoc signing of some binary: $> /usr/bin/codesign -s - -vvvv --force /home/me/FooBarCalculator.app /home/me/FooBarCalculator.app: replacing existing signature /home/me/FooBarCalculator.app: signed app bundle with Mach-O thin (arm64) [Hello] /home/me/FooBarCalculator.app: timestamps differ by 185 seconds - check your system clock codesign then exits with a non-zero exit code and thus errors out. Our investigation so far shows that the message about timestamps differing turns out to be misleading. What we have been able to narrow down is that, if on some host H1, a binary (FooBarCalculator.app in this case) was signed with a (valid) identity and if for whatever reason, during codesigning there was a timestamp difference, then that difference gets embedd

Thanks for the careful diagnostic work. Two observations from your post jump out: Same source code, two builds: the Xcode 16.4 / iOS 18 SDK build runs correctly in iOS 26, the Xcode 26 / iOS 26 SDK build does not. The page itself runs correctly in Safari with Web Inspector attached. Together, those localize the problem to how the WKWebView is being set up or driven inside your app at the iOS 26 SDK build, rather than the page or the device. The some JavaScript executes while others don't pattern is the most useful clue for narrowing further. That pattern is consistent with WKContentWorld isolation in WKWebView. WKContentWorld separates JavaScript execution into distinct namespaces: The page world (WKContentWorld.pageWorld) — JavaScript executed here can see page-defined globals, including functions defined in the page's

Part 2... Getting into the sequence here: The Dock icon disappears — loginwindow removes the app's UI via its applicationQuit event, even though the process is still running The system was told to quit the app, so the first step was to remove its visible parts, like its dock icon. LaunchServices loses track of the application's PID — it can no longer determine the PID from the LSASN The system removed it from system #2, so it disappears from LaunchServices. Now, there's some interesting nuance here: When I respond with ES_AUTH_RESULT_DENY to an AUTH_SIGNAL event targeting a GUI application, the system enters an inconsistent state: I don't think that's actually true, at least not on its own. That is, if you send kill -9 from the terminal, I don't think any of the above would happen. What I'd expect to happen is that your app just sits there doing nothing and continues working normally. That's because there are two different ways for an app to disappear. The first is that the system n

Part 1... Hypothesis: loginwindow observes the AUTH_SIGNAL event (or a related notification) and proactively removes the Dock UI entry when a termination signal targets a GUI app — regardless of whether the signal was ultimately denied. This seems like a coordination gap between EndpointSecurity's signal interception and loginwindow/LaunchServices' app lifecycle management. No, that’s what's going on. What's actually going on is that the system has two different systems that track stuff that's running on the system: The low level system is the POSIX pid-based mechanism you're familiar with. This is also the level the ES system operates at and is the core mechanism used to track processes. Every process running on the system exists within this system. The high level system is built on top of #1 and is what manages the concept of Apps. It doesn't have as clear an API layer (much of its API is private), but its origins were the Carbon Process Manager and it's what APIs like LaunchServices and NSWorkspac

A similar question was discussed here. The error code is different (3 vs. 8), but the technical nature is pretty much the same: The error was triggered by the framework, and is not something that can be fixed from the app side. SwiftData + CloudKit creates a new task when it detects that the previous task failed, or that there is unsynchronized data, which can eventually get the data synchronized. So in case your app data is synchronized, you can ignore the error. If your app doesn’t synchronize data at all, that will be a coding level issue on your side, and you can follow TN3164 and TN3163 to debug the issue. Best, —— Ziqiao Chen  Worldwide Developer Relations.