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
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!
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?
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?
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!
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?
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’m seeing a crash when running my app on iOS 18 simulators or devices using Xcode 26 beta 3.
My app’s minimum deployment target is iOS 17, and the crash does not happen when running from Xcode 16.4.
The crash occurs specifically at this line:
return UIStoryboard(name: storyboard.rawValue, bundle: nil)
.instantiateViewController(withIdentifier: view.rawValue)
Crash Details:
** 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)'
*** First throw call stack:
(0x191c3321c 0x18f0cdabc 0x191c91ea0 0x19d740774 0x19d740a18 0x19d740cac 0x194626680 0x194dbc784 0x19d740890 0x19d740cac 0x1949aadd8 0x19d740890 0x19d740a18 0x19d740cac 0x194802e24 0x1945f008c 0x194ed1808 0x107a8bfa0 0x107a8c05c 0x1945ec128 0x19d740890 0x19d740cac 0x1945eba60 0x19d740890 0x19d740a18 0x19d740cac 0x1945f07dc 0x1945eaea4 0x19492ee80 0x10763de00 0x1076e56fc 0x1076e5674 0x1076e5e04 0x19496108c 0x194f9b9a0 0x1949072c4 0x194f998cc 0x194f9af04 0x19445139c 0x19445ac28 0x194467508 0x1079afaec 0x1079aff5c 0x1944189a0 0x194417be4 0x1944114e4 0x194411404 0x194410ab4 0x19440c1e4 0x191b28a8c 0x191b288a4 0x191b28700 0x191b29080 0x191b2ac3c 0x1ded09454 0x19453d274 0x194508a28 0x1073564f4 0x1b89fff08)
terminating due to uncaught exception of type NSException
The crash occurs immediately at app launch, when attempting to load a storyboard-based UITabBarController.
Works as expected on:
Xcode 16.4 + iOS 18 (simulator/device)
Xcode 26 beta 3 + iOS 26 (simulator/device)
Running from Xcode 26 beta 3 onto iOS 18 simulators or devices and it immediate crash from the particular storyboard
Setup:
Xcode: 26 beta 3
macOS: 15.5
iOS Simulators: iOS 18.5
Minimum deployment target: iOS 17
UIKit-based app (not using SwiftUI)
No custom toolbars or host views in use explicitly
Is this a known compatibility issue when building with the iOS 26 SDK and running on iOS 18?
Are there any workarounds or recommendations for running apps targeting iOS 17+ on iOS 18 simulators when using Xcode 26?
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…")
}
}
}
}
}
}
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?
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?
[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'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.
|&#9;&#9;&#9;&#9;|
|&#9;&#9;&#9;&#9;|
|&#9;&#9;&#9;&#9;|
|&#9;&#9;&#9;&#9;|
|&#9; 1&#9;&#9;|
|&#9;&#9;&#9; 2|
|&#9;&#9;&#9;&#9;|
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
|&#9;&#9;&#9;&#9;|
|&#9;&#9;&#9;&#9;|
|&#9;&#9;&#9;&#9;|
|&#9;&#9;&#9; 2|
|&#9; 1&#9;&#9;|
|&#9;&#9;&#9;&#9;|
|&#9;&#9;&#9;&#9;|
Position b: both touches usually register
|&#9;&#9;&#9;&#9;|
|&#9;&#9;&#9;&#9;|
|&#9;&#9;&#9;&#9;|
|&#9;&#9;&#9;&#9;|
|&#9; 1&#9; 2|
|&#9;&#9;&#9;&#9;|
|&#9;&#9;&#9;&#9;|
Position c: only touch 1 registers
|&#9;&#9;&#9;&#9;|
|&#9;&#9;&#9;&#9;|
|&#9;&#9;&#9;&#9;|
|&#9;&#9;&#9;&#9;|
|&#9; 1&#9;&#9;|
|&#9;&#9;&#9; 2|
|&#9;&#9;&#9;&#9;|
Position d: both touches register
|&#9;&#9;&#9;&#9;|
|&#9;&#9;&#9;&#9;|
|&#9;&#9;&#9;&#9;|
|&#9;&#9;&#9;&#9;|
|&#9; 1&#9;&#9;|
|&#9;&#9;&#9;&#9;|
|&#9;&#9;&#9; 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.
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 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
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 have a custom document-based iOS app that also runs on macOS. After implementing -activityItemsConfiguration to enable sharing from the context menu, I found that the app crashes on macOS when selecting Share… from the context menu and then selecting Save (i.e. Save to Files under iOS). This problem does not occur on iOS, which behaves correctly.
- (id<UIActivityItemsConfigurationReading>)activityItemsConfiguration {
NSItemProvider * provider = [[NSItemProvider alloc] initWithContentsOfURL:self.document.presentedItemURL];
UIActivityItemsConfiguration * configuration = [UIActivityItemsConfiguration activityItemsConfigurationWithItemProviders:@[ provider ]];
// XXX crashes with com.apple.share.System.SaveToFiles
return configuration;
}
Additionally, I found that to even reach this crash, the workaround implemented in the NSItemProvider (FBxxx) category of the sample project is needed. Without this, the app will crash much earlier, due to SHKItemIsPDF() erroneously invoking -pathExtension on an NSItemProvider. This appears to be a second bug in Apple’s private ShareKit framework.
#import <UniformTypeIdentifiers/UniformTypeIdentifiers.h>
@implementation NSItemProvider (FBxxx)
// XXX SHKItemIsPDF() invokes -pathExtension on an NSItemProvider (when running under macOS, anyway) -> crash
- (NSString *)pathExtension {
return self.registeredContentTypes.firstObject.preferredFilenameExtension;
}
@end
Again, this all works fine on iOS (17.5) but crashes when the exact same app build is running on macOS (14.5).
I believe these bugs are Apple's. Any idea how to avoid the crash? Is there a way to disable the "Save to Files" option in the sharing popup?
I filed FB13819800 with a sample project that demonstrates the crash on macOS. I was going to file a TSI to get this resolved, but I see that DTS is not responding to tech support incidents until after WWDC.
Topic:
UI Frameworks
SubTopic:
UIKit
We are using a TabView as the TabBarController in our app for main navigation. On one of the tabs we have a view that consists of a TabView with .tabViewStyle(.page) in order to scroll horizontally between pages inside of that specific tab.
The .tabBarMinimizeBehavior(.onScrollDown) works on all the other TabItem views, but for this one it does not recognise any vertical scrolling in any of the pages, in order to minimize the TabBar.
I believe this is a bug? If we don't wrap the views inside the TabView with .page style, we are able to get the expected behaviour using the tabBarMinimizeBehavior.
Please let us know if this is going to be fixed in a future iOS 26 beta release.
after i updated to iOS 26.0 Beta3, UIScrollEdgeElementContainerInteraction crashed:
let scrollInteraction = UIScrollEdgeElementContainerInteraction()
scrollInteraction.edge = .bottom
scrollInteraction.scrollView = webView?.scrollView
bottomBar.addInteraction(scrollInteraction)
i got this crash info:unrecognized selector sent to instance: UIScrollEdgeElementContainerInteraction setEdge: and UIScrollEdgeElementContainerInteraction setScrollView