In the past few years, there hasn't been much updates around Storyboards and yet it seems like Xcode supports them. Even before the first release of SwiftUI, many developers stopped using Storyboards for compelling reasons such as: They introduce two sources of truth for the UI It's not easy to read the content during code-review They can cause merge conflicts Often they fail to load, especially after a new major release of Xcode, without any error I was wondering whether there's a dedicated team working on Storyboards or if they're just abandoned. I understand this question may overlap with what the Xcode team does; so, let me rephrase it: in a large project, what are the pros and cons of using Storyboards when building views using UIKit? For instance, do they work well with things such as navigation by employing segues, the liquid glass or the new resizing feature? Finally, one of the benefits of using Storyboards is the fact that they visualize the UI, including the constraints. However, since now we can UIViewController in Preview, can we safely say that Previews can deliver the same thing?

When the marked text is touched, or when the cursor is moved between the marked text, the marked text will be disappear In order to implement the function of active input, we use the setMarkedText(_:selectedRange:) method provided by UITextDocumentProxy to insert and mark the input text, but when the marked text is touched, or when the cursor is moved between the text, the marked text will be disappear. This is a very obvious error and cannot be avoided. So far, this problem still occurs on devices with the system version of iOS 27 beta , so we cannot use this method to perfectly implement the function of active input, which is a big trouble for us. We want the text to be displayed normally after the user touches the marked text. And the cursor can move in the marked text, so that the user can perform operations such as insert, remove, etc. May I ask what methods can be used to achieve the above effect? If this is a bug, please fix it as soon as possible. More details can be found by the video link: [https://www.youtube.com/shorts/dd8VhBJ88og] STEPS TO REPRODUCE 1.Use the setMarkedText(_:selectedRange:) method provided by UITextDocumentProxy to insert and mark text 2.Touch the marked text or long press the cursor to move to the marked text

I would like to provide alternate IconComposer-designed icons (that support light, dark, mono) for my macOS app. The DockTile approach only works when app is running, but also only with NSImage. And there doesn't seem to be a way to load an NSImage from a .icon file that matches the current appearance option. Thank you.

I have an app where CoreData is working great - but I want to add widgets. I'm following a tutorial where they create an AppGroup and in the migration they use appendingPathComponent(_:) which is deprecated (iOS 8.0–26.1) however the recommended replacement appending(path:directoryHint:) starts support at iOS 16. I'm hanging on to iOS 15 for some users who don't want to upgrade their phones - but is it time to give up on that for widgets running on released iOS 26 and beyond? I assume I'll need to use if #available(iOS 16.0, *) for the new code. How does this work for the CoreData migration for the older phones? So far this is just in TestFlight. Any recommendations?

In macOS 27, document-based applications appear to gain a new feature where, when Autosave in Place is enabled, draft document titles are automatically suggested based on the document’s content. I was surprised to see this, but I think it is a great feature. (Interestingly, I have received similar feature requests from users of my own application in the past, but I declined them because I felt they would add unnecessary complexity.) My question is mostly out of curiosity: how is this feature implemented? My assumption is that the system may be reusing the new Spotlight indexing infrastructure to extract document content, perhaps by combining the Data returned from NSDocument.data(ofType:) during autosave with the document’s fileType. Is that understanding correct, or is a different mechanism involved? Are there any articles, WWDC sessions, or other documentation that explain this new draft title suggestion feature? I have not been able to find any information about it. Also, is there currently any way to disable this behavior? I am not personally looking to turn it off, but I suspect some users of my application may eventually ask for that option.

UITabBarController's new prominentTabIdentifier property is a really nice addition! Thank you! Will there be official support via the UITab API for using the underlying _UITabBarAuxiliaryView as a primary action as many apps, such as the Apple Design Award Finalist, Structured, does for presenting a sheet, for example?

Hey Team, Using NSWorkspace.icon(forFile:) and pointing to an app bundle, the system returns an NSImage with the icon of the app, but in the current style. For example, if the user selected tinted icons in Appearance in System Settings, then any icon I receive back from the API will be tinted using the current accent color. Is there a way to override this and get the original icon? Thanks, Ari

What is the expected behaviour of UISlider.TrackConfiguration.Tick's title and image properties? On iOS, these seem to be no-ops. The docs also don't indicate what these properties do. let ticks = [ UISlider.TrackConfiguration.Tick(position: 0, title: "Slow", image: UIImage(systemName: "tortoise.fill")), UISlider.TrackConfiguration.Tick(position: 1, title: "Fast", image: UIImage(systemName: "hare.fill")) ] let configuration = UISlider.TrackConfiguration(ticks: ticks) let slider = UISlider() slider.trackConfiguration = configuration

In a simple scenario, it's possible to have a ScrollView that contains a LazyVStack where the headers or footers of Section gets pinned to the top safe area. In a more complicated scenario, where The ScrollView needs to ignore the top safe area The navigation bar is hidden until a certain view, call it Foo, has gone behind what used to be the top safe area, i.e., only about 100p of the view is visible which would be invisible if the navigation bar wasn't transparent/hidden. The navigation bar becomes visible once Foo is scrolled up to a threshold that was explained earlier A second view, call is Bar, that's positioned below Foo, should never go behind the navigation bar, i.e., it should be pinned to the bottom of the navigation bar I managed to achieve this behaviour by having a State for the ignored safe area edges that gets updated based on how far Foo is scrolled. However, I get a jumpy behaviour because the ScrollView tries to adjust its contentOffset/contentInset based on the new top safe area. This jumpy behaviour is very hard to compensate especially when user scrolls very fast. In UIKit, I could achieve this behaviour by overriding viewSafeAreaInsetsDidChangeand tweaking the contentInset, and contentOffset on a collection/table view. Maybe I need to rethink my approach in a declarative way that aligns better with SwiftUI. Any thoughts on how to achieve this?

Is there any documentation on the NSText* features supported by the various document types NSAttributedString can encode in AppKit? For example if I create an NSTextTable (which works fine in RTF), how can I can know if it's supported in the following types: DocFormat WordML OfficeOpenXML OpenDocument They mostly are not, and if I use merged cells (row/col spans) the support is even lower. Similarly, if I wanted to use Markdown decoding support to encode to the HTML type, does AppKit provide translation from PresentationIntent to the NSText* implementations?

Views with custom nonisolated init fail to compile when using @MainActor-isolated @Environment properties (e.g., \.openURL, \.dismiss). From the Swift 6 migration documentation, it seems encouraged to define inits nonisolated, and it seems base SwiftUI components also have their inits defined as nonisolated (e.g. TimelineView, LazyHStack, etc), which makes sense. How do you achieve marking a SwiftUI View's init as nonisolated when it uses environment variables, without producing the following build error "Main actor-isolated default value of 'self.openURL' cannot be used in a nonisolated initalizer" ? It seems @State variable defined in a view has the ability to be set in a nonisolated init but not @Environment. What mechanism prevents this under the hood ?

I have a NavigationStack where every child view except the root has a trailing close button. On each child view transition, the button re-renders itself. Is there a way to fix the button? I saw in the Apple Developer app the behavior I want when registering a lab and the confirmation screen, but I think the implementation is just changing the center content of the view and it isn't pushing a new view to the stack path that has different toolbar items. Root: VStack { Content Next button --> Page 2 } Cancel button leading edge Page 2: VStack { Copy Next button --> page 3 } built in back button leading edge cancel button trailing edge Page 3: VStack { Copy Finish button --> dismisses whole workflow } built in back button leading edge cancel button trailing edge So on page 3, the cancel button is new. I can't figure out how to not have the glass effect animate it in new. I want the 'same' cancel button to be there. This is an oversimplification of a resumable form where the user can cancel (save and resume) at any time. Is there a built in way to have the trailing edge button be fixed? Would moving where the button is defined make a different and expose a way for each child view to propagate upwards if the cancel button should be shown or not? Updated with sample, assumes iOS 18 + 26 code so using .topTrailing not new 'action' placement: import SwiftUI struct Demo: View { @State private var path: [String] = [] var body: some View { NavigationStack(path: $path) { Button("Go") { path.append("Second") } .navigationDestination(for: String.self) { destination in switch destination { case "Second": VStack { Text("Second") Button("Next") { path.append("Third") } } .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Close", role: .cancel) { path = [] } } } case "Third": VStack { Text("Third") Button("Finish") { path = [] } } .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Close", role: .cancel) { path = [] } } } default: Text("Undefined") } } } } }

