At WWDC25 we launched a new type of Lab event for the developer community - Group Labs. A Group Lab is a panel Q&A designed for a large audience of developers. Group Labs are a unique opportunity for the community to submit questions directly to a panel of Apple engineers and designers. Here are the highlights from the WWDC25 Group Lab for UI Frameworks. How would you recommend developers start adopting the new design? Start by focusing on the foundational structural elements of your application, working from the "top down" or "bottom up" based on your application's hierarchy. These structural changes, like edge-to-edge content and updated navigation and controls, often require corresponding code modifications. As a first step, recompile your application with the new SDK to see what updates are automatically applied, especially if you've been using standard controls. Then, carefully analyze where the new design elements can be applied to your UI, paying particular attention to custom controls or UI that could benefit from a refresh. Address the large structural items first then focus on smaller details is recommended. Will we need to migrate our UI code to Swift and SwiftUI to adopt the new design? No, you will not need to migrate your UI code to Swift and SwiftUI to adopt the new design. The UI frameworks fully support the new design, allowing you to migrate your app with as little effort as possible, especially if you've been using standard controls. The goal is to make it easy to adopt the new design, regardless of your current UI framework, to achieve a cohesive look across the operating system. What was the reason for choosing Liquid Glass over frosted glass, as used in visionOS? The choice of Liquid Glass was driven by the desire to bring content to life. The see-through nature of Liquid Glass enhances this effect. The appearance of Liquid Glass adapts based on its size; larger glass elements look more frosted, which aligns with the design of visionOS, where everything feels larger and benefits from the frosted look. What are best practices for apps that use customized navigation bars? The new design emphasizes behavior and transitions as much as static appearance. Consider whether you truly need a custom navigation bar, or if the system-provided controls can meet your needs. Explore new APIs for subtitles and custom views in navigation bars, designed to support common use cases. If you still require a custom solution, ensure you're respecting safe areas using APIs like SwiftUI's safeAreaInset. When working with Liquid Glass, group related buttons in shared containers to maintain design consistency. Finally, mark glass containers as interactive. For branding, instead of coloring the navigation bar directly, consider incorporating branding colors into the content area behind the Liquid Glass controls. This creates a dynamic effect where the color is visible through the glass and moves with the content as the user scrolls. I want to know why new UI Framework APIs aren’t backward compatible, specifically in SwiftUI? It leads to code with lots of if-else statements. Existing APIs have been updated to work with the new design where possible, ensuring that apps using those APIs will adopt the new design and function on both older and newer operating systems. However, new APIs often depend on deep integration across the framework and graphics stack, making backward compatibility impractical. When using these new APIs, it's important to consider how they fit within the context of the latest OS. The use of if-else statements allows you to maintain compatibility with older systems while taking full advantage of the new APIs and design features on newer systems. If you are using new APIs, it likely means you are implementing something very specific to the new design language. Using conditional code allows you to intentionally create different code paths for the new design versus older operating systems. Prefer to use if #available where appropriate to intentionally adopt new design elements. Are there any Liquid Glass materials in iOS or macOS that are only available as part of dedicated components? Or are all those materials available through new UIKit and AppKit views? Yes, some variations of the Liquid Glass material are exclusively available through dedicated components like sliders, segmented controls, and tab bars. However, the "regular" and "clear" glass materials should satisfy most application requirements. If you encounter situations where these options are insufficient, please file feedback. If I were to create an app today, how should I design it to make it future proof using Liquid Glass? The best approach to future-proof your app is to utilize standard system controls and design your UI to align with the standard system look and feel. Using the framework-provided declarative API generally leads to easier adoption of future design changes, as you're expressing intent rather than specifying pixel-perfect visuals. Pay close attention to the design sessions offered this year, which cover the design motivation behind the Liquid Glass material and best practices for its use. Is it possible to implement your own sidebar on macOS without NSSplitViewController, but still provide the Liquid Glass appearance? While technically possible to create a custom sidebar that approximates the Liquid Glass appearance without using NSSplitViewController, it is not recommended. The system implementation of the sidebar involves significant unseen complexity, including interlayering with scroll edge effects and fullscreen behaviors. NSSplitViewController provides the necessary level of abstraction for the framework to handle these details correctly. Regarding the SceneDelagate and scene based life-cycle, I would like to confirm that AppDelegate is not going away. Also if the above is a correct understanding, is there any advice as to what should, and should not, be moved to the SceneDelegate? UIApplicationDelegate is not going away and still serves a purpose for application-level interactions with the system and managing scenes at a higher level. Move code related to your app's scene or UI into the UISceneDelegate. Remember that adopting scenes doesn't necessarily mean supporting multiple scenes; an app can be scene-based but still support only one scene. Refer to the tech note Migrating to the UIKit scene-based life cycle and the Make your UIKit app more flexible WWDC25 session for more information.

