@DTS Engineer we believe we have found out the problem now... We created a TSI and Apple suggested that we tried find the crashing code by isolation, i.e., pulling our code until the crash disappeared. With some effort we managed to make a small demo app where the crash occurred. We realised that we have a UIView, which is backed by CATiledLayer. But for this view we also had backgroundColor = .clear. Even without the view's draw(rect:) method the app could crash! Apple's TSI engineer explained that if you have a view that implements draw(rect:) then you should not set the background color at the same time! But we needed the background to be transparent, and so we found that setting isOpaque = false instead of setting the background color made the crash disappear! We still believe that UIKit shouldn't crash if you set the background color, which it didn't do prior to iOS 26 :)

Hi again @DTS Engineer and thanks :) We have also a run with just address sanitizer and that shows a double free in 'com.apple.coreanimation.imageprovider.concurrent' - see attached file AppleAddressSanitizer.txt . We are a bit desperate by now, so I think we will create a TSI and refer to this forum thread... Best regards :)

Phew, I already feel bad asking you again 😅 It turns out that MTE and Malloc Stack Logging cannot be enabled at the same time. But I've tried to enabled Malloc Stack Logging, and then get delayed crash somewhere else. Unfortunately, I didn't really understand where/what to look for in Xcode. I tried to hit the 'Memory Graph Debug' but then the crash context seemed to get lost... most likely I am doing it wrong... A little context of our app: An UIPageViewController where you can swipe left/right to see the next/previous image. An UIViewController that has a TileImageView subview TileImageView that shows an image. This view is using CATileLayer. When draw(rect:) is called for a specific tile, we either show a cached tile or send a network request to a local server for the tile data. When the network response is received (callback in draw(rect:) we call the view's draw(rect:) to update with tile. Now if I scroll through the pages the crash may occur. As stated before this code was working fine before iOS 26. But of course I am unsure if the callback in draw(rect:) could somehow screw-up if e.g., the TileImageView was deallocated. But we should check for weak-self, etc. By trying to disable code I've found that if I pull out the code in the callback we still crash, i.e., we don't update the draw(rect:). But if I pull out the actual call we don't crash... wondering why the async network call seems to have this side-effect on this...

Hi @DTS Engineer and thanks :) I hope that your boss will get you a iPhone 17 😅 I'm trying to attach the ips-file again. I added the.txt extension to make it possible to attach it. I hope it will not screw up and make it an inline text-box when I git 'Reply' 😬 Looking at the ips-file I found that it does not show the finding that Xcode show, e.g., "Thread X: Use of deallocated memory" but it then misses "Memory allocated by Thread 1" and "Memory deallocated by Thread 1", so I am not sure the ips-file is that useful for MTE :( CrashReport-2025-11-28-141148.ips.txt

@DTS Engineer / Quinn, forgot to tag you on my reply yesterday, and so this extra comment today :)

Hey Quinn and thanks, I've managed to get an iPhone 17 Pro and enabled MTE, which is super awesome! 🤤 Looking forward to get that on MBPs and iPads... Not sure how to present the finding other than dumping some screenshots. But here the memory corruption doesn't seem to happen in URLRequest but in the UI stack alone. But I could be wrong 😅 So imagine the three screenshot below glued together... We are using CATiledLayer. Wondering if it could be related to that...

@dhoerl great that you could use my 'you need to reboot your Mac' finding... 😅 As I understand it Thumbnails and Previews are related. Thumbnails are small and quick to render. Previews are for bigger/better examples of your file, e.g., if you hit space-bar in the Finder on the file. If Preview is not implemented it may fall back to the Thumbnails-based solution. 😀

@DTS Engineer it seems like .crash-files gets translated into text-file... so I can no longer attach it. I will try to upload it and share a link instead...

@DTS Engineer thanks for noticing that... arghh, maybe I attached it as 'Text': 2025-10-08_10-13-45.1128_+0200-8acf1536892bf0576f963e1534419cd29e6e10b8.crash :)

We have created feedback FB17767223 now. Here we have attached two crash-reports, as well as a sysdiagnose and CI_PRINT_TREE PDFs... When the latter was enabled we didn't get the crash though. Thanks :)

After days of trying all kinds of weird stuff I finally got something to work! 😅 Findings: I never got qlmanage -t to trigger anything for my Thumbnail Extension 😑 Even though I used qlmanage -r, qlmanage -r cache and killall -9 QuickLookThumbnailing QuickLookUIService Finder I never got it to trigger. Even though I used pluginkit to see that my plugin thumbnail extension was registered AND enabled I never got it to trigger. log stream --predicate 'subsystem == "com.apple.quicklook"' was basically useless to me. Logging out and in of my compute made no difference. But then finally I tried to REBOOT my computer and then suddenly it started to work if I used the Finder app only! (qlmanage -t is still useless.) Holy cow I spent forever on that... 🙈 (macOS 15.4.1)

@DTS Engineer , I don't assume that we have correctly identified the problem, But to us it seems like a failed negotiation for TCP SYN, i.e., Apple network framework not doing fallback to a basic TCP SYN. Then it was our idea/hope to get a domain expert from Apple to give their five cents on it. But it sounds like that is not possible before I try that disableECN and so I will try to look into that one day... 🥹 Cheers!

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

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!

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...