SwiftUI List performance

Description I've encountered a consistent hang/freeze issue in SwiftUI applications when using nested LazyVStack containers with Accessibility Inspector (simulator) or VoiceOver (physical device) enabled. The application becomes completely unresponsive and must be force-quit. Importantly, this hang occurs in a minimal SwiftUI project with no third-party dependencies, suggesting this is a framework-level issue with the interaction between SwiftUI's lazy view lifecycle and the accessibility system. Reproduction Steps I've created a minimal reproduction project available here: https://github.com/pendo-io/SwiftUI_Hang_Reproduction To Reproduce: Create a SwiftUI view with the following nested LazyVStack structure: struct NestedLazyVStackView: View { @State private var outerSections: [Int] = [] @State private var innerRows: [Int: [Int]] = [:] var body: some View { ScrollView { LazyVStack(alignment: .leading, spacing: 24) { ForEach(outerSections, id: .self) { section in VStack(ali

I'm building out a live activity that has a button which is meant to update the content state of the Live Activity. It calls a LiveActivityIntent that runs in the app process. The push server starts my live activity and the buttons work just fine. I pass the push token back to the server for further updates and when the next update is pushed by the server the buttons no longer work. With the debugger I'm able to verify the app intent code runs and passes the updated state to the activity. However the activity never updates or re-renders. There are no logs in Xcode or Console.app that indicates what the issue could be or that the update is ignored. I have also tried adding the frequent updates key to my plist with no change. I'm updating the live activity in the LiveActivityIntent like this: public func perform() async throws -> some IntentResult { let activities = Activity.activities for activity in activities { let currentState = activity.content.state let currentIndex = currentState.pageIndex ??

Overview In iOS 26, a List embedded in a NavigationStack inside a TabView exhibits a visual glitch when switching tabs. When the list is scrolled such that some rows are partially obscured by the navigation bar, the system correctly applies a fade/opacity effect to those rows. However, if the user switches to another tab while rows are in this partially obscured (faded) state, those rows briefly flash at full opacity during the tab transition before disappearing. This flash is visually distracting and appears to be inconsistent with the intended scroll-edge opacity behavior. The issue occurs only for rows partially obscured by the navigation bar. Rows partially obscured by the tab bar do not exhibit this flashing behavior. Steps to Reproduce: Run the attached minimal reproduction on iOS 26. Open the first tab. Scroll the list so that some rows are partially hidden behind the navigation bar (showing the native faded appearance). While rows are in this partially faded state, switch to

Hi all, When navigating between two screens where the first uses .inline and the second .large title display mode, the NavigationBar shows visible resizing glitches during the push animation. This is especially noticeable when using a custom background color (e.g. yellow) via UINavigationBarAppearance or .toolbarBackground(Color.yellow, for: .navigationBar). I’m already using the same appearance for standard, scrollEdge, and compact, with configureWithOpaqueBackground(), but the issue remains. Is this a known UIKit or SwiftUI issue? Any recommended workaround? Thanks.

I just spend the morning debugging LocationButton and the associated CLLocationManagerDelegate only to realise that it works perfectly in iOS 18.5 but no longer works for me in iOS 26.0, 26.2 or 26.2.1 (the latter on-device). It does work when I run my app on macOS 26.2 (Designed for iPad). Is there a change in behaviour or requirements on iOS I am missing? On iOS 18.5 I observe that the authorisation status changes from .notDetermined to .authorizedWhenInUse after the LocationButton has been tapped and my delegate is able to obtain the location through locationManager(_ , didUpdateLocations:). On iOS 26.x the authorisation status remains .notDetermined and my delegate receives locationManager(_:didFailWithError:) with error code .denied. Setting NSLocationWhenInUseUsageDescription in my Info.plistdid not help. Just in case ;) FB21798098 (SwiftUI LocationButton fails to acquire authorization on iOS 26)

On iOS 26.01 & 26.2, the system keyboard shows uneven horizontal padding: Leftmost key column touches the screen edge Right side has visible padding This behavior is reproducible: In existing apps In a brand-new demo app In both UIKit and SwiftUI Xcode: 26.0.1 & 26.2 iOS: 26.0.1 & 26.2 Simulator Devices tested: iPhone 15 / iPhone 15 Pro Keyboard types: .numberPad, .decimalPad Frameworks: UIKit, SwiftUI

In SwiftUI, it is recommended not to store ViewBuilder closures in sub-views but instead evaluate them directly in init and store the result (example: https://www.youtube.com/watch?v=yXAQTIKR8fk). That has the advantage, as I understand it, that the closure doesn't need to be re-evaluated on every layout pass. On the other side, identity is a very important topic in SwiftUI to get the UI working properly. Now I have this generic view I'm using with a closure which is displayed in two places (HStack & VStack). Should I store the closure result and get the performance improvements, or evaluate it in place and get correct identities (if that is even an issue)? Simplified example: struct DynamicStack: View { @ViewBuilder var content: () -> Content var body: some View { ViewThatFits(in: .horizontal) { HStack { content() } VStack { content() } } } } vs struct DynamicStack: View { @ViewBuilder var content: Content var body: some View { ViewThatFits(in: .horizontal) { HStack { conten

Note: This document is specifically focused on what happens after a DEXT has passed its initial code-signing checks. Code-signing issues are dealt with in other posts. Preliminary Guidance: Using and understanding DriverKit basically requires understanding IOKit, something which isn't entirely clear in our documentation. The good news here is that IOKit actually does have fairly good foundational documentation in the documentation archive. Here are a few of the documents I'd take a look at: IOKit Fundamentals IOKit Device Driver Design Guidelines Accessing Hardware From Applications Special mention to QA1075: Making sense of IOKit error codes,, which I happened to notice today and which documents the IOReturn error format (which is a bit weird on first review). Those documents do not cover the full DEXT loading process, but they are the foundation of how all of this actually works. Understanding the IOKitPersonalities Dictionary The first thing to understand here is that the IOKitPersonalities is called that