Simplely, when we set UITextView.inputView and then call becomeFirstResponder, but the custom inputView could not show expectedly just like before. We test this code in iOS17 and below, while only iOS17 does not work. And xcode console print these logs: Failed to retrieve snapshot. -[RTIInputSystemClient remoteTextInputSessionWithID:performInputOperation:] perform input operation requires a valid sessionID -[RTIInputSystemClient remoteTextInputSessionWithID:performInputOperation:] perform input operation requires a valid sessionID -[RTIInputSystemClient remoteTextInputSessionWithID:performInputOperation:] perform input operation requires a valid sessionID -[RTIInputSystemClient remoteTextInputSessionWithID:performInputOperation:] perform input operation requires a valid sessionID Unsupported action selector setShiftStatesNeededInDestination:autoShifted:shiftLocked: Unsupported action selector setShiftStatesNeededInDestination:autoShifted:shiftLocked: Unsupported action selector setShiftStatesNeededInDestination:autoShifted:shiftLocked: Unsupported action selector setShiftStatesNeededInDestination:autoShifted:shiftLocked:

Dear Apple Developer Support, We found that on devices running iOS 26.1 Beta, if we set the separator style of a UITableView to None via xib, the setting will have no effect and the table view cells will show separators. To reproduce this issue, I created a simple project. Please refer to the following screenshots. On iOS 26.0, no separator is showing. However on iOS 26.1, separators are showing. We have already filed a bug report FB20365301. We'd like to know if this is a bug and if it will be fixed before iOS 26.1 is officially released. Thank you.

