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.

In my CarPlay app my CPMapButton with system images have the wrong tint when the CarPlay appearance is set to "Always Dark". Here is what it looks like. When I change the system appearance to "Automatic" the buttons look fine. Has anyone encountered this or know how to fix it?

According to the UtilityWindow documentation: • They receive FocusedValues from the focused main scene in an application, similar to commands in the main menu, which can be used to display information on the active content as the user focuses on different scenes. This makes me think that any UtilityWindow, even across Scenes, should always receive @FocusedValues from the currently focused window of any scene. However, the following code doesn't quite work: @Observable class Info: Identifiable { let id = UUID() } struct ExampleApp: App { var body: some Scene { WindowGroup { ContentView() // Inside, it uses .focusedSceneValue(info) } UtilityWindow("Test") { UtilityWindowContent() } } } struct UtilityWindowContent: View { @FocusedValue(Info.self) var info var body: some View { Text(info?.id ?? "<nil>") // This always shows "<nil>" } } Here's some annotated screenshots of what's happening in a project: Menu bar commands do work with the same setup: As a workaround, attempting to use @FocusedValue in the App struct works, but as a result, the value appears to instantiate multiple times in the background, and they re-instantiate with every focus change. The @FocusedValue variable gets the correct instance, but it's needlessly initializing others in the background. This is on macOS 26.0 Tahoe Beta 8 (25A5349a).

What is the recommended way to obtain the concentric corner radius for views within grouped UICollectionView cells? In the most basic example, a UICollectionView with one section and one cell, we observe the cell takes almost the shape of a capsule, but it is indeed not a capsule. What is the way to obtain the radius of the grouped area from within the cell or its registration? I would like to layer elements on top that are concentric to the cell's clip shape. I've tried using custom views with .concentric UICornerConfigurations, setting .cornerConfiguration on the cell and on a custom backgroundView and I've even tried obtaining the .effectiveRadius of the cell after layout (returns 0.0). As of Xcode 26.0 Beta 7, nothing works. This seems like a huge omission; what am I missing here?

Anytime I have 1 item, then add another, the app crashes with the following error: Swift/IntegerTypes.swift:8835: Fatal error: Double value cannot be converted to Int because it is either infinite or NaN I'm not working with Int values though, so I'm not sure why this is happening. It's also not point me towards any specific line. I've printed out all of the values being used for the chart and none of them are showing as infinite or NaN. The data being used is created in a View. @State private var pieChartData: [PieChartDataPoint] = [] Then in the onAppear and onChange its gets loaded using the following function: func getPieChartDataPoints() -> [PieChartDataPoint] { self.map({ PieChartDataPoint(label: $0.name, value: $0.monthlyAmount()) }) } That's an extension on a SwiftData model type I have called Recurring. @Model final class Recurring { var id = UUID() enum Kind: String, CaseIterable, Codable { case income = "Income" case bill = "Bill" func plural() -> String { switch self { case .income: "Income" case .bill: "Bills" } } } enum Frequency: String, CaseIterable, Codable, Identifiable { var id: Frequency { self } case weekly = "Weekly" case biweekly = "Biweekly" case monthly = "Monthly" case quarterly = "Quarterly" case annually = "Annually" } var name: String = "" var kind: Kind = Kind.income var frequency: Frequency = Frequency.biweekly var amount: Double = 0 init(name: String, kind: Kind, frequency: Frequency, amount: Double) { self.name = name self.kind = kind self.frequency = frequency self.amount = amount } func amount(from cycle: Cycle) -> Double { switch cycle { case .weekly: monthlyAmount() * 12 / 52 case .biweekly: monthlyAmount() * 12 / 26 case .monthly: monthlyAmount() } } func monthlyAmount() -> Double { switch frequency { case .weekly: amount * 52 / 12 case .biweekly: amount * 26 / 12 case .monthly: amount case .quarterly: amount * 4 / 12 case .annually: amount / 12 } } } Here is the DataPoint structure. struct PieChartDataPoint: Identifiable, Equatable { var id = UUID() var label: String var value: Double } Finally here is the chart. Chart(sorted, content: { dataPoint in SectorMark( angle: .value(dataPoint.label, getValue(from: dataPoint)), innerRadius: 50, angularInset: 5 ) .foregroundStyle(by: .value("Label", dataPoint.label)) .cornerRadius(10) .opacity(getSectorMarkOpacity(for: dataPoint)) }) .scaledToFill() .chartLegend(.hidden) .chartAngleSelection(value: $chartSelection) .onChange(of: chartSelection, checkSelection) For testing purposes, I have removed all of the modifiers and only had a simple SectorMark in the Chart, however, that was still crashing. Does anyone know why this is happening?

