We use SwiftUI's .tabViewBottomAccessory in our iOS apps for displaying an Audio MiniPlayer View (like in the Apple Music App). TabView(selection: $viewModel.selectedTab) { // Tabs here } .tabViewBottomAccessory { if viewModel.showAudioMiniPlayer { MiniPlayerView() } } The Problem This code works perfectly on iOS 26.0. When viewModel.showAudioMiniPlayer is false, the accessory is completely hidden. However, on iOS 26.1 (23B5059e), when 'viewModel.showAudioMiniPlayer' becomes false, the MiniPlayerView disappears, but an empty container remains, leaving a blank space above the tab bar. Is this a known Bug in iOS 26.1 and are there any effective workarounds?

Seemingly innocuous contents passed to tabViewBottomAccessory can trigger inscrutable AttributeGraph cycles, which can then cause unexplained broken behavior of views that may be participating in these cycles. These cycles can be introduced by adding common elements to the tabViewBottomAccessory view hierarchy, like Slider, Button, Toggle, and even things simple if statements surrounding Text elements. These cycles can even also be triggered in a manner that causes the tabViewBottomAccessoryPlacement Environment value to be nil, which can then cause views that depend on this value to render incorrectly or not at all. The errors logged to the Xcode console are of the form: === AttributeGraph: cycle detected through attribute 29528 === === AttributeGraph: cycle detected through attribute 324264 === No further information about this attribute is available in any public Xcode tools. Environment XCode Version 26.0 (17A324) iOS 26.0 (23A343) Steps to reproduce Run the sample above in Simulator Observe no AttributeGraph cycles in Xcode console. Uncomment any of the commented out examples in SliderView.body Observe Xcode console for AttributeGraph cycle messages. Observe glitchy animation behavior Expected Behavior No AttributeGraph cycle diagnostics for ordinary state changes. tabViewBottomAccessoryPlacement always present (non-nil) while accessory is attached. Dependent views update consistently. Errors logged to the Console would help guide me towards a resolution Impact Undermines confidence in adopting tabViewBottomAccessory. Hard to debug: cycle traces are opaque and environment silently degrades (becomes nil) instead of asserting. Nearly shipped a UI where accessory layout fails sporadically. What would help Underlying fix to prevent cycles for ordinary accessory content mutations. Guarantee (or documented contract) that tabViewBottomAccessoryPlacement is never nil while accessory is active, or an assert if invariants break. Option to enable detailed environment propagation trace when a cycle is detected. Symbolic source identifiers in cycle backtraces. Documentation note on current limitations (if certain view types are not yet supported in accessory regions).

