We are seeing a hard main-thread abort on iOS 26 during cold launch when VoiceOver (or another accessibility client) is active. about 1–7 seconds after process start. The crashing thread essentially shows only main from the app; the fatal path is entirely in system frameworks. What happens is that UIAccessibility asks for an accessibility value, UIKit.axbundle handles it (on iOS 26.5 we exact-match-symbolicate this to -[_UITabButtonAccessibility accessibilityValue] + 120), then AXCoreUtilities safeSwiftValueForKey reflects a Swift object via Mirror / AttributeGraph. While copying an unowned field, the referent is already gone, so libswiftCore calls swift_abortRetainUnowned and the process dies. Not finding unowned in app source does not contradict this: the reflected object can live in system or SDK Swift state. OS versions in the corpus: iOS 26.5 (23F77), 26.6 (23G71), and 26.6.1 (23G83). All reports load UIKit.axbundle. Launch-to-crash gaps range from roughly 1.4s to 7.3s. Most 26.6 samples share UIKit.axbundle binary UUID 387c6473…; we did not have matching Device Support for that build locally. One iOS 26.5 sample has UIKit.axbundle binary UUID dca69975… and AXCoreUtilities 78a7c163…, both exactly matching local Device Support, so atos on that sample is trustworthy. On that iOS 26.5 sample (filename redacted), the symbolicated path is: VoiceOver / AX → UIAccessibility (_iosAccessibilityAttributeValue → _accessibilityAXAttributedValue → _accessibilityPotentiallyAttributedValueForNonAttributedSelector) → UIKit.axbundle -[_UITabButtonAccessibility accessibilityValue] + 120 → AXCoreUtilities (_AXSafeSwiftValueForKeyTm → safeSwiftValueForKey → _visitValueWithReflection) → AttributeGraph (AGTypeApplyFields2::Visitor::visit_field) → libswiftCore (swift_reflectionMirror_subscript → copyUnownedFieldContents → swift_unknownObjectUnownedLoadStrong → swift_abortRetainUnowned) → App: main only Frame 32 math: runtime 0x2be49b130, slide base 0x2be3cf000, offset 0xCC130 → _UITabButtonAccessibility accessibilityValue + 120. Questions for anyone hitting the same stack: 1.Is there already an Apple Feedback / radar for safeSwiftValueForKey + swift_abortRetainUnowned on iOS 26? crash_ios265_redacted.txt

I have an application that needs to make a USSD call, but on some devices the * and # don't work on the dialer, on others it does. if let phoneNumber = ussdNumberTextfield.text { let encoded = "telprompt:\(phoneNumber)".addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed)! if let url = URL(string: encoded) { if application.canOpenURL(url){ DispatchQueue.main.async { self.application.open(url, options: [:]) { success in } } } } }

Summary On iOS 27 the top scroll edge effect of a UITableView is sized around the UIRefreshControl as an edge element, but appears to key on the control's presence in the scroll view rather than its current height. After endRefreshing(), the control collapses to zero height but stays attached, and the effect region keeps reserving a refresh-control's worth of space. The first row stays blurred and dimmed even though it is scrolled fully clear of the navigation bar. Environment iOS 27 (beta), iPhone Xcode 27.0.0 Beta 4 UIKit, UITableView inside a UINavigationController Reproduces with the default edge effect style and with an explicit .soft Steps to reproduce Push a UITableViewController with a UIRefreshControl onto a navigation stack. Ensure content extends under the navigation bar (default for UITableViewController). Pull to refresh and let the refresh end. Observe the first row after the refresh control has retracted. Expected Once the control retracts, the edge effect returns to its pre-pull height and the first row renders crisply. Actual The region stays roughly one refresh-control height too tall and the first row stays blurred. Row positions are unaffected — content offset and adjustedContentInset are correct. Only the extent of the effect is wrong. It corrects itself on the next push/pop. Two probes that isolate it These narrow the cause to the control's presence rather than a general staleness: Re-assigning tableView.topEdgeEffect.style after endRefreshing(), including on a later runloop turn, does NOT correct the region. The style is not what is stale. Detaching the control DOES correct it immediately: tableView.refreshControl = nil So the region is measured from the control being in the hierarchy, and is never re-measured when the control merely collapses. Secondary issue A UIRefreshControl that has been detached is inert if the same instance is re-assigned: tableView.refreshControl = nil tableView.refreshControl = sameInstance // never triggers again A freshly constructed UIRefreshControl must be assigned instead. This is not documented and looks like a second bug. Minimal sample Attached. A UITableViewController with a refresh control and a "Push" bar button that pushes and pops an empty view controller, so the incorrect region and the post-navigation correction can be compared in one run. Related FB20756572 reports the same "edge-effect extent is stale until the next navigation" behaviour for UIScrollEdgeElementContainerInteraction sizing, and notes a change in iOS 27 seed 1. That report received no reply.

