I have raised a Feedback FB23015978 This applied to Xcode/Ios 27/26 and maybe earlier. This issue relates to ‘Charts’ This issue exists back to iOS 26 and maybe before. I have provided an app that creates a simple table of integer values representing a summary of scores achieved in 10m Air Pistol shooting. It is genuine data that I want to display certain aspects of. The the counts represent the number of times that particular score was achieved during a 60 shot qualification match. The graph I want to show is the spread of the number of 10s, 9s and hopefully not to many 8s or less. To say that this was a nightmare is a massive understatement. To narrow down the issue I have created an app whose sole purpose is to represent that real world data. Fundamentally, the score and count are integer values. I have created a set of view that display a bar chart of the data representing the values as Score Count ——————— Int Int String Int Int String String String Furthermore, I have added a version of each of the above using a domain such that any values with a count of zero up to the first non-zero value are excluded from the charts. Each screenshot of the chart also show the text for the actual Chart view. As can be seen by visual inspection, it is pretty much a total mess. Firstly, you can see that some of the charts have thick bars that are as expected however, half of the charts are rendered with little thin bars. The IntStringDomain, StringInt, and StringString charts have bars that are drawn outside of the designated chart area. Charts such as the IntInt and IntIntDomain chart do not show the righthand x-axis value. Although some of the chart data may not make sense the way it is presented which attribute is the x-axis or y-axis, the charts should be bullet proof. I have attached the screen shots. can't find a way to post he app sorry. Here are the charts, each one also shows the code that generated it. For those of a nervous disposition, look away now.

As someone coming from Android development, I’m trying to learn how to think the SwiftUI way. For beginners building real-world apps, what mental models matter most around state management, navigation, and structuring screens so the app can scale as it grows?

What are the performance implications of building an app that is effectively single-threaded (for example, heavily isolated to @MainActor) versus one that allows work to execute across multiple executors and threads?

Putting: let statusItem = NSStatusBar.system.statusItem(withLength: NSStatusItem.variableLength) at the top of AppDelegate.swift and no other code at all generates the warning below in the console when the app runs. Looks benign but it sure would be great to not have that happen. Anyone figure out how to stop this other than muting the warning? I tried all kinds of exotic deferring but that just makes the code brittle and unreadable. Here's the warning: It's not legal to call -layoutSubtreeIfNeeded on a view which is already being laid out. If you are implementing the view's -layout method, you can call -[super layout] instead. Break on void _NSDetectedLayoutRecursion(void) to debug. This will be logged only once. This may break in the future. Xcode 26.5, 26.4 - macOS 26.5.1

Hello, I'm trying to present an app overlay (like an HUD) that should appear on top of everything (the app UI could be the root content view or a modal presented from the content view or a modal over a modal presented from the content view, etc.). If I use a ZStack for example, the issue is that the view is not visible if the ZStack is presenting a modal for example. In UIKit, I think we can use instantiate another UIWindow to show content above the top window of the app (what a native alert does if I'm not wrong). What would be the equivalent in SwiftUI? How could I create this? Thanks, Axel

Dear Apple, I am sending feedback regarding the desktop management of macOS to improve the user experience. Mission Control currently only has a “+” button to the right, meaning that all new desktops are forced to the right side of the line. Adding an identical “+” button to the left will increase ease of using the OS, as I don’t necessarily need every new desktop to be on the right side. This will increase usability and make using desktops significantly easier than manually dragging them into the needed positions every time I add a desktop. Another thing is that when I maximize apps, all desktops go to the left by one spot. There should be a setting where you can control where desktops go when maximizing screens, either you want every desktop to go to the right or the left. This makes things easier as sometimes I have my main app on the right, with all the multi-tasking on the left. If desktops move to the right instead of the left, no open apps will be interfered with. (Please put this setting in the “Desktop and Dock” section). I have been using macOS for a year now, and those details were quite clear. Please consider this as a software update for over 100 million Macbook users, increasing usability without changing the OS so much people barely know how to use it. I have been concentrating significantly on macOS lately, noticing an upgrade followed by another, and is how I noticed this. Please consider this a fresh start for my feedback. I apologize for my previous un-trained replies. I am not a trained professional, but I genuinely care about improving the user experience and wanted to share these layout ideas. I promise to keep my interactions respectful of the forum guidelines from now on. May these desktop management ideas be considered? Thanks, Alyaman

