If you use UISceneDelegate's scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) to handle deep links (such as tapping a widget) you might run into an issue where this callback is called twice in the majority of cases. If you push a view controller in response to this, you might end up with two pushed view controllers, if you do not mitigate this. This is exclusively an issue in iOS 26.0 and works as expected on iOS 18. func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) { /// Add any widget to the home screen that uses the widgetURL modifier and tap them. Most of the time, openURLContexts() will get called twice. /// If you run this project on iOS 18, it's *always* called once as expected. print("openURLContexts \(URLContexts)") } Filed as FB20301454

There is no issue with triggering onDrag when long-pressing for the first time. However, if the user releases their finger and the DropDelegate determines this is not a valid drop operation, it will not trigger a view update. In this case, when the user long-presses the same view again, the onDrag method will not be triggered even though the floating Preview view is already displayed under the finger. The problem will not recur if the DropDelegate updates the view (such as swapping the positions of views). The same code works without issues on iOS 18. The problem can be reproduced with simple code like the following： struct ContentView: View { var body: some View { Rectangle() .fill(.blue) .onDrag { print("OnDrag") return NSItemProvider() } } } The "OnDrag" log will only be output once.

‏‏‏آلَحـ🇾🇪‏ᬼ⃝⃡Wٌـّاج this string cause a crash on iOS 26 when sett label.text Crashed: com.apple.main-thread 0 CoreText 0xf720c std::__1::__hash_table<std::__1::__hash_value_type<long, CGPoint>, std::__1::__unordered_map_hasher<long, std::__1::__hash_value_type<long, CGPoint>, std::__1::hash, std::__1::equal_to, true>, std::__1::__unordered_map_equal<long, std::__1::__hash_value_type<long, CGPoint>, std::__1::equal_to, std::__1::hash, true>, std::__1::allocator<std::__1::__hash_value_type<long, CGPoint>>>::erase(std::__1::__hash_const_iterator<std::__1::__hash_node<std::__1::__hash_value_type<long, CGPoint>, void*>>) + 300 1 CoreText 0xf63d4 TGlyphComposer::ComposeGlyphs(long, TInlineVector<unsigned short, 30ul> const&, TInlineVector<long, 30ul> const&) + 2896 2 CoreText 0x8b018 TCombiningEngine::ResolveCombiningMarks(TCombiningEngine::CombiningFlag, bool, bool*) + 2232 3 CoreText 0x4edf0 TKerningEngine::PositionGlyphs(TRunGlue&, TCharStream const&, signed char) + 1108 4 CoreText 0x4eee8 TTypesetter::FinishLayout(std::__1::tuple<TLine const*, TCharStream const*, void const* ()(__CTRun const, __CFString const*, void*), void*, std::__1::shared_ptr, unsigned int, unsigned char, bool, long> const&, TRunGlue&, signed char, SyncState) + 64 5 CoreText 0x34608 TTypesetterAttrString::Initialize(__CFAttributedString const*, bool) + 3300 6 CoreText 0x34d88 TTypesetterAttrString::TTypesetterAttrString(__CFAttributedString const*, __CFDictionary const*, bool) + 160 7 CoreText 0x34c38 CTLineCreateWithAttributedString + 84 8 UIFoundation 0x6204 __NSCoreTypesetterCreateBaseLineFromAttributedString + 704 9 UIFoundation 0xafd38 -[NSCoreTypesetter _stringDrawingCoreTextEngineWithOriginalString:rect:padding:graphicsContext:forceClipping:attributes:stringDrawingOptions:drawingContext:stringDrawingInterface:] + 2652 10 UIFoundation 0x26bc __NSStringDrawingEngine + 1592 11 UIFoundation 0xab308 -[NSString(NSExtendedStringDrawing) boundingRectWithSize:options:attributes:context:] + 164 12 UIKitCore 0x186a978 + 132 13 UIKitCore 0x48a7c + 668 14 UIKitCore 0x186b35c + 444 15 UIKitCore 0x186eb30 + 408 16 UIKitCore 0x486d4 + 136 17 UIKitCore 0x47c1c + 80 18 UIKitCore 0x1b68e4 + 80 19 UIKitCore 0x1867c08 + 760 20 UIKitCore 0x18678ec + 72 21 UIKitCore 0x186be30 + 104 ....... 28 UIKitCore 0xa894e0 + 52 29 UIKitCore 0x19047fc + 76 30 UIKitCore 0xa88b0c + 1196 31 UIKitCore 0xa91ce0 + 524 32 UIKitCore 0xa9222c + 280 33 UIKitCore 0xa90550 + 3036 34 UIKitCore 0x1e1604 + 280 35 UIKitCore 0x27078 + 912 36 UIKitCore 0x27b38 + 40 37 UIKitCore 0x190df68 + 2532 38 QuartzCore 0xac8bc + 116 39 QuartzCore 0x8f2fc + 600 40 QuartzCore 0xadf84 + 200 41 QuartzCore 0x6ef78 + 536 42 QuartzCore 0x9bab0 + 644 43 QuartzCore 0xa93c0 + 88 44 UIKitCore 0x780f0 + 52 45 UIKitCore 0x78024 + 352 46 UIKitCore 0x85ee8 + 128 47 UIKitCore 0x85378 + 60 48 UpdateCycle 0x15f8 UC::DriverCore::continueProcessing() + 84 49 CoreFoundation 0x6a230 + 28 50 CoreFoundation 0x6a1a4 + 172 51 CoreFoundation 0x47c6c + 232 52 CoreFoundation 0x1d8b0 + 820 53 CoreFoundation 0x1cc44 + 532 54 GraphicsServices 0x1498 GSEventRunModal + 120 55 UIKitCore 0xa9ddc + 792 56 UIKitCore 0x4eb0c UIApplicationMain + 336 57 UIKitCore 0x18a860 + 588 59 ??? 0x18c7cae28 (缺少)