Hi everyone, I am currently implementing the new Search API in a UIKit app using @AppIntent(schema: .system.search), ShowInAppSearchResultsIntent, and UISceneAppIntent. While testing on the iOS beta, I’ve hit a significant lifecycle disparity between how UIKit and SwiftUI apps process system intents during a process-cold launch. According to the documentation for UIScene.ConnectionOptions.appIntent, this property should contain the intent that triggered the scene creation. However, in a UIKit app with a single-window scene lifecycle, this isn't happening consistently. Here is the behaviour breakdown I am seeing: Cold Launch (Siri/Search → App completely closed) SwiftUI App: Works as documented. The intent is present in connection options. scene(_:willPerformAppIntent:) is not called. UIKit App (with AppIntentSceneDelegate): The connectionOptions.appIntent property is completely nil inside scene(:willConnectTo:options:). Instead, the intent is delivered late via scene(:willPerformAppIntent:) right after scene connection completes. Warm Launch (Siri/Search → App already suspended in memory) Both SwiftUI and UIKit: Behave identically. The intent is delivered directly to scene(_:willPerformAppIntent:). The Problem Because of this gap, there is no unified way to handle a process-cold launch under UIKit. There is no LaunchOptionsKey available to identify that an App Intent initiated the launch, and the missing connection option forces us to bifurcate our routing logic. I have already filed a bug report via Feedback Assistant: FB24513291 and attached a minimal reproducible sample project. Has anyone else run into this specific AppIntentSceneDelegate race condition on the iOS beta? If so, what architecture or unified pattern are you using to normalize the lifecycle routing between cold and warm launches in UIKit? Any insights or clean workaround ideas would be highly appreciated!

Our app is being killed by the watchdog on iPadOS 26 (iPad Pro 11, 3rd gen) when navigating between tabs after using search. The crash only occurs when AssistiveTouch is enabled — disabling it prevents the issue entirely. The crash stack shows the main thread blocked in CoreUI vector glyph rasterization (CUINamedVectorGlyph _layerNamesForRenderingMode:inRendition:) triggered during a UINavigationController transition while the keyboard is being dismissed: UINavigationController _startCustomTransition → UIKeyboardSceneDelegate _restoreInputViewsWithId → UITextField resignFirstResponder → SwiftUI ViewGraphRootValueUpdater.render → UIButton layoutSubviews → UIImageView _setImage → CUINamedVectorGlyph _layerNamesForRenderingMode:inRendition: The termination reason: FRONTBOARD domain:10 code:0x8BADF00D "Failed to terminate gracefully after 5.0s" WatchdogEvent: process-exit WatchdogVisibility: Foreground Key observations: Only reproduces with AssistiveTouch enabled iPad Pro 11 (3rd gen), iPadOS 26 Our code is not on the crashing thread — it's entirely UIKit/CoreUI/SwiftUI framework code Similar to issues reported in thread/808808 (https://developer.apple.com/forums/thread/808808) and dotnet/maui#32365 (https://github.com/dotnet/maui/issues/32365) Is this a known issue with AssistiveTouch + UINavigationController transitions on iPadOS 26? Is there a recommended workaround?

In UIKit, Swift, I would need to insert a SF Symbol into a textField or a label. The symbol shows correctly in Xcode (in a string in code or in IB). But at runtime, the symbol is not found and replaced in the TextField by the unfound symbol: Is there a way to achieve this and display the symbol as a pure string, like we do with emoji ?

