This issue was in the first iOS 26 beta and it still there with Xcode 26 beta 6 (17A5305f). Feedback is FB18581605 and contains sample project to reproduce the issue.
I assign a target and action to a UISlider for the UIControl.Event.valueChanged value:
addTarget(self, action: #selector(sliderValueDidChange), for: .valueChanged)
Here’s the function.
@objc
func sliderValueDidChange(_ sender: UISlider, event: UIEvent) {
print(event)
}
When printing the event value, there is a crash. When checking the event value with lldb, it appears uninitialized.
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
Applying glass effect, providing a shape isn't resulting in the provided shape rendering the interaction correctly.
.glassEffect(.regular.tint(Color(event.calendar.cgColor)).interactive(), in: .rect(cornerRadius: 20))
results in properly drawn view but interactive part of it is off. light and shimmer appear as a capsule within the rect.
On iOS17, UIDevice.current.batteryLevel is returning values rounded to 0.05, such as 1, 0.95, 0.9. Which used to be a 1% granularity in iOS16. Is this a bug or a new feature?
Using desaturated mode on an image in a widget will break any links or buttons that use the image as their 'label'.
Using the following will just open the app as if there was no link at all - therefore just using the fallback userActivity handler, or any .widgetURL() urls provided.
Link(destination: URL(string: "bug://never-works")!) {
Image("puppy")
.widgetAccentedRenderingMode(.desaturated)
}
The same goes for buttons:
Button(intent: MyDemoIntent()) {
Image("puppy")
.widgetAccentedRenderingMode(.desaturated)
}
I've tried hacky solutions like putting the link behind the image using a ZStack, and disabling hit testing on the image, but they don't work. Anything else to try?
Logged as Feedback #15152620.
When I build my app for iPad OS, either 26, or 18.5, as well as iOS on 16.5 from Xcode 26 with UIDesignRequiresCompatibility enabled my app is crashing as it loads the main UIViewController, a subclassed UITabBarController which is being loaded programatically from a Storyboard from another SplashScreen ViewController.
On i(Pad)OS 18.5 I get this error:
Thread 1: "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)"
On iPadOS 26 I get this error:
UIKitCore/UICoreHostingView.swift:54: Fatal error: init(coder:) has not been implemented
There is no issue building from Xcode 16.4, regardless of targeted i(Pad)OS.
Hello!
I have experienced a weird bug in iOS 26 Beta (8) and previous beta versions. The safe area inset is not correctly aligned with the keyboard toolbar on real devices and simulators.
When you focus a new textfield the bottom safe area is correctly placed aligned the keyboard toolbar.
On real devices the safe area inset view is covered slightly by the keyboard toolbar, which is even worse than on the simulator.
Here's a clip from a simulator:
Here's the code that reproduced the bug I experienced in our app.
#Preview {
NavigationStack {
ScrollView {
TextField("", text: .constant(""))
.padding()
.background(Color.secondary)
TextField("", text: .constant(""))
.padding()
.background(Color.green)
}
.padding()
.safeAreaInset(edge: .bottom, content: {
Color.red
.frame(maxWidth: .infinity)
.frame(height: 40)
})
.toolbar {
ToolbarItem(placement: .keyboard) {
Button {} label: {
Text("test")
}
}
}
}
}
There seems to be a performance issue when scrolling using the track pad with SwiftUI scroll views in macOS 15. This issue is NOT present in macOS 14.
When using the track pad the scrolling is not smooth, but "stutters". However scrolling using the scroll bars is very smooth. The "stuttering" is worse if the SwiftUI ScrollView is in the detail view of a NavigationSplitView.
The problem is not noticeable in scroll views with a small number views, but when the more views inside the scroll view, the more prominent the problem becomes.
I have a simple example app that illustrates the problem here (the example app is a simplification of my app Yammixer): https://github.com/danwaltin/SwiftUIScrollViewPerformance
When running this example app on macOS 14 (Sonoma) on an Intel i7 Mac book pro from 2019 the scrolling is "buttery smooth".
But on macOS 15 (Sequoia) on my Apple Silicon M1 Mac book pro the issue is very obvious.
When using Instruments I see that on macOS 15 "flame graph" shows that 85% of the execution time is in a "_hitTestForEvent" method. If the test app does not use NavigationSplitView about 70% of execution time is in the _hitTestForEvent method.
Topic:
UI Frameworks
SubTopic:
SwiftUI
My usage of TextField.focused() works fine in Xcode 14.3.1 but is broken as of Xcode 15. I first noticed it in the second beta and it's still broken as of the 4th beta.
Feedback / OpenRadar # FB12432084
import SwiftUI
struct ContentView: View {
@State private var text = ""
@FocusState var isFocused: Bool
var body: some View {
ScrollView {
TextField("Test", text: $text)
.textFieldStyle(.roundedBorder)
.focused($isFocused)
Text("Text Field Is Focused: \(isFocused.description)")
}
}
}
I am using a LayzVStack embedded into a ScrollView. The list items are fetched from a core data store by using a @FetchResult or I tested it also with the new @Query command coming with SwiftData.
The list has one hundred items 1, 2, 3, ..., 100.
The user scrolled the ScrollView so that items 50, 51, ... 60 are visible on screen.
Now new data will be fetched from the server and updates the CoreData or SwiftData model. When I add new items to the end of the list (e.g 101, 102, 103, ...) then the ScrollView is keeping its position.
Opposite to this when I add new items to the top (0, -1, -2, -3, ...) then the ScrollView scrolls down.
Is there a way with the new SwiftData and SwiftUI ScrollView modifiers to update my list model without scrolling like with UIKit where you can query and set the scroll offset pixel wise?
Hi folks,
there's currently a known issue in TipKit due to which it won't show popover tips on buttons that are inside a SwiftUI ToolbarItem. For example, if you try this code, the popover tip will not appear:
ToolbarItem {
Button(action: {...}) {
Label("Tap here", systemImage: "gear")
}
.popoverTip(sampleTip)
}
There's an easy workaround for this issue. Just apply a style to the button. It can be any style. Some examples are bordered, borderless, plain and borderedProminent. Here's a fixed version of the above code:
ToolbarItem {
Button(action: {...}) {
Label("Tap here", systemImage: "gear")
}
.buttonStyle(.plain) // Adding this line fixes the issue.
.popoverTip(sampleTip)
}
Hope this helps anyone running into this issue.
unifieldFlexKeyboard[53102:24145174] [External] -[UIInputViewController needsInputModeSwitchKey] was called before a connection was established to the host application. This will produce an inaccurate result. Please make sure to call this after your primary view controller has been initialized.
hey
All of a sudden, after iOS 18.4 was released, I am having tons of navigation problems in my app in production. Buttons navigating to empty pages, views seeming to 'freeze', top navigation bar mismatched with the content of the page. It seems that iOS 18.4 broke a critical piece of UIKit + SwiftUI bridging functionality that my project relies on.
My application is written with both UIKit and SwiftUI components. Here is a breakdown of my setup:
UIApplicationDelegate >
UIWindow >
rootViewController of window is a UITabBarController >
each tab is a UINavigationController
rootViewController of nav controller is a UIHostingController >
rootView of the hosting controller is a SwiftUI View
In my SwiftUI views, I have been using NavigationLink for horizontal 'push' style navigation in my SwiftUI views. I do not use NavigationView, I only rely on the bridging capabilities of UINavigationController to action on my NavigationLinks. This has never been an issue, until iOS 18.4 was released. Now, when running iOS 18.4, I am having all sorts of unexpected behavior in the UI. I will break down 2 of these use cases here:
Use case A:
In one of my SwiftUI views, I have a ForEach for which each element's view is a NavigationLink. This is using the NavigationLink(_ destination:,label:) initializer. Navigating forward from here works/looks normal.
However, once I try to navigate backward from that destination (tap the 'Back' button in top left), the view goes blank and the navigation bar at the top of the page (which is maintained by the UINavigationController instance) does not change. If I call popToRootViewController on that nav controller, the navigation bar at the top of the page returns to its normal state, but the view is still blank.
It is not until after I have called popToRootViewController, and then navigate to a different tab of the UITabBarController and return to the initial tab, does the SwiftuI content view (the one with the ForEach) finally redraw and the view hierarchy is restored.
Here is a warning that is logged in the console when I tap the 'Back ' button:
Top view controller's view unexpectedly not in window for navigation transition. Skipping layout. nav = <UINavigationController: 0x1110bbe00>, topVC = <TtGC7SwiftUI19UIHostingControllerV5MyApp10MyPage: 0x106814e00>
EDIT: If I replace the NavigationLink with a call to UINavigationController.pushViewController, I am still seeing the exact same behavior. Pressing back button makes the view empty > need to pop to root view controller and switch tabs in order to restore the view.
Use case B
Another instance of this issue happens whenever I try to use a NavigationLink inside of a view that itself was the destination of a NavigationLink in its parent view (i.e.: Root view > detail view > sub-detail view). For example, take the detail view destination in use case A. I have tapped a NavigationLink from the ForEach and landed on the detail view. Again, so far things work/look normal. Now, if I tap on another NavigationLink from that detail view, the view does not transition to the new page. The top navigation bar does transition, and shows the title and actions associated with this second destination. However, the view of this second destination is not displayed.
It is worth noting that the same warning I mentioned above is also logged when I tap the NavigationLink to navigate to this second destination.
Top view controller's view unexpectedly not in window for navigation transition. Skipping layout. nav = <UINavigationController: 0x109859400>, topVC = <TtGC7SwiftUI19UIHostingControllerVVS_19BridgedPresentation8RootView: 0x300ab8000>
Strangely, if I switch to a different tab of the UITabBarController and back to the initial tab, this second destination's view is successfully rendered. It seems that switching tabs in this UITabBarController is calling something in either SwiftUI or UIKit that is redrawing my views.
Conclusion
This is a serious issue with UIKit + SwiftUI bridging support. I have never had problems like this until devices started running iOS 18.4, and there is nothing in the iOS 18.4 changelog that suggests this was an intentional change. All of a sudden, after updating to the latest iOS version, my app is totally broken.
I want to be clear that I'm not using deprecated NavigationLink methods in these instances. My app's minimum deployment target is iOS 16.
I know that there are more modern navigation APIs like navigation stack, etc. I am looking for answers about my use case: whether it is officially unsupported as of iOS 18.4, whether this setup should be supported and this is indeed some sort of bug in iOS, or anything in-between. I'm happy to provide formatted code if needed for discussion purposes. This is about my entire app's view hierarchy so there are a lot of disparate lines of code that make up this problem.
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)
}
}
}
Dear All,
Recent updates in SwiftUI allow to add scope bars just beneath the search bar. Those are limited in space, though.
How does one implement a scrollable filter as is seen in the Apple’s own Developer app?
Hello.
In my app, I use RegisterEventHotkey to implement global keyboard shortcuts to trigger actions.
Up until macOS Sequoia, I was able to use a keyboard shortcut with option and shift as the modifiers, like option shift 2 (⌥ ⇧ 2).
Now, on macOS Sequoia, using RegisterEventHotkey to register a hotkey with those exact modifiers (option and shift), regardless of the key, fails with the error -9868 (eventInternalErr).
Is this a documented and wanted change, or is this a bug? Other modifier keys (just command, command option, command shift, command control, control shift, etc), all work.
Any insight into this would be appreciated. (Feedback filed: FB15163561)
Thank you,
Matthias
Hi folks,
I've used a NavigationSplitView within one of the tabs of my app since iOS 16, but with the new styling in iOS 18 the toolbar region looks odd. In other tabs using e.g. simple stacks, the toolbar buttons are horizontally in line with the new tab picker, but with NavigationSplitView, the toolbar leaves a lot of empty space at the top (see below). Is there anything I can do to adjust this, or alternatively, continue to use the old style?
Thanks!
I have a List in a sidebar style which contains a LazyVGrid and a Section with a simple list contents. Every thing works well except when content increases and layout changes (from two columns to one column) for the LazyVGrid with editMode changing to .active ... LazyVGrid does not expand/resize when the content increases (the increased content gets clipped)...but does when user expands/folds on the section below :(. However LazyVGrid resizes to show the entire content when the content shrinks with editMode reverting to .inactive
Note: If I replace the List with a ScrollView...lazyVGrid resizes perfectly when content increases in editMode = .active....but then I would lose all the Sidebar and List characteristics for the Section below :(
Also, looks like .onMove is not supported in LazyVGrids
Any pointers to solve the LazyVGrid (embedded in a List) not resizing or expanding when content increases ... will be deeply appreciated.
var body: some View {
List {
LazyVGrid(columns: editMode?.wrappedValue == .active ? singleColumn : twoColumns, alignment: .leading, spacing: 10) {
ForEach(editMode?.wrappedValue == .active ? allDashItems : selectedDashItems) { dashitem in
DashItemCell(dashitem)
}
.onMove(perform: moveDashItem)
.environment(\.editMode, editMode)
}
Section(header: Text("Bottom Section")) {
ForEach (sectionList)	{ item in
ListItemCell(item)
}
.onDelete(perform: deleteFolder)
.onMove(perform: moveFolder)
}
}
.listStyle(SidebarListStyle())
}
For information I stumbled upon a regression with SwiftUI Slider on iOS 26. Its onEditingChanged closure might be called twice when interaction ends, with a final Boolean incorrect value of true provided to the closure.
As a result apps cannot reliably rely on this closure to detect when an interaction with the slider starts or ends.
I filed a feedback under FB20283439 (iOS 26.0 regression: Slider onEditingChanged closure is unreliable).
SwiftUI Popover Crash on iPad During Resizing in Stage Manager with Exception.
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Trying to layout popover in the delegate callback popoverPresentationController:willRepositionPopoverToRect:inView: will lead to recursion. Do not force the popover's container view or an ancestor to layout in this callback.'
(Occurred from iPadOS 18.1)
struct ContentView: View {
@State var showPopover: Bool = false
var body: some View {
VStack {
Text("Hello, world!")
Button(action: {
showPopover = true
}, label: {
Text("Open Popover")
})
}
.padding()
.popover(isPresented: $showPopover, attachmentAnchor: .point(.trailing), content: {
VStack {
Text("Popover Content")
}
})
}
}
After updating to Sonoma, the following is logged in the Xcode console when an editable text field becomes key. This doesn't occur on any text field, but it seems to happen when the text field is within an NSPopover or an NSSavePanel.
ViewBridge to RemoteViewService Terminated: Error Domain=com.apple.ViewBridge Code=18 "(null)" UserInfo={com.apple.ViewBridge.error.hint=this process disconnected remote view controller -- benign unless unexpected, com.apple.ViewBridge.error.description=NSViewBridgeErrorCanceled}
What does this mean?
Topic:
UI Frameworks
SubTopic:
AppKit