Experiencing 100% CPU usage in SwiftUI app using UIHostingController, only on iOS 26 beta and Xcode beta. Issue involves excessive view updates in AttributeGraph propagation. Stack trace (main thread): thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x00000001c38b9aa4 AttributeGraph`AG::Graph::propagate_dirty(AG::AttributeID) + 416 frame #1: 0x00000001d9a743ec SwiftUICore`SwiftUI.ObservationGraphMutation.apply() -> () + 656 frame #2: 0x00000001d97c0d4c SwiftUICore`function signature specialization <Arg[2] = [Closure Propagated : closure #1 () -> () in SwiftUI.(AsyncTransaction in _F9F204BD2F8DB167A76F17F3FB1B3335).apply() -> (), Argument Types : [SwiftUI.AsyncTransaction]> of generic specialization <()> of closure #1 () throws -> τ_0_0 in SwiftUI.withTransaction<τ_0_0>(SwiftUI.Transaction, () throws -> τ_0_0) throws -> τ_0_0 + 336 frame #3: 0x00000001d9a6ac80 SwiftUICore`merged function signature specialization <Arg[3] = Owned To Guaranteed> of function signature specialization <Arg[1] = [Closure Propagated : implicit closure #2 () -> () in implicit closure #1 @Sendable (SwiftUI.(AsyncTransaction in _F9F204BD2F8DB167A76F17F3FB1B3335)) -> () -> () in SwiftUI.GraphHost.flushTransactions() -> (), Argument Types : [SwiftUI.AsyncTransaction]> of SwiftUI.GraphHost.runTransaction(_: Swift.Optional<SwiftUI.Transaction>, do: () -> (), id: Swift.Optional<Swift.UInt32>) -> () + 196 frame #4: 0x00000001d9a52ab0 SwiftUICore`SwiftUI.GraphHost.flushTransactions() -> () + 176 frame #5: 0x00000001d8461aac SwiftUI`closure #1 (SwiftUI.GraphHost) -> () in SwiftUI._UIHostingView._renderForTest(interval: Swift.Double) -> () + 20 frame #6: 0x00000001d9bf3b38 SwiftUICore`partial apply forwarder for closure #1 (SwiftUI.ViewGraph) -> τ_1_0 in SwiftUI.ViewGraphRootValueUpdater.updateGraph<τ_0_0>(body: (SwiftUI.GraphHost) -> τ_1_0) -> τ_1_0 + 20 frame #7: 0x00000001d9e16dc4 SwiftUICore`SwiftUI.ViewGraphRootValueUpdater._updateViewGraph<τ_0_0>(body: (SwiftUI.ViewGraph) -> τ_1_0) -> Swift.Optional<τ_1_0> + 200 frame #8: 0x00000001d9e1546c SwiftUICore`SwiftUI.ViewGraphRootValueUpdater.updateGraph<τ_0_0>(body: (SwiftUI.GraphHost) -> τ_1_0) -> τ_1_0 + 136 frame #9: 0x00000001d8461a7c SwiftUI`closure #1 () -> () in closure #1 () -> () in closure #1 () -> () in SwiftUI._UIHostingView.beginTransaction() -> () + 144 frame #10: 0x00000001d846aed0 SwiftUI`partial apply forwarder for closure #1 () -> () in closure #1 () -> () in closure #1 () -> () in SwiftUI._UIHostingView.beginTransaction() -> () + 20 frame #11: 0x00000001d984f814 SwiftUICore`closure #1 () throws -> τ_0_0 in static SwiftUI.Update.ensure<τ_0_0>(() throws -> τ_0_0) throws -> τ_0_0 + 48 frame #12: 0x00000001d984e114 SwiftUICore`static SwiftUI.Update.ensure<τ_0_0>(() throws -> τ_0_0) throws -> τ_0_0 + 96 frame #13: 0x00000001d846aeac SwiftUI`partial apply forwarder for closure #1 () -> () in closure #1 () -> () in SwiftUI._UIHostingView.beginTransaction() -> () + 64 frame #14: 0x00000001851eab1c UIKitCore`___lldb_unnamed_symbol311742 + 20 * frame #15: 0x00000001852b56a8 UIKitCore`___lldb_unnamed_symbol315200 + 44 frame #16: 0x0000000185175120 UIKitCore`___lldb_unnamed_symbol308851 + 20 frame #17: 0x00000001d984e920 SwiftUICore`static SwiftUI.Update.dispatchImmediately<τ_0_0>(reason: Swift.Optional<SwiftUI.CustomEventTrace.ActionEventType.Reason>, _: () -> τ_0_0) -> τ_0_0 + 300 frame #18: 0x00000001d95a7428 SwiftUICore`static SwiftUI.ViewGraphHostUpdate.dispatchImmediately<τ_0_0>(() -> τ_0_0) -> τ_0_0 + 40 frame #19: 0x00000001852b59dc UIKitCore`___lldb_unnamed_symbol315204 + 192 frame #20: 0x00000001852b54a4 UIKitCore`___lldb_unnamed_symbol315199 + 64 frame #21: 0x0000000185745dd4 UIKitCore`_UIUpdateSequenceRunNext + 120 frame #22: 0x0000000186144fac UIKitCore`schedulerStepScheduledMainSectionContinue + 56 frame #23: 0x00000002505ad150 UpdateCycle`UC::DriverCore::continueProcessing() + 36 frame #24: 0x0000000180445b20 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24 frame #25: 0x0000000180445a68 CoreFoundation`__CFRunLoopDoSource0 + 168 frame #26: 0x00000001804451f4 CoreFoundation`__CFRunLoopDoSources0 + 220 frame #27: 0x00000001804443a8 CoreFoundation`__CFRunLoopRun + 756 frame #28: 0x000000018043f458 CoreFoundation`_CFRunLoopRunSpecificWithOptions + 496 frame #29: 0x00000001928d19bc GraphicsServices`GSEventRunModal + 116 frame #30: 0x0000000186224480 UIKitCore`-[UIApplication _run] + 772 frame #31: 0x0000000186228650 UIKitCore`UIApplicationMain + 124 frame #32: 0x000000010bb1b504 MyApp.debug.dylib`main at main.swift:13:1 frame #33: 0x00000001043813d0 dyld_sim`start_sim + 20 frame #34: 0x000000010468ab98 dyld`start + 6076 Used let _ = Self.printChanges() in my SwiftUI View and got infinite changes of \_UICornerProvider.<computed 0x000000018527ffd8 (Optional<UICoordinateSpace>)> changed. Reproduces only on beta; works on stable iOS. Likely beta-specific bug in SwiftUI rendering.

