Hi, my reply comes late, I know ^_^ but today is started to try it again, sad that it's still not working. The Idea behind that is, that I worked on a simple app which helps the user to detect all devices which are in his home network environment. One way to detect some devices is to make this generic mDNS lookup to get all service types and with the help of the interface name you can do a estimation which device it could be. or is there any better solution which apple provides to detect devices in a home network ? or is this something that is not allowed due to data privacy restrictions ? best regards, Vinz

Ah great, thank you for your reply :) Best regards, Vinz

Hi Matt and Quinn, Thank you for your fast reply. This light up things for me, i will try to get the service list via dnssd framework. To get the Endpoints I can then use NWBrowser. Just for clarification, the entitlement is still needed to do this or for iOS 14+ ? I used NSNetservice in the past and it was possible to get service list without the entitlement. Thank you both

I also discovered this bug. I hope this is a bug, this blocks my development process for iOS 17 currently.

After some investigation I found the issue. The Problem was related to store the Incoming Data in a Foundation.Data Buffer and clearing the Buffer had this impact on performance. I switched over to DispatchData and the Performance is now as expected.

I am experiencing the exact same problem with the current iOS/Xcode version. The issue occurs intermittently but completely breaks the database. It appears that the data is not always saved correctly, and attempting to load it subsequently leads to an exception. In my network measurement app, I attempt to store the results using SwiftData. I have tried disabling autosave and saving the context manually, but the problem persists. Additionally, I tried removing the @Attribute(.unique) from my UUID field, but this does not seem to resolve the issue. This is my model: @Model internal class StorageModel { var uuid: UUID var date: Date var result: ResultModel required init(uuid: UUID = UUID(), date: Date = Date(), result: ResultModel = .init()) { self.uuid = uuid self.date = date self.result = result } }

I don't understand your goal here? Probably everything should be able to work from iOS 5 to 17 if you write your app in Objective-C and don't use API's, Frameworks whatever that are not supported on iOS 5.0 (but can be handled by using some pre processor stuff). The Question is why should you do this? Why do you want support such an old OS Version that is outdated for years and nearly nobody is using It by today. Before you start you should maybe take some footsteps in the Coding Game for better understanding everything ;) Cheers Vinz

I have found a Solution that worked for me and I was able to reproduce the error. It seems that SwiftData don't likes having directly optional values. I attached an example for better understanding. If I have no optionals directly (inside an array it seems to work) the problem is gone for me. @Model internal class StorageModel { var uuid: UUID var date: Date var result: ResultModel required init(uuid: UUID = UUID(), date: Date = Date(), result: ResultModel = .init()) { self.uuid = uuid self.date = date self.result = result } } internal struct ResultModel: Codable { internal var uuid = UUID() internal var locations: [LocationModel] = [] // This is okay internal var location = LocationModel? // This causes the crash for me internal var workingLocation = LocationModel(latitude: .zero, longitude: .zero) // This is also okay } internal struct LocationModel: Codable { internal var latitude: Double? internal var longitude: Double? init(latitude: Double, longitude: Double) { self.latitude = latitude self.longitude = longitude } }

Hi Quinn, Thanks a lot for your response. I initially thought it wouldn't be possible to add a Task afterwards because the entire workflow differs a lot in concurrency in comparison to the "old" way I implemented things. But I decided to currently stay away from concurrency for my custom network stuff. I exposed the high level API of my framework to concurrency and that works pretty well in the app and makes the ViewModel much more readable. But internally I'm not really happy with the flow control and it's much harder to build a good solution when I have to deal with a lot of AsyncSequences. I'm sure the Network.framework Engineers will build something fantastic and most of time im very impatient but I think it's worth the wait until Network.framework supports concurrency out of the box. Then I think it's much easier for me to build an appropriate solution for my framework. But all in all. Thank's for your work, you always helped me a lot in the last years 😊