Hi Quinn! I was almost betting $100 that you - the Forum's one-man army - would reply! :D Yes, it is the same path in both cases. The only difference is the NSFileExtendedAttributes com.apple.rootless when running the Archive-build. Thanks! Best regards, Jens :)

Hi again :) I'm really sorry; just reran and found that the paths were actually different 🙈 I've added this code piece to show the difference: NSLog(@"Quinn: NSTemporaryDirectory(): %@", NSTemporaryDirectory()); NSError *error = nil; NSDictionary *dictionary = [NSFileManager.defaultManager attributesOfItemAtPath:NSTemporaryDirectory() error:&error]; NSLog(@"Quinn: error: %@", error); NSLog(@"Quinn: dictionary: %@", dictionary); Debug: 2021-06-23 12:35:30.315 QLICProcessor[71421:3730283] Quinn: NSTemporaryDirectory(): /var/folders/_h/cbm2fp054c9byr188mdyxhw00000gp/T/com.apple.quicklook.qlmanage/ 2021-06-23 12:35:30.315 QLICProcessor[71421:3730283] Quinn: error: (null) 2021-06-23 12:35:30.316 QLICProcessor[71421:3730283] Quinn: dictionary: { NSFileCreationDate = "2021-06-18 20:22:23 +0000"; NSFileExtensionHidden = 0; NSFileGroupOwnerAccountID = 20; NSFileGroupOwnerAccountName = staff; NSFileModificationDate = "2021-06-23 10:30:11 +0000"; NSFileOwnerAccountID = 502; NSFileOwnerAccountName = jsc; NSFilePosixPermissions = 448; NSFileProtectionKey = NSFileProtectionCompleteUntilFirstUserAuthentication; NSFileReferenceCount = 16; NSFileSize = 512; NSFileSystemFileNumber = 32688057; NSFileSystemNumber = 16777220; NSFileType = NSFileTypeDirectory; } and archive: 2021-06-23 12:28:13.608 QLICProcessor[62356:3702628] Quinn: NSTemporaryDirectory(): /var/folders/_h/cbm2fp054c9byr188mdyxhw00000gp/T/ 2021-06-23 12:28:13.608 QLICProcessor[62356:3702628] Quinn: error: (null) 2021-06-23 12:28:13.609 QLICProcessor[62356:3702628] Quinn: dictionary: { NSFileCreationDate = "2021-05-17 13:09:39 +0000"; NSFileExtendedAttributes = { "com.apple.rootless" = {length = 7, bytes = 0x666f6c64657273}; }; NSFileExtensionHidden = 0; NSFileGroupOwnerAccountID = 20; NSFileGroupOwnerAccountName = staff; NSFileModificationDate = "2021-06-23 10:20:49 +0000"; NSFileOwnerAccountID = 502; NSFileOwnerAccountName = jsc; NSFilePosixPermissions = 448; NSFileProtectionKey = NSFileProtectionCompleteUntilFirstUserAuthentication; NSFileReferenceCount = 1958; NSFileSize = 62656; NSFileSystemFileNumber = 529943; NSFileSystemNumber = 16777220; NSFileType = NSFileTypeDirectory; } The command I use to start the app: qlmanage -p -c com.mycompany.myfile -g MyQLGenerator.qlgenerator ~/Desktop/MyFile.xyz Update: If I enabled the Hardened Runtime exception 'Allow DYLD Environment Variables' I also get the working path /var/folders/_h/cbm2fp054c9byr188mdyxhw00000gp/T/com.apple.quicklook.qlmanage/... Thanks! :)

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

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!

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

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.

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!

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

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!

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!

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.

Clarification: the problem is reproducible on three M1 Max-based computers. But not one M3 Max-based computer. Not sure that is enough to conclude anything...

Thanks a lot Quinn/@DTS Engineer—as always you to invaluable help to us! 😀 And sorry not for responding until now... I got busy with something else and then went on holiday 😅 By using the rvictl tool as you suggested we were able to see a difference between iOS 17/18! In iOS 18 the SYN message has also the ECE and CWR flags set! Our device responds with RST and then iOS 18 tries two more times with same result: Isn't iOS 18 supposed to fallback on RST and send new SYN without those flags set? If not then what are the alternatives? Can we configure this for our app? We use NSMutableURLRequest. Do we need to update some really old firmware in our device? This is most likely not possible and will make some customers sad :( Thanks again for the info about the rvictl tool!

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. @DTS Engineer /Quinn, thanks for the tips page... But please forgive me when you only get in here occasionally then you can easily forget those... but I will try not to use the 'reply' in the future... but maybe 'reply' should just be removed then... :) Such a TSI code-level support request would be routed to me, and I’m gonna give you the same answer there as I’m giving you here. Oh wauw! :D Did you try my Network framework / disableECN suggestion? No I did not try that because it will not solve our problem as such... The thing is that we believe iOS 18 should do a fallback! Creating the TSI was to get Apple's network engineers to give their take on that, i.e., conclude that Apple network has a bug or not. Doesn't that make sense instead of doing stop-gap solutions? And yes, I feel like Feedback has never brought us anywhere sorry... it seems to us no-one is actually looking at them 😅 Thanks a million as usual :)