When displaying a view with a Button inside a ScrollView using the sheet modifier, if you try to close the sheet by swiping and your finger is touching the Button, the touch is not canceled. This issue occurs when building with Xcode 16 but does not occur when building with Xcode 15. Here is screen cast. https://drive.google.com/file/d/1GaOjggWxvjDY38My4JEl-URyik928iBT/view?usp=sharing Code struct ContentView: View { @State var isModalPresented: Bool = false var body: some View { ScrollView { Button { debugPrint("Hello") isModalPresented.toggle() } label: { Text("Hello") .frame(height: 44) } Button { debugPrint("World") } label: { Text("World") .frame(height: 44) } Text("Hoge") .frame(height: 44) .contentShape(Rectangle()) .onTapGesture { debugPrint("Hoge") } } .sheet(isPresented: $isModalPresented) { ContentView() } } }

When I copy and paste example code in apple developer documentation, LongPressGesture does not work as expected in Xcode Version 16.0 (16A242) and iOS 18. It seems updating(_:body:) method does not work when used with LongPressGesture. When I make a breakpoint in updating(_:body:) method and long press the blue circle on the screen of simulator(or device), it is expected to be caught in breakpoint or it is expected that color of circle turns from blue to red to green. However, it is not caught in breakpoint and never turns to red. Question of Stackoverflow is about same issue and I can not use onLongPressGesture method to implement required feature of my app. Development environment: Xcode Version 16.0 (16A242), macOS 14.5 Run-time configuration: iOS 18.0

Hello. I have an 12 year old app that still has some objective-c code in it. I have a place where i have a flip animation between 2 view controllers that looks like this: [UIView transitionFromView:origView toView:newViewController.view duration:0.5 options:UIViewAnimationOptionTransitionFlipFromRight completion:nil]; It has looked like this since 2012 at least. In our production release, it works prior to 26.1, but in 26.1 and 26.2, the flip is off-center and looks weird. it's like both edges flip the same way. It's a little bit hard to explain. If seen at least 2 other app store apps that i have installed behave this way too, from 26.1 and onwards. Anyone else seen this? Is there anything that can be done about it? Thankful for thoughts.

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.

I'm being faced with an issue when using SwiftUI's WebView on iOS 26. In many websites, the top/bottom content is unaccessible due to being under the app's toolbars. It feels like the WebView doesn't really understand the safe areas where it's being shown, because the content should start right below the navigation bar, and only when the user scrolls down, the content should move under the bar (but it's always reachable if the users scroll back up). Here's a demo of the issue: Here's a 'fix' by ensuring that the content of the WebView never leaves its bounds. But as you can see, it feels out of place on iOS 26 (would be fine on previous OS versions if you had a fully opaque toolbar): Code: struct ContentView: View { var body: some View { NavigationStack { WebView(url: URL(string: "https://apple.com")).toolbar { ToolbarItem(placement: .primaryAction) { Button("Top content covered, unaccessible.") {} } } } } } Does anyone know if there's a way to fix it using some sort of view modifier combination or it's just broken as-is?

Hi, I've run into two problems using SwiftData in iOS 18 that are total show-stoppers for my app, causing it to run out of memory and be killed by the system. The same app runs fine on iOS 17. The two problems are inter-related in a way I can't exactly diagnose, but are easy to reproduce. Problem #1: Calling .count on the array that represents a relationship or Query causes the whole array of objects to be loaded into memory. Problem #2: When a @Model object is loaded, properties that are declared with .externalStorage are loaded unnecessarily, and use tons of memory. It's possible that #1 is normal behavior, exacerbated by #2. I've written a test app that demonstrates the extreme difference in memory usage between the OS Versions. It uses a typical navigation pattern, with content counts on the left-side view. Each item has one thumbnail and one large image in .externalStorge. GitHub Source When populated with 80 items, each containing one thumbnail and one large image in .externalStorge, the app launches in 17.5 using 29mb of memory. On iOS 18, in the same conditions, 592 mb. When the first folder is selected, causing a list of thumbnails to load, iOS 17 uses just 86mb. iOS 18 uses 599mb, implying that all image data has already been loaded. So I'm asking for help from Apple or the Community in finding a workaround. I've been advised that finding a workaround may be necessary, as this may not be addressed in 18.0. Thanks in advance for any insight. Radars: FB14323833, FB14323934 (See attached images, or try it yourself) (You may notice in the 18.0 screenshots that the item counts don't add up right. That's yet another 18.0-SwiftData anomaly regarding relationships that I haven't tackled yet, but is also demonstrated by the sample app.)