Hey All! Curious if others are seeing this where UIAlertController style action sheets (and to some extent Alert type) in iPad OS 27.0 B1 seem to be very buggy. By that i mean if you have an action sheet that has 20 items or some, half of them are not visible until you scroll or move the mouse over them (in simulator), and when tapping on them its a hit or miss if it triggers the delegate, sometimes it triggers on the first tap (click) or sometimes it takes 2 to 3 taps (clicks) to the delegate to trigger and the actioinsheet to dismiss. On initial look it seems iOS 27.0 B1 is working just fine, seems iPad Specific. While the list of the items not showing is only for action sheets, the 'sometimes' takes 2 to 3 taps (clicks) to select and item happens in both type ActionSheet and Alert. Sometimes it takes 2 to 3 taps to tigger an alert button etc. Both the above described issues happen on both device and simulator. Ive attached a video and a sample Proj to FB22998239. Hoping one of the UIKit Engineers can take a look, thanks for everything!

I want to connect a BluetoothHFP microphone to MFi hearing aids. Whenever I make the microphone the input it steals the output and whenever I make the MFi the output it steals the input. Is it possible to do this using AVAudioSession? Is it possible to redefine the MFi hearing aids as a speaker and use Live Listen?

iPhone 16Pro 512GB..UI FREEZES, HARDWARE CONTINUES

UIPageViewController crashes with _UIQueuingScrollView state inconsistency on iOS 26 We are experiencing two types of crashes in UIPageViewController (transition style .scroll) that only occur on iOS 26. These crashes do not occur on iOS 18 or earlier with the same code. Crash 1: "No view controller managing visible view" NSInternalInconsistencyException: No view controller managing visible view <_UIQueuingScrollView: 0x...> -[UIPageViewController _flushViewController:animated:] -[UIPageViewController _setViewControllers:withTransition:animated:completion:] This occurs when calling setViewControllers(_:direction:animated:completion:) after a swipe gesture, particularly when didFinishAnimating delegate method does not fire. Crash 2: "Duplicate states in queue" NSInternalInconsistencyException: Duplicate states in queue for view: <UIView: 0x...> -[_UIQueuingScrollView _enqueueCompletionState:] -[_UIQueuingScrollView _enqueueAnimatedScrollInDirection:withRevealView:coverView:stashedView:translation:] This occurs when programmatic page changes (setViewControllers with animated: true) overlap with internal _UIQueuingScrollView state that has not been fully cleaned up. Reproduction Steps Create a UIPageViewController with .scroll transition style Swipe partially (without completing the page transition), then release Immediately tap a button that calls setViewControllers(_:direction:animated:completion:) Repeat a few times — the crash occurs intermittently Combining swipe gestures with programmatic setViewControllers calls reliably triggers one of the two crashes within a few attempts. Root Cause Analysis On iOS 26, the UIPageViewControllerDelegate method pageViewController(_:didFinishAnimating:previousViewControllers:transitionCompleted:) sometimes does not fire after a swipe gesture is cancelled or completed. This leaves _UIQueuingScrollView in a dirty internal state (pending transition data not cleared). A subsequent setViewControllers call then encounters this stale state and triggers an assertion failure. The crash stack traces are entirely within UIKit internals (_UIQueuingScrollView, UIPageViewController), with no app code in the crashing frames. Environment Xcode 26.4.1 iOS 26 (all beta versions tested) iPhone 17, iPhone 16 Pro, iPhone 16 Pro Max (simulator and device) UIPageViewController with transitionStyle: .scroll Does not reproduce on iOS 18 or earlier

