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

iOS 18 broke some functionality in my Objective-C app with regard to using the DatePicker. The key lines are as follows: datePicker.timeZone = [NSTimeZone timeZoneForSecondsFromGMT:timezoneOffset]; datePicker.date = [NSDate date]; When timezoneOffset is -29380, the value for San Francisco, the Date Picker is a whole MONTH off. It shows November instead of December. But when it is -29359, the value for Seattle, which is in the same time zone (PST), it shows the correct month. In fact, even towns surrounding San Francisco usually return the correct value. Some other cities in other time zones also cause the Date Picker to be a month off.

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.

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)") } } }

When I update a variable inside my model that is marked @Transient, my view does not update with this change. Is this normal? If I update a non-transient variable inside the model at the same time that I update the transient one, then both changes are propagated to my view. Here is an example of the model: @Model public class WaterData { public var target: Double = 3000 @Transient public var samples: [HKQuantitySample] = [] } Updating samples only does not propagate to my view.

Hi there! I'm making an app that stores data for the user's profile in SwiftData. I was originally going to use UserDefaults but I thought SwiftData could save Images natively but this is not true so I really could switch back to UserDefaults and save images as Data but I'd like to try to get this to work first. So essentially I have textfields and I save the values of them through a class allProfileData. Here's the code for that: import SwiftData import SwiftUI @Model class allProfileData { var profileImageData: Data? var email: String var bio: String var username: String var profileImage: Image { if let data = profileImageData, let uiImage = UIImage(data: data) { return Image(uiImage: uiImage) } else { return Image("DefaultProfile") } } init(email:String, profileImageData: Data?, bio: String, username:String) { self.profileImageData = profileImageData self.email = email self.bio = bio self.username = username } } To save this I create a new class (I think, I'm new) and save it through ModelContext import SwiftUI import SwiftData struct CreateAccountView: View { @Query var profiledata: [allProfileData] @Environment(\.modelContext) private var modelContext let newData = allProfileData(email: "", profileImageData: nil, bio: "", username: "") var body: some View { Button("Button") { newData.email = email modelContext.insert(newData) try? modelContext.save() print(newData.email) } } } To fetch the data, I originally thought that @Query would fetch that data but I saw that it fetches it asynchronously so I attempted to manually fetch it, but they both fetched nothing import SwiftData import SwiftUI @Query var profiledata: [allProfileData] @Environment(\.modelContext) private var modelContext let fetchRequest = FetchDescriptor<allProfileData>() let fetchedData = try? modelContext.fetch(fetchRequest) print("Fetched count: \(fetchedData?.count ?? 0)") if let imageData = profiledata.first?.profileImageData, let uiImage = UIImage(data: imageData) { profileImage = Image(uiImage: uiImage) } else { profileImage = Image("DefaultProfile") } No errors. Thanks in advance

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.

I have SwiftData models containing arrays of Codable structs that worked fine before adding CloudKit capability. I believe they are the reason I started seeing errors after enabling CloudKit. Example model: @Model final class ProtocolMedication { var times: [SchedulingTime] = [] // SchedulingTime is Codable // other properties... } After enabling CloudKit, I get this error logged to the console: 'NSKeyedUnarchiveFromData' should not be used to for un-archiving and will be removed in a future release CloudKit Console shows this times data as "plain text" instead of "bplist" format. Other struct/enum properties display correctly (I think) as "bplist" in CloudKit Console. The local SwiftData storage handled these arrays fine - this issue only appeared with CloudKit integration. What's the recommended approach for storing arrays of Codable structs in SwiftData models that sync with CloudKit?

On iOS 18, while on a modal screen, if the scrolling starts on a button, that button gets pressed, outside of a modal this doesn't reproduce, also not reproducible on older iOS versions, neither on modals or outside of them. The code to reproduce the issue: import SwiftUI struct ContentView: View { @State var presentModal = false var body: some View { Button(action: { presentModal = true }, label: { Text("open modal") }) .sheet(isPresented: $presentModal, content: { ScrollView { ForEach(0..<100, id: \.self) { index in Button(action: { print("Button \(index) tapped!") }) { Text("Button \(index)") .frame(maxWidth: .infinity) .frame(height: 100) .background(randomColor(for: index)) .padding(.horizontal) } } } }) } func randomColor(for index: Int) -> Color { let hue = Double(index % 100) / 100.0 return Color(hue: hue, saturation: 0.8, brightness: 0.8) } } #Preview { ContentView() }

When I create a SwiftUI toolbar item with placement of .keyboard on iOS 26, the item appears directly on top of and in contact with the keyboard. This does not look good visually nor does it match the behavior seen in Apple's apps, such as Reminders. Adding padding to the contents of the toolbar item only expands the size of the item but does not separate the capsule background of the item from the keyboard. How can I add vertical padding or spacing to separate the toolbar item capsule from the keyboard?

I want a different color, one from my asset catalog, as the background of my first ever swift UI view (and, well, swift, the rest of the app is still obj.c) I've tried putting the color everywhere, but it does't take. I tried with just .red, too to make sure it wasn't me. Does anyone know where I can put a color call that will actually run? Black looks very out of place in my happy app. I spent a lot of time making a custom dark palette. TIA KT @State private var viewModel = ViewModel() @State private var showAddSheet = false var body: some View { ZStack { Color.myCuteBg .ignoresSafeArea(.all) NavigationStack { content .navigationBarTitleDisplayMode(.inline) .toolbar { ToolbarItem(placement: .principal) { Image("cute.image") .font(.system(size: 30)) .foregroundColor(.beigeTitle) } } } .background(Color.myCuteBg) .presentationBackground(.myCuteBg) .sheet(isPresented: $showAddSheet) { AddView() } .environment(viewModel) .onAppear { viewModel.fetchStuff() } } .tint(.cuteColor) } @ViewBuilder var content: some View { if viewModel.list.isEmpty && viewModel.anotherlist.isEmpty { ContentUnavailableView( "No Content", image: "stop", description: Text("Add something here by tapping the + button.") ) } else { contentList } } var contentList: some View { blah blah blah } } First I tried the background, then the presentation background, and finally the Zstack. I hope this is fixed because it's actually fun to build scrollable content and text with swiftUI and I'd been avoiding it for years.

Generic parameter 'V' could not be inferred ERROR

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

In iOS 18.4.1, DocumentGroup contains the DocumentView twice. (this may cause issues with alerts) To reproduce (iOS 18.4): In XCode Version 16.3 (16E140), create new project. Choose iOS, "Document App". No need to make code changes. Compile and run app on iOS 18.4 (simulator or device). in iOS (sim or device): Tap create document (once the app launched). in XCode: click "Debug View Hierarchy" in XCode: rotate the view Hierarch to reveal duplicated Document View hierarchies (2 Document Hosting Controllers), see screenshot. This probably affects alert view... I get warnings and it does not work properly (used to work ok on previous versions). Previous versions To compare with previous versions of iOS, run the same code and procedure on iOS 18.3 for example (see screenshot). Will report on Feedback assistant as well...

I've posted a couple times now about major issues I'm having with NSLayoutManager and have written to Apple for code-level support, but no one at Apple has responded to me in more than two weeks. So I'm turning to the community again for any help whatsoever. I'm fairly certain it's a real bug in TextKit. If I'm right about that, I'd love for anyone at Apple to take an interest. And better yet, if I'm wrong (and I hope I am), I'd be incredibly grateful to anyone who can point out where my mistake lies! I've been stuck with this bug for weeks on end. The crux of the issue is that I'm getting what seemed to be totally incompatible results from back to back calls to textContainer(forGlyphAt:effectiveRange:) and lineFragmentRect(forGlyphAt:effectiveRange:withoutAdditionalLayout:)... I'd lay out my text into a fairly tall container of standard page width and then query the layout manager for the text container and line fragment rect for a particular glyph (a glyph that happens to fall after many newlines). Impossibly, the layout manager would report that that glyph was in said very tall container, but that the maxY of its lineFragmentRect was only at 14 points (my NSTextView's isFlipped is true, so that's 14 points measuring from the top down). After investigating, it appears that what is happening under the hood is NSLayoutManager is for some reason laying out text back into the first container in my series of containers, rather than overflowing it into the next container(s) and/or giving me a nil result for textContainer(forGlyphAt:...) I've created a totally stripped down version of my project that recreates this issue reliably and I'm hoping literally anyone at Apple will respond to me. In order to recreate the bug, I've had to build a very specific set of preview data - namely some NSTextStorage content and a unique set of NSTextViews / NSTextContainers. Because of the unique and particular setup required to recreate this bug, the code is too much to paste here (my preview data definition is a little unwieldy but the code that actually processes/parses it is not). I can share the project if anyone is able and willing to look into this with me. It seems I'm not able to share a .zip of the project folder here but am happy to email or share a dropbox link.

We have encountered a problem on iOS 26. When switching to dark mode, the color of all subviews (font color, background color, etc.) of the Sidebar (Primary View) of UISplitViewController will not change. For example, if it is set to the color of UIColor.label, it will always be black and will not be white in dark mode. On Xcode, just create a UISplitViewController in Storyboard without changing any settings, and run it directly to see the following: The title of the Navigation Bar defaults to the label color, and it is still black after switching to dark mode. There is no such problem in the Secondary View or other places. This problem has occurred since iOS 26 beta 3, and iOS 26 beta 4 is now the same. But beta 1 and beta 2 have no problem. I'm not sure if this is a bug, or if there is something that needs to be changed to adapt to iOS 26?

I have a few view controllers in a large UIKit application that previously started showing content right below the bottom of the top navigation toolbar. When testing the same code on iOS 26, these same views have their content extend under the navigation bar and toolbar. I was able to fix it with: if #available(iOS 26, *, *) { self.edgesForExtendedLayout = [.bottom] } when running on iOS 26. I also fixed one or two places where the main view was anchored to self.view.topAnchor instead of self.view.safeAreaLayoutGuide.topAnchor. Although this seems to work, I wonder if this was an intended change in iOS 26 or just a temporary bug in the beta that will be resolved. Were changes made to the safe area and edgesForExtendedLayout logic in iOS 26? If so, is there a place I can see what the specific changes were, so I know my code is handling it properly? Thanks!

I honestly thought I was getting somewhere with this, but alas, no. Every time I do anything in my List of ItemRows it jumps back to the top. Here's the setup: DataService.swift: final class DataService { static let shared = DataService() private init() {} let coreData: CoreData = CoreData() let modelData: ModelData = ModelData() } ModelData.swift: @Observable class ModelData: ObservableObject { var allItems: [ItemDetails] var standardItems: [ItemDetails] var archivedItems: [ItemDetails] init() { allItems = [] standardItems = [] archivedItems = [] } func getInitialData() { // Get all items, then split them into archived and non-archived sets, because you can't use `.filter` in a view... allItems = dataService.coreData.getAllItems() standardItems.append(contentsOf: allItems.filter { !$0.archived }) archivedItems.append(contentsOf: allItems.filter { $0.archived }) } } MainApp.swift: // Get access to the data; this singleton is a global as non-view-based functions, including the `Scene`, need to access the model data let dataService: DataService = DataService.shared @main struct MainApp: App { // Should this be @ObservedObject or @StateObject? @ObservedObject private var modelData: ModelData = dataService.modelData // I would use @StateObject if the line was... //@StateObject private var modelData: ModelData = ModelData() // right? // But then I couldn't use modelData outside of the view hierarchy var body: some Scene { WindowGroup { ZStack { MainView() .environment(modelData) } } .onAppear { modelData.getInitialData() } } } MainView.swift: struct MainView: View { @Environment(ModelData.self) private var modelData: ModelData var body: some View { ... ForEach(modelData.standardItems) { item in ItemRow(item) } ForEach(modelData.archivedItems) { item in ItemRow(item) } } } ItemRow.swift: struct ItemRow: View { @Environment(\.accessibilityDifferentiateWithoutColor) private var accessibilityDifferentiateWithoutColor var item: ItemDetails @State private var showDeleteConfirmation: Bool = false var body: some View { // Construct the row view // `accessibilityDifferentiateWithoutColor` is used within the row to change colours if DWC is enabled, e.g. use different symbols instead of different colours for button images. // Add the .leftSwipeButtons, .rightSwipeButtons, and .contextMenu // Add the .confirmationDialog for when I want to ask for confirmation before deleting an item } } Now, the problems: Swipe an item row, tap one of the buttons, e.g. edit, and the list refreshes and jumps back to the top. In the console I see: ItemRow: @self, @identity, _accessibilityDifferentiateWithoutColor changed. Why did accessibilityDifferentiateWithoutColor change? The setting in Settings > Accessibility > Display & Text Size has not been changed, so why does the row's view think it changed? With a .confirmationDialog attached to the end of the ItemRow (as seen in the code above), if I swipe and tap the delete button the list refreshes and jumps back to the top again. In the console I see: ItemRow: @self, @identity, _accessibilityDifferentiateWithoutColor, _showDeleteConfirmation changed. Right, it changed for the one row that I tapped the button for. Why does every row get redrawn? I already had to shift from using the colorScheme environment variable to add new asset colours with light and dark variants to cover this, but you can't do that with DWC. Honestly, managing state in SwiftUI is a nightmare. I had zero problems until iOS 26 started removing one or two rows when I scrolled, and the fix for that - using @Statebject/@ObservedObject - has introduced multiple further annoying, mind-bending problems, and necessitated massive daily refactorings. And, of course, plenty of my time islost trying to figure out where a problem is in the code because "The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions"...

I have arrived at a certain architectural solution for my SwiftUI code which is helped by, in certain situations, modifying the state while the body is being evaluated. Of course, I am always open to realizing that a given solution may be creating difficulties precisely because it is fundamentally ill-advised. However, in this post I won't attempt to explain the details of my architecture or justify my reasoning regarding wanting to change the state in the middle of a view update. I just want to ask, why exactly is it prohibited? Is it not rather like normal recursion, which can of course produce infinite loops if done wrong but which is perfectly logically sound as long as the recursing function eventually stabilizes?

Hello, I'm experiencing a navigation bar positioning issue with my UIKit iPad app on iPadOS 26 (23A340) using Xcode 26 (17A321). The navigation bar positions under the status bar initially, and after orientation changes to landscape, it positions incorrectly below its expected location. This occurs on both real device (iPad mini A17 Pro) and simulator. My app uses UIKit + Storyboard with a Root Navigation Controller. A stack overflow post has reproduce the bug event if it's not in the same configuration: https://stackoverflow.com/questions/79752945/xcode-26-beta-6-ipados-26-statusbar-overlaps-with-navigationbar-after-presen I have checked all safe areas and tried changing some constraints, but nothing works. Have you encountered this bug before, or do you need additional information to investigate this issue?