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

Is it possible to use the Matter.xcframework without the MatterSupport extension for onboarding a Matter device to our own ecosystem(own OTBR and matter controller) for an official App Store release? Currently, we can achieve this in developer mode by adding the Bluetooth Central Matter Client Developer mode profile (as outlined here https://github.com/project-chip/connectedhomeip/blob/master/docs/guides/darwin.md). For an official release, what entitlements or capabilities do we need to request approval from Apple to replace the Bluetooth Central Matter Client Developer mode profile? Thank you for your assistance.

Hi, I’m implementing a macOS DNS Proxy as a system extension and running into a persistent activation error: OSSystemExtensionErrorDomain error 9 (validationFailed) with the message: extension category returned error This happens both on an MDM‑managed Mac and on a completely clean Mac (no MDM, fresh install). Setup macOS: 15.x (clean machine, no MDM) Xcode: 16.x Team ID: AAAAAAA111 (test) Host app bundle ID: com.example.agent.NetShieldProxy DNS Proxy system extension bundle ID: com.example.agent.NetShieldProxy.dnsProxy The DNS Proxy is implemented as a NetworkExtension system extension, not an app extension. Host app entitlements From codesign -d --entitlements :- /Applications/NetShieldProxy.app: xml com.apple.application-identifier AAAAAAA111.com.example.agent.NetShieldProxy <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.developer.team-identifier</key> <string>AAAAAAA111</string> <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.application-groups</key> <array> <string>group.com.example.NetShieldmac</string> </array> <key>com.apple.security.files.user-selected.read-only</key> <true/> xml com.apple.application-identifier AAAAAAA111.com.example.agent.NetShieldProxy.dnsProxy <key>com.apple.developer.networking.networkextension</key> <array> <string>dns-proxy-systemextension</string> </array> <key>com.apple.developer.team-identifier</key> <string>AAAAAAA111</string> <key>com.apple.security.application-groups</key> <array> <string>group.com.example.NetShieldmac</string> <string>group.example.NetShieldmac</string> <string>group.example.agent.enterprise.macos</string> <string>group.example.com.NetShieldmac</string> </array> DNS Proxy system extension Info.plist On the clean Mac, from: bash plutil -p "/Applications/NetShieldProxy.app/Contents/Library/SystemExtensions/com.example.agent.NetShieldProxy.dnsProxy.systemextension/Contents/Info.plist" I get: json { "CFBundleExecutable" => "com.example.agent.NetShieldProxy.dnsProxy", "CFBundleIdentifier" => "com.example.agent.NetShieldProxy.dnsProxy", "CFBundleName" => "com.example.agent.NetShieldProxy.dnsProxy", "CFBundlePackageType" => "SYSX", "CFBundleShortVersionString" => "1.0.1.8", "CFBundleSupportedPlatforms" => [ "MacOSX" ], "CFBundleVersion" => "0.1.1", "LSMinimumSystemVersion" => "13.5", "NSExtension" => { "NSExtensionPointIdentifier" => "com.apple.dns-proxy", "NSExtensionPrincipalClass" => "com_example_agent_NetShieldProxy_dnsProxy.DNSProxyProvider" }, "NSSystemExtensionUsageDescription" => "SYSTEM_EXTENSION_USAGE_DESCRIPTION" } The DNSProxyProvider class inherits from NEDNSProxyProvider and is built in the system extension target. Activation code In the host app, I use: swift import SystemExtensions final class SystemExtensionActivator: NSObject, OSSystemExtensionRequestDelegate { private let extensionIdentifier = "com.example.agent.NetShieldProxy.dnsProxy" func activate(completion: @escaping (Bool) -> Void) { let request = OSSystemExtensionRequest.activationRequest( forExtensionWithIdentifier: extensionIdentifier, queue: .main ) request.delegate = self OSSystemExtensionManager.shared.submitRequest(request) } func request(_ request: OSSystemExtensionRequest, didFailWithError error: Error) { let nsError = error as NSError print("Activation failed:", nsError) } func request(_ request: OSSystemExtensionRequest, didFinishWithResult result: OSSystemExtensionRequest.Result) { print("Result:", result.rawValue) } } Runtime behavior on a clean Mac (no MDM) config.plist is created under /Library/Application Support/NetShield (via a root shell script). A daemon runs, contacts our backend, and writes /Library/Application Support/NetShield/state.plist with a valid dnsToken and other fields. The app NetShieldProxy.app is installed via a notarized, stapled Developer ID .pkg. The extension bundle is present at: /Applications/NetShieldProxy.app/Contents/Library/SystemExtensions/com.example.agent.NetShieldProxy.dnsProxy.systemextension. When I press Activate DNS Proxy in the UI, I see in the unified log: text NetShieldProxy: [com.example.agent:SystemExtensionActivator] Requesting activation for system extension: com.example.agent.NetShieldProxy.dnsProxy NetShieldProxy: [com.example.agent:SystemExtensionActivator] SystemExtensionActivator - activation failed: extension category returned error (domain=OSSystemExtensionErrorDomain code=9) NetShieldProxy: [com.example.agent:SystemExtensionActivator] SystemExtensionActivator - OSSystemExtensionError code enum: 9 NetShieldProxy: [com.example.agent:SystemExtensionActivator] SystemExtensionActivator - validationFailed And: bash systemextensionsctl list -> 0 extension(s) There is no prompt in Privacy & Security on this clean Mac. Question Given: The extension is packaged as a system extension (CFBundlePackageType = SYSX) with NSExtensionPointIdentifier = "com.apple.dns-proxy". Host and extension share the same Team ID and Developer ID Application cert. Entitlements on the target machine match the provisioning profile and Apple’s docs for DNS Proxy system extensions (dns-proxy-systemextension). This is happening on a clean Mac with no MDM profiles at all. What are the likely reasons for OSSystemExtensionErrorDomain error 9 (validationFailed) with "extension category returned error" in this DNS Proxy system extension scenario? Is there any additional configuration required for DNS Proxy system extensions (beyond entitlements and Info.plist) that could trigger this category-level validation failure? Any guidance or examples of a working DNS Proxy system extension configuration (host entitlements + extension Info.plist + entitlements) would be greatly appreciated. Thanks!

We've often observed connectivity issues from our VPN app that can only be remedied by removing the VPN profile. It happens to a small but significant amount of our users, this often happens more when the app is updated, but the VPN profile corruption can happen without that too. The behavior we're observing is that any socket opened by the packet tunnel process just fails to send any data whatsoever. Stopping and restarting the packet tunnel does not help. The only solution is to remove the profile and create a new one. We believe our app is not the only one suffering from this issue as other VPN apps have added a specific button to refresh their VPN profile, which seemingly deletes and re-created the VPN configuration profile. Previously, we've caught glimpses of this in a sysdiagnose, but that was a while ago and we found nothing of interest. Alas, the sysdiagnose was not captured on a device with the network extension diagnostic profile (it was not a developer device). I would love to get technical support with this, as our bug reports have gone unanswered for long enough, yet we are still struggling with this issue. But of course, there is no minimum viable xcodeproject that reproduces this. Is there anything we can feasibly do to help with this issue? Is it even an acknowledged issue?

Hi everyone, I’ve filed a Feedback report (FB20986470) for a serious issue affecting the Call Directory database when add phone numbers for call blocking. When adding blocking numbers to a Call Directory extension, the system’s CallKit database (/private/var/mobile/Library/CallDirectory/CallDirectory.db) becomes corrupted. The reload call (reloadExtensionWithIdentifier) fails with error code 11 when the system tries to insert blocking entries, and the Console app on macOS shows the following errors: database corruption page 2265525 of /private/var/mobile/Library/CallDirectory/CallDirectory.db at line 81343 of [f0ca7bba1c] database corruption at line 79387 of [f0ca7bba1c] Error Domain=com.apple.callkit.database.sqlite Code=11 "sqlite3_step for query 'INSERT INTO PhoneNumberBlockingEntry (extension_id, phone_number_id) VALUES (?, (SELECT id FROM PhoneNumber WHERE (number = ?))), (?, (SELECT id FROM PhoneNumber WHERE (number = ?))),...)'" After this happens, CallKit becomes fully corrupted on the device and no further numbers can be added, even after: Disabling and re-enabling the extension Restarting the device (either force or soft restart) Reinstalling the app Waiting for a couple of minutes after this issue happens (that CallKit could possibly self-recovered) I also tested other call-blocking apps, and they all fail with the same error. The only thing that recovers the system is a full “Reset All Settings.” This issue has been reported by many users of my app, across multiple iOS versions and devices. Similar related issue reported by another developer: https://developer.apple.com/forums/thread/806129 Steps to Reproduce: Enable the Call Directory extension from a call-blocking app. Add and reload blocking numbers (a few thousand entries). Perform multiple reloads between additions. Check the Console, the corruption errors appear. From this point, all insert attempts fail system-wide. Expected Result: Entries should be inserted successfully, or the system should self-recover without persistent corruption. Actual Result: sqlite3_step fails with Code=11, and the Call Directory database remains corrupted until the user resets all settings. Additional Notes: All numbers are sorted and deduplicated before insertion. Happens intermittently after multiple reloads. The system log always shows internal database failure. Environment: Device: iPhone 16 Plus iOS 18.2 Beta (23C5027f) Xcode 16.1 (17B55) Attachments (included in Feedback FB20986470): sysdiagnose captured immediately after the failure (with Phone app General Profile) It seems like a system-level corruption affecting all Call Directory extensions once it occurs.

In IOS17 and IOS18, core spotlight can only match app contents by searching for the displayName, but cannot hit the contents by using keywords. Moreover, when matching the app content by searching for the "displayName", it requires inputting four consecutive characters to achieve a match.These issues did not occur in iOS 16. What is the reason for this? Here is my code. func addItemToIndex(_ item: QSpotlightItem) { let attributeSet = CSSearchableItemAttributeSet(contentType: .item) attributeSet.title = item.title attributeSet.displayName = item.title attributeSet.contentDescription = item.contentDescription attributeSet.keywords = item.keywords attributeSet.thumbnailData = item.thumbnailImage attributeSet.contactKeywords = item.keywords attributeSet.supportsNavigation = true let searchableItem = CSSearchableItem(uniqueIdentifier: item.id, domainIdentifier: "xxx", attributeSet: attributeSet) searchableItem.expirationDate = .distantFuture CSSearchableIndex.default().indexSearchableItems([searchableItem]) { error in if let error = error { } else { } } }

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?

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).

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.

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.