Feedback submitted: FB24460699 The sample projects are attached to the feedback report. Environment:iOS27 Beta6; iPhone 17Pro Problem:I have encountered a consistently reproducible third-party custom keyboard layout issue in iOS 27.0 beta 1 through beta 6. The custom keyboard initially appears correctly. If I switch apps while the text input remains focused and the keyboard remains visible, and then return to the host app, the system adds a 17-point area above the custom keyboard extension. Steps to reproduce Install and enable a third-party custom keyboard. Switch to the sample custom keyboard and open the host app so that the text editor in the center receives focus. Do not dismiss the keyboard or remove focus from the editor. Return to the Home Screen or switch to another app. Return to the host app. A new blank area now appears above the custom keyboard content. I tested both a system-determined extension view height and an extension view explicitly constrained to 180 points. Both configurations produce exactly the same change. After the foreground transition, the following extension-side values remain unchanged: view.bounds inputView.bounds extension.window.bounds view.safeAreaInsets, which remains {0, 0, 0, 0} The requested 180-point extension height Only the system keyboard frame received by the host app increases by 17 points. I also drew a rounded pink boundary inside the transparent extension root view. When the issue occurs, the new area appears outside that boundary. I tested several third-party keyboards and reproduced the issue with all of them. This suggests that the behavior is caused by iOS rather than by my app. Questions On iOS 27, is it expected behavior for a custom keyboard to gain a 17pt top area after its host app returns from the background? If this is a system issue, is there any workaround that can be used until it is fixed?

Product: Vozzy — custom keyboard + containing app for user-initiated dictation. Bundle: br.com.buddyapps.FlowType App Group: group.br.com.buddyapps.FlowType Flow: User selects our keyboard in a host app (Notes/Messages). Without Full Access, QWERTY input works locally. With Full Access, user taps Microphone to dictate. Containing app owns mic permission, AVAudioSession, capture, SpeechAnalyzer, Foundation Models. Keyboard never captures audio; it reflects shared state and inserts via textDocumentProxy. Already settled (do not re-ask): No public API to identify the host app. No public API to return to the host app. Feedback: FB22247647. Question (single issue): App Review Guideline 4.4.1 says keyboard extensions must not launch apps other than Settings. Is there any public, App-Review-compliant mechanism for a custom keyboard to request its containing app to activate audio capture for this user-initiated dictation flow? If yes: Which public API / App Intent surface? Is a visible switch to the containing app required? May the audio session continue while the user returns to the host app? May Stop/Cancel commands travel through an App Group while the containing app is backgrounded? Our current policy: Launch uses public NSExtensionContext.open (Debug only). Release has no keyboard path that opens the containing app. Release does allow in-place signaling when the app is already resident (App Group command + Darwin notification; launches nothing). We will not enable Release launch without a written answer naming an allowed public mechanism. App Group payload inventory + retention, Full Access-off QWERTY behavior, onboarding privacy copy. I do not have a focused Xcode sample because this is an API / App Review policy question, not a crash or incorrect return value. The keyboard extension never captures audio. Debug uses public NSExtensionContext.open; Release compiles that path out. I can attach flow diagrams and a device screen recording. Related: FB22247647 (return to host — already answered No; not re-asking).

When using the interactive swipe gesture to back in a navigation controller, cells in a collection view resize during the transition. It does not happen when using the back button. This can lead to very strange glitches. Most of the time it looks like the leading side gets bigger and smaller when animating. The trigger seems to be preservesSuperviewLayoutMargins = true. Sample project: https://gist.github.com/nicoreese/32080748babee9d10cfd151d4ad94622 Video of the issue as seen in the Health app: https://mastodon.social/@nicoreese/117138839377696127 Filed under: FB24461877 There's a similar issue with UIStackViews: FB22340191 Looks like both issues were introduced with iOS 26. Does anyone know a fix for this. I suspect this won't get fixed very fast at the system level.

I’m seeing in issue on iOS 27 with TextKit 1 backed UITextViews where grammar checking makes part of the text disappear. For TextKit 2 views, there's a blue underline and a shimmer effect that's applied to the text when a grammatical error is detected. For TextKit 1 views the underline appears but instead of the shimmer effect, the text just disappears. Steps to reproduce: Create a UITextView using TextKit 1: UITextView(usingTextLayoutManager: false) Fill it with a very long document (makes the bug easier to reproduce). Type a phrase that triggers a grammar correction, such as “self aware”. Wait for the system to suggest “self-aware”. The blue underline appears but the two words disappear. I've found a partial workaround by overriding NSLayoutManager.drawGlyphsForGlyphRange and calling CGContextSetFillColorWithColor on the affected range, but this isn't great. Filed as FB24319258. Has anyone else encountered this on the iOS 27 betas? Would appreciate any guidance.