When developing a custom keyboard on iOS, even after enabling Full Access (RequestsOpenAccess = true), it is still not possible to record audio — the recording simply does not start. This is despite the fact that: the user is explicitly warned the user provides informed consent by enabling Full Access According to Apple’s documentation: https://developer.apple.com/documentation/uikit/configuring-open-access-for-a-custom-keyboard “However, with RequestsOpenAccess set to true, the keyboard has all the capabilities in the preceding list.” At the same time, the preceding list includes: “No access to microphone and speaker” This creates ambiguity. The wording suggests that enabling Full Access should lift prior restrictions, yet in practice, microphone access remains unavailable to third-party keyboards. Why this is concerning With Full Access enabled, a keyboard already has: network access the ability to transmit user input From a privacy standpoint, this is already highly sensitive. Preventing microphone access while allowing these capabilities appears inconsistent. Meanwhile, Apple’s own system keyboard supports voice dictation, which creates a functional gap between first-party and third-party keyboards. Competition perspective This raises a broader question about equal access to platform capabilities. Restricting third-party keyboards from using the microphone — while first-party solutions can — may be seen as: unequal treatment of developers a limitation of competition in input methods Such differences are increasingly scrutinized under EU regulations like the Digital Markets Act and Article 102 TFEU, which emphasize fair access to platform features and prohibit self-preferencing by dominant platforms. Request for clarification Is microphone access intentionally restricted for all third-party keyboards, even with Full Access enabled? If so, what is the technical or policy justification? Are there plans to provide a secure and user-consented way to enable audio input for custom keyboards? Clarification on this would help developers better understand platform limitations and design decisions.

I published the latest update of my AppKit app in September with macOS 26.0. I just wanted to create a new update, but compiling on macOS 26.4 now fails because of the symbol NSTextAttachment.character which is referenced in my code. The error is Type 'NSTextAttachment' has no member 'character' I've never experienced before that a symbol suddenly is not available anymore without even a deprecation notice from one OS release to the next, let alone a minor release. Is this a bug in macOS or Xcode, or should I start worrying about symbols becoming unavailable anytime?

I have the following view hierarchy in my app: [UINavigationController] -> [MainViewController] -> [MyTabBarController] -> [DashboardViewController] In my MainViewController I have a button that pushes the MyTabBarController onto the navigation controllers stack. In the tab bar controller I only have one tab in this example showing the DashboardViewController. That all works fine, and when I tap the back button on MyTabBarController, everything works fine and the MainViewController is shown again. The UI works exactly how I want it, but when I load up the 'Debug Memory Graph' view, I can see that my DashboardViewController is still in memory and it seems the UITab has a reference to it. The MyTabBarController is NOT in memory anymore. MyTabBarController is very simple: class MyTabBarController: UITabBarController { override func viewDidLoad() { super.viewDidLoad() self.mode = .tabSidebar var allTabs:[UITab] = [] let mainTab = UITab(title: "Dashboard", image: UIImage(systemName: "chart.pie"), identifier: "dashboard", viewControllerProvider: { _ in return UINavigationController(rootViewController: DashboardViewController()) }) allTabs.append(mainTab) setTabs(allTabs, animated: false) } } And the DashboardViewController is empty: class DashboardViewController: UIViewController { } The only reason I created as a seperate class in this example is so I can easily see if it's visible in the memory debug view. I have uploaded the simple sample app to GitHub: https://github.com/fwaddle/TabbarMemoryLeakCheck Anyone have any suggestions? Here is a screen grab of the memory debug view showing the UITab having a reference to the DashboardViewController even though MyTabBarController has been dealloc'd:

MyOwnKeyboard Pad app has 4 text views with textfields that use touch screen for editing. There is one view, Compose, that has a textfield and a textview (UIRepresentable). The app enters text into the view using textfield buttons. The app has total control of editing. When entering text if the screen is touched it conflicts the cursor position and creates an "out of bounds" failure. In that view the app does not need any touch events. I need a method in UIRepresentable to disable the touch event. I am not familiar with UIRepresentable as this code was provided by Apple to solve a 16 bit unicode character issue. What would be the code to disable touch events in the UIRepresentable compose view. The app is free for a while until this problem is fixed. It is for iPads 11"+ . The name in the app store is MyOwnKeyboard Pad. I know some great engineer will find the answer. DTS tried. Thanks to all, maybe I'll sell some. Charlie 25mar26

My app uses TextKit 1 and unfortunately still cannot migrate to TextKit 2 because of some bugs (for instance in FB17103305 I show how NSTextView.shouldDrawInsertionPoint has no effect, but I opened that feedback exactly one year ago and it still has no answer). Unfortunately TextKit 1 has another bug which causes the text cursor to jump unpredictably up or down when pressing the arrow keys and setting UITextView.typingAttributes. Run the code below on iPhone 17 Pro Max Simulator. Scroll the text down until you see “Header 2”. Place the text cursor after “# “. Press the arrow down key twice to move the cursor two lines down. The cursor moves to the top of the view instead. Continuing to press the arrow keys up and down results in the cursor sometimes moving as expected, other times jumping around wildly. Does anyone know a workaround? I created FB22382453. class TextView: UITextView, UITextViewDelegate { override func awakeFromNib() { let _ = layoutManager delegate = self let header = textAttributes(fontSize: 30) let body = textAttributes(fontSize: 15) let string = NSMutableAttributedString(string: String(repeating: "a", count: 2681) + "\n", attributes: body) string.append(NSAttributedString(string: """ # Header 1 """, attributes: header)) string.append(NSMutableAttributedString(string: String(repeating: "a", count: 5198) + "\n", attributes: body)) string.append(NSAttributedString(string: """ # Header 2 """, attributes: header)) string.append(NSMutableAttributedString(string: String(repeating: "a", count: 7048) + "\n", attributes: body)) textStorage.setAttributedString(string) } func textViewDidChangeSelection(_ textView: UITextView) { typingAttributes = textStorage.attributes(at: selectedRange.location - 1, effectiveRange: nil) } private func textAttributes(fontSize: Double) -> [NSAttributedString.Key: Any] { var textAttributes = [NSAttributedString.Key: Any]() textAttributes[.font] = UIFont(name: "Courier", size: fontSize) let paragraphStyle = NSMutableParagraphStyle() paragraphStyle.minimumLineHeight = round(fontSize * 1.3) paragraphStyle.maximumLineHeight = paragraphStyle.minimumLineHeight textAttributes[.paragraphStyle] = paragraphStyle return textAttributes } }