When my app launches, it makes maybe 9 or so network requests to load initial data. It also reads some data from disc. Sporadically, I'm seeing an issue where some of the network requests succeed, but anything involving reading from disc does not load immediately. I'm able to move around in the app, tap buttons, swap tabs, swipe pages, so my main actor isn't stuck. Other data that don't involve disc reading / writing is also blank. About 2 minutes in, suddenly everything loads (both stuff from disc and stuff from the network), nearly instantly, the way it should have done when the app launched. Server logs show more initial network requests succeed than we can see data loaded in the app, and then about 2 minutes later, there's a flood of the rest of the requests which then succeed. The responses to some of these initial network requests cause us to make other network requests, and the sever sees some of those start right away. However, other consequences of these first requests are to touch the disc (to search for manually-cached data), and anything that is supposed to happen after that does not succeed until the 2 minute mark. But what bothers me is some things in the app which don't touch the disc also seem to have successful network requests. I'm seeing it on an iPhone 14Pro running iOS 18.2.1, with 607 GB of disc space available. When I take screenshots of the loading screens in my app during the apparent freeze, the clock in the screenshots are right - they reflect the clock at the moment I took the screenshot, but the EXIF data in all dozen or so images shows the exact second 2 minutes later when the server gets the resulting flood of network requests. Screenshots taken after the freeze is over have exif timestamps that match the screenshots, as short as 5 seconds after the freeze ends. The screenshot file names, though sequential, are out of order. for instance, some screenshots from 12:58 have file names numbered after screenshots taken at 12:59. but not all are out of order. This seems like disc contention has spread outside the app, and is impacting the system writing the images to disc. How do I diagnose a cause for this? How does disc contention affect the networking? I have caching turned off for my network requests. We only have a manual image cache, but I don't know how that would stall the display of data that should fetch and display without attempting to hit the image cache. This happens maybe a couple of times a day for some people, maybe once every couple of weeks for others, but of course, it never when we're trying to debug it.

