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

With iOS 27's automatic resizability for iPhone apps on iPad and in iPhone Mirroring, what's the recommended pattern for views that need genuinely different layouts at different size classes — is ViewThatFits the intended tool, or should we still branch on size class for larger structural changes? — Divya Ravi, Senior iOS Engineer

I made a few attempts to implement a similar label but I'm not sure if it's possible using public APIs. Could you give any tips about how to approach implementing this? Thank you!

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 have a List that's embedded in an NSHostingView with an @Observable data connecting the two worlds. I can select an item in the list with the mouse and use arrow keys to change the selection and it is updated properly on the AppKit side. However, when I change the selection from the AppKit side, the selection disappears in the List, even though an .onChange does get triggered with the right new selection ID. But the UI no longer displays it. I created a simple NSHostView example and that works. But the same method does not work in a more complex layout where the view is much deeper in the hierarchy. Something is happening because the List loses its last selection highlight. What's the best approach to tracking down why the List UI is not updating the selection? I am trying to avoid going back to using NSTableView and doing it all manually, but I really need to selection to be able to change. Thank you.

The inspector attached to the multi-column Split View, does not display its navigation elements on iOS 26. How to fix it?

If I want to implement the "view style" pattern that various SwiftUI components have (like ButtonStyle for Button and PickerStyle for Picker, to name a few) for my own custom components, is there any guidance on how to do that? Specifically, is there a way to do that without having to resort to using AnyView? My attempts to implement this have been fine with retaining type information using some View and generics, up until the point I need to create an interface for specifying a view style to use and propagating that down to the component that I'm styling. Using the SwiftUI environment seems like the natural way to do this propagation, but I seem to run afoul of the type system when trying to use it. If we take ButtonStyle from SwiftUI as an example of the general structure of this pattern, we're talking about having a protocol with an associated Body type, and a corresponding makeBody function that does the actual styling of the component and returns a Body instance. Because of the associated types in this protocol, I'm unsure how to put an instance of something that conforms to the protocol into the environment for propagation. I end up having to create a "sibling" type of sorts that more or less does the same thing as my protocol, but works with AnyView so I can have concrete types to use with the environment and pass around to my view. This doesn't seem ideal because of the use of AnyView and some of the downsides that come with that. I've included a simplified version of this at the end of this post to showcase roughly what I'm doing now that is working, but it feels like there should be some better way to achieve this without needing to reach for AnyView. Is there something that I'm not aware of with Swift or SwiftUI that would let me ditch it, or is this the best way to achieve this right now without improvements to SwiftUI to better support this? protocol MyViewStyle { associatedtype Body: View func makeBody(text: String) -> Body } struct TextMyViewStyle: MyViewStyle { func makeBody(text: String) -> some View { return Text(text) } } struct AnyMyViewStyle { let _makeBody: (String) -> AnyView init<Style: MyViewStyle>(_ style: Style) { self._makeBody = { text in AnyView(style.makeBody(text: text)) } } func makeBody(text: String) -> AnyView { _makeBody(text) } } extension EnvironmentValues { @Entry var myViewStyle: AnyMyViewStyle = AnyMyViewStyle(TextMyViewStyle()) } struct MyView: View { @Environment(\.myViewStyle) private var style let text: String var body: some View { style.makeBody(text: text) } }

At WWDC22, it was stated that TextKit 2 did not support tables and printing and possibly other attributes and NSTextView would revert back to TextKit 1. At what point can we be sure that TextKit 2 supports everything TextKit 1 did and NSTextView will no longer revert back. My app makes use of a subclass of NSTextView and custom layoutManager and migrating to support both versions seems incredibly complex. Thank you.

Hello, What is the solution to this problem, assuming that you are not supposed to use AnyView, which I hear over and over again? Given this protocol: protocol MyProtocol { associatedtype V: View var content: () -> V { get } } if I want to store a heterogenous collection of MyProtocol, let collection: [any MyProtocol], then the underlying V type of each is erased to any View, which (supposedly) does not conform to View. Is there no way to "unbox" the existential any View to get the underlying View back? That unboxing idea is something I heard in a few WWDC videos but it seems like it does not apply to View.

