I tried that while debugging earlier, applying NFC normalization didn't help, NFD looked like another promising workaround (fixed the cases I had at hand). I settled on the folding approach as that felt more robust, given that NFC still failed. So if normalisation changes things then that it’s clearly Foundation’s bug to fix. Otherwise not? I mean, a framework that can't reliably compare two strings, how are developers supposed to build upon such a framework?

What are you creating this array for? Is it a temporary thing that only exists in memory and it used, say, to present a sort list of items to the user? Or are you using it for something more persistent? Or something that’s internal, so not being displayed to the user. After sorting, the elements are divided into sections and then displayed to the user. The section membership is unstable now which causes the UI framework to throw. I think I found a workaround for now in this category on NSString: - (NSComparisonResult)fb24975737LocalizedCaseInsensitiveCompare:(NSString *)other { NSLocale *locale = NSLocale.currentLocale; // Fold each entire string first, then collate without case-insensitive options. NSString *left = [self stringByFoldingWithOptions:NSCaseInsensitiveSearch locale:locale]; NSString *right = [other stringByFoldingWithOptions:NSCaseInsensitiveSearch locale:locale]; return [left compare:right options:0 range:NSMakeRange(0, left.length) locale:locale]; } With this code I cannot reproduce the inconsistencies anymore. Looks like Foundation's combined case-insensitive comparison is trying to outsmart itself.

Tried switching to localizedCaseInsensitiveCompare, though that has similar issues NSString *a = @"\u1F28\u0399abc"; // ἨΙabc NSString *b = @"\u1F2E\u0399zzz"; // ἮΙzzz [a localizedCaseInsensitiveCompare:b] == NSOrderedDescending; // YES [b localizedCaseInsensitiveCompare:a] == NSOrderedDescending; // YES NSString *c = @"\u0397\u0313\u0345abc"; // ᾘabc NSString *d = @"\u1F28\u0399abc"; // ἨΙabc [c localizedCaseInsensitiveCompare:d] == NSOrderedAscending; // YES [d localizedCaseInsensitiveCompare:c] == NSOrderedSame; // YES Really getting confused here... Feedback Assistant: FB24975737

Still happens with 26.6. I've now disabled this option, hoping that'll work around the issue.

That would be great. I've asked the end-user reporting the issue to confirm.

In my case the crash was caused indirectly by animating the viewcontrollers change inside splitViewController(_:collapseSecondary:onto:). Not sure if that's allowed by UIKit, but similarly to your case this code has worked for more than a decade without problems until 26.1. Anyway, after removing the animation the issue disappears.

I'm seeing a similar crash, also started on 26.1, see below. In my case I have no instance level button var, so I'm trying to find another workaround.. Thread 0 Crashed: 0 libobjc.A.dylib 0x308a6544c objc_retain 1 UIKitCore 0x31a164490 -[_UIButtonBarItemLayout _updateItemViewSizing] 2 UIKitCore 0x31a164180 -[_UIButtonBarItemLayout _updateItemView] 3 UIKitCore 0x31a6b6dc8 -[_UIButtonBarItemLayout minimumLayoutWidthGivenMinimumSpaceWidth:] 4 UIKitCore 0x31a6b7ee8 -[_UIButtonBarItemGroupLayout recalculateLayoutWidthsGivenItemSpaceWidth:] 5 UIKitCore 0x31a6a5a24 -[_UIButtonBar _widthInfoForLayout:] 6 UIKitCore 0x31a1623b0 -[_UIButtonBar _layoutBar] 7 UIKitCore 0x31a162324 __42-[_UIButtonBarStackView updateConstraints]_block_invoke 8 UIKitCore 0x31b717a88 +[UIView(Animation) performWithoutAnimation:] 9 UIKitCore 0x31a1622cc -[_UIButtonBarStackView updateConstraints] 10 UIKitCore 0x319dc97e4 -[UIView(AdditionalLayoutSupport) _previousFittingSizeInfo] [...]

Feedback report: FB20496282

Yes, my iOS file provider is NSFileProviderReplicatedExtension, and is available on iOS, macOS and visionOS. So that works ok. The UI extension is UIKit, and that one is currently available on iOS only. I am now trying to extend that to visionOS. MacOS will follow after that as it needs code changes.

Do you mean that uploading to TestFlight a macOS app with an NSFileProviderReplicatedExtension + a file provider UI extension triggers the same error? That will be an issue in the app submission process, because these extensions are supported on macOS, as discussed here. I haven't tested this with macOS (yet). What I meant is that the two documents I listed before have the same contradiction for macOS as for visionOS. I am not sure if the availability of the sample code makes it more official. I mean, that page lists Mac Catalyst as supported while FPUIActionExtensionViewController.h states FPUI_AVAILABLE(ios(11.0), macos(10.15)) API_UNAVAILABLE(macCatalyst) I'll probably try this for macOS at some point in the future as the app is also available on macOS (with NSFileProviderReplicatedExtension), but my current File Provider UI code is based on UIKit (coming from iOS) so that is why I started with visionOS. Which is not really encouraging yet :-) From a developer's viewpoint the issue is pretty simple, as the full framework documentation lists visionOS as supported, and it works as expected in the simulator. It looks like just a flag at the App Store that is blocking the upload. I remember facing a similar issue in the past with the App Store blocking a specific (legitimate) app type. I don't recall the exact details, maybe someone else recognizes this? Anyway, I'll file the FB report as you requested. Richard.

Just tried the same experiment in a (newly created) AppKit app, exact same readability issue, so it's not SwiftUI-specific. Hmm, looks like I cannot edit the title of this post, or add an "appkit" tag.

FB20158292

That post advises to use .destructive (which is clearly not working) and provides an (iOS-only?) option to change the color of all non-destructive buttons, and I don't want to turn all my buttons red 😎 I'll file a FB report.

Here is a simple view to demonstrate the issue struct ContentView: View { @State private var isPresented = false var body: some View { VStack { Button("Test") { isPresented = true } } .alert("Test", isPresented: $isPresented, actions: { Button("Delete All", role: .destructive) {} }, message: { Text("Are You Sure?") }) .padding() } } Which results in The destructive button is almost unreadable. WCAG score is 1.4, far below the minimum recommended 4.5. I found this post on SO going back to Big Sur, but not on this forum. Any known workarounds (except for building my own dialogs, which I am trying to avoid)? Using confirmationDialog instead of alert does not make a difference.

Opening a Private Window "fixed" it for me.