Recently I've been working on a demo project called iLibrary. The main goal was to learn more about CloudKit and SwiftData. After a while I noticed that there were some hangs/freezes when running the app in debug mode. I first tried this with Xcode 15.4 and iOS 17.5. Here the hang only appears at the beginning, but only for a few seconds. But when I exit debug mode, there are no more hangs. With Xcode 16 beta 4 and iOS 18 it looks completely different. In this case, the hangs and freezes are always present, whether in debug mode or not. And it's not just at the beginning, it's throughout the app. I'm aware that this is still a beta, but I still find this weird. And when I profile this I see that the main thread gets quite overloaded. Interestingly, my app doesn't have that many operations going on. So I guess something with the sync of SwiftData or my CloudKitManger where I fetch some records from the public database is not running fine. Lastly, I wanted to delete the iCloud app data. So I went to Settings and tried to delete it, but it didn't work. Is this normal? Does anyone have any idea what this could be? Or has anyone encountered this problem as well? I'd appreciate any support. My project: https://github.com/romanindermuehle/iLibrary

I'm seeing a lot of these in my logs: PersistentIdentifier PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(url: x-swiftdata://Course/BC9CF99A-DE6A-46F1-A18D-8034255A56D8), implementation: SwiftData.PersistentIdentifierImplementation) was remapped to a temporary identifier during save: PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(url: x-coredata:///Course/t58C849CD-D895-4773-BF53-3F63CF48935B210), implementation: SwiftData.PersistentIdentifierImplementation). This is a fatal logic error in DefaultStore ... though everything seems to work. Does anyone know what this means in this context? Anything I can do to not have this appear?

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