I have an App Intent that conforms to ShowsSnippetView and returns a view that is shown in the Siri interface after the shortcut runs. The view simply consists of a VStack with a Text element, with no special styling. When my device is set to dark mode, the view doesn't adapt: the text is black, but the background of the Siri interface is a transparent dark gray, which makes the text almost unreadable. The text should be white in dark mode. The colorScheme environment value inside the view corresponds to light mode, even though the device is set to dark mode. This is most likely a bug in iOS.

Whenever I start editing TextField or while editing TextField, Xcode shows this worning, and takes a few seconds to show the keyboard. There is no 'availabilityDetailedInfo' in my source code, and I could not find similar errors on the internet. Can't find or decode availabilityDetailedInfo unavailableReasonsHelper: Failed to get or decode availabilityDetailedInfo Can't find or decode reasons unavailableReasonsHelper: Failed to get or decode unavailable reasons as well Can't find or decode availabilityDetailedInfo unavailableReasonsHelper: Failed to get or decode availabilityDetailedInfo Can't find or decode reasons unavailableReasonsHelper: Failed to get or decode unavailable reasons as well

I found an issue when implementing an alert with a TextField to input a name. I want the action button to be disabled until a name has been entered, but the action block is never executed when the button has become enabled and pressed. The problem seems to appear only when name is initially an empty string. Tested with iOS 17.0. struct MyView: View { @State private var name = "" var body: some View { SomeView() .alert(...) { TextField("Name", text: $name) Button("Action") { // Action }.disabled(name.isEmpty) Button("Cancel", role: .cancel) {} } } }

My app displays some text that should appear the same regardless of the container view or window size, i.e. it should grow and shrink with the container view or window. On iOS there is UILabel.adjustsFontSizeToFitWidth but I couldn't find any equivalent API on macOS. On the internet some people suggest to iteratively set a smaller font size until the text fits the available space, but I thought there must be a more efficient solution. How does UILabel.adjustsFontSizeToFitWidth do it? My expectation was that setting a font's size to a fraction of the window width or height would do the trick, but when resizing the window I can see a slightly different portion of it. class ViewController: NSViewController { override func loadView() { view = MyView(frame: CGRect(x: 0, y: 0, width: 400, height: 400)) NSLayoutConstraint.activate([view.widthAnchor.constraint(equalTo: view.heightAnchor, multiplier: 3), view.heightAnchor.constraint(greaterThanOrEqualToConstant: 100)]) } } class MyView: NSView { let textField = NSTextField(labelWithString: String(repeating: "a b c d e f g h i j k l m n o p q r s t u v w x y z ", count: 2)) override init(frame frameRect: NSRect) { super.init(frame: frameRect) textField.translatesAutoresizingMaskIntoConstraints = false textField.setContentCompressionResistancePriority(.defaultLow, for: .horizontal) addSubview(textField) NSLayoutConstraint.activate([textField.topAnchor.constraint(equalTo: topAnchor), textField.leadingAnchor.constraint(equalTo: leadingAnchor), textField.trailingAnchor.constraint(equalTo: trailingAnchor)]) } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } override func resize(withOldSuperviewSize oldSize: NSSize) { // textField.font = .systemFont(ofSize: frame.width * 0.05) textField.font = .systemFont(ofSize: frame.height * 0.1) } }

We have some rather old code that worked for many years, but recently started to crash sporadically here: The crash looks like this: or Our code is called from many threads concurrently, but as said it worked without any issues until recently. I've found the apparently same crash on iOS at this Reddit post: https://www.reddit.com/r/iOSProgramming/comments/1kle4h4/ios_185_doesnt_fix_cicontext_rendering_crash/ Recap: we believe it started on macOS 18.4 and is still on macOS 18.5. But maybe it was already on macOS 18.3. This matches the observation in the Reddit post well. Should we create a feedback with sysdiagnose? Thanks! :)

I'm using one UITabBarController which leads to 6 NavigationController. Therefore the user will get 4 icons displayed and one icon with three points to see the rest of the Navigation Controller. If the user now tries to edit the list and moves one item from the hidden area towards the TabBar at the bottom, the App crashes with the error: Exception NSException * "Can't add self as subview" 0x0000600000d16040 I can see this effect at least on both my apps. If the same compilation is run on a older iOS version, there is no crash. Is there anything I have to take care of the configuration of the TabBar, when it comes to iOS26?

Is anyone else getting new warning about menu items with submenus when running on Tahoe? I'm getting big performance problems using my menu as well as seeing these messages and I'm wondering if there's a connection. My app is faceless with a NSStatusItem with an NSMenu. Specifically it's my own subclass of NSMenu where I have a lot of code to manage the menu's dynamic behavior. This code is directly in the menu subclass instead of in a controller because the app I forked had it this way, a little wacky but I don't see it being a problem. A nib defines the contents of the menu, and it's instantiated manually with code like: var nibObjects: NSArray? = [] guard let nib = NSNib(nibNamed: "AppMenu", bundle: nil) else { ... } guard nib.instantiate(withOwner: owner, topLevelObjects: &nibObjects) else { ... } guard let menu = nibObjects?.compactMap({ $0 as? Self }).first else { ... } Within that nib.instantiate call I see a warning logged that seems new to Tahoe, before the menu's awakeFromNib is called, that says (edited): Internal inconsistency in menus - menu <NSMenu: 0x6000034e5340> believes it has <My_StatusItem_App.AppMenu: 0x7f9570c1a440> as a supermenu, but the supermenu does not seem to have any item with that submenu My_StatusItem_App.AppMenu: 0x7f9570c1a440 is my menu belonging to the NSStatusItem, NSMenu: 0x6000034e5340 is the submenu of one of its menu items. At a breakpoint in the NSMenu subclass's awakeFromNib I print self and see clear evidence of the warning's incorrectness. Below is a snippet of the console including the full warning, only edited for clarity and brevity. It shows on line 32 menu item with placeholder title "prototype batch item" that indeed has that submenu. Internal inconsistency in menus - menu <NSMenu: 0x6000034e5340> Title: Supermenu: 0x7f9570c1a440 (My StatusItem App), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( "<NSMenuItem: 0x6000010e4fa0 Do The Thing Again, ke mask='<none>'>", "<NSMenuItem: 0x6000010e5040 Customize\U2026, ke mask='<none>'>", "<NSMenuItem: 0x6000010e50e0, ke mask='<none>'>" ) believes it has <My_StatusItem_App.AppMenu: 0x7f9570c1a440> Title: My StatusItem App Supermenu: 0x0 (None), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( ) as a supermenu, but the supermenu does not seem to have any item with that submenu (lldb) po self <My_StatusItem_App.AppMenu: 0x7f9570c1a440> Title: My StatusItem App Supermenu: 0x0 (None), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( "<NSMenuItem: 0x6000010fd7c0 About My StatusItem App\U2026, ke mask='<none>', action: showAbout:, action image: info.circle>", "<NSMenuItem: 0x6000010fd860 Show Onboarding Window\U2026, ke mask='Shift', action: showIntro:>", "<NSMenuItem: 0x6000010fd900 Update Available\U2026, ke mask='<none>', action: installUpdate:, standard image: icloud.and.arrow.down, hidden>", "<NSMenuItem: 0x6000010e46e0, ke mask='<none>'>", "<NSMenuItem: 0x6000010e4780 Start The Thing, ke mask='<none>', action: startTheThing:>", "<NSMenuItem: 0x6000010e4dc0 \U2318-\U232b key detector item, ke mask='<none>', view: <My_StatusItem_App.KeyDetectorView: 0x7f9570c1a010>>", "<NSMenuItem: 0x6000010e4e60, ke mask='<none>'>", "<NSMenuItem: 0x6000010e4f00 saved batches heading item, ke mask='<none>', view: <NSView: 0x7f9570b4be10>, hidden>", "<My_StatusItem_App.BatchMenuItem: 0x6000016e02c0 prototype batch item, ke mask='<none>', action: replaySavedBatch:, submenu: 0x6000034e5340 ()>", "<NSMenuItem: 0x6000010f7d40, ke mask='<none>'>", "<My_StatusItem_App.ClipMenuItem: 0x7f956ef14fd0 prototype copy clip item, ke mask='<none>', action: copyClip:>", "<NSMenuItem: 0x6000010fa620 Settings\U2026, ke='Command-,', action: showSettings:>", "<NSMenuItem: 0x6000010fa6c0, ke mask='<none>'>", "<NSMenuItem: 0x6000010fa760 Quit My StatusItem App, ke='Command-Q', action: quit:>" ) Is this seemingly incorrect inconsistency message harmless? Am I only grasping at straws to think it has some connection to the performance issues with this menu?

We have written code to blur the app screen in "applicationWillResignActive" when app goes to app switcher. But the blur affect is observed only some times. Is there is any specific reason for this? We have a doubt that applicationWillResignActive is not always completely executed or is dismissed by OS for other priority activities. Is this is expected behaviour or are we missing anything here?

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.

struct ContentView: View { var body: some View { NavigationSplitView { List { Text("row 1") Text("row 2") Text("row 3") } .toolbar(content: { ToolbarItem { Button("aa", action: onToolbar) } }) } detail: { HSplitView { VStack { Image(systemName: "globe") .imageScale(.large) .foregroundStyle(.tint) Text("Hello, world!") } .toolbar(id: "toolbar", content: { ToolbarItem(id: "toolbar-1") { Button("bb", action: onToolbar) } }) .padding() Text("right") } }.navigationTitle("") } func onToolbar() {} } Run & Crash NSToolbar 0x6000005665b0 already contains an item with the identifier com.apple.SwiftUI.splitViewSeparator-0. Duplicate items of this type are not allowed.

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.

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!

In tvOS 18 the onMoveCommand is missing the first press after a view is loaded and every time the direction is changed. It also misses the first press on a button after a focus change. This appears to only impact the newer silver remote and not the older black remote or IR remotes. With the code bellow press any direction 3 times and it will only log twice. struct ButtonTest: View { var body: some View { VStack { Button { debugPrint("button 1") } label: { Text("Button 1") } Button { debugPrint("button 2") } label: { Text("Button 2") } Button { debugPrint("button 3") } label: { Text("Button 3") } } .onMoveCommand(perform: { direction in debugPrint("move \(direction)") }) .padding() } }

I'm using GoogleMaps in my project. Legacy preview works well but new preview (Xcode 16.3.1 beta) produces error. It doesn't seem to find Googlemaps.a. == PREVIEW UPDATE ERROR: FailedToLaunchAppError: Failed to launch *** ================================== | [Remote] JITError | | ================================== | | | [Remote] CouldNotLoadInputStaticArchiveFile: Could not load static archive during preview: /Users/xxx/Library/Developer/Xcode/DerivedData/BOA-eiluspltxasszsfkpqrnnsxsjhth/Build/Products/Debug_BOA_Inhouse-iphonesimulator/GoogleMaps.a | | | | path: /Users/xxx/Library/Developer/Xcode/DerivedData/BOA-eiluspltxasszsfkpqrnnsxsjhth/Build/Products/Debug_BOA_Inhouse-iphonesimulator/GoogleMaps.a | | | | ================================== | | | | | [Remote] XOJITError | | | | | | XOJITError: arm64 slice of /Users/xxx/Library/Developer/Xcode/DerivedData/BOA-eiluspltxasszsfkpqrnnsxsjhth/Build/Products/Debug_BOA_Inhouse-iphonesimulator/GoogleMaps.a does not contain an archive