In iOS26, when using a standalone UITabBar without UITabBarController, the liquid glass blur effect is not applied when scrollable content moves behind the tab bar. However, the blur effect appears correctly when using UITabBarController. Sample Screenshots: When using UITababr When using UITababrController Sample Code: class SimpleTabBarController: UIViewController, UITabBarDelegate { let tabBar = UITabBar() let redItem = UITabBarItem(title: "Red", image: .add, tag: 0) let blueItem = UITabBarItem(title: "Blue", image: .checkmark, tag: 1) override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .white tabBar.items = [redItem, blueItem] tabBar.selectedItem = redItem tabBar.delegate = self tabBar.translatesAutoresizingMaskIntoConstraints = false let tableContainerView = TableContainerView() view.addSubview(tableContainerView) tableContainerView.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ tableContainerView.topAnchor.constraint(equalTo: view.topAnchor), tableContainerView.leadingAnchor.constraint(equalTo: view.leadingAnchor), tableContainerView.trailingAnchor.constraint(equalTo: view.trailingAnchor), tableContainerView.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) view.addSubview(tabBar) NSLayoutConstraint.activate([ tabBar.leadingAnchor.constraint(equalTo: view.leadingAnchor), tabBar.trailingAnchor.constraint(equalTo: view.trailingAnchor), tabBar.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) }

[Also submitted as FB20213961] SwiftUI Button with a label: closure containing only an Image view has a smaller tap target than buttons created with a Label or the convenience initializer. The hit area shrinks to the image bounds instead of preserving the standard minimum tappable size. SCREEN RECORDING On a physical device, the difference is obvious—it’s easy to miss the button. Sometimes it even shows the button-tapped bounce animation but doesn’t trigger the action. SYSTEM INFO Xcode Version 26.0 (17A321) macOS 15.6.1 (24G90) iOS 26.0 (23A340) SAMPLE CODE The following snippet shows the difference in hit targets between the convenience initializer, a Label, and an Image (the latter two in a label: closure). // ✅ Hit target is entire button Button("Button 1", systemImage: "1.square.fill") { print("Button 1 tapped") } // ✅ Hit target is entire button Button { print("Button 2 tapped") } label: { Label("Button 2", systemImage: "2.square.fill") } // ❌ Hit target is smaller than button Button { print("Button 3 tapped") } label: { Image(systemName: "3.square.fill") }

I am using below code to change navigationBar bg colour, but the text is hidden in large title. It works fine in previous versions. Kindly refer below code and attached images. Code: override func viewWillAppear(_ animated: Bool) { super.viewWillAppear(animated) navigationController?.navigationBar.prefersLargeTitles = true navigationItem.largeTitleDisplayMode = .always let appearance = UINavigationBarAppearance() appearance.backgroundColor = UIColor( red: 0.101961, green: 0.439216, blue: 0.388235, alpha: 1.0 ) navigationController?.navigationBar.standardAppearance = appearance navigationController?.navigationBar.scrollEdgeAppearance = appearance navigationController?.navigationBar.compactAppearance = appearance } Referenced images:

I am using a common UI pattern: UITabBarController as window root, each tab with a separate UINavigationController stack. I want the (bottom!) tab bar to be only visible when the user is at the root of the app and hide it when a detail page is opened. To do that, I used hidesBottomBarWhenPushed on any view controller that would be pushed on my navigation stacks and that worked fine in the past. But with iOS 26, I am seeing several issues: On iOS where when the bottom tab bar is used, when in a details page and navigating back, the tab bar becomes fully visible immediately instead of slowly animating in as it has been in the past. This is particular visible and annoying when using the "swipe to go back" gesture On iPad, the situation is even worse: On iPadOS 18, the tab bar appeared in the navigation controller's navigation bar - no matter if hidesBottomBarWhenPushed was set or not - fine. But now, with iPadOS 26, this top tab bar disappears when a child is pushed. Not only that, it disappears abruptly, without animation, and the Liquid Glass effect on the UIBarButtonItems is broken as well. There is no transition whatsoever, buttons are simply replaced with the new UIBarButtonItems of the pushed view controller once it became fully visible. It gets even worse when swipe-back navigating on iPadOS: As soon as the back transition starts, the tab bar becomes visible again (without animation), covering the title (view) of the UINavigationController. If the swipe-back transition is not completed the tab bar suddenly stays visible When the swipe-back transition is interrupted close to the end of the transition and it goes back to the pushed view controller, the top UIBarButtonItems are showing a visual glitch where the content (text or icon) stays on the area where the tab bar is, while their container (the glass effect) are on the vertically aligned to the title view. I am surprised that I have not found any similar reports of these problems, so I am wondering if I am doing anything wrong or using hidesBottomBarWhenPushed simply isn't recommended or supported any more.