Issue with Universal Links and App Extension (ShieldAction Handler) I'm currently working on a POC app using the FamilyControls framework and facing an issue when trying to open a Universal Link from an app extension, specifically from a ShieldAction handler. When I try to open a Universal Link, I encounter the following error: Failed to open URL https://sixteen-server-c008110f8759.herokuapp.com/.well-known/apple-app-site-association: Error Domain=FBSOpenApplicationServiceErrorDomain Code=1 "The request to open 'com.apple.mobilesafari' failed." UserInfo={BSErrorCodeDescription=RequestDenied, NSUnderlyingError=0x14f2d90b0 {Error Domain=FBSOpenApplicationErrorDomain Code=3 "Application com.sixteen.life is neither visible nor entitled, so may not perform un-trusted user actions." UserInfo={BSErrorCodeDescription=Security, NSLocalizedFailureReason=Application com.sixteen.life is neither visible nor entitled, so may not perform un-trusted user actions.}} Context: I’m using a ShieldAction handler as part of an App Extension to trigger the action (e.g., "Break in Shield") in my app. The app extension (ShieldAction handler) is responsible for trying to open the Universal Link. I’m encountering the error because the app is not visible or entitled to perform this action, which seems to be related to security restrictions when using App Extensions. Questions: App Extension and Universal Link Interaction: Is it possible for an App Extension (like ShieldAction handler) to open a Universal Link or trigger an external app, such as Safari, even though it is not the foreground app? Entitlements for App Extensions: Are there any specific entitlements or permissions required to allow an app extension (ShieldAction handler) to open Universal Links or perform actions like opening Safari from the background? App Visibility and State: How can I ensure that my app is in the right state (visible/active) and has the necessary entitlements to trigger these actions when running in the context of an app extension? Workaround: If this behavior is restricted due to app extension limitations, what would be the recommended workaround to handle launching external apps (like Safari) or Universal Links from within an app extension?