My usage of TextField.focused() works fine in Xcode 14.3.1 but is broken as of Xcode 15. I first noticed it in the second beta and it's still broken as of the 4th beta. Feedback / OpenRadar # FB12432084 import SwiftUI struct ContentView: View { @State private var text = "" @FocusState var isFocused: Bool var body: some View { ScrollView { TextField("Test", text: $text) .textFieldStyle(.roundedBorder) .focused($isFocused) Text("Text Field Is Focused: \(isFocused.description)") } } }

The following is verbatim of a feedback report (FB19809442) I submitted, shared here as someone else might be interested to see it (I hate the fact that we can't see each other's feedbacks). On iOS 16, TextKit 2 calls NSTextLayoutFragment's draw(at:in:) method once for the first paragraph, but for every other paragraph, it calls it continuously on every scroll step in the UITextView. (The first paragraph is not cached; its draw is called again when it is about to be displayed again, but then it is again called only once per its lifecycle.) On iOS 17, the behavior is similar; the draw method gets called once for the 1st and 2nd paragraph, and for every other paragraph it again gets called continuously as a user scrolls a UITextView. On iOS 18 (and iOS 26 beta 4), TextKit 2 calls the layout fragment's draw(at:in:) on every scroll step in the UITextView, for all paragraphs. This results in terrible performance. TextKit 2 is promised to bring many performance benefits by utilizing the viewport - a new concept that represents the visible area of a text view, along with a small overscroll. However, having the draw method being constantly called almost negates all the performance benefits that viewport brings. Imagine what could happen if someone needs to add just a bit of logic to that draw method. FPS drops significantly and UX is terribly degraded. I tried optimizing this by only rendering those text line fragments which are in the viewport, by using NSTextViewportLayoutController.viewportBounds and converting NSTextLineFragment.typographicBounds to the viewport-relative coordinate space (i.e. the coordinate space of the UITextView itself). However, this patch only works on iOS 18 where the draw method is called too many times, as the viewport changes. (I may have some other problems in my implementation, but I gave up on improving those, as this can't work reliably on all OS versions since the underlying framework isn't calling the method consistently.) Is this expected? What are our options for improving performance in these areas?