I've been testing the safeAreaBar modifier to develop a custom tab bar. From my understanding, this should enable the .scrollEdgeEffectStyle to work with this bar, but I don't see any effect. Could you please clarify the difference between safeAreaBar and safeAreaInset?

[Submitted as FB18870294, but posting here for visibility.] In iOS 26 beta 3 (23A5287g), implicit animations no longer work when conditionally showing or hiding rows in a Form. Rows with Text or other views inside a Section appear and disappear abruptly, even when wrapped in withAnimation or using .animation() modifiers. This is a regression from iOS 18.5, where the row item animates in and out correctly with the same code. Repro Steps Create a new iOS App › SwiftUI project. Replace its ContentView struct with the code below Build and run on an iOS 18 device. Tap the Show Middle Row toggle and note how the Middle Row animates. Build and run on an iOS 26 beta 3 device. Tap the Show Middle Row toggle. Expected Middle Row item should smoothly animate in and out as it does on iOS 18. Actual Middle Row item appears and disappears abruptly, without any animation. Code struct ContentView: View { @State private var showingMiddleRow = false var body: some View { Form { Section { Toggle( "Show **Middle Row**", isOn: $showingMiddleRow.animation() ) if showingMiddleRow { Text("Middle Row") } Text("Last Row") } } } }

When testing with iOS 18.4 Beta on iPhones which support Dynamic Island, after doing a Face ID authentication, the amount of time it takes before the AppDelegate method applicationDidBecomeActive() is called takes longer than iPhones that do not support Dynamic Island. The time it takes is about double, 1.2 seconds vs 2.5 seconds on average. This does not occur with versions before 18.4 Beta. Anyone else seeing this?