Continuing with my investigations of several issues that we have been noticing in our testing of the JDK with macosx 15.x, I have now narrowed down at least 2 separate problems for which I need help. For a quick background, starting with macosx 15.x several networking related tests within the JDK have started failing in very odd and hard to debug ways in our internal lab. Reading through the macos docs and with help from others in these forums, I have come to understand that a lot of these failures are to do with the new restrictions that have been placed for "Local Network" operations. I have read through https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy and I think I understand the necessary background about these restrictions. There's more than one issue in this area that I will need help with, so I'll split them out into separate topics in this forum. That above doc states: macOS 15.1 fixed a number of local network privacy bugs. If you encounter local network privacy problems on macOS 15.0, retest on macOS 15.1 or later. We did have (and continue to have) 15.0 and 15.1 macos instances within our lab which are impacted by these changes. They too show several networking related failures. However, I have decided not to look into those systems and instead focus only on 15.3.1. People might see unexpected behavior in System Settings > Privacy & Security if they have multiple versions of the same app installed (FB15568200). This feedback assistant issue and several others linked in these documentations are inaccessible (even when I login with my existing account). I think it would be good to have some facility in the feedback assistant tool/site to make such issues visible (even if read-only) to be able to watch for updates to those issues. So now coming to the issue. Several of the networking tests in the JDK do mulicasting testing (through BSD sockets API) in order to test the Java SE multicasting socket API implementations. One repeated failure we have been seeing in our labs is an exception with the message "No route to host". It shows up as: Process id: 58700 ... java.net.NoRouteToHostException: No route to host at java.base/sun.nio.ch.DatagramChannelImpl.send0(Native Method) at java.base/sun.nio.ch.DatagramChannelImpl.sendFromNativeBuffer(DatagramChannelImpl.java:914) at java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:871) at java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:798) at java.base/sun.nio.ch.DatagramChannelImpl.blockingSend(DatagramChannelImpl.java:857) at java.base/sun.nio.ch.DatagramSocketAdaptor.send(DatagramSocketAdaptor.java:178) at java.base/java.net.DatagramSocket.send(DatagramSocket.java:593) (this is just one example stacktrace from java program) That "send0" is implemented by the JDK by invoking the sendto() system call. In this case, the sendto() is returning a EHOSTUNREACH error which is what is then propagated to the application. The forum text editor doesn't allow me to post long text, so I'm going to post the rest of this investigation and logs as a reply.