I use VNRecognizeTextRequest to recognise a series of letters drawn by hand in the app. When I draw a few letters, it usually works fine. is recognised as "LV" But if I draw a single letter: or in most cases, I get zero observation, even using recognitionLevel3. But this was recognized as "V": It is apparently not a question of how well drawn letters, as even this was recognised as "LI": However, this one was not I have even tried to add custom words, to no avail: request.customWords = ["I", "V", "L"] General observation is that single letters are rarely or never recognised, dual letters may be recognised ; 3 letters are systematically recognised. But, I have now increased the brushWidth, and it works much better, even with single letter: What tuning of VNRecognizeTextRequest do I miss ?

I’m seeing inconsistent UISegmentedControl background-color behavior on certain devices running iOS 26. The same code works as expected on other devices and iOS versions, but on affected devices the control does not display the assigned backgroundColor. The issue occurs using standard UIKit colors and does not depend on custom fonts, images, or appearance extensions. Here is a simplified example using only public UIKit APIs: private let segmentedControl = UISegmentedControl(items: ["Card", "Email"]) private func setupSegmentedControl() { segmentedControl.selectedSegmentIndex = 0 guard let cardIcon = UIImage( systemName: "creditcard.fill", withConfiguration: UIImage.SymbolConfiguration( pointSize: 14, weight: .semibold ) ), let emailIcon = UIImage( systemName: "envelope.fill", withConfiguration: UIImage.SymbolConfiguration( pointSize: 14, weight: .semibold ) ) else { return } segmentedControl.setImage( cardIcon, forSegmentAt: 0 ) segmentedControl.setImage( emailIcon, forSegmentAt: 1 ) segmentedControl.backgroundColor = .systemGray5 segmentedControl.selectedSegmentTintColor = .systemBlue segmentedControl.layer.cornerRadius = 8 segmentedControl.clipsToBounds = true let font = UIFont.systemFont( ofSize: 14, weight: .medium ) segmentedControl.setTitleTextAttributes( [ .foregroundColor: UIColor.label, .font: font ], for: .normal ) segmentedControl.setTitleTextAttributes( [ .foregroundColor: UIColor.white, .font: font ], for: .selected ) segmentedControl.addTarget( self, action: #selector(segmentChanged(_:)), for: .valueChanged ) view.addSubview(segmentedControl) } @objc private func segmentChanged( _ sender: UISegmentedControl ) { print("Selected segment: \(sender.selectedSegmentIndex)") } UISegmentedControl Apple Documentation

My app has a split view with a root view and a detail view, both of which are inside their own navigation view controller. The navigation bar of the detail view can be hidden to allow the user to stay more focused on the content. The problem is that when the navigation bar of the content view is hidden in portrait mode and the iPhone is rotated to landscape mode, the navigation bar of the content view becomes visible automatically and the sidebar appears on the left side, but the navigation bar of the sidebar is hidden. Is it expected that the navigation bar becomes visible automatically when rotating the device? Why is the navigation bar of the sidebar hidden? Is this related to hiding the navigation bar of the content view and why does this happen? What am I supposed to do so that the navigation bar of the sidebar remains visible at all times? For comparison the two cases: After rotation when navigation bar of content view was visible: After rotation when navigation bar of content view was hidden: import UIKit class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { window = UIWindow(windowScene: scene as! UIWindowScene) window!.rootViewController = SplitViewController() window!.makeKeyAndVisible() } } class SplitViewController: UISplitViewController, UISplitViewControllerDelegate { var detailNavigationViewController: UINavigationController! init() { super.init(nibName: nil, bundle: nil) detailNavigationViewController = UINavigationController(rootViewController: DetailViewController()) viewControllers = [UINavigationController(rootViewController: RootViewController())] } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } func showDetail() { showDetailViewController(detailNavigationViewController, sender: nil) } } class RootViewController: UIViewController { override func loadView() { navigationItem.title = "Root" navigationItem.rightBarButtonItem = UIBarButtonItem(systemItem: .add) let button = UIButton(primaryAction: UIAction(handler: { [self] _ in (splitViewController as! SplitViewController).showDetail() })) button.setTitle("Show detail", for: .normal) button.translatesAutoresizingMaskIntoConstraints = false view = UIView() view.layer.backgroundColor = UIColor(white: 0.9, alpha: 1).cgColor view.addSubview(button) NSLayoutConstraint.activate([NSLayoutConstraint(item: button, attribute: .centerX, relatedBy: .equal, toItem: view, attribute: .centerX, multiplier: 1, constant: 0), NSLayoutConstraint(item: button, attribute: .centerY, relatedBy: .equal, toItem: view, attribute: .centerY, multiplier: 1, constant: 0)]) } } class DetailViewController: UIViewController { override func loadView() { navigationItem.title = "Detail" navigationItem.leftBarButtonItem = UIBarButtonItem(image: UIImage(systemName: "sidebar.leading"), primaryAction: UIAction(handler: { _ in UIView.animate(withDuration: 0.3) { [self] in self.splitViewController!.preferredDisplayMode = .oneOverSecondary } })) navigationItem.rightBarButtonItem = UIBarButtonItem(systemItem: .add) let button = UIButton(primaryAction: UIAction(handler: { [self] _ in navigationController!.setNavigationBarHidden(!navigationController!.isNavigationBarHidden, animated: true) })) button.setTitle("Toggle navigation bar", for: .normal) button.translatesAutoresizingMaskIntoConstraints = false view = UIView() view.addSubview(button) NSLayoutConstraint.activate([NSLayoutConstraint(item: button, attribute: .centerX, relatedBy: .equal, toItem: view, attribute: .centerX, multiplier: 1, constant: 0), NSLayoutConstraint(item: button, attribute: .centerY, relatedBy: .equal, toItem: view, attribute: .centerY, multiplier: 1, constant: 0)]) } } I created FB24413608.