Hi everyone, I am experiencing a strange rendering issue on iPadOS 26 when sizeRestrictions.minimumSize is set on a UIWindowScene. After rotating the device and then rotating it back to the original orientation, the window appears to be stretched based on its previous dimensions. This resulting "stretched" area does not resize or redraw correctly, leaving a significant black region on the screen. Interestingly, as soon as I interact with the window (e.g., a slight drag or touch), the UI snaps back to its intended state and redraws perfectly. Here is a sample code and capture of behavior. class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let windowScene = (scene as? UIWindowScene) else { return } windowScene.sizeRestrictions?.minimumSize = CGSize( width: 390, height: 844 // larger than the height of iPad in landscape ) // initialize... } } Has anyone else encountered this behavior? If so, are there any known workarounds to force a layout refresh or prevent this "ghost" black area during the rotation transition? Any insights would be greatly appreciated. Thanks!

When using a ScrollView inside some sort of navigation (stack or split view), large navigation titles seem to get clipped to the width of the scroll content for some reason? Minimal example: struct ContentView: View { var body: some View { NavigationStack { ScrollView { Text("Scroll Content") } .navigationTitle("Navigation Title") } } } Results in: Is this a bug in the beta, or has something changed and now I’m doing things wrong?

Is it possible to build localization into console apps, developed in SwiftUI in Xcode26. I have created a catalog, (.xcstrings file) with an English and fr-CA string. I have tried to display the French text without success. I am using the console app to test a package which also has English/French text. English text works fine in both package and the console main, but I cannot generate the French. From what I can discover so far it's not possible without bundling it as a .app, (console app). Looking for anyone who has crossed this bridge.

My app doesn't respond on iPhone Air iOS 26.1. After startup, my app shows the main view with a tab bar controller containing 4 navigation controllers. However, when a second-level view controller is pushed onto any navigation controller, the UI freezes and becomes unresponsive. The iPhone simulator running iOS 26.1 exhibits the same problem. The debug profile shows CPU usage at 100%. However, other devices and simulators do not have this problem.

I'm building a document viewer on macOS Tahoe with a 3-column NSSplitViewController (sidebar | detail | inspector), trying to replicate how Preview displays PDFs with the page centered in the visible gap between the panels, with content bleeding under them when panning or zooming. I'm using the approach from Build an AppKit app with the new design (WWDC25): detailItem.automaticallyAdjustsSafeAreaInsets = true safeAreaInsets reports the correct values (e.g. left: 208, right: 240), and the frame does extend under both panels. But PDFView with autoScales = true anchors the page to the left edge of the window instead of centering it in the visible gap between the sidebar and inspector. I can get the page to center correctly by constraining PDFView to view.safeAreaLayoutGuide, but then content no longer extends under the panels when panning or zooming, which defeats the whole purpose. What's the correct way to center PDFView content within the visible gap while keeping the frame full-width so content bleeds under the panels? I've attached pictures of how Preview does it.

I'm running macOS 26.3 and using Xcode 26.4. I'm trying to create a SwiftUI Chart that can scroll horizontally. In the SwiftUI Preview, and also running the app on macOS, the chart displays a scrollbar, but the scrollbar does not respond to mouse interaction (dragging the scrollbar, or clicking in the gutters on either side of the scrollbar). Here's the sample code: import SwiftUI import Charts private struct DataPoint: Identifiable { let id: Int let x: Double let value: Double } struct ContentView: View { private let points: [DataPoint] = (0..<60).map { index in let wave = sin(Double(index) * 0.28) * 18 let trend = Double(index) * 0.35 return DataPoint(id: index, x: Double(index), value: 60 + wave + trend) } var body: some View { Chart(points) { point in BarMark( x: .value("Data Point", point.x), y: .value("Value", point.value) ) .foregroundStyle(.blue.gradient) } .chartScrollableAxes(.horizontal) // Doesn't work: // .scrollIndicators(.hidden) // .never also does not work .chartXVisibleDomain(length: 20) .padding() } } #Preview { ContentView() }

I'm triaging the issue with the fast scrolling on UIScrollView and I'm really upset how little to no info this component is on the internet. Like i disabled scrolling and yet after holding the dpad down to scroll downward eventually the fast scroll mechanism is used. The issue I have is that I have a setup where the scrollview scrolling is disabled and whenever cells are focused it'll scroll to the cell's position for that cells to focused on top left side of the scrollview. I start off with the cell placed at position x of 1000. I scroll down enough to enable fast scrolling. While fast scrolling vertically, i press left a couple of time and it somewhat scroll horizontally. Actual scrollView index is suddenly placed to x:0 instead of let say x:950-1000 Expected should be scrolled to the left of cell at position x 1000. Attached the stack trace and the log showcasing it and run it on simulator tvos 26.2. Initial properties of the scrollview we set up scroll = [UIScrollView new]; scroll.contentInsetAdjustmentBehavior = UIScrollViewContentInsetAdjustmentNever; scroll.automaticallyAdjustsScrollIndicatorInsets = false; [scroll setDirectionalLockEnabled:TRUE]; [scroll setContentInset:UIEdgeInsetsMake(0, 0, 0, 0)]; scroll.bounces = FALSE; scroll.delaysContentTouches = FALSE; scroll.showsVerticalScrollIndicator = FALSE; scroll.showsHorizontalScrollIndicator = FALSE; The plan for me at least is to somehow disable the horizontal scrolling interaction of it when fast scrolling is enabled, without accessing the private components of it.

NavigationLink selection in DisclosureGroup not working with .draggable modifier This was recently also posted here: https://stackoverflow.com/questions/79914290/ I am playing around with a tree data structure with folders and entries.I would like to add dragging of entries and folders between folders, using .draggable and dropDestination. In my current code, dragging works, but selection of entries no longer works, except if I click outside of the Text If I comment out .draggable(subfolder.name) in func FolderRow(), selection works as expected. How can I make sure both selection and drag and drop works for both folders and entries? I also tried using Transferable and Codable, but I get the same result. Here is an MRE: import SwiftData import SwiftUI @Model final class Folder { @Attribute(.unique) var name: String // Parent var parentFolder: Folder? // Child folders @Relationship(deleteRule: .cascade, inverse: \Folder.parentFolder) var subfolders: [Folder] = [] // Leaf entries @Relationship(deleteRule: .cascade, inverse: \Entry.folder) var entries: [Entry] = [] init(name: String, parentFolder: Folder? = nil) { self.name = name self.parentFolder = parentFolder } } @Model final class Entry { @Attribute(.unique) var name: String var detail: String var folder: Folder? // recursive relationship init(name: String, detail: String) { self.name = name self.detail = detail } } @main struct TestMacApp: App { var body: some Scene { WindowGroup { SidebarView() .modelContainer(for: Folder.self) } } } struct SidebarView: View { @Environment(\.modelContext) private var context @Query(filter: #Predicate<Folder> { $0.parentFolder == nil }) private var rootFolders: [Folder] var body: some View { NavigationSplitView { List { ForEach(rootFolders) { folder in FolderRow(folder: folder) .draggable(folder.name) } } } detail: { Text("detail") } .onAppear { seed() } } } struct FolderRow: View { @Environment(\.modelContext) private var context var folder: Folder @State private var isExpanded: Bool = true var body: some View { DisclosureGroup(isExpanded: $isExpanded) { // Subfolders ForEach(folder.subfolders) { subfolder in FolderRow(folder: subfolder) .draggable(subfolder.name) // disabling this line fixes the selection } // Entries (leaf nodes) ForEach(folder.entries) { entry in NavigationLink(destination: EntryDetail(entry: entry)) { EntryRow(entry: entry) } .draggable(entry.name) } } label: { Label(folder.name, systemImage: "folder") } .dropDestination(for: String.self) { names, _ in return handleDrop(of: names) } } } struct EntryRow: View { var entry: Entry var body: some View { Text(entry.name) } } struct EntryDetail: View { var entry: Entry var body: some View { Text(entry.detail) } } extension FolderRow { private func handleDrop(of names: [String]) -> Bool { do { for name in names { if let droppedEntry = try context.fetchFilteredModel(filter: #Predicate<Entry> { x in x.name == name }) { droppedEntry.folder = folder print("dropped \(droppedEntry.name) on \(folder.name)") } else if let droppedFolder = try context.fetchFilteredModel(filter: #Predicate<Folder> { x in x.name == name }) { if droppedFolder.parentFolder != nil && droppedFolder != folder { droppedFolder.parentFolder = folder print("dropped \(droppedFolder.name) on \(folder.name)") } } } return true } catch { debugPrint(error.localizedDescription) return false } } } extension SidebarView { private func seed() { do { // delete current models for folder: Folder in try context.fetchAllModels() { context.delete(folder) } try context.save() let rootFolder = Folder(name: "Root") let entry1 = Entry(name: "One", detail: "Detail One") let entry2 = Entry(name: "Two", detail: "Detail Two") rootFolder.entries.append(contentsOf: [entry1, entry2]) let subFolder1 = Folder(name: "Sub1", parentFolder: rootFolder) let entry3 = Entry(name: "Three", detail: "Detail Three") let entry4 = Entry(name: "Four", detail: "Detail Four") subFolder1.entries.append(contentsOf: [entry3, entry4]) let subFolder2 = Folder(name: "Sub2", parentFolder: rootFolder) let entry5 = Entry(name: "Five", detail: "Detail Five") let entry6 = Entry(name: "Six", detail: "Detail Six") subFolder2.entries.append(contentsOf: [entry5, entry6]) context.insert(rootFolder) } catch { debugPrint(error) } } } extension ModelContext { // convenience methods func fetchAllModels<M>() throws -> [M] where M: PersistentModel { let fetchDescriptor = FetchDescriptor<M>() return try fetch(fetchDescriptor) } func fetchFilteredModels<M>(filter: Predicate<M>) throws -> [M] where M: PersistentModel { let fetchDescriptor = FetchDescriptor<M>(predicate: filter) return try fetch(fetchDescriptor) } func fetchFilteredModel<M>(filter: Predicate<M>) throws -> M? where M: PersistentModel { return try fetchFilteredModels(filter: filter).first } }

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!

I got this debuglog in Xcode26. "UIScene lifecycle will soon be required. Failure to adopt will result in an assert in the future." I haven't included any UIScene lifecycle code. I read the article on TN3187: Migrating to the UIKit scene-based life cycle. Does this mean that when iOS27 iPhone is released, the app will crash after startup? If Xcode26/iOS27 crashes, is there a quick fix I can use?

The following is verbatim of a feedback report (FB22367951) I submitted, shared here as someone else might be interested to see it. I have reproduced this bug on iPadOS 26.3.1 (a) and 26.4. During scene resizing on iPad, UIPageViewController's setViewControllers method fails to do its work. The navigation starts and for a brief moment you can see the new view controller coming from the expected direction, but shortly after it fails and stays on the same [current] view controller. It doesn't even call the completion handler when it fails. When the navigation succeeds (due to not resizing a scene during the navigation) after previously failing at least once, the completion handler is sometimes called more than once. I have created a demo project, which I have pushed to this repo: https://github.com/galijot/SceneResize-Breaks-UIPageViewController I have also attached a zip of the project to this report.

Hi, Overview I have a Mac app with a settings window. When I add a button it is added to the center. I want it on the trailing edge, I even tried adding it as confirmationAction but doesn’t work. Screenshot Feedback FB21374186 Steps to reproduce Run the project on mac Open the app's settings by pressing ⌘ , Notice that the Save button is in the center instead of the trailing edge Code App import SwiftUI @main struct SettingsToolbarButtonBugApp: App { var body: some Scene { WindowGroup { ContentView() } Settings { SettingsView() .frame(width: 300, height: 400) } } } SettingsView import SwiftUI struct SettingsView: View { var body: some View { NavigationStack { Form { Text("Settings window") } .toolbar { ToolbarItem(placement: .confirmationAction) { // Save button is the center instead of trailing edge Button("Save") {} } } .navigationTitle("Settings") } } }

Our app uses a UIView backed by a CATiledLayer that is embedded in a UIScrollView, to represent a large document viewer. (PDF data, actually.) It needs to be big - far too big to allocate a single layer, and it needs to be able to reveal more detail as you zoom in. This is the exact use case for a CATiledLayer. CATiledLayer does its drawing on a background thread, as you know, and we've always taken care to make our draw method thread-safe. It has worked great for us, for over a decade now. However, starting with iOS 26, we've been having some surprising crashes. It looks like our CATiledLayer (I think?) is trying to trigger a layout on the background thread as well. This is frustrating because it doesn't have any subviews or sublayers - there's no reason for it. I'm suspecting the CATiledLayer because it does its drawing on a thread, so maybe it would also do other things there, but honestly, I'm not sure - it's hard to tell. Here's the crash. Normally with a crash like this, the solution is to bounce your layout call out to the main thread, but in our case, I'm not the one calling the layout function. The system (Core Animation) is doing it, and I can't figure out what I might be doing that is triggering it. Everything I am doing is on the main thread, and there's none of my code in this stack trace. It's possible this may have something to do with the SwiftUI hosting view, as well? There's definitely one of those involved here - our custom PDF viewer is embedded in one. (That's another reason to suspect the CATiledLayer - whatever is crashing here is in a SwiftUI hosting view, and the PDF viewer is just about the only UIKit on the screen, here, embedded in a hosting view.) I also have a test app that is pure UIKit, where I have not been able to reproduce the crash. I've tried subclassing CATiledLayer and having an empty implementation of updateSublayers, and some other, similar hacks along those lines, but nothing I do seems to help. I'm tempted to try moving from CATiledLayer to simple UIViews, and tiling those myself, but that's a lot of work. I want to be sure there's not some other solution before I try something like that. Is CATiledLayer still a supported mechanism or should I be moving away from it? If it is something entirely different that is crashing here, I don't want to do a bunch of rework of the PDF viewer only to end up with the same results. It really smells like a UIKit bug to me, or at least UIKit making some concurrency assumptions that CATiledLayer is breaking. But all I can really do is guess. *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread.' *** First throw call stack: ( 0 CoreFoundation 0x00000001804f7348 __exceptionPreprocess + 172 1 libobjc.A.dylib 0x000000018009c094 objc_exception_throw + 72 2 CoreAutoLayout 0x000000022d3cc13c __36-[NSISEngine rebuildFromConstraints]_block_invoke + 0 3 CoreAutoLayout 0x000000022d3cbee0 -[NSISEngine _optimizeWithoutRebuilding] + 68 4 CoreAutoLayout 0x000000022d3cbe14 -[NSISEngine optimize] + 92 5 CoreAutoLayout 0x000000022d3c8744 -[NSISEngine performPendingChangeNotifications] + 100 6 UIKitCore 0x00000001869c7e7c -[UIView(Hierarchy) layoutSubviews] + 132 7 SwiftUI 0x00000001ddb40318 $s7SwiftUI14_UIHostingViewC14layoutSubviewsyyF + 68 8 SwiftUI 0x00000001ddb40358 $s7SwiftUI14_UIHostingViewC14layoutSubviewsyyFTo + 32 9 UIKitCore 0x0000000185642d34 block_destroy_helper.13 + 10136 10 UIKitCore 0x00000001856430c8 block_destroy_helper.13 + 11052 11 UIKitCore 0x00000001869d6ff4 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2656 12 QuartzCore 0x000000018c8fd194 _ZN2CA5Layer15perform_update_EPS0_P7CALayerjNS_17LayerUpdateReasonEPNS_11TransactionE + 452 13 QuartzCore 0x000000018c8fc9e4 _ZN2CA5Layer17update_if_needed_EPNS_11TransactionENS_17LayerUpdateReasonE + 600 14 QuartzCore 0x000000018c908674 _ZN2CA5Layer28layout_and_display_if_neededEPNS_11TransactionE + 152 15 QuartzCore 0x000000018c81d914 _ZN2CA7Context18commit_transactionEPNS_11TransactionEdPd + 544 16 QuartzCore 0x000000018c84da48 _ZN2CA11Transaction6commitEv + 636 17 QuartzCore 0x000000018c89ea8c _ZL21CAImageProviderThreadPjb + 1004 18 libdispatch.dylib 0x00000001033d59dc _dispatch_client_callout + 12 19 libdispatch.dylib 0x00000001033bf728 _dispatch_continuation_pop + 740 20 libdispatch.dylib 0x00000001033f3344 _dispatch_async_redirect_invoke + 700 21 libdispatch.dylib 0x00000001033cf470 _dispatch_root_queue_drain + 356 22 libdispatch.dylib 0x00000001033cffc4 _dispatch_worker_thread2 + 272 23 libsystem_pthread.dylib 0x0000000103276b50 _pthread_wqthread + 228 24 libsystem_pthread.dylib 0x000000010327598c start_wqthread + 8 ) libc++abi: terminating due to uncaught exception of type NSException