Is the Cancel button intentionally removed from UISearchBar (right side)? Even when using searchController with navigationItem also. showsCancelButton = true doesn’t display the cancel button. Also: When tapping the clear ("x") button inside the search field, the search is getting canceled, and searchBarCancelButtonClicked(_:) is triggered (Generally it should only clear text, not cancel search). If the search text is empty and I tap outside the search bar, the search is canceled. Also when I have tableview in my controller(like recent searches) below search bar and if I try to tap when editing started, action is not triggered(verified in sample too). Just cancellation is happening. In a split view controller, if the search is on the right side and I try to open the side panel, the search also gets canceled. Are these behaviors intentional changes, beta issues, or are we missing something in implementation?

Summary In a SwiftUI drag-and-drop flow, the only robust way I’ve found to detect cancellation (user drops outside any destination) is to rely on the NSItemProvider created in .onDrag and run cleanup when it’s deallocated, via a custom onEnded callback tied to its lifecycle. On iOS 26, the provider appears to be deallocated immediately after .onDrag returns (unless I keep a strong reference), so a deinit/onEnded-based cancel hook fires right away and no longer reflects the true end of the drag session. I’d like to know: 1. Is there a supported, reliable way to detect when a drag ends outside any drop target so I can cancel and restore the source row? 2. Is the iOS 26 NSItemProvider deallocation timing a bug/regression or intended behavior? Minimal SwiftUI Repro This example shows: • creating a custom NSItemProvider subclass with an onEnded closure • retaining it to avoid immediate dealloc (behavior change on iOS 26) • using performDrop to mark the drag as finished import SwiftUI import UniformTypeIdentifiers final class DragProvider: NSItemProvider { var onEnded: (() -> Void)? deinit { // Historically: called when the system drag session ended (drop or cancel). // On iOS 26: can fire immediately after .onDrag returns unless the provider is retained. onEnded?() } } struct ContentView: View { struct Item: Identifiable, Equatable { let id = UUID(); let title: String } @State private var pool: [Item] = (1...4).map { .init(title: "Option \($0)") } @State private var picked: [Item] = [] @State private var dragged: Item? @State private var dropFinished: Bool = true @State private var activeProvider: DragProvider? // Retain to avoid immediate dealloc private let dragType: UTType = .plainText var body: some View { HStack(spacing: 24) { // Destination list (accepts drops) VStack(alignment: .leading, spacing: 8) { Text("Picked").bold() VStack(spacing: 8) { ForEach(picked) { item in row(item) } } .padding() .background(RoundedRectangle(cornerRadius: 8).strokeBorder(.quaternary)) .onDrop(of: [dragType], delegate: Dropper( picked: $picked, pool: $pool, dragged: $dragged, dropFinished: $dropFinished, activeProvider: $activeProvider )) } .frame(maxWidth: .infinity, alignment: .topLeading) // Source list (draggable) VStack(alignment: .leading, spacing: 8) { Text("Pool").bold() VStack(spacing: 8) { ForEach(pool) { item in row(item) .onDrag { startDrag(item) return makeProvider(for: item) } preview: { row(item).opacity(0.9).frame(width: 200, height: 44) } .overlay( RoundedRectangle(cornerRadius: 8) .fill(item == dragged ? Color(.systemBackground) : .clear) // keep space ) } } .padding() .background(RoundedRectangle(cornerRadius: 8).strokeBorder(.quaternary)) } .frame(maxWidth: .infinity, alignment: .topLeading) } .padding() } private func row(_ item: Item) -> some View { RoundedRectangle(cornerRadius: 8) .strokeBorder(.secondary) .frame(height: 44) .overlay( HStack { Text(item.title); Spacer(); Image(systemName: "line.3.horizontal") } .padding(.horizontal, 12) ) } // MARK: Drag setup private func startDrag(_ item: Item) { dragged = item dropFinished = false } private func makeProvider(for item: Item) -> NSItemProvider { let provider = DragProvider(object: item.id.uuidString as NSString) // NOTE: If we DO NOT retain this provider on iOS 26, // its deinit can run immediately (onEnded fires too early). activeProvider = provider provider.onEnded = { [weak self] in // Intended: run when system drag session ends (drop or cancel). // Observed on iOS 26: may run too early unless retained; // if retained, we lose a reliable "session ended" signal here. DispatchQueue.main.async { guard let self else { return } if let d = self.dragged, self.dropFinished == false { // Treat as cancel: restore the source item if !self.pool.contains(d) { self.pool.append(d) } self.picked.removeAll { $0 == d } } self.dragged = nil self.dropFinished = true self.activeProvider = nil } } return provider } // MARK: DropDelegate private struct Dropper: DropDelegate { @Binding var picked: [Item] @Binding var pool: [Item] @Binding var dragged: Item? @Binding var dropFinished: Bool @Binding var activeProvider: DragProvider? func validateDrop(info: DropInfo) -> Bool { dragged != nil } func performDrop(info: DropInfo) -> Bool { guard let item = dragged else { return false } if let idx = pool.firstIndex(of: item) { pool.remove(at: idx) } picked.append(item) // Mark drag as finished so provider.onEnded won’t treat it as cancel dropFinished = true dragged = nil activeProvider = nil return true } } } Questions Is there a documented, source-side callback (or best practice) to know the drag session ended without any performDrop so we can cancel and restore the item? Has the NSItemProvider deallocation timing (for the object returned from .onDrag) changed intentionally on iOS 26? If so, what’s the recommended replacement signal? Is there a SwiftUI-native event to observe the end of a drag session that doesn’t depend on the provider’s lifecycle?

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'm using the PasteButton component to paste content from clipboard. On the docs it says that the PasteButton will handle internally permissions and will not present the prompt. But in my case seems to be not true. I removed all the occurrencies of UIPasteboard.general.string since i read that this will cause the prompt to appear. Also as you can see on the code below i'm not doing fancy or weird things, even with the base component this behaviour is still there. PasteButton(payloadType: String.self) { strings in if let first = strings.first { print("clipboard text: \(first)") } } I can see other apps using this paste button without asking for permissions every time, but i cannot see any issue in my code.

I’m trying to understand the exact role of the return value in the UITextFieldDelegate method textFieldShouldReturn(_:). From my experiments in Xcode, I observed: Returning true vs false does not seem to cause any visible difference (e.g., the keyboard does not automatically dismiss either way). I know that in shouldChangeCharactersIn returning true allows the system to insert the character, and returning false prevents it. That’s clear. For textFieldShouldReturn, my current understanding is that returning true means “let the OS handle the Return press,” and returning false means “I’ll handle it myself.” My confusion: what is it that the OS actually does when it “handles” the Return press? Does UIKit do anything beyond calling this delegate method? If the system is supposed to dismiss the keyboard when returning true, why doesn’t it happen automatically? I’d appreciate clarification on the expected use of this return value — specifically, what default behavior the system performs (if any) when we return true. Thanks!

(NSString*)getClienttime { NSDate* currentDate = [NSDate date]; NSDateFormatter* dateformatter = [[NSDateFormatter alloc] init]; dateformatter.timeZone = [NSTimeZone timeZoneForSecondsFromGMT:8*3600]; dateformatter.locale= [NSLocale systemLocale]; [dateformatter setDateFormat:@"yyyy-MM-dd HH:mm:ss"]; return [dateformatter stringFromDate:currentDate]?:@""; } the info of crash 1 libicucore.A.dylib icu::UnicodeString::copyFrom(icu::UnicodeString const&, signed char) (in libicucore.A.dylib) + 36 2 libicucore.A.dylib icu::DecimalFormatSymbols::operator=(icu::DecimalFormatSymbols const&) (in libicucore.A.dylib) + 64 3 libicucore.A.dylib icu::DecimalFormatSymbols::operator=(icu::DecimalFormatSymbols const&) (in libicucore.A.dylib) + 64 4 libicucore.A.dylib icu::DecimalFormat::DecimalFormat(icu::DecimalFormat const&) (in libicucore.A.dylib) + 188 5 libicucore.A.dylib icu::DecimalFormat::clone() const (in libicucore.A.dylib) + 48 6 libicucore.A.dylib icu::NumberFormat::createInstance(icu::Locale const&, UNumberFormatStyle, UErrorCode&) (in libicucore.A.dylib) + 188 7 libicucore.A.dylib icu::SimpleDateFormat::initialize(icu::Locale const&, UErrorCode&) (in libicucore.A.dylib) + 580 8 libicucore.A.dylib icu::SimpleDateFormat::SimpleDateFormat(icu::Locale const&, UErrorCode&) (in libicucore.A.dylib) + 332 9 libicucore.A.dylib icu::DateFormat::create(icu::DateFormat::EStyle, icu::DateFormat::EStyle, icu::Locale const&) (in libicucore.A.dylib) + 264 10 libicucore.A.dylib udat_open (in libicucore.A.dylib) + 396 11 CoreFoundation __cficu_udat_open (in CoreFoundation) + 72 12 CoreFoundation __ResetUDateFormat (in CoreFoundation) + 508 13 CoreFoundation __CreateCFDateFormatter (in CoreFoundation) + 324 14 Foundation -[NSDateFormatter _regenerateFormatter] (in Foundation) + 204 15 Foundation -[NSDateFormatter stringForObjectValue:] (in Foundation) + 104 16 ABC +[JMAContext getClienttime] (in DadaStaff) (JMAContext.m:73)

Note: in this post I discuss sceneDidEnterBackground/WillResignActive but I assume any guidance provided would also apply to the now deprecated applicationDidEnterBackground/applicationWillResignActive and SwiftUI's ScenePhase (please call out if that's not the case!). A common pattern for applications with sensitive user data (banking, health, private journals, etc.) is to obsurce content in the app switcher. Different apps appear to implement this in two common patterns. Either immediately upon becoming inactive (near immediately upon moving to task switcher) or only upon becoming backgrounded (not until you've gone to another app or back to the home screen). I’d like to make sure we’re aligned with Apple’s intended best practices and am wondering if an anti-pattern of using sceneWillResignActive(_:) may be becoming popularized and has minor user experience inconviences (jarring transitions to the App Switcher/Control Center/Notification Center and when the system presents alerts.) Our applications current implementation uses sceneDidEnterBackground(_:) to obscure sensitive elements instead of sceneWillResignActive(_:), based on the recomendations from tech note QA1838 and the documentation in sceneDidEnterBackground(_:) ... Shortly after this method [sceneWillEnterBackground] returns, UIKit takes a snapshot of your scene’s interface for display in the app switcher. Make sure your interface doesn’t contain sensitive user information. Both QA1838 and the sceneDidEnterBackground documentation seem to indicate backgrounding is the appropriate event to respond to for this pattern but I am wondering if "to display in the app switcher" may be causing confusion since your app can also display in the app switcher upon becoming inactive and if some guidance could be added to sceneWillResignActive that it is not nesscary to obsure content during this state (if that is true). In our testing, apps seems to continue to play any in-progress animations when entering the app switcher from the application (inactive state), suggesting no snapshot capture. We also discovered that it appears sceneWillResignActive not always be called (it usually is) but occasionally you can swipe into the app switcher without it being called but that sceneDidEnterBackground is triggered more consistently. It appears the Wallet app behaves as I'd expect with sceneDidEnterBackground on card details screens as well (ejecting you to the card preview if you switch apps) but will keep you on the card details screen upon becoming inactive. Questions: Is sceneDidEnterBackground(_:) still Apple’s recommended place to obscure sensitive content, or should apps handle this earlier (e.g. on inactive)? Would it actually be recommended against using sceneWillResignActive active given it seems to not be gauranteed to be called? Ask: Provide an updated version of QA1838 to solidfy the extrapolation of applicationDidEnterBackground -> sceneDidEnterBackground Consider adding explicit guidance to sceneWillResignActive documentation

I have a strange issue for iOS26. I have a UITabBarController at the root view of the app, but on certain actions, I want to hide it temporarily, and then have some options where the user can press a button which display some options using UIAlertController. It used to work fine before, but with iOS26, when the UIAlertController is presented, the tab bar (which is hidden by setting the ‘frame’) suddenly pops back into view automatically, when I don't want it to. Here's an example that reproduces the issue: class TestTableViewController: UITableViewController { private var isEditMode: Bool = false override func viewDidLoad() { super.viewDidLoad() // Do any additional setup after loading the view. self.navigationItem.leftBarButtonItem = UIBarButtonItem(title: "Change", style: .plain, target: self, action: #selector(changeMode)) } @objc func changeMode() { print("change mode called") if isEditMode == false { isEditMode = true // hide tab bar setEditingBarVisible(true, animated: true) self.navigationItem.rightBarButtonItem = UIBarButtonItem(title: "Action", style: .plain, target: self, action: #selector(showActionsList)) } else { isEditMode = false // show tab bar setEditingBarVisible(false, animated: true) self.navigationItem.rightBarButtonItem = nil } } @objc func showActionsList() { let alert = UIAlertController(title: "Action", message: "showing message", preferredStyle: .actionSheet) alert.addAction(UIAlertAction.init(title: "Cancel", style: .cancel, handler: nil)) self.present(alert, animated: true, completion: nil) } @objc func setEditingBarVisible(_ visible: Bool, animated: Bool) { guard let tabBar = tabBarController?.tabBar else { return } let performChanges = { // Slide the tab bar off/on screen by adjusting its frame’s y. // This is safe because UITabBar is frame-managed, not Auto Layout constrained. var frame = tabBar.frame let height = frame.size.height if visible { // push it down if not already if frame.origin.y < self.view.bounds.height { frame.origin.y = self.view.bounds.height + self.view.safeAreaInsets.bottom } // Give our content its full height back (remove bottom safe-area padding that tab bar created) self.additionalSafeAreaInsets.bottom = 0 } else { // bring it back to its normal spot frame.origin.y = self.view.bounds.height - height // Re-apply bottom safe-area so content clears the tab bar again self.additionalSafeAreaInsets.bottom = height } tabBar.frame = frame // Ensure layout updates during animation self.tabBarController?.view.layoutIfNeeded() self.view.layoutIfNeeded() } if animated { UIView.animate(withDuration: 0.28, delay: 0, options: [.curveEaseInOut]) { performChanges() } } else { performChanges() } } } I have a bar button called 'Change', and selecting it should hide/show the UITabBar at the bottom, and show/hide a different bar button called 'Action'. Selecting the 'Action' button shows an alert. With iOS26, with the tab bar moved out of view, when the 'Action' button is called, the alert shows but the tab bar automatically moves into view as well. Is this a known issue? Any workaround for it? I filed FB19954757 just in case.

[NSBitmapImageRep imageRepsWithContentsOfFile] is returning empty/solid black bitmaps for some image files with HDR on macOS Tahoe beta. I opened an Apple feedback report but curious if anyone else is seeing this. Errors thrown in the debugger are: IIOApplyHDRGainMap:351: FlexGTC headroom (4.0) doesn't match target headroom (1.0) +[HDRImage getGainMapVersionMajor:minor:fromMetadata:]:417: Failed to get metadata tag: HDRGainMap:HDRGainMapVersion +[HDRImage getGainMapHeadroom:fromMetadata:]:443: Failed to read gain map version info: <CGImageMetadata 0x9fc013700> ( iio:hasXMP = True ) This function call has worked reliable for many years before the Tahoe beta.

Hello, I am experiencing a crash in a SwiftUI app. It happens when I place multiple views inside a ScrollView. The crash occurs only on a physical device (it does not reproduce in the Simulator). It happens during runtime, seemingly while SwiftUI is updating or laying out the view hierarchy. I have not been able to determine the exact cause. I am attaching a text file with the entire backtrace from LLDB. swiftui_crash_backtrace Is this a known SwiftUI issue? Any recommendations on how to further investigate or work around it? Any help or suggestions would be appreciated. Xcode 16.3 / iOS 18.6.2 Thank you!

Hello! I have experienced a weird bug in iOS 26 Beta (8) and previous beta versions. The safe area inset is not correctly aligned with the keyboard toolbar on real devices and simulators. When you focus a new textfield the bottom safe area is correctly placed aligned the keyboard toolbar. On real devices the safe area inset view is covered slightly by the keyboard toolbar, which is even worse than on the simulator. Here's a clip from a simulator: Here's the code that reproduced the bug I experienced in our app. #Preview { NavigationStack { ScrollView { TextField("", text: .constant("")) .padding() .background(Color.secondary) TextField("", text: .constant("")) .padding() .background(Color.green) } .padding() .safeAreaInset(edge: .bottom, content: { Color.red .frame(maxWidth: .infinity) .frame(height: 40) }) .toolbar { ToolbarItem(placement: .keyboard) { Button {} label: { Text("test") } } } } }

Observed on iPadOS 26 b8 in apps built with current SDK: Floating keyboard lacks corner mask Floating key blue highlight not aligned with its background Invoking floating keyboard can result in “ghost” full-sized keyboard appearing at bottom of screen Swipe-dismissing floating keyboard can result in it bouncing back up, again with ghost keyboard appearing Touching globe key can produce menus truncated/obscured by ghost keyboard Ghost keyboard can remain visible even after backgrounding the app (Some of these issues may be limited to non-English keyboards) FB19951605

have a SwiftUI View where I can edit financial transaction information. The data is stored in SwiftData. If I enter a TextField element and start typing, it is super laggy and there are hangs of 1-2 seconds between each input (identical behaviour if debugger is detached). On the same view I have another TextField that is just attached to a @State variable of that view and TextField updates of that value work flawlessly. So somehow the hangs must be related to my SwiftData object but I cannot figure out why. This used to work fine until a few months ago and then I could see the performance degrading. I have noticed that when I use a placeholder variable like @State private var transactionSubject: String = "" and link that to the TextField, the performance is back to normal. I am then using .onSubmit { self.transaction.subject = self.transactionSubject } to update the value in the end but this again causes a 1 s hang. :/ Below the original code sample with some unnecessary stuff removed: struct EditTransactionView: View { @Environment(\.modelContext) var modelContext @Environment(\.dismiss) var dismiss @State private var testValue: String = "" @Bindable var transaction: Transaction init(transaction: Transaction) { self.transaction = transaction let transactionID = transaction.transactionID let parentTransactionID = transaction.transactionMasterID _childTransactions = Query(filter: #Predicate<Transaction> {item in item.transactionMasterID == transactionID }, sort: \Transaction.date, order: .reverse) _parentTransactions = Query(filter: #Predicate<Transaction> {item in item.transactionID == parentTransactionID }, sort: \Transaction.date, order: .reverse) print(_parentTransactions) } //Function to keep text length in limits func limitText(_ upper: Int) { if self.transaction.icon.count > upper { self.transaction.icon = String(self.transaction.icon.prefix(upper)) } } var body: some View { ZStack { Form{ Section{ //this one hangs TextField("Amount", value: $transaction.amount, format: .currency(code: Locale.current.currency?.identifier ?? "USD")) //this one works perfectly TextField("Test", text: $testValue) HStack{ TextField("Enter subject", text: $transaction.subject) .onAppear(perform: { UITextField.appearance().clearButtonMode = .whileEditing }) Divider() TextField("Select icon", text: $transaction.icon) .keyboardType(.init(rawValue: 124)!) .multilineTextAlignment(.trailing) } } } .onDisappear(){ if transaction.amount == 0 { // modelContext.delete(transaction) } } .onChange(of: selectedItem, loadPhoto) .navigationTitle("Transaction") .navigationBarTitleDisplayMode(.inline) .toolbar{ Button("Cancel", systemImage: "trash"){ modelContext.delete(transaction) dismiss() } } .sheet(isPresented: $showingImagePickerView){ ImagePickerView(isPresented: $showingImagePickerView, image: $image, sourceType: .camera) } .onChange(of: image){ let data = image?.pngData() if !(data?.isEmpty ?? false) { transaction.photo = data } } .onAppear(){ cameraManager.requestPermission() setDefaultVendor() setDefaultCategory() setDefaultGroup() } .sheet(isPresented: $showingAmountEntryView){ AmountEntryView(amount: $transaction.amount) } } } }

I have a custom list and I want to make the names in the list editable through double tap. I know how to solve this hacky ways. But are there no solid way to achieve this? like having .disabled without graying it out?

Is it possible at all to programmatically change visible rect / map region programmatically? Otherwise, how can we make sure user sees anythng just after starting the app, if nearest POIs are far away?

The following code shows that a selected button in a list gots blurred if a glass effect is applied to the list. This happens if the button style is plain or glass. It does not happen if the button style is bordered. Is this a wanted documented behavior or is this a bug? struct ContentView: View { @State private var items = [ "Item 1", "Item 2", "Item 3", "Item 4"] var body: some View { ZStack { Image(systemName: "globe") .resizable() List(items, id: \.self) { item in Button(action: {}, label: { Text(item) }) } .padding() .glassEffect(in: Rectangle()) } } }