Hello, I found a difference in application lifecycle behavior between iPadOS 26.5 and iPadOS 27 beta when the app is running in the foreground and the iPad top button is pressed to put the device into sleep. Test condition Device: iPad App state: app is running in foreground (active) Action: press the top button once to put the device to sleep Observed via UIApplicationDelegate lifecycle callbacks Observed behavior iPadOS 26.5 The following callbacks are called in this order: applicationWillResignActive applicationDidEnterBackground iPadOS 27 beta The following callbacks are called in this order: applicationWillResignActive applicationDidBecomeActive applicationWillResignActive applicationDidEnterBackground Expected behavior I expected the lifecycle sequence on iPadOS 27 beta to be the same as, or at least consistent with, iPadOS 26.5 when the device is put to sleep from the foreground app state. In particular, I did not expect applicationDidBecomeActive to be called during the transition to sleep/background. Question Is this changed behavior expected in iPadOS 27 beta, or could this be a bug in the beta? If this is expected, could you clarify the intended lifecycle behavior when the top button is pressed and the device transitions to sleep? Thank you.

On iOS 27 beta, when a search field hosted by a UISearchTab becomes active in landscape on a device with a sensor housing, the field lays out edge-to-edge, and its leading magnifier ends up inside the safe area inset. The same code is correct on iOS 26, so this looks like a regression. It then gives the environment, the setup (tabs API + UISearchTab with automaticallyActivatesSearch, plain UISearchController assigned in init, no placement or scrolling flags, no custom bar subclass), expected versus actual, and the measurements: window = 812 x 375, safeAreaInsets left/right 50 (usable 50…762) tab-hosted, active: field = (8.0, 122.0, 744.0, 44.0) ← 42pt inside the left inset tab-hosted, idle: field = (94.0, 311.0, 680.0, 44.0) ← trailing edge overruns by 12pt presented (no tabs): field = (101.7, 126.7, 553.0, 30.7) ← fully inside iOS 26 iOS 27 Not sure if it's known/has a supported workaround.

