I’m encountering an accessibility issue in SwiftUI related to keyboard navigation.
🐞 Problem
When using an AttributedString to display Markdown content in a SwiftUI view (such as a Text view), any links included in the Markdown are not keyboard focusable when Full Keyboard Access is enabled. This means users can’t navigate to or activate the links using the Tab key or other keyboard-only methods.
💻 Platform
iOS version: 16+
Framework: SwiftUI
Device: All tested iPhones and iPads
🧪 Steps to Reproduce
Enable Full Keyboard Access in iOS settings.
Run the included SwiftUI Playground or equivalent app using the code below.
Try to navigate to the link using Tab or keyboard arrow keys.
Observe that the Markdown link is not reachable via keyboard focus.
🧩 Expected Behavior
The Markdown link should be reachable via keyboard focus.
It should be possible to activate the link using Space or Return.
📚 Example code
struct ContentView: View {
let attributedString: AttributedString
init() {
self.attributedString = try! AttributedString(
markdown: "This is a [test link](https://apple.com) inside an attributed string."
)
}
var body: some View {
VStack {
Text("Issue: Attributed Markdown Link Is Not Focusable with full keyboard access")
.font(.headline)
.padding()
Text(attributedString) // The link is not focusable with
.padding()
.border(Color.gray, width: 1)
Text("Expected: The link should be focusable with Full Keyboard Access.")
.foregroundColor(.red)
.padding()
}
}
}
Explore the various UI frameworks available for building app interfaces. Discuss the use cases for different frameworks, share best practices, and get help with specific framework-related questions.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Any view that is content for the tabViewBottomAccessory API fails to retain its state as of the last couple of 26.1 betas (and RC). The loss of state happens (at least) when the currently selected tab is switched (filed as FB20901325).
Here's code to reproduce the issue:
struct ContentView: View {
@State private var selectedTab = TabSelection.one
enum TabSelection: Hashable {
case one, two
}
var body: some View {
TabView(selection: $selectedTab) {
Tab("One", systemImage: "1.circle", value: .one) {
BugExplanationView()
}
Tab("Two", systemImage: "2.circle", value: .two) {
BugExplanationView()
}
}
.tabViewBottomAccessory {
AccessoryView()
}
}
}
struct AccessoryView: View {
@State private var counter = 0 // This guy's state gets lost (as of iOS 26.1)
var body: some View {
Stepper("Counter: \(counter)", value: $counter)
.padding(.horizontal)
}
}
struct BugExplanationView: View {
var body: some View {
ScrollView {
VStack(alignment: .leading, spacing: 16) {
Text("(1) Manipulate the counter state")
Text("(2) Then switch tabs")
Text("BUG: The counter state gets unexpectedly reset!")
}
.multilineTextAlignment(.leading)
}
}
}
I have a macOS app made with SwiftUI where I want to show a list of data in a tabular fashion. SwiftUI Table seems to be the only built-in component that can do this.
I would like to let the user size the columns and have their widths restored when the app is relaunched. I can find no documentation on how to do this and it does not seem to be saved and restored automatically.
I can find no way to listen for changes in the column widths when the user resizes and no way to set the size from code.
For a macOS app it seems that the only way to set the width of a column is to use e.g. .width(min: 200, max: 200). This in effect disables resizing of the column. It seems that idealSize is totally ignored on macOS.
Any suggestions?
My app doesn't respond on iPhone Air iOS 26.1.
After startup, my app shows the main view with a tab bar controller containing 4 navigation controllers. However, when a second-level view controller is pushed onto any navigation controller, the UI freezes and becomes unresponsive. The iPhone simulator running iOS 26.1 exhibits the same problem.
The debug profile shows CPU usage at 100%.
However, other devices and simulators do not have this problem.
I'm developing a rhythm game for iOS which has four buttons spanning the width of the screen in portrait. I noticed that my testers were having some missed inputs on the buttons on the left and right due to the fact that iOS, by default, tries to ignore accidental touches on the edges of the screen. So I enabled "Defer System Gestures" on the left and right edges, but then quickly started to notice a new, very specific, issue.
Description of the issue
If you have finger #1 touching and holding anywhere in the middle of the screen, and finger #2 touches on the far right or left edge of the screen just below the horizontal position of finger #1, those touches are inconsistently not recognized. If finger #1 is not present, this issue does not occur. If finger #2 is above or well below finger #1, this issue also does not occur. A dead zone is created on the right and left edges of the screen just below the horizontal position of the first touch.
Here is a rough representative example of where touches #1 and #2 need to be for this issue to manifest, in case the text above is not clear.
|				|
|				|
|				|
|				|
|	 1		|
|			 2|
|				|
It just so happens that this issue is causing major usability problems with my game, as it results in what the user sees as sporadic and inconsistent response when the game calls for two notes to be played at the same time.
Steps to recreate the issue
Here are the steps if you want to recreate the problem yourself using the "Create New Gesture" pane in "Assistive Touch" (Note that this problem is not specific to the Settings app, but rather is an issue across the system—however this panel defers system gestures and shows where touches are being read, so it is a great place to demonstrate):
(1) Go to Settings > Accessibility > Touch > Assistive Touch > Create New Gesture...;
(2) With one finger, touch the middle of the screen and hold it through step 3;
(3) With a second finger, tap 4 times along the right (or left) edge of the screen in the following places:
(a) well above the vertical position of the first touch,
(b) just above the vertical position of the first touch,
(c) just below the vertical position of the first touch, and
(d) well below the vertical position of the first touch;
(4) Notice how, more than half the time, touch (c) does not register. I have found that this problem is more replicatable when the first touch is on the lower half of the screen, but I have been able to replicate it when the finger is higher as well, just not as consistently.
Here are the four positions described in the steps above:
Position a: both touches register
|				|
|				|
|				|
|			 2|
|	 1		|
|				|
|				|
Position b: both touches usually register
|				|
|				|
|				|
|				|
|	 1	 2|
|				|
|				|
Position c: only touch 1 registers
|				|
|				|
|				|
|				|
|	 1		|
|			 2|
|				|
Position d: both touches register
|				|
|				|
|				|
|				|
|	 1		|
|				|
|			 2|
Is there anything I can do to resolve this behavior? My app requires gesture deferment to be on for the expected experience by the user, and this bug is causing other issues for my testers that kind of need to be resolved before I can confidently release the game.
Try this simple code:
import SwiftUI
import StoreKit
struct ReviewView: View {
@Environment(\.requestReview) var requestReview
var body: some View {
Button("Leave a review") {
requestReview()
}
}
}
When the Review Alert shows, the "Not Now" button is disabled for some reason!? It was always tappable in all iOS versions that I remember. And there is no way to opt out, unless the user taps on the stars first. Is it a bug or a feature?
Thanks for looking into it!
Hello,
While integrating the Liquid Glass UI introduced in iOS 26 into my existing app, I encountered an unexpected issue.
My app uses a UITabBarController, where each tab contains a UINavigationController,
and the actual content resides in each UIViewController.
Typically, I perform navigation using navigationController?.pushViewController(...) and hide the TabBar by setting vc.hidesBottomBarWhenPushed = true when needed.
This structure worked perfectly fine prior to iOS 26, and I believe many apps use a similar approach.
However, after enabling Liquid Glass UI, a problem occurs.
Problem Description
From AViewController, I push BViewController with hidesBottomBarWhenPushed = true.
BViewController appears, and the TabBar is hidden as expected.
When performing a swipe-back gesture, as soon as AViewController becomes visible, the TabBar immediately reappears (likely due to A’s viewWillAppear).
The TabBar remains visible for a short moment even if the gesture is canceled — during that time, it is also interactable.
Before iOS 26, the TabBar appeared synchronized with AViewController and did not prematurely show during the swipe transition.
Tried using the new iOS 18 API:
tabBarController?.setTabBarHidden(false, animated: true)
It slightly improves the animation behavior, but the issue persists.
If hidesBottomBarWhenPushed is now deprecated or discouraged,
migrating entirely to setTabBarHidden would require significant refactoring, which is not practical for many existing apps.
Is this caused by a misuse of hidesBottomBarWhenPushed,
or could this be a regression or design change in iOS 26’s Liquid Glass UI?
When you use .navigationTransition(.zoom(sourceID: "placeholder", in: placehoder)) for navigation animation, going back using the swipe gesture is still very buggy on IOS26. I know it has been mentioned in other places like here: https://developer.apple.com/forums/thread/796805?answerId=856846022#856846022 but nothing seems to have been done to fix this issue.
Here is a video showing the bug comparing when the back button is used vs swipe to go back: https://imgur.com/a/JgEusRH
I wish there was a way to at least disable the swipe back gesture until this bug is fixed.
I've been experimenting with Liquid Glass quite a bit and watched all the WWDC videos. I'm trying to create a glassy segmented picker, like the one used in Camera:
however, it seems that no matter what I do there's no way to recreate a truly clear (passthrough) bubble that just warps the light underneath around the edges. Both Glass.regular and Glass.clear seem to add a blur that can not be evaded, which is counter to what clear ought to mean.
Here are my results:
I've used SwiftUI for my experiment but I went through the UIKit APIs and there doesn't seem to be anything that suggests full transparency.
Here is my test SwiftUI code:
struct GlassPicker: View {
@State private var selected: Int?
var body: some View {
ScrollView([.horizontal], showsIndicators: false) {
HStack(spacing: 0) {
ForEach(0..<20) { i in
Text("Row \(i)")
.id(i)
.padding()
}
}
.scrollTargetLayout()
}
.contentMargins(.horizontal, 161)
.scrollTargetBehavior(.viewAligned)
.scrollPosition(id: $selected, anchor: .center)
.background(.foreground.opacity(0.2))
.clipShape(.capsule)
.overlay {
DefaultGlassEffectShape()
.fill(.clear) // Removes a semi-transparent foreground fill
.frame(width: 110, height: 50)
.glassEffect(.clear)
}
}
}
Is there any way to achieve the above result or does Apple not trust us devs with more granular control over these liquid glass elements?
Looking to see if anyone has experienced this issue, and is aware of any workarounds.
With an app migrating towards SwiftUI Views but still using UIKit for primary navigation, my app makes use of UIHostingController to push SwiftUI Views onto a UINavigationController stack in a lot of areas. With iOS 26, I notice that SwiftUI's Menu view really struggles to present when contained in a UIHostingController. An error is logged to the console on presentation, and depending on the UI, the Menu won't present inside of it's container, or will jump around the screen.
The bug, it seems is based in a private class UIReparentingView and I am curious if anyone has found a work around for this issue. The error reported is:
Adding '_UIReparentingView' as a subview of UIHostingController.view is not supported and may result in a broken view hierarchy. Add your view above UIHostingController.view in a common superview or insert it into your SwiftUI content in a UIViewRepresentable instead.
The simplest way to see this issue is to create a new storyboard based project. From the ViewController present a UIHostingController with a SwiftUI view that has a Menu and then simply tap to open the Menu. Thanks for any input!
When navigationTransition returns through the return gesture, the original view disappears。
The same problem occurs when using the official example。
https://developer.apple.com/documentation/swiftui/enhancing-your-app-content-with-tab-navigation
xcode Version 16.4 (16F6)
macOS 15.5
I understand this is a known issue, but it’s truly unacceptable that it remains unresolved. Allowing users to customize toolbars is a fundamental macOS feature, and it has been broken since the release of macOS 15.
How is it possible that this issue persists even in macOS 15.3 beta (24D5040f)?
FB15513599
import SwiftUI
struct ContentView: View {
@State private var showEditItem = false
var body: some View {
VStack {
VStack {
Text("Instructions to reproduce the crash")
.font(.title)
.padding()
Text("""
1. Click on "Toggle Item"
2. In the menu go to File > New Window
3. In new window, click on "Toggle Item"
""")
}
.padding()
Button {
showEditItem.toggle()
} label: {
Text("Toggle Item")
}
}
.padding()
.toolbar(id: "main") {
ToolbarItem(id: "new") {
Button {
} label: {
Text("New…")
}
}
if showEditItem {
ToolbarItem(id: "edit") {
Button {
} label: {
Text("Edit…")
}
}
}
}
}
}
An app built on Xcode 26 (beta4) presents various UIViewCOntrollers. Presentation of any UIViewController that contains a UIToolbar leads to a UIKit crash when run on an iOS 18.5 device, it does not crash when run on iOS 26.
The exception logged:
*** Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate class named TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView because no class named TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView was found; the class needs to be defined in source code or linked in from a library (ensure the class is part of the correct target)'
Anyone else seen this?
I've submitted a bug report via Feedback Assistant, including a minimal Xcode workspace that reproduces the crash, hoping this will get some attention.
Hi,
I am running iOS Simulator on iOS 26 and I am trying to change unselectedItemTintColor of UITabBarItem in my TabBarViewController but it did not work when I tried following ways:
Setting an iconColor through UITabBarAppearance() class
Setting unselected item tint color like tabBar.unselectedItemTintColor = .black
As an example attached file, I would like to set Settings tab's item color (icon + title) with different one when it is unselected.
[Submitted as FB18870294, but posting here for visibility.]
In iOS 26 beta 3 (23A5287g), implicit animations no longer work when conditionally showing or hiding rows in a Form.
Rows with Text or other views inside a Section appear and disappear abruptly, even when wrapped in withAnimation or using .animation() modifiers. This is a regression from iOS 18.5, where the row item animates in and out correctly with the same code.
Repro Steps
Create a new iOS App › SwiftUI project.
Replace its ContentView struct with the code below
Build and run on an iOS 18 device.
Tap the Show Middle Row toggle and note how the Middle Row animates.
Build and run on an iOS 26 beta 3 device.
Tap the Show Middle Row toggle.
Expected
Middle Row item should smoothly animate in and out as it does on iOS 18.
Actual
Middle Row item appears and disappears abruptly, without any animation.
Code
struct ContentView: View {
@State private var showingMiddleRow = false
var body: some View {
Form {
Section {
Toggle(
"Show **Middle Row**",
isOn: $showingMiddleRow.animation()
)
if showingMiddleRow {
Text("Middle Row")
}
Text("Last Row")
}
}
}
}
I am using the TabView control in SwiftUI on a tvOS 18 target with the style of sidebarAdaptable. When I have 7 or less tabs things operate correctly. When I add an 8th tab and you navigate to the contents of the tab the menu collapses as expected but you cannot navigate back to restore the menu. This code reproduces the issue:
import SwiftUI
struct ContentView: View {
var body: some View {
TabView {
Tab("Tab1", systemImage: "person.circle") {
Button("Button1") {}
}
Tab("Tab2", systemImage: "person.circle") {
Button("Button2") {}
}
Tab("Tab3", systemImage: "person.circle") {
Button("Button3") {}
}
Tab("Tab4", systemImage: "person.circle") {
Button("Button4") {}
}
Tab("Tab5", systemImage: "person.circle") {
Button("Button5") {}
}
Tab("Tab6", systemImage: "person.circle") {
Button("Button6") {}
}
Tab("Tab7", systemImage: "person.circle") {
Button("Button7") {}
}
Tab("Tab8", systemImage: "person.circle") {
Button("Button8") {}
}
}
.tabViewStyle(.sidebarAdaptable)
}
}
If you eliminate Tab 8 the problem goes away. You can navigate back to the menu by moving to the left.
Notably the Destination Video sample also reproduces this issue:
https://developer.apple.com/documentation/visionos/destination-video
To reproduce:
Load the above code or Destination Video sample.
Navigate right (click right on remote or swipe right). Menu dismisses and just shows the item you have selected in the upper left corner.
Try to navigate left by clicking left on the remote or swiping left. It looks like the collapsed menu gets focus briefly, screen elements flash but the focus remains outside the menu.
Has anyone else encountered this issue?
When using my app's complications with either Siri Intents or App Intents after syncing .watchface files, the complications appear without names in the iOS Watch app's complication picker. This leads to complications showing as blank entries without previews in the native watch app selector.
I'm using WidgetKit to create Watch complications with both approaches: AppIntents and Siri Intents.
We've tried multiple approaches with our WidgetKit watch complications:
Switching between IntentConfiguration and StaticConfiguration
Using different naming conventions for kind strings
Ensuring display names are properly set
Testing across different watchOS versions
But the result is always the same: after syncing .watchface files, our complications appear unnamed in the Watch app's complication picker.
Is this a known limitation with .watchface syncing, a bug in the current implementation, or is there a specific requirement we're missing to maintain complication names during the sync process?
struct ContentView: View {
@State var isPresented = false
var body: some View {
Button {
isPresented.toggle()
} label: {
Text("Button")
}
.sheet(isPresented: $isPresented) {
SubView()
}
}
}
struct SubView: View {
@State var text = ""
var body: some View {
NavigationStack {
TextEditor(text: $text)
.toolbar {
ToolbarItemGroup(placement: .bottomBar) {
Button("Click") {
}
}
ToolbarItemGroup(placement: .keyboard) {
Button("Click") {
}
}
}
}
}
}
I've been testing the safeAreaBar modifier to develop a custom tab bar. From my understanding, this should enable the .scrollEdgeEffectStyle to work with this bar, but I don't see any effect.
Could you please clarify the difference between safeAreaBar and safeAreaInset?
I have a UIKit app with a UIHostingController embedded as a child controller.
In this UIHostingController there's a SwiftUI view which expands and collapses with an animation to show/hide content within it.
The hosting controller uses .intrinsicContentSize sizing option.
This all works fine, and the animation of the expand/collapse looks good so far as the SwiftUI view, in a preview for example.
But running the app the hosting controller doesn't animate its view's size alongside the SwiftUI view animating its size.
Instead the hosting controller jumps from the correct start/end sizes without any animation.
So technically although it has the right size when the SwiftUI view is expanded/collapsed, this not a nice UX as the hosting controller jumps immediately from its small size to its larger one on expanding and vice versa for collapsing while the SwiftUI contents animates nicely.
I'm assuming there's somewhere I should be calling (in some form or another) a:
UIView.animate(withDuration: 0.4) {
hostingController.view.layoutIfNeeded()
}
alongside the SwiftUI animations - but I can't see any hook between my SwiftUI view .animation(value:) function and somewhere that hosting controller could jump in alongside this animation and animate its view's frame.
Topic:
UI Frameworks
SubTopic:
SwiftUI