We're observing new crashes specifically on iOS 18.4 devices with this pattern: Exception Type: SIGTRAP Exception Codes: fault addr: 0x000000019bc0f088 Crashed Thread: 0 Thread 0 0 libsystem_malloc.dylib _xzm_xzone_malloc_from_tiny_chunk.cold.1 + 36 1 libsystem_malloc.dylib __xzm_xzone_malloc_from_tiny_chunk + 612 2 libsystem_malloc.dylib __xzm_xzone_find_and_malloc_from_tiny_chunk + 112 3 libsystem_malloc.dylib __xzm_xzone_malloc_tiny_outlined + 312 4 CoreGraphics CG::Path::Path(CG::Path const&) + 132 5 CoreGraphics _CGPathCreateMutableCopyByTransformingPath + 112 6 CoreGraphics _CGFontCreateGlyphPath + 144 7 CoreGraphics _CGGlyphBuilderLockBitmaps + 1112 8 CoreGraphics _render_glyphs + 292 9 CoreGraphics _draw_glyph_bitmaps + 1116 10 CoreGraphics _ripc_DrawGlyphs + 1464 11 CoreGraphics CG::DisplayList::executeEntries(std::__1::__wrap_iter<std::__1::shared_ptr<CG::DisplayListEntry const>*>, std::__1::__wrap_iter<std::__1::shared_ptr<CG::DisplayListEntry const>*>, CGContextDelegate*, CGRenderingState*, CGGStack*, CGRect const*, __CFDictionary const*, bool) + 1328 12 CoreGraphics _CGDisplayListDrawInContextDelegate + 340 13 QuartzCore _CABackingStoreUpdate_ + 612 14 QuartzCore ____ZN2CA5Layer8display_Ev_block_invoke + 120 15 QuartzCore -[CALayer _display] + 1512 16 QuartzCore CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 420 17 QuartzCore CA::Context::commit_transaction(CA::Transaction*, double, double*) + 476 18 QuartzCore CA::Transaction::commit() + 644 19 UIKitCore ___34-[UIApplication _firstCommitBlock]_block_invoke_2 + 36 20 CoreFoundation ___CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 21 CoreFoundation ___CFRunLoopDoBlocks + 352 22 CoreFoundation ___CFRunLoopRun + 868 23 CoreFoundation _CFRunLoopRunSpecific + 572 24 GraphicsServices _GSEventRunModal + 168 25 UIKitCore -[UIApplication _run] + 816 26 UIKitCore _UIApplicationMain + 336 27 app _main + 132 28 dyld __dyld_process_info_create + 33284 Key Observations: Crash occurs during font glyph path creation (CGFontCreateGlyphPath) Involves memory allocation in malloc's xzone implementation 100% reproducible on iOS 18.4, not seen in prior OS versions Occurs during standard CALayer rendering operations Not tied to any specific font family or glyph content Questions for Apple: Is this crash signature recognized as a known issue in iOS 18.4's CoreGraphics? Could changes to xzone memory management in iOS 18.4 interact poorly with font rendering? Are there specific conditions that might trigger SIGTRAP in CGPathCreateMutableCopyByTransformingPath? Any recommended mitigations for text rendering while awaiting system updates?

I’m developing a share extension for iOS 26 with Xcode 26. When the extension’s sheet appears, it always shows a full white background, even though iOS 26 introduces a new “Liquid Glass” effect for partial sheets. Expected: The sheet background should use the iOS 26 glassmorphism effect as seen in full apps. Actual behavior: Custom sheets in my app get the glass effect, but the native system sheet in the share extension always opens as plain white. Steps to reproduce: Create a share extension using UIKit Present any UIViewController as the main view Set modalPresentationStyle = .pageSheet (or leave as default) Observe solid white background, not glassmorphism Sample code: swift override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .clear preferredContentSize = CGSize(width: UIScreen.main.bounds.width, height: 300) } Troubleshooting attempted: Tried adding UIVisualEffectView with system blur/materials Removed all custom backgrounds Set modalPresentationStyle explicitly Questions: Is it possible to enable or force the Liquid Glass effect in share extensions on iOS 26? Is this a limitation by design or a potential bug? Any workaround to make extension sheet backgrounds match system glass appearance?