On iOS 27 beta 3, scene(_:willConnectTo:options:) is now called twice at launch — once for a .windowApplication scene, and once for a keyboard input scene (_UISceneSessionRoleKeyboardInputScene). On earlier iOS versions only the .windowApplication scene was delivered. Parts of my code read connectedScenes and take the first element, e.g.: UIApplication.shared.connectedScenes.first?.delegate as! SceneDelegate In my testing the .windowApplication scene is always first, so .first still works — but I can't find any documentation confirming this ordering. Questions: Is the order of connectedScenes guaranteed (is .windowApplication always first), or should it be treated as unordered? Should I instead always filter explicitly, e.g. first { $0 is UIWindowScene && $0.session.role == .windowApplication }? Is delivering the keyboard-input scene to the app's UIWindowSceneDelegate intended on iOS 27, or a beta artifact? FB24389661 (Ordering of UIApplication.connectedScenes not documented when multiple scene roles connect (iOS 27)

When a view combines .navigationBarBackButtonHidden(true) with a custom ToolbarItem(placement: .navigationBarLeading) back button, both controls render side by side in the navigation bar — the system back button is not fully suppressed, only visually emptied. This appears to be related to the new Liquid Glass toolbar platter system introduced this cycle. Environment Xcode 27 beta 3 iOS Version : 27.0 Reproduces on: Simulator 16.0 (1063.4) SimulatorKit 955.7 CoreSimulator 1168 Steps to Reproduce Create a NavigationStack with a root view and a pushed detail view. On the detail view, set .navigationBarBackButtonHidden(true). Also add a custom back button via .toolbar { ToolbarItem(placement: .navigationBarLeading) { Button { dismiss() } label: { HStack { Image(systemName: "chevron.backward"); Text("Back") } } } }. Expected Result Only the custom "Back" button (chevron + text) is visible. Actual Result Two back-button-shaped controls appear side by side: an empty/default system back button platter, and the custom "Back" button. Confirmed via Xcode's View Debugger (Debug ▸ View Debugging ▸ Capture View Hierarchy): two sibling UIPlatformGlassInteractionView nodes exist under NavigationBarPlatterContainer_v2 ▸ PlatterContainerHostingView. One wraps a bare, unlabeled _UIButtonBarButton (the system-generated back control); the other wraps a BarItemView containing the app's custom Button (chevron + "Back" text). Both are laid out as independent glass platters rather than being merged into one leading toolbar group. Minimal Reproducible Project Attached: [BackButtonDuplicationRepro.zip] — a stripped-down single-screen repro isolating just this behavior (no navigation stack customization, no third-party code). Related report This looks like the same underlying issue as thread 812048 ("Toolbar Rendering Bug — ToolbarItem Duplication when Back Button Hidden"), which an Apple DTS engineer has already responded to requesting a reproducible project — hopefully this attached project + View Debugger evidence helps move that along. Also potentially related: thread 814816 (hidesSharedBackground not working for backBarButtonItem), which points at the same general area of the new Liquid Glass toolbar/platter system.

My app is themeable, and uses window.overrideUserInterfaceStyle to set the userInterfaceStyle independently from the system setting. This works great, except this does not change the userInterfaceStyle of the menus. So I'm occasionally experiencing light menus with a dark themed app, and vice versa. Question: how to override the userInterfaceStyle of the menus managed by UIMainMenuSystem?

I add a series of buttons in the UIToolbar of accessoryView. Before liquidGlass (Xcode 26.6, iOS 26), I get this: Buttons are properly stacked, allowing up to 8 buttons, which is what I need. But with liquidGlass, buttons are now enclosed in a useless bubble, and thus take much more space. No way to accommodate 8 buttons anymore, they are displayed in the "…" followup section, which is very inconvenient. In iOS 26, I can still set UIDesignRequiresCompatibility to true and get the expected presentation. But that does not work in Xcode 27 / iOS 27. Code is essentially the following: let bar = UIToolbar(frame:CGRect(x: 0, y: 0, width: 200, height: 44)) let letterBack = UIImage(named: "letterBackground")! let targetSize = CGSize(width: 36, height: 36) let scaledImage = letterBack.scalePreservingAspectRatio( targetSize: targetSize ) let letterI = UIBarButtonItem(title: "I", style: .plain, target: self, action: #selector(letterTapped(_:))) letterI.setBackgroundImage(scaledImage, for: .normal, barMetrics: .default) // Same for other letters bar.items = [letterI, letterV, letterX, letterL, letterC, flexibleSpace, peseudoReturn] bar.sizeToFit() aTextField.inputAccessoryView = bar I have tried to use barMetrics: .compact to no avail So, a few questions: Is it possible, with liquidGlass, to have the buttons displayed without their ellipse bubble, so that they stack against each other ? Is there other appearence setting to set ? Or should I give up toolbar and create a collectionView that I will place atop keyboard ? In anycase, liquidGlass is really problematic in term of screen estate use.

Using Xcode 27.0ß4. I set a textField text with an emoji: statusReponseLabel.text = "👍" In iOS 27, I get the expected result (on the left). In iOS 26.3 (simulator), I just get a question mark. I have tested with a print, the text is properly set. I replaced with: statusReponseLabel.text = "A👍B" In iOS 26.3, I get A followed by the question mark, B is skipped as well. Is it an iOS issue or just a simulator issue in beta version ?