When appending additional UIAction children to the horizontal edit menu UIMenu returned in the delegate method func textView(_ textView: UITextView, editMenuForTextIn range: NSRange, suggestedActions: [UIMenuElement]) -> UIMenu? If the menu is long enough to need an overflow chevron vertical menu (introduced in iOS 26) my UIAction only show either a title or an image not both, is UIAction the right UIMenuElement type to supply here? How to get both the title and the image to appear in the overflow vertical menu?

I’m developing a text editor. In the main pane of a window managed by NSSplitViewController, I place an NSTextView enclosed in an NSScrollView alongside a custom NSView subclass that displays line numbers. The issue is that the line number view sits outside the scroll view, so it does not participate in the visual effects applied by the title bar or by an NSSplitViewItemAccessoryViewController attached to the parent view controller. This problem has existed since around macOS 26, but it appears to be more noticeable in macOS 27 Beta 1. Due to various implementation requirements, my line number view cannot be implemented as a subclass of NSRulerView. In this situation, is there any supported way to ensure that accessory view and toolbar effects are also properly applied to views that are outside the scroll view? The attached screenshot demonstrates a case where the edge effect is not applied correctly. The line number view on the left side does not participate in the effect and instead appears to visually break through it.

Hey Team, System-provided quick actions in Finder sport a template image that adapts correctly to light and dark modes. However when I add a quick action extension in my app, the icon I refer to in the Info.plist renders in full color, even if it is defined in the asset catalog as a template image. This forces me to either use my app icon or a gray icon that will work in either appearance. How can I get the system-provided quick actions treatment? Thanks, Ari

For developing an iOS fully-featured code editor (i.e line numbers + color pass for syntax highlighting + collapsible sections + debug markers/highlights) what would be the best strategy for iOS 27? UITextView with new viewport control delegate Custom TextKit2 UIView Custom TextKit1 UIView (this was the recommendation I got as of WWDC25)

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?

Is it possible to remove the ugly sidebar and inspector chrome with AppKit? I don't care if it's a hack or a swizzle or something, but I need to get rid of this. I want to convert this: Into this (photoshopped): Thanks for your help!

Is this the right way to pass data to a sheet for editing? struct Detail: View { ... // The single atomic source of truth for our sheet presentation @State var editorConfig: EditorConfig? // Completely encapsulated local configuration package struct EditorConfig: Identifiable { var id: PersistentIdentifier { item.persistentModelID } let context: ModelContext let item: Item } var body: some View { ... Button("Edit") { // 1. Spin up a separate scratchpad container layer let context = ModelContext(modelContext.container) context.autosaveEnabled = false // 2. Safely resolve our model inside the new isolated playground if let sandboxItem = context.model(for: item.persistentModelID) as? Item { // 3. Package it up to trigger the sheet presentation editorConfig = EditorConfig(context: context, item: sandboxItem) } } } } // 4. SwiftUI tracks value replacement accurately without ghost state bugs .sheet(item: $editorConfig) { config in // Inject the isolated context into the sheet's environment chain EditorView(item: config.item) .environment(\.modelContext, config.context) } } }

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?

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.

I am giving the user a view onto a selection of database records. There could be a handful of these, there could be 10,000 of them. At present I use a UITableView. Cells are therefore created or recycled on demand. When a cell is created, it is displayed with default "empty" contents and it sends a message to the server to request a record. When the record arrives, the cell is then able to change its own contents so that the record appears on the screen. There are of course various optimisations, such as cancelling a request if the cell goes offscreen before a reply is received; or delaying a request if it looks as if the cell will end up being off the screen once scrolling has stopped. All this happens with fixed-height cells. Accordingly the UITableView has all the data it needs to work out where every one of the 10,000 cells is. I now want to extend this to variable-height cells. That is: cells whose height depends on the content received from the database. Accordingly, when a cell receives its data it may find itself having to change its own size. Is this structure practicable with UITableView?