We’ve recently updated our app to adopt the native iOS 26 tab bar. Since then, we’ve started seeing crashes on iOS 26 devices with swift_getObjectType appearing in the stack. I’ve reviewed the logs in Organizer but couldn’t find anything conclusive. The issue seems isolated to iOS 26 and doesn’t reproduce on earlier versions. com.grofers.consumer_issue_2cc3a4a209ab2b47bfbdab919a320fa7_crash_session_68148be54ef5441fac56d3138d055bac_DNE_5_v2_stacktrace.txt

Some character display on iOS 26 cause crash String sample Crash stack

I have an NSBrowser inside a window. When I start resizing a column I noticed a peculiar behavior: it causes NSWindowWillStartLiveResizeNotification to get posted for the NSWindow the browser is inside (and did end gets posted when column resizing finishes). The browser is not the NSWindow contentView but a descendant of the contentView. I have my reasons for caring (I'm currently listening for these window resize notifications) but my code naively assumes that NSWindowWillStartLiveResizeNotification - NSWindowDidEndLiveResizeNotification indicates a window resizing session, not a column resizing session for the NSBrowser. This is in contrast to NSOutlineView. When resizing columns in NSOutlineView the window resize notifications do not get posted. NSBrowser deliberately kicks it off: -[NSWindow _startLiveResize]; -[NSBrowser _resizeColumn:withEvent:] () So this seems quite intentional but is it necessary in modern macOS? Should I file a bug? I already did FB20298148

The .tint modifier doesn't seem to change the background color on the redesigned macOS 26 toggles. For example, using: Toggle("", isOn: isOn) .toggleStyle(.switch) .tint(.cyan) .scaleEffect(0.8) .opacity(isEnabled ? 1.0 : 0.4) the toggles use the system accent color instead of cyan. Has SwiftUI introduced a new modifier for that? I couldn't find anything in the June 2025 changes.

I created a tableview with two cells and configured a left-swipe action for each cell. When I swipe left, the cell displays normally. When I swipe the cell back to its original position, the view displays normally. When I quickly swipe right after the cell has been reset, the view displays noticeably abnormally. import UIKit import Vision import CoreImage import CoreImage.CIFilterBuiltins class ViewController: UIViewController { var tasks = ["学习 Swift", "阅读文档", "编写代码", "测试应用", "提交审核"] private let tableView: UITableView = { let table = UITableView() table.register(UITableViewCell.self, forCellReuseIdentifier: "cell") return table }() override func viewDidLoad() { super.viewDidLoad() view.addSubview(tableView) tableView.frame = view.bounds tableView.dataSource = self tableView.delegate = self // 关键设置 tableView.estimatedRowHeight = 0 tableView.estimatedSectionHeaderHeight = 0 tableView.estimatedSectionFooterHeight = 0 tableView.rowHeight = 60 // 固定高度 } } // MARK: - UITableViewDataSource extension ViewController: UITableViewDataSource { func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { return tasks.count } func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { let cell = tableView.dequeueReusableCell(withIdentifier: "cell", for: indexPath) cell.textLabel?.text = tasks[indexPath.row] cell.textLabel?.numberOfLines = 0 // 允许多行文本 return cell } } // MARK: - UITableViewDelegate extension ViewController: UITableViewDelegate { func tableView(_ tableView: UITableView, trailingSwipeActionsConfigurationForRowAt indexPath: IndexPath) -> UISwipeActionsConfiguration? { let deleteAction = UIContextualAction(style: .destructive, title: nil) { [weak self] (_, _, completionHandler) in guard let self = self else { return } } deleteAction.image = UIImage(systemName: "trash") deleteAction.backgroundColor = .systemRed let configuration = UISwipeActionsConfiguration(actions: [deleteAction]) configuration.performsFirstActionWithFullSwipe = false return configuration } // 可选：精确控制行高（二选一） func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat { return 60 // 固定高度，或者根据内容计算 } }

Is anyone else experiencing NavigationStack title disappearing in iOS 26? Hey everyone, I just updated to iOS 26 and I'm running into a really frustrating issue with my app. Wondering if anyone else is seeing this or if I'm missing something obvious. What's happening: My navigation titles are completely blank when the app first loads, but then magically appear when I scroll down. It's super weird and makes my app look broken at first glance. My setup: I'm using NavigationStack with some pretty standard stuff: Navigation title with .navigationTitle() A toolbar with a settings button ScrollView content with a gradient background Here's basically what I have: NavigationStack { ScrollView { VStack(spacing: 24) { // My app content here - cards, etc. ForEach(myItems) { item in // Content cards } } .padding() } .background( LinearGradient( gradient: Gradient(colors: [ Color.surfacePrimary, Color.surfacePrimary.opacity(0.95), Color.surfaceSecondary.opacity(0.3) ]), startPoint: .top, endPoint: .bottom ) ) .navigationTitle("My Title") // ← This doesn't show up initially! .toolbar { ToolbarItem(placement: .navigationBarTrailing) { Button("Settings") { // Settings action } } } } The weird part: Works perfectly fine on my iOS 18.6.2 device Completely broken on iOS 26 - blank navigation area As soon as I scroll, the title appears and stays there Happens on both simulator and physical device What I've tried: Double-checking my code (it's identical to what worked before) Testing on multiple devices Different navigation title strings Removing and re-adding the toolbar Has anyone else run into this? I'm thinking it might be an iOS 26 bug with NavigationStack, but I wanted to check if others are seeing it before filing a radar. It's affecting my main landing screens (Tennis, NFL, and Prediction Markets tabs) and honestly looks pretty bad when users first open the app and see blank headers. Temporary fix I found: If anyone else hits this, I discovered that forcing inline titles works as a workaround: .navigationTitle("My Title") .navigationBarTitleDisplayMode(.inline) // This fixes it but kills large titles Obviously not ideal since we lose the nice large title behavior, but at least the titles show up. Questions: Is this happening to anyone else's iOS 26 apps? Any better workarounds that preserve large titles? Should I file this as a radar or is Apple already aware? Really hoping this gets fixed soon - having to choose between broken navigation or losing large titles is pretty frustrating. Thanks for any insights! Anyone else dealing with this NavigationStack nightmare in iOS 26? 😅

From what I’ve seen, this issue has been around since macOS 13 and can be reproduced reliably. It happens with some apps like Music, Notes, and Google Chrome. Here’s how to see it: 1.Make sure “Minimize windows into application” is enabled in System Settings, or just open a minimized app later directly from its application icon. 2.Open one of the apps mentioned above. 3.Minimize it. 4.Click the minimized app in the Dock to restore it. You’ll notice the GUI flashes for a moment and the minimize animation plays again. Some additional info here: https://forums.macrumors.com/threads/weird-glitches-during-restore-from-minimalization-of-any-app.2370260/ A video clipped from another GitHub issue: https://private-user-images.githubusercontent.com/13177224/445474477-36d8c784-9588-4186-8b6a-875c4077ce1c.mp4?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NTgyMTQ0ODEsIm5iZiI6MTc1ODIxNDE4MSwicGF0aCI6Ii8xMzE3NzIyNC80NDU0NzQ0NzctMzZkOGM3ODQtOTU4OC00MTg2LThiNmEtODc1YzQwNzdjZTFjLm1wND9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA5MTglMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwOTE4VDE2NDk0MVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTMwOWYwZWVmMDBjZWRiNzA2MDg1NDFiMTIxNmU3ZmFiZWIwOThjYzRmYmE1OWJiZWNlZjFlNjRlYjA4NTVkYjgmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.xbAxdTgxadCVCZPsnZkhx9HnVbjP-D5w1GfPTBatIWQ

I’m building a document-based macOS app using SwiftUI with an AppKit NSDocument. By default, when the window has no toolbar, the document title and proxy icon (with the edited state dot and standard saving controls) appear nicely centered in the title bar. However, as soon as I attach a toolbar - even an empty one - the document proxy moves to the leading edge of the title bar. Is there a way to keep the document proxy/title centered in a document-based SwiftUI app while also using a toolbar? Or is the left-alignment now the only supported behavior when a toolbar is present? Thanks in advance for any guidance.

I noticed that when I have a fullscreen window in macOS 26, sidebars look like they are cut off at the top: they suddenly stop where the title bar/toolbar would appear when moving the mouse to the top of the screen, leaving a wide empty gap. Am I the only one who finds this ugly? Is this intended, or is there a workaround? This is how it looks in fullscreen (the sidebar borders are not easy to distinguish, look for the drop shadow): And this when moving the mouse to the top screen border to show the menu bar: I created FB20291636. @main class AppDelegate: NSObject, NSApplicationDelegate, NSWindowDelegate { func applicationDidFinishLaunching(_ aNotification: Notification) { let splitViewController = NSSplitViewController() splitViewController.addSplitViewItem(NSSplitViewItem(sidebarWithViewController: ViewController())) splitViewController.addSplitViewItem(NSSplitViewItem(viewController: ViewController())) let window = NSWindow(contentViewController: splitViewController) window.styleMask = [.titled, .closable, .miniaturizable, .resizable, .fullSizeContentView] window.toolbar = NSToolbar() window.delegate = self window.makeKeyAndOrderFront(nil) } func window(_ window: NSWindow, willUseFullScreenPresentationOptions proposedOptions: NSApplication.PresentationOptions = []) -> NSApplication.PresentationOptions { return [.autoHideToolbar, .autoHideMenuBar, .fullScreen] } } class ViewController: NSViewController { override func loadView() { let stack = NSStackView(views: [ NSTextField(labelWithString: "asdf") ]) stack.orientation = .vertical stack.alignment = .leading view = stack view.frame = CGRect(x: 0, y: 0, width: 300, height: 300) } }

When using LazyVGrid within a ScrollView with the .searchable modifier, scrolling is impossible on iPhone 15 (I’m assuming other older devices are affected too). This behavior does not occur on iPhone 16 and newer. This also only happens, when the search bar is placed at the top, for example if the ScrollView is within a TabView. Here's a short screen recording of the issue: And this is a minimal example causing the issue: import SwiftUI struct ContentView: View { var body: some View { TabView { Tab("Text", systemImage: "gear") { ExampleTab() } } } } struct ExampleTab: View { @State private var searchText: String = "" var body: some View { NavigationStack { ScrollView { LazyVGrid( columns: [GridItem( .adaptive(minimum: 120) )], spacing: 20 ) { ForEach(1..<100) { index in Text("Test \(index)") } } } .searchable(text: self.$searchText) } } }

I'm encountering an issue with system accessories in UICollectionViewCells after overriding the trait collection. Specifically, the accessories are misaligned and shifted downwards. This issue occurs when using setOverrideTraitCollection (other trait override methods produce the same result). Interestingly, this doesn't happen with all accessories; for example, the disclosureIndicator is scaled correctly. If I don't use setOverrideTraitCollection (or other trait override methods), the system accessories scale as expected. Here's a code snippet demonstrating the issue. I have a "Fix Size" button that overrides the trait collection to a UITraitCollection with a UIContentSizeCategory of large. The "Follow Settings" button resets the trait collection, allowing the views to scale according to the system settings. import UIKit class ViewController: UIViewController { let button: UIButton = { let button = UIButton(type: .system) button.setTitle("Fix Size", for: .normal) return button }() let buttonRe: UIButton = { let button = UIButton(type: .system) button.setTitle("Follow Settings", for: .normal) return button }() var listItems: [Int] = [1, 2, 3, 4, 5] var collectionView: UICollectionView? override func viewDidLoad() { super.viewDidLoad() button.addTarget( self, action: #selector(ViewController.buttonTapped), for: .touchUpInside ) buttonRe.addTarget( self, action: #selector(ViewController.buttonTappedToRe), for: .touchUpInside ) view.backgroundColor = .white view.addSubview(button) view.addSubview(buttonRe) setupCollectionView() if let collectionView = collectionView { view.addSubview(collectionView) } } override func viewDidLayoutSubviews() { super.viewDidLayoutSubviews() collectionView?.frame = CGRect( x: 0, y: 0, width: view.bounds.width, height: view.bounds.height - 100 ) button.frame = CGRect( x: 0, y: view.bounds.height - 100, width: view.bounds.width / 2, height: 50 ) buttonRe.frame = CGRect( x: view.bounds.width / 2, y: view.bounds.height - 100, width: view.bounds.width / 2, height: 50 ) } @objc func buttonTapped() { setOverrideTraitCollection( UITraitCollection(preferredContentSizeCategory: .large), forChild: self ) } @objc func buttonTappedToRe() { setOverrideTraitCollection(nil,forChild: self) } private func updateCollectionViewLayout() { guard let collectionView = collectionView else { return } collectionView.collectionViewLayout.invalidateLayout() collectionView.performBatchUpdates(nil) collectionView.reloadData() } private func setupCollectionView() { var config = UICollectionLayoutListConfiguration(appearance: .insetGrouped) config.trailingSwipeActionsConfigurationProvider = { [weak self] indexPath in let deleteAction = UIContextualAction(style: .destructive, title: "Delete") { [weak self] _, _, completion in self?.deleteItem(at: indexPath) completion(true) } return UISwipeActionsConfiguration(actions: [deleteAction]) } let layout = UICollectionViewCompositionalLayout.list(using: config) let collectionView = UICollectionView(frame: view.bounds, collectionViewLayout: layout) collectionView.delegate = self collectionView.dataSource = self collectionView.register(UICollectionViewListCell.self, forCellWithReuseIdentifier: "cell") collectionView.isEditing = true self.collectionView = collectionView } private func deleteItem(at indexPath: IndexPath) { listItems.remove(at: indexPath.item) guard let collectionView = collectionView else { return } collectionView.deleteItems(at: [indexPath]) } override func traitCollectionDidChange(_ previousTraitCollection: UITraitCollection?) { super.traitCollectionDidChange(previousTraitCollection) if previousTraitCollection?.preferredContentSizeCategory != traitCollection.preferredContentSizeCategory { updateCollectionViewLayout() } } } extension ViewController: UICollectionViewDataSource { func numberOfSections(in collectionView: UICollectionView) -> Int { return 1 } func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int { return listItems.count } func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell { let cell = collectionView.dequeueReusableCell(withReuseIdentifier: "cell", for: indexPath) as! UICollectionViewListCell var content = UIListContentConfiguration.valueCell() content.text = "Item \(listItems[indexPath.item])" cell.contentConfiguration = content cell.accessories = [.delete( options: UICellAccessory.DeleteOptions( reservedLayoutWidth: .custom(50) ) )] return cell } } extension ViewController: UICollectionViewDelegate { func collectionView(_ collectionView: UICollectionView, didSelectItemAt indexPath: IndexPath) { collectionView.deselectItem(at: indexPath, animated: true) } } The attached screenshot illustrates the misalignment that occurs after tapping the 'Fix Size' button, with the system accessibility text size set to accessibilityExtraExtraExtraLarge setting Has anyone else experienced this issue or have suggestions on how to resolve it? Any help would be greatly appreciated!

When preparing the app for the new iOS 26, I came across an unpleasant design decision. Specifically, in the new design, the keyboard has rounded corners, under which the system background is visible. And here we have only two options, a light/dark background, which breaks all keyboard calls in the application. Can you tell me if there is any way around this problem?

I have a TabView (no modifiers) as the top-level view in my app. Starting with iOS 26 it starts off partially "under" the Status Bar, and then repositions if I switch between apps. Starting Point After Switching To/From Another App In the simulator, pressing "Home" and then reopening the app will fix it. Anyone else seeing something similar? Is there a modifier I'm missing on TabView that might prevent this behaviour? Thanks!

In our app we show a warning when UIScreen.main.isCaptured is true. After updating to iOS 26, some users are seeing this warning, even though they say they are not recording the screen. The issue persists after rebooting and reinstalling the app. I know this flag is expected to be true during screen recording or sharing. Are there any new scenarios in iOS 26 that could trigger isCaptured, or any known issues where it may be set unexpectedly or maybe accidentally by the user?

Hello,Our app has caught an issue with gesture recognizers. This problem only occurs on Mac OS 26.0. From the stack trace, it seems that this is not a problem on the app side, but an exception reported by AppKit. I have provided the stack trace, please help check it. stack info: NSInternalInconsistencyException: AppKit doesn't support comparing gesture recognizers across windows AppKit doesn't support comparing gesture recognizers across windows NSInternalInconsistencyException __exceptionPreprocess exception info: OS Version: macOS 26.0.0 Exception Type: NSInternalInconsistencyException: AppKit doesn't support comparing gesture recognizers across windows Crash Thread ID: 0 Application Specific Information: AppKit doesn't support comparing gesture recognizers across windows NSInternalInconsistencyException __exceptionPreprocess expanded stack: Crashed Thread:0 stack.package stack.filename stack.function stack.lineno stack.in_app CoreFoundation None __exceptionPreprocess None 0 libobjc.A.dylib None objc_exception_throw None 0 Foundation None -[NSAssertionHandler handleFailureInFunction:file:lineNumber:description:] None 0 AppKit None NSGestureRecognizerContainerCompare None 0 AppKit None -[NSView(GestureContainers) _compareGestureRecognizerContainer:] None 0 AppKit None -[NSGestureRecognizer isDeeperThanContainer:referenceNode:] None 0 Gestures None GFGestureNodeDefaultValue None 0 Gestures None GFGestureComponentControllerSetNode None 0 Gestures None __swift_memcpy24_8 None 0 Gestures None __swift_memcpy24_8 None 0 Gestures None __swift_memcpy24_8 None 0 Gestures None __swift_memcpy24_8 None 0 Gestures None __swift_memcpy24_8 None 0 Gestures None block_destroy_helper None 0 Gestures None __swift_memcpy80_8 None 0 Gestures None __swift_memcpy80_8 None 0 CoreFoundation None CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION None 0 CoreFoundation None __CFRunLoopDoObservers None 0 CoreFoundation None __CFRunLoopRun None 0 CoreFoundation None _CFRunLoopRunSpecificWithOptions None 0 HIToolbox None RunCurrentEventLoopInMode None 0 HIToolbox None ReceiveNextEventCommon None 0 HIToolbox None _BlockUntilNextEventMatchingListInMode None 0 AppKit None _DPSBlockUntilNextEventMatchingListInMode None 0 AppKit None _DPSNextEvent None 0 AppKit None -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] None 0 AppKit None -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:] None 0 AppKit None -[NSApplication run] None 0 AppKit None NSApplicationMain None 0 None None None 0

Scenario: Typing Chinese Zhuyin “ㄨㄤ” and then selecting the candidate word “王”. On iOS 18, the delegate (textField:shouldChangeCharactersInRange:replacementString:) is called with: range: {0, 2} replacementString: "王" On iOS 26, the delegate (textField:shouldChangeCharactersInRanges:replacementString:) instead provides: ranges: [{2, 0}] replacementString: "王" This results in inconsistent text input handling compared to earlier system versions. Implement: Limit user input to a maximum of 100 Chinese characters. - (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string { if ([textField markedTextRange]) { return YES; } NSString *changedString = [textField.text stringByReplacingCharactersInRange:range withString:string]; if (changedString.length > 100) { return NO; } return YES; } Questions: Is this an intentional change in iOS 26? If intentional, what is the recommended way to handle such cases in order to support both iOS 18 and iOS 26 consistently?

Scenario: Typing Chinese Zhuyin “ㄨㄤ” and then selecting the candidate word “王”. On iOS 18, the delegate (textField:shouldChangeCharactersInRange:replacementString:) is called with: range: {0, 2} replacementString: "王" On iOS 26, the delegate (textField:shouldChangeCharactersInRanges:replacementString:) instead provides: ranges: [{2, 0}] replacementString: "王" This results in inconsistent text input handling compared to earlier system versions. Implement: Limit user input to a maximum of 100 Chinese characters. - (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string { if ([textField markedTextRange]) { return YES; } NSString *changedString = [textField.text stringByReplacingCharactersInRange:range withString:string]; if (changedString.length > 100) { return NO; } return YES; } Questions: Is this an intentional change in iOS 26? If intentional, what is the recommended way to handle such cases in order to support both iOS 18 and iOS 26 consistently?