In Swift 6, stricter concurrency rules can lead to challenges when making SwiftUI views conform to Equatable. Specifically, the == operator required for Equatable must be nonisolated, which means it cannot access @MainActor-isolated properties. This creates an error when trying to compare views with such properties: Error Example: struct MyView: View, Equatable { let title: String let count: Int static func ==(lhs: MyView, rhs: MyView) -> Bool { // Accessing `title` here would trigger an error due to actor isolation. return lhs.count == rhs.count } var body: some View { Text(title) } } Error Message: Main actor-isolated operator function '==' cannot be used to satisfy nonisolated protocol requirement; this is an error in the Swift 6 language mode. Any suggestions? Thanks FB: FB15753655 (SwiftUI View cannot conform custom Equatable protocol in Swift 6.)

Hi, In the WWDC25 session Elevate an app with Swift concurrency (timestamps: 8:04 and later), the StickerViewModel is shown annotated with @Observable but not @MainActor. The narration mentions that updates happen on the main thread, but that guarantee is left implicit in the calling code. In Swift 6, though, one of the major benefits is stronger compiler enforcement against data races and isolation rules. If a view model were also annotated with @MainActor, then the compiler could enforce that observable state is only updated on the main actor, preventing accidental background mutations or updates that can cause data races between nonisolated and main actor-isolated uses. Since @Observable already signals that state changes are intended to be observed (and in practice, usually by views), it seems natural that such types should also be main-actor isolated. Otherwise, we’re left with an implicit expectation that updates will always come from the main thread, but without the compiler’s help in enforcing that rule. This also ties into the concept of local reasoning that was emphasized in other Swift 6 talks (e.g. Beyond the basics of structured concurrency). With @MainActor, I can look at a view model and immediately know that all of its state is main-actor isolated. With only @Observable, that guarantee is left out, which feels like it weakens the clarity that Swift 6 is trying to promote. Would it be considered a best practice in Swift 6 to use both @Observable and @MainActor for UI-facing view models? Or is the intention that SwiftUI developers should rely on calling context to ensure main-thread updates, even if that means the compiler cannot enforce isolation? Thanks!

In iPadOS 26, Apple introduced macOS-style window control buttons (close, minimize, fullscreen) for iPad apps running in a floating window. I'm working on a custom toolbar (UIView) positioned near the top of the window, and I'd like to avoid overlapping with these new controls. However, I haven't found any public API that exposes the frame, layout margins, or safe area insets related to this new UI region. I've checked the window's safeAreaInsets, additionalSafeAreaInsets, and UIWindowSceneDelegate APIs, but none of them seem to reflect the area occupied by these buttons. Is there an officially supported way to: Get the layout information (frame, insets, or margins) of the window control buttons on iPadOS 26? Or, is there a system-defined guideline or padding value we should use to avoid overlapping this new UI? Any clarification or guidance would be appreciated!

I am trying to understand why I am seeing crash reports for my code that creates a view from a NIB like the code below. The crash occurs when referencing contentView which should have been bound when the NIB was loaded. Am I missing something here other than checking the result of the loadNibNamed function call? class MyView: NSView { @IBOutlet var contentView: NSView! init() { super.init(frame: NSRect(x: 0, y: 0, width: 84.0, height: 49.0)) commonInit() } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } private func commonInit() { Bundle.main.loadNibNamed("MyView", owner: self, topLevelObjects: nil) translatesAutoresizingMaskIntoConstraints = false contentView.translatesAutoresizingMaskIntoConstraints = false addSubview(contentView) contentView.frame = self.bounds }

For information I stumbled upon a regression with SwiftUI Slider on iOS 26. Its onEditingChanged closure might be called twice when interaction ends, with a final Boolean incorrect value of true provided to the closure. As a result apps cannot reliably rely on this closure to detect when an interaction with the slider starts or ends. I filed a feedback under FB20283439 (iOS 26.0 regression: Slider onEditingChanged closure is unreliable).

Hello, I have a number of UIViewControllers that are presented as follows: vc.modalPresentationStyle = UIModalPresentationStyle.popover vc.modalTransitionStyle = UIModalTransitionStyle.coverVertical self.present(vc, animated: true, completion: nil) The VC is designed from a Storyboard where I set the 'view' of the VC to have a .clear 'backgroundColor', I have a smaller 'Alert View' added as a subview which is what the user interacts with. In iOS 13 - iOS 18 this would present modally, not take up the entire screen and allow the user to see relevant context from the screen underneath. In iOS 26 Beta 5 and every beta prior the system injects a 'UIDropShadowView' in the View Hierarchy, this view has a solid color backdrop, either white/black depending on light/dark mode. This causes all underlying content to be blocked and essentially forces a full screen modal presentation despite the existing design. I am looking for a way to remove this solid color. I'm not sure if it's intentional or a bug / oversight. I have been able to remove it in a hacky way, I cycle the view hierarchy to find 'UIDropShadowView' and set it's backdrop to transparent. However when you swipe down to partially dismiss the view it turns to Liquid Glass when it is around 75% dismissed and then resets the background color to white/black. I tried creating a custom UIViewControllerTransitioningDelegate so that I could re-implement the existing behaviour but it's incredibly difficult to mimic the partial dismiss swipe down effect on the VC. I have also tried changing my presentation to: vc.modalPresentationStyle = UIModalPresentationStyle.overFullScreen vc.modalTransitionStyle = UIModalTransitionStyle.crossDissolve This works but then the user loses the ability to interactively swipe to dismiss. Any help would be appreciated. Thank you!

I have a SwiftUI app. It fetches records through CoreData. And I want to show some records on a widget. I understand that I need to use AppGroup to share data between an app and its associated widget. import Foundation import CoreData import CloudKit class DataManager { static let instance = DataManager() let container: NSPersistentContainer let context: NSManagedObjectContext init() { container = NSPersistentCloudKitContainer(name: "DataMama") container.persistentStoreDescriptions = [NSPersistentStoreDescription(url: FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: group identifier)!.appendingPathComponent("Trash.sqlite"))] container.loadPersistentStores(completionHandler: { (description, error) in if let error = error as NSError? { print("Unresolved error \(error), \(error.userInfo)") } }) context = container.viewContext context.automaticallyMergesChangesFromParent = true context.mergePolicy = NSMergePolicy(merge: .mergeByPropertyObjectTrumpMergePolicyType) } func save() { do { try container.viewContext.save() print("Saved successfully") } catch { print("Error in saving data: \(error.localizedDescription)") } } } // ViewModel // import Foundation import CoreData import WidgetKit class ViewModel: ObservableObject { let manager = DataManager() @Published var records: [Little] = [] init() { fetchRecords() } func fetchRecords() { let request = NSFetchRequest<Little>(entityName: "Little") do { records = try manager.context.fetch(request) records.sort { lhs, rhs in lhs.trashDate! < rhs.trashDate! } } catch { print("Fetch error for DataManager: \(error.localizedDescription)") } WidgetCenter.shared.reloadAllTimelines() } } So I have a view model that fetches data for the app as shown above. Now, my question is how should my widget get data from CoreData? Should the widget get data from CoreData through DataManager? I have read some questions here and also read some articles around the world. This article ( https://dev.classmethod.jp/articles/widget-coredate-introduction/ ) suggests that you let the Widget struct access CoreData through DataManager. If that's a correct fashion, how should the getTimeline function in the TimelineProvider struct get data? This question also suggests the same. Thank you for your reading my question.

Demo project link https://cdn.pokekara.com/int/other/1737343007_fbcdee810da429552b12ffa2644d928c.zip

Hello, In my app, I have an onboarding made of multiple steps in a NavigationStack. I also have a state variable that controls an if else root branch to show either the onboarding NavigationStack or the app content if the onboarding is finished. I noticed that when I end the onboarding (i.e. I switch to the other part of the if else root branch), the onAppear of the first View in the NavigationStack of the onboarding is called again. I don’t understand why. Is this a bug? Thanks, Axel enum Step { case one case two case three case four } struct ContentView: View { @State private var isFinished: Bool = false @State private var steps: [Step] = [] var body: some View { if isFinished { Button("Restart") { steps = [] isFinished = false } } else { NavigationStack(path: $steps) { VStack { Text("Start") .onAppear { print("onAppear: start") } Button("Go to step 1") { steps.append(.one) } } .navigationDestination(for: Step.self) { step in switch step { case .one: Button("Go to step 2") { steps.append(.two) } .onAppear { print("onAppear: step 1") } case .two: Button("Go to step 3") { steps.append(.three) } .onAppear { print("onAppear: step 2") } case .three: Button("Go to step 4") { steps.append(.four) } .onAppear { print("onAppear: step 3") } case .four: Button("End") { isFinished = true } .onAppear { print("onAppear: end") } } } } .onAppear { print("onAppear: NavigationStack") } } } }

On iPadOS 26 beta, the navigation bar can appear inset underneath the status bar (FB18241928) This bug does not happen on iOS 18. This bug occurs when a full screen modal view controller without a status bar is presented, the device orientation changes, and then the full screen modal view controller is dismissed. This bug appears to happen only on iPad, and not on iPhone. This bug happens both in the simulator and on the device. Thank you for investigating this issue.

Using desaturated mode on an image in a widget will break any links or buttons that use the image as their 'label'. Using the following will just open the app as if there was no link at all - therefore just using the fallback userActivity handler, or any .widgetURL() urls provided. Link(destination: URL(string: "bug://never-works")!) { Image("puppy") .widgetAccentedRenderingMode(.desaturated) } The same goes for buttons: Button(intent: MyDemoIntent()) { Image("puppy") .widgetAccentedRenderingMode(.desaturated) } I've tried hacky solutions like putting the link behind the image using a ZStack, and disabling hit testing on the image, but they don't work. Anything else to try? Logged as Feedback #15152620.

The following WatchOs App example is very short, but already not functioning as it is expected, when using Digital Crown (full code): import SwiftUI struct ContentView: View { let array = ["One","Two","Three","Four"] @State var selection = "One" var body: some View { Picker("Array", selection: $selection) { ForEach(array, id: \.self) { Text($0) } } } } The following 2 errors are thrown, when using Digital Crown for scrolling: ScrollView contentOffset binding has been read; this will cause grossly inefficient view performance as the ScrollView's content will be updated whenever its contentOffset changes. Read the contentOffset binding in a view that is not parented between the creator of the binding and the ScrollView to avoid this. Error: Error Domain=NSOSStatusErrorDomain Code=-536870187 "(null)" Any help appreciated. Thanks a lot.

My SwiftUI code runs fine on macOS, iOS(iPad) and larger iPhones, but will not display the detail view on smaller iPhones. Is there a way to force the smaller iPhones to display the detail view? And if not, When I put the App on the Apple store, for sale, will the Apple store be smart enough to flag the App as not appropriate for smaller iPhones, such as the SE (2nd and 3rd gen.) and prevent downloads? Thanks in advance for any guidance.

A specific image fails to load properly using UIImageView on iOS 16 and later systems, but loads normally on iOS 15 and earlier versions. Similarly, on Mac computers, this image cannot be opened on MacOS 13 and later, whereas it opens without issue on MacOS 12 and earlier. I am curious about the reasons behind this differing behavior on both iPhone and Mac.

I'm unable to find the right combination modifiers to get drag and drop to work using the new .draggable(containerItemID:) and dragContainer(for:in:selection:_:) modifiers. The drag is initiated with the item's ID, the item is requested from the .dragContainer modifier, but the drop closure is never triggered. Minimal repro: struct Item: Identifiable, Codable, Transferable { var id = UUID() var value: String static var transferRepresentation: some TransferRepresentation { CodableRepresentation(contentType: .tab) } } struct DragDrop: View { @State var items: [Item] = [ Item(value: "Hello"), Item(value: "world"), Item(value: "something"), Item(value: "else") ] var body: some View { List(items) { item in HStack { Text(item.value) Spacer() } .contentShape(Rectangle()) .draggable(containerItemID: item.id) .dropDestination(for: Item.self) { items, session in print("Drop: \(items)") } } .dragContainer(for: Item.self) { itemID in print("Drag: \(itemID)") return items.filter { itemID == $0.id } } } } #Preview("Simple") { DragDrop() }