Hi all, After upgrading to the iOS 26 beta, the scrolling in my SwiftUI chat view is completely broken. The exact same code works perfectly on iOS 18. Context: I have a chat view using ScrollViewReader and a vertically-reversed ScrollView (with .rotationEffect(.degrees(180))). Each message row (MessageBubble) uses multiple simultaneousGesture handlers: Horizontal drag for swipe-to-reply (and other actions: pin, delete) Long press for showing popover/actions Vertical scroll for normal chat scrolling This was working great on iOS 18. In iOS 26 beta, the vertical scroll is either completely disabled, jittery, or hijacked by the message row’s drag gestures, even though .simultaneousGesture is used (see code below). Minimal Repro Sample MessageListView.swift swift Copy Edit ScrollViewReader { proxy in ScrollView(.vertical, showsIndicators: false) { LazyVStack(spacing: 0) { // ... grouped messages ForEach(...) { ... MessageBubble(...) // see below } Color.clear.frame(height: 8).id("BOTTOM_ANCHOR") } .padding(.horizontal, 4) .rotationEffect(.degrees(180)) } .rotationEffect(.degrees(180)) } MessageBubble.swift struct MessageBubble: View { // ... var body: some View { // horizontal swipe-to-reply gesture let dragGesture = DragGesture(minimumDistance: 10) // ... ZStack { // ... HStack { ... } // ... .simultaneousGesture( DragGesture(minimumDistance: 0) // for long press // ... ) .simultaneousGesture(dragGesture) // for horizontal swipe } // ... } }

In the WWDC 2025 session "Build a UIKit app with the with the new design", at the 23:22 mark, the presenter says: And finally, when you no longer need the glass on screen animate it out by setting the effect to nil. The video shows a UIVisualEffectView whose effect is set to a UIGlassEffect animating away as its effect is set to nil. But when I do this in my app (or a sample app), setting effect to nil does not remove the glass appearance. Is this expected? Is the video out of date? Or is this a bug?

Hi, I have added widgets to my iOS app and I would like to make this feature only accessible to "pro" users that have made a non-consumable in-app purchase. Currently, I am doing the following: I store an "isUnlocked" property in the Keychain after the purchase is made I read data to be displayed in the widget and here I also query the Keychain and store whether the widget is unlocked I have no refresh policy, but only change the widget data on a significant time change a different view is displayed when the app is locked Some dummy code snippets: func getTimeline(in context: Context, completion: @escaping (Timeline<Entry>) -> Void) { &#9;&#9;let entry = readContents() &#9;&#9;let timeline = Timeline(entries: [entry], policy: .never) &#9;&#9;completion(timeline) } struct WidgetEntryView: View { &#9;&#9;let entry: Provider.Entry     @Environment(\.widgetFamily) var family     @ViewBuilder     var body: some View {         switch family {         case .systemSmall:             if !entry.isUnlocked {                 LockedWidgetView()             } else if let event = entry.event {                 SmallWidgetEventView(event: event)             } else {                 NoDataWidgetView()             } ... func applicationSignificantTimeChange(_ application: UIApplication) { &#9;&#9;if #available(iOS 14.0, *) { &#9;&#9;&#9;&#9;WidgetCenter.shared.reloadAllTimelines() &#9;&#9;} ... However, 2 unexpected things happen: the view is refreshed intraday (not only at midnight i.e. at significant time change) sometimes the LockedWidgetView is displayed. Especially the latter is problematic, because it gives false information to a user that has already made the in-app purchase. How can I achieve my goal of only displaying info when the user has made the in-app purchase? Thanks in advance. P.S. Although it would not have my preference, I would also find it acceptable if the widget is only shown as option to add once the purchase is made. In other words, I was considering changing the Widget itself: struct MyWidget: Widget {     private var supportedFamilies: [WidgetFamily] = isUnlocked() ? [.systemSmall, .systemMedium] : [] but I believe I cannot re-initialise the widget from the app when the user makes the in-app purchase, because the only refresh option that I have is WidgetCenter.shared.reloadAllTimelines()

Hi, In my apps, the recent iOS 16.0 beta 7 (20A5356a) broke the .timer DateStyle property of the Text view, in a SwiftUI widget. In previous OS and beta, Text(Date(), style: .timer) was correctly displaying an increasing counter. In iOS 6.0 beta 7, Text(Date(), style: .timer) does not update anymore, (and is offset to the left). The other DateStyle (like .offset, .relative, ...) seems to update correctly. Anyone noticed that (very specific) problem ?

I created a Radar for this FB14766095, but thought I would add it here for extra visibility, or if anyone else had any thoughts on the issue. Basic Information Please provide a descriptive title for your feedback: iOS 18 hit testing functionality differs from iOS 17 What type of feedback are you reporting? Incorrect/Unexpected Behavior Description: Please describe the issue and what steps we can take to reproduce it: We have an issue in iOS 18 Beta 6 where hit testing functionality differs from the expected functionality in iOS 17.5.1 and previous versions of iOS. iOS 17: When a sheet is presented, the hit-testing logic considers subviews of the root view, meaning the rootView itself is rarely the hit view. iOS 18: When a sheet is presented, the hit-testing logic changes, sometimes considering the rootView itself as the hit view. Code: import SwiftUI struct ContentView: View { @State var isPresentingView: Bool = false var body: some View { VStack { Text("View One") Button { isPresentingView.toggle() } label: { Text("Present View Two") } } .padding() .sheet(isPresented: $isPresentingView) { ContentViewTwo() } } } #Preview { ContentView() } struct ContentViewTwo: View { @State var isPresentingView: Bool = false var body: some View { VStack { Text("View Two") } .padding() } } extension UIWindow { public override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? { /// Get view from superclass. guard let hitView = super.hitTest(point, with: event) else { return nil } print("RPTEST rootViewController = ", rootViewController.hashValue) print("RPTEST rootViewController?.view = ", rootViewController?.view.hashValue) print("RPTEST hitView = ", hitView.hashValue) if let rootView = rootViewController?.view { print("RPTEST rootViewController's view memory address: \(Unmanaged.passUnretained(rootView).toOpaque())") print("RPTEST hitView memory address: \(Unmanaged.passUnretained(hitView).toOpaque())") print("RPTEST Are they equal? \(rootView == hitView)") } /// If the returned view is the `UIHostingController`'s view, ignore. print("MTEST: hitTest rootViewController?.view == hitView", rootViewController?.view == hitView) print("MTEST: -") return hitView } } Looking at the print statements from the provided sample project:
 iOS 17 presenting a sheet from a button tap on the ContentView(): RPTEST rootViewController's view memory address: 0x0000000120009200 RPTEST hitView memory address: 0x000000011fd25000 RPTEST Are they equal? false MTEST: hitTest rootViewController?.view == hitView false RPTEST rootViewController's view memory address: 0x0000000120009200 RPTEST hitView memory address: 0x000000011fd25000 RPTEST Are they equal? false MTEST: hitTest rootViewController?.view == hitView false iOS 17 dismiss from presented view: RPTEST rootViewController's view memory address: 0x0000000120009200 RPTEST hitView memory address: 0x000000011fe04080 RPTEST Are they equal? false MTEST: hitTest rootViewController?.view == hitView false RPTEST rootViewController's view memory address: 0x0000000120009200 RPTEST hitView memory address: 0x000000011fe04080 RPTEST Are they equal? false MTEST: hitTest rootViewController?.view == hitView false iOS 18 presenting a sheet from a button tap on the ContentView(): RPTEST rootViewController's view memory address: 0x000000010333e3c0 RPTEST hitView memory address: 0x0000000103342080 RPTEST Are they equal? false MTEST: hitTest rootViewController?.view == hitView false RPTEST rootViewController's view memory address: 0x000000010333e3c0 RPTEST hitView memory address: 0x000000010333e3c0 RPTEST Are they equal? true MTEST: hitTest rootViewController?.view == hitView true You can see here ☝️ that in iOS 18 the views have the same memory address on the second call and are evaluated to be the same. This differs from iOS 17. iOS 18 dismiss RPTEST rootViewController's view memory address: 0x000000010333e3c0 RPTEST hitView memory address: 0x0000000103e80000 RPTEST Are they equal? false MTEST: hitTest rootViewController?.view == hitView false RPTEST rootViewController's view memory address: 0x000000010333e3c0 RPTEST hitView memory address: 0x0000000103e80000 RPTEST Are they equal? false MTEST: hitTest rootViewController?.view == hitView false The question I want to ask: Is this an intended change, meaning the current functionality in iOS 18 is expected? Or is this a bug and it's something that needs to be fixed? As a user, I would expect that the hit testing functionality would remain the same from iOS 17 to iOS 18. Thank you for your time.

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?

Running up Xcode 16.2 Beta 1, a lot of my code that used onPreferenceChange in Views to change @State properties of those views, such as some notion of a measured width is now complaining about mutating the @MainActor-isolated properties from Sendable closures. Now I've got to hoop-jump to change @State properties from onPreferenceChange? OK, but seems a bit of extra churn.

Hello, I face an error everytime I want to interact with a TextField. The XCode debug area is showing : CLIENT ERROR: TUINSRemoteViewController does not override -viewServiceDidTerminateWithError: and thus cannot react to catastrophic errors beyond logging them There is no crash, and the text field is working fine. I am developing for MacOS using a macbook pro Intel from 2019 with Sonoma 14.5 and Xcode 15.4 and I think that I noticed since the release of Sonoma. I was not particularly concerned by it but I noticed that interacting with the textField was leading to severe hang in my app, and micro-hang in the test app and I am wondering is these two issues could be related. The message is easy to reproduce. Just create a new Project/Application/App using SwiftUI and add a TextField to the ContentView. When you start app, click or double click on the text field, enter a message and press enter. import SwiftUI struct ContentView: View { @State var value: String = "" var body: some View { VStack { Image(systemName: "globe") .imageScale(.large) .foregroundStyle(.tint) Text("Hello, world!") TextField(text: $value, label: { Text("Test") } ) } .padding() } } Did you notice the same thing ? How I could solve it ? Note : I already posted the problem on Swift forums but it was close because related to SwiftUI https://forums.swift.org/t/error-when-clicking-on-textfield-client-error-tuinsremoteviewcontroller-does-not-override-viewservicedidterminatewitherror-and-thus-cannot-react-to-catastrophic-errors-beyond-logging-them/72134/1 Thank you

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.

Hello, I am encountering compatibility issues with older JavaScript frameworks, specifically Ext JS 4.0 and Sencha Touch 2.0, after upgrading to iOS 18.2 Beta. My application, which was working fine on previous versions of iOS, is now experiencing rendering issues, broken touch events, and performance degradation on WebKit in iOS 18.2. The issues I’m seeing include: Sencha Touch 2.0: The UI elements (like fields, and lists) are not interactive or showing their content properly. There also seems to be a delay in rendering touch events. This seem to no longer work as expected with the updated WebKit engine in iOS 18.2 Beta. My Questions: Are there any known issues with legacy JavaScript frameworks like Ext JS 4.0 and Sencha Touch 2.0 on iOS 18.2 Beta? Specifically, do these frameworks rely on older DOM methods or JavaScript features that might be deprecated in the latest WebKit engine? Has Apple officially deprecated any JavaScript features or DOM methods in WebKit that might be causing these issues? If so, are there recommended workarounds or updates to ensure compatibility with iOS 18.2? Is there a way to enable legacy JavaScript features or fallback modes in iOS 18.2 ? I would appreciate any guidance on this, as we are facing significant issues with our app’s performance and UI since upgrading to iOS 18.2. Thank you!

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.

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.

Hello Dear Developers, Is it only to me or in iOS 18 there's a problem with Settings.bundle, Im using my settings.bundle to set my enivement for my app but after upgrading to iOS 18 I can't see my Settings.Bundle in my settings iphone, just to mention that I also updated my xcode to 16. Anyone who has occur with this problem? :)

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. 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

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?

When I create a SwiftUI toolbar item with placement of .keyboard on iOS 26, the item appears directly on top of and in contact with the keyboard. This does not look good visually nor does it match the behavior seen in Apple's apps, such as Reminders. Adding padding to the contents of the toolbar item only expands the size of the item but does not separate the capsule background of the item from the keyboard. How can I add vertical padding or spacing to separate the toolbar item capsule from the keyboard?