We have changed our configuration to: Debug: ENABLE_MODULE_VERIFIER = NO Release: ENABLE_MODULE_VERIFIER = YES Great relief! Of course with a risk that module verifier first fails when we build a release build.

Hello there :) We also experience this crash occasionally... I guess it hasn't been solved yet... or is there any workaround available? Cheers!

Hello there :) We also experience this crash occasionally... I guess it hasn't been solved yet... or is there any workaround available? Cheers!

Hi @eskimo :) Problem solved! At some point I changed from using a delegate-based version of requestSendPTPCommand (ImageCaptureCore) to use block-based version. The reason for this change was to support iOS 15.0 in addition to macOS. And the delegate-based version wasn't support in iOS back then (first introduced in iOS 15.2). But now I realized that the method was called from an C++ object and not Objective C object! (In a .m-file mixed with both C++ and Objective C classes 🥹.) Changing it to delegate-based version where the delegate was an Objective C object made it work again smoothly :) Thanks again for your help and time on this!

Hey Quinn and thanks million! Wauw, I didn't even know that you could see the crash-log-files in Xcode by right-clicking and choose 'Show in Finder' 😅 (As explained we are unable to reproduce this by ourselves. So we only have crash-reports from end-users.) Here's five from the 'remoteCameraWithFailureBlock' type... Cheers! 2023-09-15_11-30-06.8328_-0700-2d7d19b4b44c0ea3103ecdf7cfd26b1e7ef1a6f8.crash 2023-09-15_17-26-21.4373_+0800-19859941dca81973829d2a5442f13bc22b0dfa4c.crash 2023-09-17_12-28-10.4574_+0900-780b6a777e9ebef887a60c4a98828348208a93e7.crash 2023-09-20_13-33-32.3042_+1000-1be91b2f3a0a083a3f85e788ea63beb396f1475c.crash 2023-09-13_19-02-17.9793_-0500-b0abc39ce89f7436a9be550d4046b278ca499416.crash

Thanks @eskimo - I just knew there would be a reply from you ♥️ Oops - we will try to use the term 'accessory' from now on here in Apple Land™ 😅 And ok then will try look into start using the Network framework instead. Will get back to you if we manage to do that soon, thanks!

Hi @enodev and thanks for your reply. Here are some follow up responses: We did check with ifconfig and the interface does get a link-local address as expected. That is also why we can "bind()" to it. "getifaddrs()" returns information that is consistent with ifconfig. The outgoing SYN is part of establishing a TCP connection so that is normal even for link-local interfaces. The odd part is the source IP does not match the interface IP. Unfortunately IPv6 is not available in this scenario. Link-local is in fact standardized in RFC 3927 although it leaves room for some implementation defined behavior (timeouts, etc). Link-local is included in MacOS as a part of Bonjour.

Of course! Thanks a lot for this Quinn! 🤓👍

Hi Quinn :) Great to see an example of how you have save a FormatStyle in variable! I really like the new format but it is sometimes really hard to use it without concrete examples... So what if I would like to have date.formatted(date: .long, time: .standard) but with TimeZone(secondsFromGMT: 0)? Is that possible to combine those two easily? Cheers!

Hi :) I was fiddling with the list of Bonjour Services in Info.plist and couldn't get it to work... But then I used the Console app and was able to see the exact string... turned out that I needed a '.' in the end... From Console I got: "App Info.plist(NSBonjourServices) does not allow '_myprotocol._http._tcp.' for (My App)" Then I just pasted that protocol name into Info.plist and it started to work :D (It might be 'my' protocol name was illformed from the beginning.) Happy days :)