I have been using the SCNetworkReachabilityGetFlags for 10+ years to inform users that their request won't work. In my experience this works pretty well although i am aware of the limitations.
Now, i am looking into the NWPathMonitor, and i have one situation that i'm trying to. get my head around - it's asynchronous.
Specifically, i am wondering what to do when my geofences trigger and i want to check network connectivity - i want to tell the user why the operation i'll perform because of the trigger couldn't be done.
SO. say i start a NWPathMonitor in didFinishLaunchingWithOptions. When the app is booted up because of a geofence trigger, might i not end up in a case where my didEnterRegion / didExitRegion gets called before the NWPathMonitor has gotten its first status?
The advantage here with SCNetworkReachabilityGetFlags, as i understand it, would be that it's synchronous?
If i want to upgrade to nwpathmonitor, i guess i have to do a method that creates a nwpathmonitor, uses a semaphore to wait for the first callback, then contunues?
Thoughts appreciated
Delve into the world of built-in app and system services available to developers. Discuss leveraging these services to enhance your app's functionality and user experience.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I've been trying to add a CoreSpotlight indexer to my macOS application. The new template for the indexer uses the new appex CSImportExtension style importer.
I've been following this ->
https://developer.apple.com/documentation/corespotlight/csimportextension
I changed the CSSupportedContentTypes in the Info.plist file to the correct file type uti.
I added a dummy value into the attributes (see code below) - just setting contentDescription to 'noodle' (easy to search for)
class ImportExtension: CSImportExtension {
override func update(_ attributes: CSSearchableItemAttributeSet, forFileAt: URL) throws {
// Add a dummy value, and see whether spotlight finds it
attributes.contentDescription = "noodle"
}
}
I have a number of files on disk that match the uti (and can be found when I search by the file name)
Yet, when I build and run my app, the a spotlight search for 'noodle' finds no results.
Can anyone give me any advice? I cannot find any indication that the ImportExtension is called (although when I put a log message at the start of the update() call there's no message in the console which seems to suggest it's not being called).
Is there any way of debugging this?
Cheers and thanks -- Darren.
I was excited to find out about Wi-Fi Aware in i[Pad]OS 26 and was eager to experiment with it. But after wiping and updating two devices (an iPhone 11 Pro and a 2018 11" iPad Pro) to Beta 1 I found out that neither of them support Wi-Fi Aware 🙁.
What current and past iPhone and iPad models support Wi-Fi Aware?
And is there a new UIRequiredDeviceCapabilities key for it, to indicate that an app requires a Wi-Fi Aware capable device?
MacOS(Apple Silicon) IOKit driver for FPGA DMA transmission, kernel panic.
Hardware and software configuration:
MAC mini M1 2020 16GB, macOS Ventura 13.0 or 13.7.8
FPGA device capability: 64-bit
Complete description:
We've developed a DMA driver for PCIe devices (FPGA) based on IOKit. The driver can start normally through kextload, and the bar mapping, DMA registers, etc. are all correct. I am testing DMA data transmission, but a kernel panic has occurred. The specific content of the panic is as follows:
{"bug_type":"210","timestamp":"2026-01-28 14:35:30.00 +0800","os_version":"macOS 13.0 (22A380)","roots_installed":0,"incident_id":"61C9B820-8D1B-4E75-A4EB-10DC2558FA75"}
{
"build" : "macOS 13.0 (22A380)",
"product" : "Macmini9,1",
"socId" : "0x00008103",
"kernel" : "Darwin Kernel Version 22.1.0: Sun Oct 9 20:14:30 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T8103",
"incident" : "61C9B820-8D1B-4E75-A4EB-10DC2558FA75",
"crashReporterKey" : "6435F6BD-4138-412A-5142-83DD7E5B4F61",
"date" : "2026-01-28 14:35:30.16 +0800",
"panicString" : "panic(cpu 0 caller 0xfffffe0026c78c2c): "apciec[pcic0-bridge]::handleInterrupt: Request address is greater than 32 bits linksts=0x99000001 pcielint=0x02220060 linkcdmsts=0x00000000 (ltssm 0x11=L0)\n" @AppleT8103PCIeCPort.cpp:1301\nDebugger message: panic\nMemory ID: 0x6\nOS release type: User\nOS version: 22A380\nKernel version: Darwin Kernel Version 22.1.0: Sun Oct 9 20:14:30 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T8103\nFileset Kernelcache UUID: C222B4132B9708E5E0E2E8B8C5896410\nKernel UUID: 0BFE6A5D-118B-3889-AE2B-D34A0117A062\nBoot session UUID: 61C9B820-8D1B-4E75-A4EB-10DC2558FA75\niBoot version: iBoot-8419.41.10\nsecure boot?: YES\nroots installed: 0\nPaniclog version: 14\nKernelCache slide: 0x000000001d1b4000\nKernelCache base: 0xfffffe00241b8000\nKernel slide: 0x000000001e3f8000\nKernel text base: 0xfffffe00253fc000\nKernel text exec slide: 0x000000001e4e0000\nKernel text exec base: 0xfffffe00254e4000\nmach_absolute_time: 0x907c3082\nEpoch Time: sec usec\n Boot : 0x6979adbb 0x00023a6a\n Sleep : 0x00000000 0x00000000\n Wake : 0x00000000 0x00000000\n Calendar: 0x6979ae1a 0x00064953\n\nZone info:\n Zone map: 0xfffffe1000834000 - 0xfffffe3000834000\n . VM : 0xfffffe1000834000 - 0xfffffe14cd500000\n . RO : 0xfffffe14cd500000 - 0xfffffe1666e98000\n . GEN0 : 0xfffffe1666e98000 - 0xfffffe1b33b64000\n . GEN1 : 0xfffffe1b33b64000 - 0xfffffe2000830000\n . GEN2 : 0xfffffe2000830000 - 0xfffffe24cd4fc000\n . GEN3 : 0xfffffe24cd4fc000 - 0xfffffe299a1c8000\n . DATA : 0xfffffe299a1c8000 - 0xfffffe3000834000\n Metadata: 0xfffffe3f4d1ac000 - 0xfffffe3f551ac000\n Bitmaps : 0xfffffe3f551ac000 - 0xfffffe3f5ac94000\n\nCORE 0 recently retired instr at 0xfffffe002569d7a0\nCORE 1 recently retired instr at 0xfffffe002569eea0\nCORE 2 recently retired instr at 0xfffffe002569eea0\nCORE 3 recently retired instr at 0xfffffe002569eea0\nCORE 4 recently retired instr at 0xfffffe002569eea0\nCORE 5 recently retired instr at 0xfffffe002569eea0\nCORE 6 recently retired instr at 0xfffffe002569eea0\nCORE 7 recently retired instr at 0xfffffe002569eea0\nTPIDRx_ELy = {1: 0xfffffe2000c23010 0: 0x0000000000000000 0ro: 0x0000000000000000 }\nCORE 0 PVH locks held: None\nCORE 1 PVH locks held: None\nCORE 2 PVH locks held: None\nCORE 3 PVH locks held: None\nCORE 4 PVH locks held: None\nCORE 5 PVH locks held: None\nCORE 6 PVH locks held: None\nCORE 7 PVH locks held: None\nCORE 0 is the one that panicked. Check the full backtrace for details.\nCORE 1: PC=0xfffffe00279db94c, LR=0xfffffe00260d5d9c, FP=0xfffffe8ffecaf850\nCORE 2: PC=0xfffffe0025be76b0, LR=0xfffffe0025be7628, FP=0xfffffe8fff08f5f0\nCORE 3: PC=0x00000001c7cacd78, LR=0x00000001c7cacd84, FP=0x000000016f485130\nCORE 4: PC=0xfffffe002557f55c, LR=0xfffffe002557f55c, FP=0xfffffe8ffe1dff00\nCORE 5: PC=0xfffffe002557f55c, LR=0xfffffe002557f55c, FP=0xfffffe8fff5eff00\nCORE 6: PC=0xfffffe002557f55c, LR=0xfffffe002557f55c, FP=0xfffffe8ffed8bf00\nCORE 7: PC=0xfffffe002557f55c, LR=0xfffffe002557f55c, FP=0xfffffe8fff11bf00\nCompressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space\nPanicked task 0xfffffe1b33aad678: 0 pages, 470 threads: pid 0: kernel_task\nPanicked thread: 0xfffffe2000c23010, backtrace: 0xfffffe8fff6eb6a0, tid: 265\n\t\t
...
Kernel Extensions in backtrace:\n com.apple.driver.AppleT8103PCIeC(1.0)[A595D104-026A-39E5-93AA-4C87CE8C14D2]@0xfffffe0026c619d0->0xfffffe0026c86c97\n dependency: com.apple.driver.AppleARMPlatform(1.0.2)[11A9713E-6739-3A4C-8571-2D8EAA062278]@0xfffffe0025f13ff0->0xfffffe0025f6255f\n dependency: com.apple.driver.AppleEmbeddedPCIE(1)[E71CBCCD-AEB8-3E7B-933D-4FED4241BF13]@0xfffffe002654e0b0->0xfffffe00265684c7\n dependency: com.apple.driver.ApplePIODMA(1)[A419BABC-A7A3-316D-A150-7C2C2D1F6D53]@0xfffffe00269a24b0->0xfffffe00269a6c3b\n dependency: com.apple.driver.IODARTFamily(1)[03997E20-8A3F-3412-A4E8-BD968A75A07D]@0xfffffe00275bcf50->0xfffffe00275d0a3f\n dependency: com.apple.iokit.IOPCIFamily(2.9)[EC78F47B-530B-3F87-854E-0A0A5FD9BBB2]@0xfffffe0027934350->0xfffffe002795f3d3\n dependency: com.apple.iokit.IOReportFamily(47)[843B39D3-146E-3992-B7C7-960148685DC8]@0xfffffe0027963010->0xfffffe0027965ffb\n dependency: com.apple.iokit.IOThunderboltFamily(9.3.3)[B22BC005-BB7B-32A3-99C0-39F3BDBD8E54]@0xfffffe0027a5e3f0->0xfffffe0027b9a1a3\n\nlast started kext at 1915345919: com.sobb.pcie-dma\t1.0.0d1 (addr 0xfffffe00240e47f0, size 9580)\nlast stopped kext at 1774866338: com.sobb.pcie-dma\t1.0.0d1 (addr 0xfffffe00240e47f0, size 9580)\nloaded
It seems that the DMA request address initiated by FPGA exceeded 32 bits, which was intercepted by PCIe root port and resulted in a kernel panic.This is also the case on macOS (M2).
I have tried the following code interface:
IOBufferMemoryDescriptor:
a. withCapacity(bufferSize, kIODirectionInOut, true);
b. inTaskWithPhysicalMask(kernel_task, kIODirectionInOut, bufferSize, 0x00000000FFFFFFFFULL)。
The physical addresses of the constructed descriptors are all >32 bits;
IODMACommand:
a. withSpecification(kIODMACommandOutputHost64, 64, 0, IODMACommand::kMapped, 0, 0),gen64IOVMSegments() The allocated IOVM address must be>32 bits, which will generate a kernel panic when used later.
b.withSpecification(kIODMACommandOutputHost32, 32, 0, IODMACommand::kMapped, 0, 0),gen32IOVMSegments() The allocation of IOVM failed with error code kIOReturnenMessageTooLarge.
So after the above attempts, the analysis shows that the strategy of Dart+PCIe root port on macOS (Apple Silicon) is causing the failure of 64 bit DMA address transfer.
I have two questions:
a. Does Dart in macOS (Apple Silicon) definitely not allocate <=32-bit IOVM addresses?
b. Is there any other way to achieve DMA transfer for FGPA devices on macOS (Apple Silicon)?
Thanks!
Since upgrading to Mac OS 10.5 Beta-2, daemons launched with launchctl are failing to open Desktop/Documents/Downloads files and folders even in read mode with an error "Operation not permitted".Does anyone facing this issue?
After pairing and having subscribed to a service, and even after having exchanged messages, the service fails after a period of time and both devices need to pair again.
Topic:
App & System Services
SubTopic:
Networking
I'm reaching out to see if anyone else is experiencing issues with the Live Caller ID feature on iOS. We recently encountered a problem where the feature stopped working entirely.
Here's a brief overview of the situation:
We were monitoring test traffic on our backend and noticed everything came to a halt around 1:00 AM UTC on November 15th.
After this time, any attempts to reach our backend through calls failed completely.
I tested this across multiple devices running iOS 18.2 and iOS 18.0.
I used both TestFlight builds and development builds via Xcode, which should communicate directly with our backend.
I experienced the problem on our main application as well as a dedicated test app.
To troubleshoot further, I even set up a local server on localhost and tried directing requests there, but the requests did not reach the local server when a call was received.
Further debugging in Console.app revealed the following error:
identity request returned error: Error Domain=com.apple.CipherML Code=400 "Error Domain=com.apple.CipherML Code=401 "Unable to request data by keywords batch: failed to fetch token issuer directory"
However, when I manually tried to hit our server endpoint using curl, the request successfully reached the server:
curl https://our_server/something
hb_method=GET hb_uri=/something [Hummingbird] Request -- log on backend
This suggests that while our backend is responsive, the requests from the iOS client side are simply not being initiated.
I wrote an AppleScript that takes a bunch of scanned jpegs with systematically named filenames and transfers information from the filename into the date and time fields. That all works fine, but I've got many more scans to do and I'd like to augment the script to include a progress meter because it takes a long time to run on e.g. 1000 photos.
I've found basic progress meter examples online that involves commands like:
set progress total steps to theImageCount
set progress completed steps to 0
set progress description to "Processing Images..."
set progress additional description to "Preparing to process."
and they run OK in a separate dummy test case, however I'm getting syntax errors for such commands in my renaming script because (I think) they're inside a
tell application "Photos"
wrapper and it looks like Photos doesn't like those commands.
A progress meter (in any AppleScript) should be a straightforward thing i.e. I can clearly define a total number of steps and I can clearly define the step number I'm currently on. I just want to display something like:
I'd even be OK with just implementing something like:
display dialog "blah blah"
but that needs to be manually dismissed with each iteration of the loop, so that's no good. I also tried:
display notification "blah blah"
but that yields hundreds of notification boxes at the top right of my screen, so that's also impractical.
I was even thinking maybe I could call some generic system progress meter with all the right variables via a "do shell script" command (although I have no idea how to do that). Something surely must be possible, but I just can't figure it out :-(. Could some kind soul please help me out. Thanks.
Topic:
App & System Services
SubTopic:
Automation & Scripting
Updated version of this post
My HomePod mini is now on version 16.4, so the the temperature and humidity sensors are enabled. The data properly shows up in the Home app on my various devices.
In my HomeKit iPad app running on Mac Catalyst, however, the data does not show up. I would expect the HomePod mini to show up in HMHome.accessories with a service of type HMServiceTypeTempatureSensor. I see all of my other HomeKit accessories, just not the HomePod mini.
I have tried with the latest Xcode (14.3) and highest available iOS Target and Minimum Deployment (16.4), macOS version 13.3. I have not, as of this writing, upgraded my HomeKit architecture, however.
Note that I haven't tried the app on an actual iPad (and the iOS simulator doesn't expose my HomeKit environment.)
Hello,
We're developing endpoint security software using the Endpoint Security framework, and we've encountered challenges with the behavior change in macOS 15 regarding provisioning UDIDs in cloned VMs.
The Change
Prior to macOS 15, cloning a VM preserved its UDID (format: 0000FE00-9C4ED9F68BBDC72D). Starting with macOS 15, cloned VMs receive a new UDID generated from the host's Secure Enclave (format: b043d27202c7ac37ca3c6b82673302225485cae9), making each clone effectively a new device.
Our Workflow
We maintain a clean base VM image and clone it for each test run. We add the base VM's UDID to our provisioning profile once, then create clones which (previously) retained that same UDID, allowing us to start new testing cycles without re-registering devices.
This is essential because our product involves low-level system integration through the Endpoint Security framework, and if something goes wrong during development, it has the potential to affect system stability. To prevent any cascading issues between test runs or different product versions, we need each test to start from a known clean state rather than reusing the same VM.
The Challenge
With each VM clone generating a new UDID, we're hitting Apple's device registration limits quickly. This particularly impacts:
New team members who spin up VMs for the first time and can't run signed builds
Our CI/CD pipeline where multiple test environments need provisioning profiles
Developers testing different branches who need separate clean environments
Current Workaround
We've found that VMs created on macOS 14 and upgraded to macOS 15+ retain their original UDID format. However, we're concerned this workaround may stop working in future macOS versions, which would leave us without a viable path forward.
If the workaround stops working, our fallback would be signing each CI build with a Developer ID signature to allow running on any device. However, we'd prefer to avoid this as it would significantly increase load on Apple's signing infrastructure for what are essentially internal test builds.
We completely understand the security reasoning behind tying UDIDs to the host's Secure Enclave for Apple Account support. However, for development workflows that don't require Apple Account features in VMs but do require clean, isolated test environments, the previous behavior was quite valuable.
Question
Is there a recommended approach for teams in our situation? We're happy to explore alternative workflows if there's a pattern we're missing, or we'd be glad to provide more context if this is a use case Apple is considering for future updates.
Thanks for any guidance you can provide!
Feedback case: FB21389730
Topic:
App & System Services
SubTopic:
Core OS
Tags:
macOS
Provisioning Profiles
Code Signing
Virtualization
Hello
I've noticed that this product, heavily promoted on the ASC forums for many years, is no longer available from the Apple App Store.
Can anyone tell me the reason why the product is no longer supported?
Friends have asked me if it is 'safe' to use.
Is it?
Note to moderator: If I'm asking in the wrong places, please redirect my question. Thank you.
I have been experimenting with the BGContinuedProcessingTask API recently (and published sample code for it https://github.com/infinitepower18/BGContinuedProcessingTaskDemo)
I have noticed that if I lock the phone, the code that runs as part of the task stops executing. My sample code simply updates the progress each second until it gets to 100, so it should be completed in 1 minute 40 seconds. However, after locking the phone and checking the lock screen a few seconds later the progress indicator was in the same position as before I locked it.
If I leave the phone locked for several minutes and check the lock screen the live activity says "Task failed".
I haven't seen anything in the documentation regarding execution of tasks while the phone is locked. So I'm a bit confused if I encountered an iOS bug here?
We are developing a macOS VPN application using NEPacketTunnelProvider with a custom encryption protocol.
We are using standard On-Demand VPN rules with Wi-Fi SSID matching but we want to add some additional feature to the native behaviour.
We want to control the 'conenect/disconnect' button status and allow the user to interact with the tunnel even when the on demand rule conditions are satisfied, is there a native way to do it?
In case we need to implement our custom on-demand behaviour we need to access to this information:
connected interface type
ssid name
and being informed when it changes so to trigger our logic, how to do it from the app side?
we try to use CWWiFiClient along with ssidDidChangeForWiFiInterface monitoring, it returns just the interface name en0 and not the wifi ssid name.
Is location access mandatory to access wifi SSID on macOS even if we have a NEPacketTunnelProvider?
Please note that we bundle our Network Extension as an App Extension (not SystemExtension).
Environment:
Xcode 26
iOS 26
Also tested on iOS 18 (working correctly)
Description:
I'm experiencing a behavior change with URL(fileURLWithPath:) when the filename starts with a tilde (~) character.
On iOS 18, passing a filename like ~MyFile.txt to URL(fileURLWithPath:) treats the tilde as a literal character. However, on iOS 26, the same code resolves the tilde as the home directory, resulting in unexpected output.
Minimal Example:
let filename = "~MyFile.txt"
let url = URL(fileURLWithPath: filename)
print(url.lastPathComponent)
Expected Result (iOS 18):
~MyFile.txt
Actual Result (iOS 26):
924AF0C4-C3CD-417A-9D5F-733FBB8FCF29
The tilde is being resolved to the app's container directory, and lastPathComponent returns the container UUID instead of the filename.
Questions:
1. Is this an intentional behavior change in iOS 26? 2. Is there documentation about this change? 3. What is the recommended approach for extracting filename components when the filename may contain special characters like ~?
Workaround:
Using NSString.lastPathComponent works correctly on both iOS versions:
let filename = "~MyFile.txt"
let result = (filename as NSString).lastPathComponent
// Returns: "~MyFile.txt" ✅
Is this the recommended approach going forward?
Hello! Some colleagues and work on Jujutsu, a version control system compatible with git, and I think we've uncovered a potential lock contention bug in either APFS or the Darwin kernel. There are four contributing factors to us thinking this is related to APFS or the Kernel:
jj's testsuite uses nextest, a test runner for Rust that spawns each individual test as a separate process.
The testsuite slowed down by a factor of ~5x on macOS after jj started using fsync. The slowdown increases as additional cores are allocated.
A similar slowdown did not occur on ext4.
Similar performance issues were reported in the past by a former Mercurial maintainer: https://gregoryszorc.com/blog/2018/10/29/global-kernel-locks-in-apfs/.
My friend and colleague André has measured the test suite on an M3 Ultra with both a ramdisk and a traditional SSD and produced this graph:
(The most thorough writeup is the discussion on this pull request.)
I know I should file a feedback/bug report, but before I do, I'm struggling with profiling and finding kernel/APFS frames in my profiles so that I can properly attribute the cause of this apparent lock contention. Naively, I ran xctrace record --template 'Time Profiler' --output output.trace --launch /Users/dbarsky/.cargo/bin/cargo-nextest nextest run, and while that detected all processes spawned by nextest, it didn't record all processes as part of the same inspectable profile and didn't really show any frames from the kernel/APFS—I had to select individual processes. So I don't waste people's time and so that I can point a frame/smoking gun in the right system, how can I can use instruments to profile where the kernel and/or APFS are spending its time? Do I need to disable SIP?
I have written the Transparent App Proxy and can capture the network flow and send it to my local server. I want to avoid any processing on the traffic outgoing from my server and establish a connection with a remote server, but instead of connecting to the remote server, it again gets captured and sent back to my local server.
I am not getting any clue on how to ignore these flows originating from my server.
Any pointers, API, or mechanisms that will help me?
Topic:
App & System Services
SubTopic:
Networking
Tags:
Network Extension
System Extensions
Endpoint Security
Our app is developed for iOS, but some users also run it on macOS (as an iOS app via Apple Silicon). The app requires local network permission, which works perfectly on iOS. Previously, the connection also worked fine on macOS, but since the recent macOS update, the app can no longer connect to our device.
Additionally, our app on macOS doesn't prompt for local network permission at all, whereas it does on iOS. Is this a known issue with iOS apps running on macOS? Has anyone else experienced this problem, or is there a workaround?
Any help would be appreciated!
Topic:
App & System Services
SubTopic:
Networking
Hello,
We use the Network API in our macOS ObjectiveC applications to create a small web server. With macOS Sequoia or Tahoe (not with Sonoma), downloading files from another computer using the built-in ethernet port is way too slow.
Steps to reproduce:
Computer A (using macOS Tahoe or Sonoma), run an application using the Network APIs to create a webserver
Make sure that this computer connects to the network using the Ethernet port, there is no issue when using WiFi
On computer B, make an HTTP request to download a 20MB file => it will take about 30 seconds to download => way too slow...
We tested with:
if on computer A you run a web server using the GCD API instead of Network, it takes 0.2 seconds to download the file => no issue
on computer A disable TSO, it improves the results, but that's not a long term solution as it doesn't hold when rebooting
I can provide sample code to demonstrate this if needed.
This is a new issue as it's been a while we use that code, and only noticed it recently, and macOS Sonoma is not impacted.
Thank you for the help you can provide.
Pierre
Hi,
We have an issue (https://github.com/actions/runner-images/issues/10924) raised by a user requesting to add 'local network access' permission for macOS 15 and macOS 15-arm64 image runners. Apple introduced a new LNP policy with macOS Sequoia that is not controlled by TCC or MDM. Could you please guide us on how to add 'local network access' permission for macOS 15 and macOS 15-arm64 image runners?
Thanks.
I have a strange crash which I have problems understanding. It only happens on a few devices, after a ModelContainer migration, and it doesn't seem to crash on the migration itself.
The fetch is done in onAppear, and shouldn't necessarily result in a crash, as it is an optional try:
let request = FetchDescriptor<Rifle>()
let data = try? modelContext.fetch(request)
if let data, !data.isEmpty {
rifle = data.first(where: { $0.uuid.uuidString == settings.selectedRifleId }) ?? data.first!
}
When I get logs from users, there seems to be an error in encoding?
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x000000018e8bfd78
Termination Reason: SIGNAL 5 Trace/BPT trap: 5
Terminating Process: exc handler [71687]
Triggered by Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libswiftCore.dylib 0x18e8bfd78 _assertionFailure(_:_:file:line:flags:) + 264
1 SwiftData 0x24e18b480 0x24e14c000 + 259200
2 SwiftData 0x24e193968 0x24e14c000 + 293224
3 SwiftData 0x24e195a78 0x24e14c000 + 301688
4 libswiftCore.dylib 0x18e8e4084 _KeyedEncodingContainerBox.encodeNil<A>(forKey:) + 352
5 libswiftCore.dylib 0x18e8d79f0 KeyedEncodingContainer.encodeNil(forKey:) + 64
6 SwiftData 0x24e19f09c 0x24e14c000 + 340124
7 SwiftData 0x24e1a3dec 0x24e14c000 + 359916
8 libswiftCore.dylib 0x18ec10be8 dispatch thunk of Encodable.encode(to:) + 32
9 SwiftData 0x24e1cd500 0x24e14c000 + 529664
10 SwiftData 0x24e1cd0c8 0x24e14c000 + 528584
11 SwiftData 0x24e1da960 0x24e14c000 + 584032
12 SwiftData 0x24e1ee2ec 0x24e14c000 + 664300
13 SwiftData 0x24e1d97d8 0x24e14c000 + 579544
14 SwiftData 0x24e1eada0 0x24e14c000 + 650656
15 SwiftData 0x24e1d989c 0x24e14c000 + 579740
16 SwiftData 0x24e1eee78 0x24e14c000 + 667256
17 Impact 0x1027403bc 0x10268c000 + 738236