Thanks Quinn. I hadn't see that post. I just did not want to be on the "extra-ordinary" track unnecessarily,.. as that how someone ends up with Int128 questions.

I agree with both of you.[1] I posted in the "iCloud and Data" section, not Networking, as a result. ;) FWIW, the contrarians in Apple+ world is pkl-lang. They use an Int128 approach. Now on plus side pkl has nice pre-canned functions to deal with "collapsing zeros" in IP string and similar transforms: https://pkl-lang.org/package-docs/pkg.pkl-lang.org/pkl-pantry/pkl.experimental.net/current/net/IPv6Address.html But...from SwiftData POV, Int128 is a built-in type, regardless of use case. And the double-whammy that you don't find out it's an issue until runtime is actually what prompted the post. Normally XCode is pretty good at telling these things. I'll file a Feedback report, since even some warning be useful. And a runtime error is not a great way to deal with "bad" @Model. Anyway, IP is a normalized[2] String in my case to SwiftData. Ending the trail of trouble of "IPv6Address" from Linux+NIO to SwiftData. I imagine any "subnet-based queries" should likely be religated to convert a "subnet" into some notion of Bonjour domain. And store "domain" in SwiftData for filtering by "subnet". The root of my problem is I need to listen on UDP broadcasts — which wasn't my choice (mDNS/DNS-SD/RFC-8305 is hard to argue against) — so got off the RN3151/etc wagon with: Network framework supports UDP multicast using the NWConnectionGroup class, but that support has limits and, specifically, it does not support UDP broadcast. If you need something that’s not supported by Network framework, use BSD Sockets. Since you're both here... is that advice actually still true? I actually took it at face value and didn't test it. The backstory is I'd to have some swift-on-server "agent" that ideally convert UDP broadcasts in proper mDNS/DNS-SD things eventually. Thought being is that more consumable to iOS/macOS apps, and also avoid the wasted duplicative UDP broadcasts. Now the app still may need to do UDP discovery – possible there wouldn't be a some server agent to proxy UDP broadcast (or LLDP etc) to Bonjour. While in my straw man I'm using same NIO code in app and Linux - which works - actually using NW Framework in app be preferable to having the EventLoopGroup and friends on the iOS app side. [1] My only defense on the networking side in using Int128 to store IPv6 in SwiftData is you might want to do some indexed query operation, based on "subnet", from SwiftUI. And, I wasn't sure that work in practice, even if one fiddled with endianness. But since SQLite does not support Int128, that mean no possibility to have some index on it. So even less useful. [2] The esoteric case of an IPv4 string of 17.1 is actually 17.0.0.1 is just left unhandled.

Interesting, you may be right SQLite does not have a 128-bit integer. And I'll probably figure something else out here, since Int128 also require Sequoia. But it's a Builtin type... so the SwiftData "rules" seem to imply those are mapped by SwiftData. Now... the internet tells me not all "Codables" work, but exactly what things don't is not well cataloged. All I know is a "IPv6 address" as Swift types have caused a lot of grief. ;)