Summary I’m experiencing two issues with SwiftUI’s navigationTransition(.zoom) on iOS 26.0 and 26.1 that break previously smooth transitions. These issues appear both on real devices and Simulator. The same code works correctly on iOS 18. Issue 1 - Source View Disappears After Drag-Dismiss When using .navigationTransition(.zoom(sourceID:..., in:...)), the source view disappears completely after the transition finishes. This only happens when the detail view is dismissed via drag (interactive dismiss). When the view is dismissed by tapping the back button, the source view remains visible as expected. Reproduced on: iOS 26.0, iOS 26.0.1 (17A400), iOS 26.1 (Simulator + physical device) Issue 2 — Flickering and Geometry Mismatch During Transition Compared to iOS 18 behavior, the outgoing view and incoming view no longer share consistent geometry. Current behavior on iOS 26: The disappearing view flickers during the drag-dismiss interaction. The source and destination views no longer align geometrically. Instead of smoothly morphing as in previous iOS versions, the two views briefly overlap incorrectly before applying the zoom animation. Expected (iOS 18) behavior: Matched geometry between source and destination. Smooth, stable zoom transition with no flickering. // // ContentView.swift // DummyTransition // // Created by Sasha Morozov on 12/11/25. // import SwiftUI struct RectItem: Identifiable, Hashable { let id: UUID = UUID() let title: String let color: Color } struct ContentView: View { @Namespace private var zoomNamespace private let items: [RectItem] = [ RectItem(title: "Red card", color: .red), RectItem(title: "Blue card", color: .blue), RectItem(title: "Green card", color: .green), RectItem(title: "Orange card", color: .orange) ] var body: some View { NavigationStack { ScrollView { VStack(spacing: 16) { ForEach(items) { item in NavigationLink { DetailView(item: item, namespace: zoomNamespace) .navigationTransition( .zoom(sourceID: item.id, in: zoomNamespace) ) } label: { RoundedRectangle(cornerRadius: 16) .fill(item.color.gradient) .frame(height: 120) .overlay( Text(item.title) .font(.headline) .foregroundStyle(.white) ) .padding(.horizontal, 16) .matchedTransitionSource(id: item.id, in: zoomNamespace) } .buttonStyle(.plain) } } .padding(.vertical, 20) } .navigationTitle("Cards") } } } struct DetailView: View { let item: RectItem let namespace: Namespace.ID var body: some View { ZStack { item.color Text(item.title) .font(.largeTitle.bold()) .foregroundStyle(.white) } .ignoresSafeArea() .navigationTitle("Detail") .navigationBarTitleDisplayMode(.inline) } } #Preview { ContentView() } Testing Environment MacBook Pro (2023, M2 Pro, 16 GB RAM) macOS 26.2 Beta (25C5031i) Xcode: Version 26.0.1 (17A400) Devices tested: Simulator (iOS 26.0 / 26.1) Physical device (iPhone 16) running iOS 26.1

[Submitted as FB21961572] When navigating from a tile in a scrolling LazyVGrid to a child view using .navigationTransition(.zoom) and then returning, the source tile can lag behind the rest of the grid if scrolling starts immediately after returning. The lag becomes more pronounced as tile content gets more complex; in this simplified sample, it can seem subtle, but in production-style tiles (as used in both of my apps), it is clearly visible and noticeable. This may be related to another issue I recently filed: Source item disappears after swipe-back with .navigationTransition(.zoom) CONFIGURATION Platform: iOS Simulator and physical device Navigation APIs: matchedTransitionSource + navigationTransition(.zoom) Container: ScrollView + LazyVGrid Sample project: ZoomTransition (DisappearingTile).zip REPRO STEPS Create a new iOS project and replace ContentView with the code below. Run the app in sim or physical device Tap any tile in the scrolling grid to navigate to the child view. Return to the grid (back button or edge swipe). Immediately scroll the grid. Watch the tile that was just opened. EXPECTED All tiles should move together as one coherent scrolling grid, with no per-item lag or desynchronization. ACTUAL The tile that was just opened appears to trail behind neighboring tiles for a short time during immediate scrolling after returning. MINIMAL CODE SAMPLE import SwiftUI struct ContentView: View { @Namespace private var namespace private let tileCount = 40 private let columns = [GridItem(.adaptive(minimum: 110), spacing: 12)] var body: some View { NavigationStack { ScrollView { LazyVGrid(columns: columns, spacing: 12) { ForEach(0..<tileCount, id: \.self) { index in NavigationLink(value: index) { RoundedRectangle(cornerRadius: 16) .fill(color(for: index)) .frame(height: 110) .overlay(alignment: .bottomLeading) { Text("\(index + 1)") .font(.headline) .foregroundStyle(.white) .padding(10) } .matchedTransitionSource(id: index, in: namespace) } .buttonStyle(.plain) } } .padding(16) } .navigationTitle("Zoom Transition Grid") .navigationSubtitle("Open tile, go back, then scroll immediately") .navigationDestination(for: Int.self) { index in Rectangle() .fill(color(for: index)) .ignoresSafeArea() .navigationTransition(.zoom(sourceID: index, in: namespace)) } } } private func color(for index: Int) -> Color { let hue = Double(index % 20) / 20.0 return Color(hue: hue, saturation: 0.8, brightness: 0.9) } } SCREEN RECORDING