Anyone worked with MapKit's MapCameraPosition in SwiftUI? I'm building a navigation app and ran into a limitation I can't find a clean solution for when using .userLocation(followsHeading: true) MapKit takes full control of the camera, smooth heading tracking, follows the user automatically. Perfect. But there's no way to set a custom pitch (tilt) on it. The only initializer available is... .userLocation(followsHeading: true, fallback: .automatic) No pitch, no distance parameters.... The workaround I found is setting .camera(MapCamera(..., pitch: 60)) first, waiting 200ms, then switching to .userLocation(followsHeading: true), MapKit inherits the pitch from the rendered camera state before handing off to user tracking.... It works, but it's clearly exploiting an undocumented behaviour in MapKit's state machine rather than a proper API Has anyone found a cleaner way to achieve this? Or is UIViewRepresentable wrapping MKMapView the only proper solution? It would be awesome to have something like this cameraPosition = .userLocation( followsHeading: true, pitch: 60, distance: 800, fallback: .automatic )

A user of my app, whose main view is a split view, reported an issue which causes the left navigation bar items to disappear without apparent reason if they rotate the device and later show the detail view, preventing them from using the back button to show the root view again. Am I doing something wrong or is it a bug? I can reproduce the issue with the following steps: Create a new document-based iOS app (as it uses scenes by default, as opposed to a regular app). Paste the code below. In the target build settings, delete "Launch Screen Interface File Base Name" and set "Launch Screen (Generation)" to YES. Without this step, for some reason, the issue doesn't happen. Launch the app in iPhone Simulator. Tap the top left button to show the root view, then the “detail” button to show the detail view. The left navigation bar button is still visible. Rotate the Simulator window right, then left again. Tap the top left button to show the root view, then the “detail” button to show the detail view. Now the left navigation bar button is invisible. Rotating the device right and left again solves the issue. I filed FB22363118. class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { window = UIWindow(windowScene: scene as! UIWindowScene) let split = SplitViewController() window!.rootViewController = split window!.makeKeyAndVisible() split.showDetail() } } class SplitViewController: UISplitViewController, UISplitViewControllerDelegate { var detailNavigationViewController: UINavigationController! init() { super.init(nibName: nil, bundle: nil) detailNavigationViewController = UINavigationController(rootViewController: DetailViewController()) viewControllers = [UINavigationController(rootViewController: RootViewController())] } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } func showDetail() { showDetailViewController(detailNavigationViewController, sender: nil) } func showRoot() { (viewControllers.first as? UINavigationController)?.popViewController(animated: true) } } class RootViewController: UIViewController { override func loadView() { navigationItem.title = "root" let button = UIButton(primaryAction: UIAction(handler: { [self] _ in (splitViewController as! SplitViewController).showDetail() })) button.setTitle("detail", for: .normal) view = button } } class DetailViewController: UIViewController { override func loadView() { navigationItem.title = "detail" view = UIView() registerForTraitChanges([UITraitHorizontalSizeClass.self]) { (self: Self, previousTraitCollection) in if previousTraitCollection.horizontalSizeClass != self.traitCollection.horizontalSizeClass { self.updateBarButtons() } } updateBarButtons() } private func updateBarButtons() { navigationItem.leftBarButtonItem = UIBarButtonItem(primaryAction: UIAction(image: UIImage(systemName: "sidebar.leading")) { [self] _ in (self.splitViewController as! SplitViewController).showRoot() }) navigationItem.rightBarButtonItem = UIBarButtonItem(title: "right") } }