Hi, I am currently experiencing some trouble when using parent model property in a predicate of a child model. I have an Item class that define parent-child relationship: @Model class Item { var timestamp: Date @Relationship(inverse: \Item.children) var parent: Item? var children: [Item] init(parent: Item? = nil, children: [Item] = [], timestamp: Date = .now) { self.parent = parent self.children = children self.timestamp = timestamp } } I subclass this model like that: @available(iOS 26, *) @Model final class CollectionItem: Item { /* ... */ } When i make a Query in my View like that the system crashes: @Query( filter: #Predicate<CollectionItem> { $0.parent == nil }, sort: \CollectionItem.name, ) private var collections: [CollectionItem] CrashReportError: Fatal Error in DataUtilities.swift AppName crashed due to fatalError in DataUtilities.swift at line 85. Couldn't find \CollectionItem.<computed 0x000000034005d4e8 (Optional<Item>)> on CollectionItem with fields [SwiftData.Schema.PropertyMetadata(name: "name", keypath: \CollectionItem.<computed 0x000000034003c120 (String)>, defaultValue: nil, metadata: nil), SwiftData.Schema.PropertyMetadata(name: "icon", keypath: \CollectionItem.<computed 0x000000034003ca04 (Optional<String>)>, defaultValue: nil, metadata: nil), SwiftData.Schema.PropertyMetadata(name: "timestamp", keypath: \Item.<computed 0x0000000340048018 (Date)>, defaultValue: nil, metadata: nil), SwiftData.Schema.PropertyMetadata(name: "parent", keypath: \Item.<computed 0x0000000340048a4c (Optional<Item>)>, defaultValue: nil, metadata: Optional(Relationship - name: , options: [], valueType: Any, destination: , inverseName: nil, inverseKeypath: Optional(\Item.<computed 0x0000000340048fe8 (Array<Item>)>))), SwiftData.Schema.PropertyMetadata(name: "children", keypath: \Item.<computed 0x0000000340048fe8 (Array<Item>)>, defaultValue: nil, metadata: nil)] When I query as Item it works but then i cannot sort on CollectionItem field and must add unnecessary down casting: @Query( filter: #Predicate<Item> { $0.parent == nil && $0 is CollectionItem }, ) private var items: [Item] Am I missing something? Is it a platform limitation or a known issue?

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!

Hello, I’m building a health-related app for both watchOS and iOS, which needs to monitor certain health data (e.g., heart rate, active energy). Before updating to watchOS 26, the queries worked reliably without any issues. However, after adapting to watchOS 26, some users have reported that health data updates stop being delivered. What I’ve observed: HKObserverQuery with enableBackgroundDelivery is set up normally. On WatchOS 26, the query sometimes stops delivering updates entirely after a certain point, and once an update is missed, it may stop delivering further updates completely. Restarting the Apple Watch temporarily restores delivery, but the problem reoccurs after some time. This makes background health data monitoring unreliable for my app. Here’s a simplified version of the code we are using: guard let heartType = HKObjectType.quantityType(forIdentifier: .heartRate) else { return } let query = HKObserverQuery(sampleType: heartType, predicate: nil) { query, completionHandler, error in if let error = error { logEvent("Observer error: \(error.localizedDescription)") return } logEvent("Heart rate changed") MyNotificationManager.shared.sendNotification() // Send a local notification completionHandler() } healthStore.execute(query) healthStore.enableBackgroundDelivery(for: heartType, frequency: .hourly) { success, error in if success { logEvent("Background heart rate delivery enabled") } else { logEvent("Failed to enable background heart rate delivery: \(error?.localizedDescription ?? "Unknown error")") } } Could you please clarify: Is this a known issue with HKObserverQuery and enableBackgroundDelivery on watchOS 26? Are there any recommended workarounds or best practices to ensure continuous background delivery of health data? Thank you in advance for your help.

We are experiencing a large number of crashes in our production environment, mainly occurring on iOS 16 systems and iPhone 8 and iPhone X devices. The crash log and stack trace are as follows: Error: Assertion failed: (false) function _onqueue_rdar53306264_addWaiter file TubeManager.cpp line 1042 Crashed: com.apple.CFNetwork.LoaderQ 0 libsystem_kernel.dylib 0x7198 __pthread_kill + 8 1 libsystem_pthread.dylib 0xd5f8 pthread_kill + 208 2 libsystem_c.dylib 0x1c4b8 abort + 124 3 libsystem_c.dylib 0x70d8c err + 266 4 CFNetwork 0x1eb80 CFURLRequestSetMainDocumentURL + 6288 5 CFNetwork 0x44fd8 CFURLCacheRemoveAllCachedResponses + 22624 6 CFNetwork 0x39460 _CFHostIsDomainTopLevel + 968 7 CFNetwork 0x1f754 CFURLRequestSetMainDocumentURL + 9316 8 CFNetwork 0x233e0 CFURLRequestSetRequestPriority + 8792 9 CFNetwork 0x20d38 CFURLRequestCopyHTTPRequestBodyStream + 1612 10 CFNetwork 0x4f950 CFHTTPCookieStorageCopyCookies + 16276 11 CFNetwork 0x15878 CFURLRequestSetURL + 7600 12 libdispatch.dylib 0x637a8 _dispatch_call_block_and_release + 24 13 libdispatch.dylib 0x64780 _dispatch_client_callout + 16 14 libdispatch.dylib 0x3f6fc _dispatch_lane_serial_drain$VARIANT$armv81 + 600 15 libdispatch.dylib 0x401e4 _dispatch_lane_invoke$VARIANT$armv81 + 432 16 libdispatch.dylib 0x41304 _dispatch_workloop_invoke$VARIANT$armv81 + 1620 17 libdispatch.dylib 0x49f14 _dispatch_workloop_worker_thread + 608 18 libsystem_pthread.dylib 0x1bd0 _pthread_wqthread + 284 19 libsystem_pthread.dylib 0x1720 start_wqthread + 8 Have you encountered a similar issue before?