I'm trying to use NSTokenField for the first time. So my custom 'representedObject' for a token has additional model data tied to it (not just the editing/display string). I noticed when I edit an existing token, type text, and hit the enter key I get the following delegate callback: - (nullable id)tokenField:(NSTokenField *)tokenField representedObjectForEditingString:(NSString *)editingString; This same delegate method is called when I type a brand new token. Is there a way to distinguish if I'm editing a token vs. creating a new one? My expectation is to be able to do something like this (made up enhancement): - (nullable id)tokenField:(NSTokenField *)tokenField representedObjectForEditingString:(NSString *)editingString atIndex:(NSUInteger)existingTokenIndex { if (existingTokenIndex == NSNotFound) { // Token is new, create a new instance MyTokenObject *newToken = //create and configure. return newToken; } else { // This would update the editing string but wouldn't discard existing data held by the token. MyTokenObject *tokenObj = [self existingTokenAtIndex:existingTokenIndex]; tokenObj.editingString = editingString; return tokenObj; } }

In this iOS app, with UIKit in Swift, I create a UISegmentedControl in stroryboard. I define the text for each segmentTitles in IB ,and need to localise. I have tried in the main.xxx files "id.segmentTitles" = ["a", "b", "c", "d", "e"]; to no avail. I understand this is a very very old issue that UISegmentedControl are not localized from stroryboard: https://stackoverflow.com/questions/12884751/uisegmentedcontrol-and-localization I tried to use a similar approach as for UITextView (which are not either localized) helpTextView.text = NSLocalizedString("id.text", tableName: "Main", comment: "helpTextView") But cannot make it. I found a work around, by localising in code: let seg0 = NSLocalizedString("a", comment: "Segment") segmentedControl.setTitle(seg0, forSegmentAt: 0) However, I get error messages in log unless I clear the segment titles in IB: ERROR: id.segmentTitles[0] not found in table Main of bundle CFBundle 0x600003b101c0 Is there a solution to this ?

I am using SwiftUI's native SecureField. When a user types their password manually, the dots render correctly in both light and dark mode. However, when iOS suggests and autofills a strong generated password, the dots become invisible in dark mode. Switching to light mode shows that they are there. Is there a supported way to force SecureField to re-render its secure entry dots correctly after iOS fills in a strong generated password in dark mode? import SwiftUI let warmMustard = Color(red: 0.780, green: 0.659, blue: 0.290) let lightText = Color(red: 0.973, green: 0.961, blue: 0.933) let darkText = Color(red: 0.118, green: 0.118, blue: 0.118) struct SecureFieldTestView: View { @Environment(\.colorScheme) var colorScheme @State private var username = "" @State private var password = "" @State private var confirmPassword = "" var body: some View { ZStack { Color(colorScheme == .dark ? UIColor.black : UIColor.white) .ignoresSafeArea() VStack(spacing: 20) { Text("Dark mode dot reproduction") .foregroundColor(colorScheme == .dark ? .white : .black) TextField("Username", text: $username) .textContentType(.username) .autocorrectionDisabled() .textInputAutocapitalization(.never) .padding() .background(colorScheme == .dark ? Color.black : Color.white) .cornerRadius(8) .foregroundColor(colorScheme == .dark ? .white : .black) .overlay(RoundedRectangle(cornerRadius: 8).stroke(warmMustard, lineWidth: 2)) SecureField("Password", text: $password) .textContentType(.newPassword) .padding() .background(colorScheme == .dark ? Color.black : Color.white) .cornerRadius(8) .foregroundColor(colorScheme == .dark ? .white : .black) .overlay(RoundedRectangle(cornerRadius: 8).stroke(warmMustard, lineWidth: 2)) SecureField("Confirm Password", text: $confirmPassword) .textContentType(.newPassword) .padding() .background(colorScheme == .dark ? Color.black : Color.white) .cornerRadius(8) .foregroundColor(colorScheme == .dark ? .white : .black) .overlay(RoundedRectangle(cornerRadius: 8).stroke(warmMustard, lineWidth: 2)) } .padding(.horizontal, 32) } } } #Preview { SecureFieldTestView() }

I have this code As you can see, the locale of the Environment is different from the Locale given by .current. This is a problem for me because I have code that uses String(localized:) and AttributedString. I would like to be able to preview them with the locale I set in the Environment without any additional work on my part. I assumed these Apis would use the locale set by the environment but no, it uses the locale as decided by the schema used to build the preview app. The current solution I have is to manually change the App Language in the Preview's scheme to be whatever I need to correctly localize the language in Preview.

@State private var selectedItems:[PhotosPickerItem] = [] { didSet { print("items changed.") } } ... PhotosPicker( selection: $selectedItems, matching: .images, ) { Text("select pictures") } I want to know selectedItem changed, but didSet of selectedItems is not work. Is there any other way to inform me: Has the user selected some pictures? I want to create a task to load picture and display them to view after user selected some picture. Thank you.

I have this code struct TestAppleSuggestion: View { @Environment(\.locale) var locale: Locale var body: some View { VStack { VStack { Text("locale: \(locale.identifier)") Text(AttributedString(localized: LocalizedStringResource( "welcome", locale: locale ))) Text(AttributedString(localized: "welcome", locale: locale )) } } } } #Preview { TestAppleSuggestion().environment(\.locale, Locale(identifier: "fr-CA")) } Heres What I see in SwiftUi Previews The Localization is working for the LocalizedStringResource but not to the AttributedString. Why?

A ToolbarItem(placement: .bottomBar) inside a NavigationSplitView detail/destination view is missing after a device rotation on iOS 26. The bottom toolbar is missing until the view has been presented in both orientations, after which it renders correctly from then on. The issue does not reproduce on iOS 18. Environment iOS 26 only — does not reproduce on iOS 18 iPhone 17 Pro Max and iPhone 17 Air (i.e. devices that expose the landscape size class Regular width / compact height) SwiftUI NavigationSplitView with .balanced style Steps to reproduce Run the sample below on an iPhone 17 Pro Max or Air (or a simulator of either). Open the detail view (which contains a .bottomBar toolbar item) while the device is in either orientation. Rotate the device. Observe that the bottom toolbar is now missing. Expected behavior The .bottomBar button remains visible across rotation, regardless of which orientation the view was first presented in. Actual behavior On first presentation, rotating the device causes the bottom toolbar to disappear. Once the view has been presented in both landscape and portrait (roughly the third presentation), the bottom bar renders correctly and continues to behave correctly afterward. The behavior is inconsistent import SwiftUI @main struct MinimumReproducibleEventApp: App { var body: some Scene { WindowGroup { NavigationSplitView(columnVisibility: .constant(.all)) { NavigationLink("Primary") { ContentView() } } detail: { Text("Hello") } .navigationSplitViewStyle(.balanced) } } } ContentView import SwiftUI struct ContentView: View { var body: some View { VStack { Image(systemName: "globe") .imageScale(.large) .foregroundStyle(.tint) Text("Hello, world!") } .toolbar { ToolbarItem(placement: .bottomBar) { Button("Hello") { print("hello") } } } } }

I’m using a standard DisclosureGroup in SwiftUI and noticed that the disclosure indicator (chevron) no longer adopts the tint color. Example: DisclosureGroup("Details") { Text("Content") } .tint(.indigo) The label text becomes indigo, but the chevron remains the default system color. I also tried creating a custom DisclosureGroupStyle to render my own chevron, but that approach appears to break some of the built-in disclosure animation behavior and interaction. Questions: Is there a supported way to customize the disclosure indicator color in DisclosureGroup? Has the behavior of .tint(_:) changed for DisclosureGroup in recent iOS releases? If customization is not currently supported, is there a recommended alternative that preserves the native disclosure animations and accessibility behavior? Tested on: iOS 26.3 and Xcode 26.3

Hi everyone, We're experiencing a bug on iOS 26 that only occurs when the user has Reduce Transparency enabled in Accessibility settings. App structure: Our app uses a TabView with a standard tab bar. Inside each tab, we use a NavigationStack. The tab bar is visible on root-level screens, and hidden on all pushed destinations using: .toolbar(.hidden, for: .tabBar) The problem: On iOS 26 with Reduce Transparency off (Liquid Glass active) — everything works correctly. The tab bar hides as expected. On iOS 26 with Reduce Transparency on — a white bar appears at the bottom of the screen in every place where the tab bar is hidden. This white bar: Overlaps content at the bottom of the screen. Blocks scroll, tap, and all user interactions in that area. We also tried: .toolbarBackground(.hidden, for: .tabBar) Removing all custom UITabBarAppearance configuration The only workaround we found is setting UIDesignRequiresCompatibility = YES in Info.plist, which reverts the entire app to the pre-iOS 26 design — not a viable long-term solution. What can we do? Thanks in advance.

I’m working on a storyboard-based AppKit application that uses an NSWindowController containing an NSSplitViewController with multiple child view controllers. The hierarchy is roughly: NSWindowController └── NSSplitViewController ├── NSViewController ├── NSViewController └── NSViewController I am trying to provide dependencies during storyboard instantiation using either @IBSegueAction or instantiateInitialController(creator:), rather than configuring everything after initialisation. What I attempted I added custom initialisers to my view controllers so I can pass dependencies at creation time: class SplitViewController: NSSplitViewController { let dependency: Dependency init?(coder: NSCoder, dependency: Dependency) { self.dependency = dependency super.init(coder: coder) } required init?(coder: NSCoder) { print("init(coder:) was called") fatalError("init(coder:) is not supported") } } I then attempted to intercept storyboard instantiation using @IBSegueAction, trying it in both the window controller and the split view controller: @IBSegueAction func makeSplitViewController(_ coder: NSCoder) -> NSSplitViewController? { SplitViewController(coder: coder, dependency: dependency) } I also tried attaching the segue action at different points in the storyboard, but the behaviour did not change. Observed behaviour Regardless of where I place the segue action, AppKit still appears to call: required init?(coder: NSCoder) This means my custom initialiser is never used for the split view controller or its children. Background reference I found this older known issue in the Xcode 11 release notes: “A Segue Action on a relationship segue between a NSWindowController and a View Controller is currently not supported and ignored. (48252727)” This suggests that, at least historically, AppKit relationship segues ignored segue actions entirely. Has this limitation since been fixed in modern Xcode/macOS SDK releases, or are relationship segues involving NSWindowController still incompatible with @IBSegueAction? More generally, what is the intended way to provide dependencies to an NSSplitViewController and its child view controllers in a storyboard-based AppKit application? I am also unclear whether instantiateInitialController(creator:) participates in the creation of container hierarchies like split view controllers, or only top-level controllers.