Defaults

Summary Apps using with one or more keys declared crash on launch or on foreground/background wake-up with . The abort comes from the Swift Concurrency runtime's task-allocator LIFO check, fired from inside the closure that yields to . The crash is reproducible across iOS 16, 17, and 18, multiple devices, and at least two distinct app versions, so it doesn't look OS- or app-specific. I have 23 byte-identical crash reports with the same offset in and the same line in the consumer. Environment version: 9.0.8 (current). The affected code paths are unchanged since the 9.0 iCloud-sync work landed, so likely affects all 9.x. Reproduces on: iOS 16.7.15 (iPhone X) — 10 reports iOS 17.4.1 (iPhone 11) — 6 reports iOS 17.7.2 (iPhone 11) — 3 reports iOS 17.5.1 (iPhone 13 mini) — 3 reports iOS 18.4 (iPhone 13) — 1 report (older app build, ) Both (cold launch) and (background wake-up). App declares 31 keys with . iCloud KV-store entitlement is enabled and the affected users have non-default payloads in their remote KV-store (i.e. takes the inner branch, not the empty-guard fast path). Crash signature is the runtime's LIFO bump-allocator check. The fatal-error message that prints to the system log immediately before the abort is the standard Concurrency one (along the lines of "freed pointer was not the last allocation"); it doesn't appear in the crash report itself but should be reproducible in Console. Steps to reproduce This is what's strongly indicated by the corpus; I haven't yet boiled it down to a standalone minimal repro target. 1. Declare several keys (the affected app has 31, but it likely reproduces with fewer). 2. Sign in to iCloud on a device/simulator with the app's iCloud KV-store entitlement active. 3. Populate with non-default values for those keys, so enters the arm (, lines 401–406). 4. Cold-launch the app, or trigger any path that fans out many calls in quick succession (initial registration, , ). 5. Crash in 's closure when the runtime tries to pop the binding. Suspected cause The dangerous composition is the way wraps : When 's parent task is resumed by an unstructured (cross-actor resume) inside an enclosing binding running on a consumer of an , the task allocator's pairing of pushes/pops can end up non-LIFO on unwind. Specifically, the continuation context allocated on the parent task's bump allocator can outlive the TaskLocal binding pushed above it by one frame, and when then pops its binding, the runtime sees the top-of-stack isn't the binding and aborts. Each individual API used here is legal Swift Concurrency; the failure is in the composition. Since this is happening on iOS 16, 17, and 18 in the same way, it isn't a runtime regression on a single OS — it's the pattern itself that the runtime fails to pair safely. What might fix it on the side This is just a suggestion — not tested. Replacing the pattern with a direct keeps the semantics (block until the main-actor write completes) but removes the cross-actor continuation resume that's tripping the allocator: is available on the package's current minimum platforms (iOS 15+, macOS 12+). I haven't verified this clears the crash in practice — I can do that and open a PR if helpful. Notes / things I'm not yet sure about I haven't captured the exact pre-abort fatal-error string from Console for any of the reports yet. The stack alone strongly implies the LIFO check, but the string would close that gap. I haven't -resolved the offset against a local Release build to confirm it lands on the unwind specifically. Happy to do that if it helps. in also spawns an orphaned that isn't stored anywhere — separate concern, but worth flagging while looking at this area.

Since updating to XCode 16, the following error is thrown in the Defaults package: "Accessing StateObject's object without being installed on a View. This will create a new instance each time." !image I'm using the package in one view only: Am I using it wrong? Before, in XCode 15, this error did not show up. And I'm using the latest main branch commit.