Just like NSScrollView lets us programmatically set the contentInset in parallel to automaticallyAdjustsContentInsets, I think there should be similar functionality for blurring effect caused by scroll edge effect. I should be able programmatically set it. If the user is manually setting the contentInset then they can simply set a boolean, which when enabled will show edge effect when the scroll document goes outside the area of inset. Eg: scrollView.contentInsets = NSEdgeInsets(top: 100, left: 0, bottom: 0, right: 0) For contentInset like above set by user, they could set edge effect in two ways Automatically: scrollView.enableEdgeEffectOutsideInsets = true // This will apply edge effect based on frame size of contentInsets Programmatically: scrollView.edgeInsetEffectFrame = NSRect...

In my app I have a sheet that has relatively small content inside. I’d like to fit the height of the sheet to the content of it. As I of course also want to support large type and don’t know how text will break to new lines, I can’t simply set a fixed pixel height. Currently I’m using this trick I saw in some blog post to get it to work. This is the view I’m presenting inside my .sheet: struct SheetContentView: View { @State private var contentHeight: CGFloat = .zero var body: some View { VStack { Text("Foo") Text("Bar") // … } .background( // Required for proper calculation of content height GeometryReader { geo in Color.clear .onChange(of: geo.size.height, initial: true) { _, newValue in contentHeight = newValue } } ) .presentationDetents([.height(contentHeight)]) } } Is this a valid way to do it? What are the best practices to handle this properly or is there even a native way to do this?

My app displays vertically scrollable text to the user which could be as short as a single screen or as long as a book chapter: imagine something like an e-book reader which uses scrolling rather than page-turning. A long time ago when development first started, I tried using UITextView, but the size of text that could be handled was quite limited (a figure of 32767 points seems to stick in the memory). Accordingly I came up with a custom solution in which a UIScrollView handled scrolling gestures and a custom UIView rendered just the part of the text that was visible at that time. That works, but it becomes cumbersome to add support for features such as selection handles and loupes. 18 years later, is there a more smoothly integrated way of displaying long scrollable text?

I've got a note editor view in my app that's built around a UITextView. At the top of the text view, it displays some metadata about the note, like location of the note (it's an e-reader app - think highlighting text and adding a note to it). I want this metadata to be able to scroll out of view if you scroll down in the text view. But it shouldn't simply be text in the text view - it's a UIView that takes the full width of the text view, with some UILabels in it. The height is on the order of 60 points tall. What's the best way to achieve this? Should the view that contains the labels be in a text attachment? Or should it be a subview of the UITextView? Or should I do something custom like make it a subview of the view that contains the UITextView and watch the UITextView's scroll position and apply a transform to move it to match?

I noticed that on iOS when I tap an already selected List row it calls the selection binding setter again. This is suprising to me because the selection value hasn't changed and results in duplicating unnecessary work to transform the data. Is this behaviour normal or should I report it as a bug? I noticed it when using custom Binding for the selection, i.e. where I implement the get and set closures myself. Thanks!

I have been pleased to see SwiftUI’s List performance improve over the years. However, when using a List that contains DisclosureGroup views, expanding and collapsing items becomes significantly slower as the amount of data grows. In my case, I need to control the initial expanded/collapsed state of each disclosure item, so I cannot use the recursive List(_:children:) API. Is there a recommended way to improve the performance of a List containing DisclosureGroup views, or is falling back to AppKit’s NSOutlineView currently the only practical solution? (Yes, for context, my app is for macOS.) The following code shows the relevant portion of my implementation: List(self.summary.files, selection: $selection) { file in DisclosureGroup(isExpanded: $expandedFileURLs.contains(file.id)) { ForEach(file.matches) { match in FolderFindMatchView(match: match) .tag(FolderFind.ResultID.match(fileID: file.id, matchID: match.id)) } } label: { FolderFindFileResultView(file: file) .draggable(item: FolderFindDraggedFile(id: .file(file.id), fileURL: file.fileURL)) } .listRowSeparator(.hidden) .tag(FolderFind.ResultID.file(file.id)) }

Since updating to iPadOS 26.3 and Xcode 26.3, I’ve observed that my testplan suites, that formerly ran 30+ hours and ended with 100% test execution, terminate early at 12-15 hours with an error that suggests an OS-related anomaly is blocking continuation of the test suite. The error in the console is " Wait for accessibility to load" and then a "failure to load accessibility". My tests use the XCUItest framework and accessibility tags to interact with screen elements on the tethered ipad. This never happened on ipadOS 26.2 and earlier. I'm curious if others have seen this behavior and when Apple will get this fixed.

Hey Team, In the Finder, the segmented control in the toolbar where the user can choose to display the files as icons, list, columns, or gallery, indicates its selection using a gray background. Is that done via custom drawing or is it a semantic option in AppKit? When I adopt Liquid Glass in my app by removing UIDesignRequiresCompatibility, my segmented control indicates the selections with a strong accent color. This could be distracting to my users and I'd like to duplicate the Finder behavior. Thanks, Ari