On macOS 15.2, any Mac Catalyst project that does not support portrait iPad orientation will no longer be able to successfully show the contents of any popover controls. This does not appear to be a problem on earlier versions of macOS and it only affects Mac Catalyst builds, not "Designed for iPad" builds. STEPS TO REPRODUCE Create a project that utilizes Mac Catalyst. Create a simple button that shows a popover with simple content. Remove Portrait as a supported orientation. Run the project on macOS 15.2 as a Mac Catalyst build. Note that the content inside the popover is not shown the popover is shown. Run the project as Designed for iPad. Note that the popover content shows correctly.

Hi, I am running iOS Simulator on iOS 26 and I am trying to change unselectedItemTintColor of UITabBarItem in my TabBarViewController but it did not work when I tried following ways: Setting an iconColor through UITabBarAppearance() class Setting unselected item tint color like tabBar.unselectedItemTintColor = .black As an example attached file, I would like to set Settings tab's item color (icon + title) with different one when it is unselected.

Hello Apple Team, I’ve encountered a regression in iOS 26.1 when building my app with Xcode 26 (iOS 26 SDK). The issue affects PKPaymentButtonType.plain, which now renders as fully invisible and produces transparent snapshots, even though the same code worked correctly in previous Xcode/iOS versions. This has a real-world impact because many apps generate static images from PKPaymentButton for payment selection UIs using UIGraphicsImageRenderer, layer.render(in:), or custom snapshot utilities. When using PKPaymentButton(paymentButtonType: .plain, paymentButtonStyle: .black) on iOS 26.1, when built with Xcode 26, the button: Appears blank / invisible Cannot be snapshotted Produces a fully transparent UIImage, even though the CGImage object exists Behaves differently than older SDKs (Xcode 16.x / iOS < 26.1 This regression only appears when compiling with the new SDK. Other button types work fine. Expected Behavior .plain button should render glyphs as documented snapshot generated via UIGraphicsImageRenderer or drawHierarchy(in:) should produce a visible image Behavior should be consistent with older SDKs unless explicitly deprecated in release notes Expected Behavior .plain button should render glyphs as documented Snapshot generated via UIGraphicsImageRenderer or drawHierarchy(in:) should produce a visible image Behavior should be consistent with older SDKs unless explicitly deprecated in release notes Actual Behavior .plain button renders no glyph at all Snapshot image is fully transparent (alpha = 0), even though size and CGImage metadata are correct Only happens when built with Xcode 26 SDK Same build from Xcode 16.x does not reproduce the issue Steps to Reproduce Create a minimal sample project in Xcode 26 Add the following code: let button = PKPaymentButton(paymentButtonType: .plain, paymentButtonStyle: .black) button.frame = CGRect(x: 0, y: 0, width: 180, height: 48) let renderer = UIGraphicsImageRenderer(size: button.bounds.size) let image = renderer.image { _ in button.drawHierarchy(in: button.bounds, afterScreenUpdates: true) } print(image) Run on iOS 26.1 device or simulator Observe that: The button appears visually empty The generated image is fully transparent Environment Xcode: 26.x (iOS 26 SDK) iOS: 26.1 (iPhone 15 Pro tested) Device: Real device Framework: UIKit + PassKit Button type: .plain ONLY Other types: .pay/.buy/.checkout = OK

Hello, While integrating the Liquid Glass UI introduced in iOS 26 into my existing app, I encountered an unexpected issue. My app uses a UITabBarController, where each tab contains a UINavigationController, and the actual content resides in each UIViewController. Typically, I perform navigation using navigationController?.pushViewController(...) and hide the TabBar by setting vc.hidesBottomBarWhenPushed = true when needed. This structure worked perfectly fine prior to iOS 26, and I believe many apps use a similar approach. However, after enabling Liquid Glass UI, a problem occurs. Problem Description From AViewController, I push BViewController with hidesBottomBarWhenPushed = true. BViewController appears, and the TabBar is hidden as expected. When performing a swipe-back gesture, as soon as AViewController becomes visible, the TabBar immediately reappears (likely due to A’s viewWillAppear). The TabBar remains visible for a short moment even if the gesture is canceled — during that time, it is also interactable. Before iOS 26, the TabBar appeared synchronized with AViewController and did not prematurely show during the swipe transition. Tried using the new iOS 18 API: tabBarController?.setTabBarHidden(false, animated: true) It slightly improves the animation behavior, but the issue persists. If hidesBottomBarWhenPushed is now deprecated or discouraged, migrating entirely to setTabBarHidden would require significant refactoring, which is not practical for many existing apps. Is this caused by a misuse of hidesBottomBarWhenPushed, or could this be a regression or design change in iOS 26’s Liquid Glass UI?

Apparently now with iOS 26.1 if you have .tabViewBottomAccessory { } you get a pill shape floater all the time. That was not like that in 26.0.

We are using a TabView as the TabBarController in our app for main navigation. On one of the tabs we have a view that consists of a TabView with .tabViewStyle(.page) in order to scroll horizontally between pages inside of that specific tab. The .tabBarMinimizeBehavior(.onScrollDown) works on all the other TabItem views, but for this one it does not recognise any vertical scrolling in any of the pages, in order to minimize the TabBar. I believe this is a bug? If we don't wrap the views inside the TabView with .page style, we are able to get the expected behaviour using the tabBarMinimizeBehavior. Please let us know if this is going to be fixed in a future iOS 26 beta release.

We’ve just added a new sample code project to the SwiftUI Essentials documentation! If you attended the recent SwiftUI foundations: Build great apps with SwiftUI activity, you might recognize Wishlist, our travel-planning sample app. You can now explore and download the complete project here

I have a custom document-based iOS app that also runs on macOS. After implementing -activityItemsConfiguration to enable sharing from the context menu, I found that the app crashes on macOS when selecting Share… from the context menu and then selecting Save (i.e. Save to Files under iOS). This problem does not occur on iOS, which behaves correctly. - (id<UIActivityItemsConfigurationReading>)activityItemsConfiguration { NSItemProvider * provider = [[NSItemProvider alloc] initWithContentsOfURL:self.document.presentedItemURL]; UIActivityItemsConfiguration * configuration = [UIActivityItemsConfiguration activityItemsConfigurationWithItemProviders:@[ provider ]]; // XXX crashes with com.apple.share.System.SaveToFiles return configuration; } Additionally, I found that to even reach this crash, the workaround implemented in the NSItemProvider (FBxxx) category of the sample project is needed. Without this, the app will crash much earlier, due to SHKItemIsPDF() erroneously invoking -pathExtension on an NSItemProvider. This appears to be a second bug in Apple’s private ShareKit framework. #import <UniformTypeIdentifiers/UniformTypeIdentifiers.h> @implementation NSItemProvider (FBxxx) // XXX SHKItemIsPDF() invokes -pathExtension on an NSItemProvider (when running under macOS, anyway) -> crash - (NSString *)pathExtension { return self.registeredContentTypes.firstObject.preferredFilenameExtension; } @end Again, this all works fine on iOS (17.5) but crashes when the exact same app build is running on macOS (14.5). I believe these bugs are Apple's. Any idea how to avoid the crash? Is there a way to disable the "Save to Files" option in the sharing popup? I filed FB13819800 with a sample project that demonstrates the crash on macOS. I was going to file a TSI to get this resolved, but I see that DTS is not responding to tech support incidents until after WWDC.

Project minimum iOS deployment is set to 16.4. When running this simple code in console we receive "Observation tracking feedback loop detected!" and map is unusable. Run code: Map(coordinateRegion: .constant(.init())) Console report: ... Observable object key path '\_UICornerProvider.<computed 0x00000001a2768bc0 (Optional<UICoordinateSpace>)>' changed; performing invalidation for [layout] of: <_TtGC7SwiftUI21UIKitPlatformViewHostGVS_P10$1a57c8f9c32PlatformViewRepresentableAdaptorGV15_MapKit_SwiftUI8_MapViewGSaVS2_P10$24ce3fc8014AnnotationData____: 0x10acc2d00; baseClass = _TtGC5UIKit22UICorePlatformViewHostGV7SwiftUIP10$1a57c8f9c32PlatformViewRepresentableAdaptorGV15_MapKit_SwiftUI8_MapViewGSaVS3_P10$24ce3fc8014AnnotationData____; frame = (0 0; 353 595); anchorPoint = (0, 0); tintColor = UIExtendedSRGBColorSpace 0.333333 0.333333 0.333333 1; layer = <CALayer: 0x12443a430>> Observable object key path '\_UICornerProvider.<computed 0x00000001a2768bc0 (Optional<UICoordinateSpace>)>' changed; performing invalidation for [layout] of: <_MapKit_SwiftUI._SwiftUIMKMapView: 0x10ae8ce00; frame = (0 0; 353 595); clipsToBounds = YES; autoresize = W+H; layer = <CALayer: 0x113beb7e0>> Observable object key path '\_UICornerProvider.<computed 0x00000001a2768bc0 (Optional<UICoordinateSpace>)>' changed; performing invalidation for [layout] of: <_MapKit_SwiftUI._SwiftUIMKMapView: 0x10ae8ce00; frame = (0 0; 353 595); clipsToBounds = YES; autoresize = W+H; layer = <CALayer: 0x113beb7e0>> Observable object key path '\_UICornerProvider.<computed 0x00000001a2768bc0 (Optional<UICoordinateSpace>)>' changed; performing invalidation for [layout] of: <_MapKit_SwiftUI._SwiftUIMKMapView: 0x10ae8ce00; frame = (0 0; 353 595); clipsToBounds = YES; autoresize = W+H; layer = <CALayer: 0x113beb7e0>> Observation tracking feedback loop detected! Make a symbolic breakpoint at UIObservationTrackingFeedbackLoopDetected to catch this in the debugger. Refer to the console logs for details about recent invalidations; you can also make a symbolic breakpoint at UIObservationTrackingInvalidated to catch invalidations in the debugger. Object receiving repeated [layout] invalidations: <_TtGC7SwiftUI21UIKitPlatformViewHostGVS_P10$1a57c8f9c32PlatformViewRepresentableAdaptorGV15_MapKit_SwiftUI8_MapViewGSaVS2_P10$24ce3fc8014AnnotationData____: 0x10acc2d00; baseClass = _TtGC5UIKit22UICorePlatformViewHostGV7SwiftUIP10$1a57c8f9c32PlatformViewRepresentableAdaptorGV15_MapKit_SwiftUI8_MapViewGSaVS3_P10$24ce3fc8014AnnotationData____; frame = (0 0; 353 595); anchorPoint = (0, 0); tintColor = UIExtendedSRGBColorSpace 0.333333 0.333333 0.333333 1; layer = <CALayer: 0x12443a430>> Observation tracking feedback loop detected! Make a symbolic breakpoint at UIObservationTrackingFeedbackLoopDetected to catch this in the debugger. Refer to the console logs for details about recent invalidations; you can also make a symbolic breakpoint at UIObservationTrackingInvalidated to catch invalidations in the debugger. Object receiving repeated [layout] invalidations: <_MapKit_SwiftUI._SwiftUIMKMapView: 0x10ae8ce00; frame = (0 0; 353 595); clipsToBounds = YES; autoresize = W+H; layer = <CALayer: 0x113beb7e0>> IDE: Xcode 26 Beta 3 Testing device: iPhone 15 Pro iOS 26 Beta 3 MacOS: Tahoe 26 Beta 3