eskimo

[quote='808800021, jamie_q, /thread/808800, /profile/jamie_q'] it appears to be limited to 8 messages. [/quote] Yep. AFAICT this is simply hard coded )-: [quote='808800021, jamie_q, /thread/808800, /profile/jamie_q'] Is this behavior expected and documented somewhere? [/quote] Not that I’ve seen. I recommend that you file a bug about this, either requesting that it be removed, or that it be documented, or both (-: Please post your bug number, or numbers, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’d like to clarify your setup here. Are you using GCC proper? Or using the Clang that’s built in to Xcode with an attribute that just happened to originate in GCC? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The doc comments for those properties say: This property is only non-zero when the report event is NEFilterReportEventFlowClosed or NEFilterReportEventFlowStatistics. The .statistics event isn’t available on iOS, so have you checked that the report event is .flowClosed? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='808401021, Mathias_, /thread/808401, /profile/Mathias_'] The advantage here with SCNetworkReachabilityGetFlags … would be that it's synchronous? [/quote] Yes and no. The API itself is synchronous, but it can block the calling thread waiting for the resolution to complete. That’s not exactly ideal. Coming back to your top-level issue, you wrote: [quote='867556022, Mathias_, /thread/808401?answerId=867556022#867556022, /profile/Mathias_'] For our geofence triggers for example [/quote] I think I’m missing something here. If you make the request without waiting for connectivity, it’ll fail promptly in most cases when the network is down. Do you need the network state to preflight the request? Or only to generate a better user-facing message if it’s already failed? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

See Fixing an untrusted code signing certificate for information about the unable to build chain to self-signed root error. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You listed five problematic entitlements: com.apple.developer.media-library com.apple.developer.music-user-token com.apple.developer.musickit com.apple.developer.playable-content com.apple.security.exception.mach-lookup.global-name All of these looks like hallucinations [1]. See Determining if an entitlement is real. ps Your post is very hard to read. See Quinn’s Top Ten DevForums Tips for advice on how to use the forums effectively, and specifically tip 5. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] I particularly like com.apple.security.exception.mach-lookup.global-name, which is very close to an entitlement used by the App Sandbox on macOS, namely com.apple.security.temporary-exception.mach-lookup.global-name.

[quote='808641021, dylandylandylan, /thread/808641, /profile/dylandylandylan'] However, this isn't thrown in this [/quote] That doesn’t strike me as strange. We generally don’t document the timing and specific errors thrown for particular user scenarios, and that’s not an accidental omission. Leaving these as implementation details gives us more flexibility to evolve the system. I recommend that you write your code to handle both sources of errors. [quote='808641021, dylandylandylan, /thread/808641, /profile/dylandylandylan'] Additionally, to catch such errors, would it be better to …? [/quote] Yes, but I wouldn’t phrase it like that. Rather, I’d say that your app should be prepared to handle errors from both: The start method throwing, and The status changing to .disconnected Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Where are you seeing this error? When you click Validate App in the Xcode organiser? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’m not aware of any change in iOS 18.7.2 that caused widespread problems like this. In my experience, such problems are usually caused by poorly written multicast code. For advice on how to avoid such probelms, see Extra-ordinary Networking > Broadcasts and Multicasts, Hints and Tips. Or, better yet, use Bonjour for this. It’s an industry standard, supported everywhere that’s relevant, and a lot easier to implement. Finally, TN3179 Understanding local network privacy has a bunch of hints and tips about local network privacy. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Sorry I didn’t respond earlier. You replied as a comment and I missed that )-: It’s better to reply as a reply. See Quinn’s Top Ten DevForums Tips for this and other titbits. Does this suggest that iOS 26 does not support this functionality? Yes. Moreover, is it possible that versions of iOS 18 and earlier may also not support this behavior in the future? I don’t normally comment on The Future™, but in this case the future is today. This technique is already unsupported on iOS 18. It just happens to work, but that’s an implementation detail. As to what you should do, I agree with Scott’s advice on your other thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

This is very reminiscent of the problems I see when installing two apps with the same main executable build UUID. See the Build-time considerations section of TN3179 Understanding local network privacy and thence TN3178 Checking for and resolving build UUID problems. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Quoting the docs: NEHotspotHelper allows your app to participate in the process of authenticating with hotspot networks, that is, Wi-Fi networks where the user must interact with the network to gain access to the wider Internet. Hotspot helper is, and has never been, a recommended way to “identify a network switch”. [quote='808341021, arnair, /thread/808341, /profile/arnair'] What is the proper replacement for this? [/quote] The replacement for the supported uses cases of NEHotspotHelper are the hotspot helper evaluation and authentication provider extensions. See here. However, these are tightly focused on the supported use cases, and thus are unlikely to help you with the unsupported use cases. To help you with that, I need a better understanding of your high-level goals. What are you actually trying to detect? And to what end? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

In the new API — so, NetworkConnection not NWConnection — there’s no explicit ‘start’ method. Rather, the connection starts implicitly when you do something that needs it. The exception to this rule is QUIC. In that case you can start the QUIC tunnel using that start() method you referenced. That’s useful when you want to start the tunnel but don’t want to immediately start any connections over that tunnel. However, this is optional. Starting a stream over the tunnel will implicitly start the tunnel. Note this comment in that page: Available when ApplicationProtocol conforms to MultiplexProtocol. QUIC is the only MultiplexProtocol currently available, so it’s the only place this method is available. So, it’s not available for TCP, or even for QUIC streams within a tunnel. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='808473021, raunits, /thread/808473, /profile/raunits'] we need to wrap them in a framework [/quote] Right. And there’s no built-in support for that. There are a couple of paths you might take here: Wrap it yourself. Use a mergeable library. The first option is obvious, but surprisingly tricky. You have to manually create a .framework wrapper around your dynamic library. The tricky part [1] is in crafting the correct Info.plist. I generally recommend that you create a test framework using Xcode and then crib the on-disk structure from that. Alternatively, you could update the build process for that “independent codebase” to create a mergeable library. You can then create a framework within your own app and merge that mergeable library into it. IMPORTANT Do this for each of the platforms you support, and remember that the device and the simulator are different platforms. Your best option here is to do it separately for each platform, and then merge it all together into one XCFramework. Finally, I have a

You definitely want to use automatic code signing for this stuff (-: Try this: In Signing & Capabilities, enable automatic code signing on both targets. Then remove the App Groups capability from each target. Select a real device as a run destination and choose Product > Build. I’d expect that to work (-: Back in Signing & Capabilities, add the App Groups capability to the app target. And enable the relevant group from the list shown by that capability. Try building again. Repeat steps 4 through 6 for the widget target. How far do you get? And if things fail, what error do you see? Also, what version of Xcode are you using? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com