On pressing the secondary button on my ShieldConfigurationExtension, I remove the shields by setting shields in the named ManagedStore to nil in my ShieldActionExtension. // ShieldActionExtension.swift let store = ManagedSettingsStore() store.shield.applications = nil store.shield.applicationCategories = nil Now after some duration I want to re-apply the shields again for which I do the following: // ShieldActionExtension.swift DispatchQueue.main.asyncAfter(deadline: .now() + unlockDuration) { [weak self] in self?.reapplyShields(for: sessionId, application: application) } private func reapplyShields(for sessionId: String, application: ApplicationToken) { store.shield.applications = Set([application]) } Followed by the completionHandler: // ShieldActionExtension.swift completionHandler(.defer) Now the expectation is ShieldConfigurationExtension should be re-triggered with store.shield.applications = Set([application]), however I see the default iOS screen time shield. This behavior is experience when the blocked app is running in the foreground. However, if I close and re-open the blocked app - the ShieldConfigurationExtension is trigerred again correctly. If I do a completionHandler(.none) instead, the overriden configuration method in ShieldConfigurationExtension is not triggered. How do I make sure ShieldConfigurationExtension is triggered if the blocked app is running in the foreground when the shields are re-applied again?

Is there any way I can know that another app has gone full screen? Please note that this is not what NSWindowDidEnterFullScreenNotification does, that only works for my own windows. As for why I need to know: Say you're playing a YouTube video full screen. The video fills up the main display, and if there's a second display, it goes black. Well, mostly. I have a utility app with small status windows that remain on top. I'd like to be polite and hide them in this scenario.

I have this sample code import SwiftUI struct ContentView: View { var body: some View { ParentView() } } struct ParentView: View { @State var id = 0 var body: some View { VStack { Button { id+=1 } label: { Text("update id by 1") } TestView(id: id) } } } struct TestView: View { var sequence = DoubleGenerator() let id: Int var body: some View { VStack { Button { sequence.next() } label: { Text("print next number").background(content: { Color.green }) } Text("current id is \(id)") }.task { for await number in sequence.stream { print("next number is \(number)") } } } } final class DoubleGenerator { private var current = 1 private let continuation: AsyncStream<Int>.Continuation let stream: AsyncStream<Int> init() { var cont: AsyncStream<Int>.Continuation! self.stream = AsyncStream { cont = $0 } self.continuation = cont } func next() { guard current >= 0 else { continuation.finish() return } continuation.yield(current) current &*= 2 } } the print statement is only ever executed if I don't click on the update id by 1 button. If i click on that button, and then hit the print next number button, the print statement doesn't print in the xcode console. I'm thinking it is because the change in id triggered the view's init function to be called, resetting the sequence property and so subsequent clicks to the print next number button is triggering the new version of sequence but the task is still referring its previous version. Is this expected behaviour? Why in onChange and Button, the reference to the properties is always up to date but in .task it is not?

Hi all, I’m working on the alternative marketplace app and using MarketplaceKit and ActionButton. On the main page, users see a list of items, each with an ActionButton. I’m experiencing significant UI hangs when this page loads. What I’ve Observed: Instruments (Hangs and SwiftUI profilers) show that the hangs occur when ActionButton instances are rendered. Creating or updating ActionButton properties triggers synchronous XPC communication with the managedappdistributiond process on the main thread. Each XPC call takes about 2-3 ms, but with many ActionButtons, the cumulative delay is noticeable and impacts the user experience. I have tested on iOS 18.7 and 26.1, using Xcode 26.2. But in general, the issue is not specific to a device or iOS version. The problem occurs in both Debug and Release builds. Hangs can be severe depending on the number of items in a section, generally between 200-600 ms, resulting in noticeable lag and a poor user experience. I haven’t found much documentation on the internal workings of ActionButton or why these XPC calls are necessary. I have tried Lazy loading and reducing the amount of ActionButton instances. That makes the hangs less noticeable, but there are still hitches when new sections with items are added to the view hierarchy. This is not an issue with SwiftUI or view updates in general. If I replace ActionButton with UIButton, the hangs are completely gone. Minimal Example: Here’s a simplified version of how I’m using ActionButton in my SwiftUI view. The performance issue occurs when many of these views are rendered in the list: struct ActionButtonView: UIViewRepresentable { let viewModel: ActionButtonViewModel let style: ActionButtonStyle func makeUIView(context: Context) -> ActionButton { return ActionButton(action: viewModel.action) } func updateUIView(_ uiView: ActionButton, context: Context) { uiView.update(\.size, with: context.coordinator.size) uiView.update(\.label, with: viewModel.title) uiView.update(\.isEnabled, with: context.environment.isEnabled) uiView.update(\.fontSize, with: style.scaledFont(for: viewModel.title)) uiView.update(\.backgroundColor, with: style.backgroundColor.color) uiView.update(\.tintColor, with: style.textAndIconColor) uiView.update(\.cornerRadius, with: style.cornerRadius(height: uiView.frame.size.height)) uiView.update(\.accessibilityLabel, with: viewModel.accessibilityLabel) uiView.update(\.accessibilityTraits, with: .button) uiView.update(\.accessibilityUserInputLabels, with: viewModel.accesibilityUserInputLabels) uiView.update(\.tintAdjustmentMode, with: .normal) } func makeCoordinator() -> Coordinator { Coordinator(viewModel: viewModel) } class Coordinator: NSObject { ... } } extension ActionButton { fileprivate func update<T>(_ keyPath: WritableKeyPath<ActionButton, T>, with value: T) where T: Equatable { if self[keyPath: keyPath] == value { return } var mutableSelf = self mutableSelf[keyPath: keyPath] = value } } From the Instruments samples, it’s clear that the performance issues originate from NativeActionButtonView.makeUIView(context:) and NativeActionButtonView.updateUIView(_:context:). The following stack trace is common for all blocking calls, indicating that NSXPCConnection is being used for cross-process communication: mach_msg2_trap mach_msg2_internal mach_msg_overwrite mach_msg _dispatch_mach_send_and_wait_for_reply dispatch_mach_send_with_result_and_wait_for_reply xpc_connection_send_message_with_reply_sync __NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY__ -[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:] ___forwarding___ _CF_forwarding_prep_0 __35-[_UISlotView _setContentDelegate:]_block_invoke_2 -[_UISlotView _updateContent] ... NativeActionButtonView.sizeThatFits(_:uiView:context:) protocol witness for UIViewRepresentable.sizeThatFits(_:uiView:context:) in conformance NativeActionButtonView ... Additionally, the Thread State Trace shows that during the XPC calls, the main thread is blocked and is later made runnable by managedappdistributiond. This confirms that the app is indeed communicating with the managedappdistributiond process. Since there is limited documentation and information available, I have some questions: Is there a way to batch update ActionButton properties to reduce the number of XPC calls? Is it possible to avoid or defer XPC communication when creating/updating ActionButton instances? Are there best practices for efficiently rendering large numbers of ActionButtons in SwiftUI? Is this a known issue, and are there any recommended workarounds? Can Apple provide more details on ActionButton’s internal behavior and XPC usage? Any insights or suggestions would be greatly appreciated!

Hello everyone, When I press Control + Space on my Bluetooth keyboard to trigger input method switching, the accessory view fails to appear. This prevents me from quickly identifying the current input method type. Upon inspecting the View Hierarchy, I noticed that UICursorAccessoryView is not being created. For context, my input method responder inherits from UIResponder and conforms to the UITextInputTraits, UIKeyInput, and UITextInput protocols. The accessory view displays normally during accented input and Chinese input. Could you please guide me on how to troubleshoot this issue?

I failed to resize the icon image from instances of NSRunningApplication. I can only get 32×32 while I'm expecting 16×16. I felt it unintuitive in first minutes… Then I figured out that macOS menu seems not allowing many UI customizations (for stability?), especially in SwiftUI. What would be my best solution in SwiftUI? Must I write some boilerplate SwiftUI-AppKit bridging?

I'm building an app with a min iOS of 26. In iOS 26, bottom toolbars are attached to the NavStack where in ios18 they were attached to a vstack or scrollview. But in ios26 if the toolbar is attached to something like a vstack, it displays too low on an iPhone 16e and sits behind the tab bar. Fine. But with a parent-child view, the parent has a NavStack (with bottom toolbar attached) and the child view doesn't have a NavStack. So...that's a problem. The functional impact of this contradiction (bottom toolbars go on the NavStack and child views don't have a NavStack) is actually two problems. the parent view bottom toolbar shows up on the child view (because it's the closest NavStack) whether it's appropriate on the view or not. the child view can't have a viable bottom toolbar because without a NavStack any buttons are hidden behind the tab view. The second problem can be worked around using a top toolbar or safe area edge inset instead of a toolbar at the bottom or something. But those don't solve the first problem of the parent view bleeding through. So, I have to be crazy, right. Apple wouldn't create a scenario where bottom toolbars are not functional on parent-child views in ios26. Any suggestions that I'm missing?

When the guy was talking about structural identity, starting at about 8:53, he mentioned how the swiftui needs to guarantee that the two views can't swap places, and it does this by looking at the views type structure. It guarantees that the true view will always be an A, and the false view will always be a B. Not sure exactly what he means because views can't "swap places" like dogs. Why isn't just knowing that some View is shown in true, and another is shown in false, enough for its identity? e.g. The identity could be "The view on true" vs "The view on false", same as his example with "The dog on the left" vs "The dog on the right"

I have a UIHostingController on which I have set: hostingController.sizingOptions = [.intrinsicContentSize] The size of my SwiftUI content changes with animation (I update a @Published property on an ObservableObject inside a withAnimation block). However, I notice that my hostingController.view just jumps to the new frame without animating the change. Question: how can I animate the frame changes in UIHostingController that are caused by sizingOptions = [.intrinsicContentSize]

We noticed in multiple apps that readableContentGuide is way too wide on iOS 26.x. Here are changes between iPad 13inch iOS 18.3 and the same device iOS 26.2 (but this affects also iOS 26.0 and iOS 26.1): 13 inch iOS 18 Landscape ContentSizeCategory: XS, Width: 1376.0 , Readable Width: 560.0 S, Width: 1376.0 , Readable Width: 600.0 M, Width: 1376.0 , Readable Width: 632.0 L, Width: 1376.0 , Readable Width: 664.0 XL, Width: 1376.0 , Readable Width: 744.0 XXL, Width: 1376.0 , Readable Width: 816.0 XXXL,Width: 1376.0 , Readable Width: 896.0 A_M, Width: 1376.0 , Readable Width: 1096.0 A_L, Width: 1376.0 , Readable Width: 1280.0 A_XL,Width: 1376.0 , Readable Width: 1336.0 13 inch iOS 26 Landscape ContentSizeCategory: XS, Width: 1376.0 , Readable Width: 752.0 S, Width: 1376.0 , Readable Width: 800.0 M, Width: 1376.0 , Readable Width: 848.0 L, Width: 1376.0 , Readable Width: 896.0 XL, Width: 1376.0 , Readable Width: 1000.0 XXL, Width: 1376.0 , Readable Width: 1096.0 XXXL,Width: 1376.0 , Readable Width: 1200.0 A_M, Width: 1376.0 , Readable Width: 1336.0 The code I used: class ViewController: UIViewController { lazy var readableView: UIView = { let view = UIView() view.backgroundColor = .systemBlue view.translatesAutoresizingMaskIntoConstraints = false return view }() override func viewDidLoad() { super.viewDidLoad() view.addSubview(readableView) NSLayoutConstraint.activate([ readableView.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor), readableView.leadingAnchor.constraint(equalTo: view.readableContentGuide.leadingAnchor), readableView.trailingAnchor.constraint(equalTo: view.readableContentGuide.trailingAnchor), readableView.bottomAnchor.constraint(equalTo: view.safeAreaLayoutGuide.bottomAnchor) ]) } override func viewDidLayoutSubviews() { super.viewDidLayoutSubviews() if readableView.frame.width > 0 { let orientation = UIDevice.current.orientation print(""" ContentSizeCategory: \(preferredContentSizeCategoryAsString()) Width: \(view.frame.width) , Readable Width: \(readableView.frame.width), Ratio: \(String(format: "%.1f", (readableView.frame.width / view.frame.width) * 100))% """) } } func preferredContentSizeCategoryAsString() -> String { switch UIApplication.shared.preferredContentSizeCategory { case UIContentSizeCategory.accessibilityExtraExtraExtraLarge: return "A_XXXL" case UIContentSizeCategory.accessibilityExtraExtraLarge: return "A_XXL" case UIContentSizeCategory.accessibilityExtraLarge: return "A_XL" case UIContentSizeCategory.accessibilityLarge: return "A_L" case UIContentSizeCategory.accessibilityMedium: return "A_M" case UIContentSizeCategory.extraExtraExtraLarge: return "XXXL" case UIContentSizeCategory.extraExtraLarge: return "XXL" case UIContentSizeCategory.extraLarge: return "XL" case UIContentSizeCategory.large: return "L" case UIContentSizeCategory.medium: return "M" case UIContentSizeCategory.small: return "S" case UIContentSizeCategory.extraSmall: return "XS" case UIContentSizeCategory.unspecified: return "U" default: return "D" } } } Please advise, it feels completely broken. Thank you.

既然 iOS 26 必须启用 UIScene 生命周期，那么 UIAlertView/UIActionSheet 就实际已经无法使用了，所以为什么不直接将它们标记为不可用，或者直接移除？

When I navigate to a player controller and switch to landscape mode, and then pop it and choose portrait mode, the tabBar encounters an issue

I've integrated PencilKit into my app, but I've noticed that shape recognition isn't working during drawing, even though it works perfectly in the Notes app. Is this a bug, or is shape recognition simply not supported in PencilKit for Swift?

I just found a weird bug: If you place a Text view using .foregroundStyle(.secondary), .tertiary, or other semantic colors inside a ScrollView, and apply a Material background clipped to an UnevenRoundedRectangle, the text becomes invisible. This issue does not occur when: The text uses .primary or explicit colors (e.g., .red, Color.blue), or The background is clipped to a standard shape (e.g., RoundedRectangle). A minimal reproducible example is shown below: ScrollView{ VStack { Image(systemName: "globe") .imageScale(.large) .foregroundStyle(.tint) Text("Hello World.") .font(.system(size: 15)) .foregroundStyle(.quinary) } } .padding() .frame(height: 100) .background(Material.regular) .clipShape(UnevenRoundedRectangle(topLeadingRadius: 10,bottomLeadingRadius: 8,bottomTrailingRadius:8, topTrailingRadius: 8))

I have a text editor where I replace the selected text when a button is tapped. Most of the time it works, but sometimes the new text is inserted at the end of the text instead of at the selected position. Is this a bug? @Bindable var note: Richnote @State private var selection = AttributedTextSelection() var body: some View { VStack { TextEditor(text: $note.content, selection: $selection) Button("Replace text") { let textToInsert = "A long text that makes me think lalala" note.content.replaceSelection(&selection, withCharacters: textToInsert) }

I have an existing iOS app with MapKit. It always shows the current user location with UserAnnotation. But the same isn't true for macOS. I have this sample macOS application in SwiftUI. In the following, the current user location with a large blue dot appears only occasionally. It won't, 19 of 20 times. Why is that? I do have a location privacy key in Info.plist. And the Location checkbox is on under Signing & Capabilities. import SwiftUI import MapKit struct ContentView: View { @State private var markerItems: [MarkerItem] = [ MarkerItem(name: "Farmers Market 1", lat: 35.681, lon: 139.691), MarkerItem(name: "Farmers Market 2", lat: 35.685, lon: 139.695), MarkerItem(name: "Farmers Market 3", lat: 35.689, lon: 139.699) ] @State private var position: MapCameraPosition = .automatic var body: some View { Map(position: $position) { UserAnnotation() ForEach(markerItems, id: \.self) { item in Marker(item.name, coordinate: CLLocationCoordinate2D(latitude: item.lat, longitude: item.lon)) } } .mapControlVisibility(.hidden) .mapStyle(.standard(elevation: .realistic)) .ignoresSafeArea() } } #Preview { ContentView() } struct MarkerItem: Hashable { let name: String let lat: Double let lon: Double }

Hi, I am looking to display (in SwiftUI) the Tabview page dots like in the weather app in the toolbar, an important thing is I want to keep page controls by tapping and scrubbing. Actually, I want to do what's on Apple Design's Page Controls page; here's the link and a photo of what I'd like to do. Could you help me? https://developer.apple.com/design/human-interface-guidelines/page-controls

I'm looking to support toggleable bullet and numbered lists in my IOS 26 app. currently my text editor looks like this @Binding var text: AttributedString var requestFocus: Bool = false @State private var selection = AttributedTextSelection() @FocusState private var isFocused: Bool var body: some View { TextEditor(text: $text, selection: $selection) .scrollContentBackground(.hidden) .background(Color.clear) .focused($isFocused) .safeAreaInset(edge: .bottom) { if isFocused { FormattingToolbar(text: $text, selection: $selection) .padding(.horizontal) .padding(.vertical, 8) .background(Color(UIColor.systemBackground)) } } .onChange(of: requestFocus) { _, newValue in if newValue { isFocused = true } } } } i cant find any useful docs on how to best implement this. anything helps, thanks

I have (had) a view controller that does a bit of manual layout in a -viewDidLayout override. This was pretty easy to manage - however since introducing NSGlassEffectView into the view hierarchy I sometimes am getting hit with "Unable to simultaneously satisfy constraints" and Appkit would break a constraint to 'recover.' It appears translatesAutoresizingMaskIntoConstraints is creating some really weird fixed width and height constraints. Here I wasn't doing any autolayout - just add the glass view and set its frame in -viewDidLayout. At runtime since I do manual layout in -viewDidLayout the frames are fixed and there is no real "error" in my app in practice though I wanted to get rid of the constraint breaking warning being logged because I know Autolayout can be aggressive about 'correctness' who knows if they decide to throw and not catch in the future. In my perfect world I would probably just prefer a view.doesManualLayout = YES here - the subviews are big containers no labels so localization is not an issue for me. Rather than playing with autoresizing masks to get better translated constraints I decided to set translatesAutoresizingMaskIntoConstraints to NO and make the constraints myself. Now I get hit with the following exception: "The window has been marked as needing another Layout Window pass, but it has already had more Layout Window passes than there are views in the window" So this happens because the view which now has constraints -- I adjusted the frame of it one point in -viewDidLayout. My question is - is not legal to make changes in -viewDidLayout - which seems like the AppKit version of -viewDidLayoutSubviews. In UIKit I always thought it was fine to make changes in -viewDidLayoutSubviews to frames - even if constraints were used - this is a place where you could override things in complex layouts that cannot be easily described in constraints. But in AppKit if you touch certain frames in -viewDidLayout it can now cause this exception (also related: https://developer.apple.com/forums/thread/806471) I will change the constant of one of the constraints to account for the 1 point adjustment but my question still stands - is it not legal to touch frames in -viewDidLayout when autolayout constraints are used on that subview? It is (or at least was if I remember correctly) permitted to change the layout in -viewDidLayoutSubviews in UIKit but AppKit seems to be more aggressive in its checking for layout correctness). What about calling -sizeToFit on a control in viewDidLayout or some method that has side effect of invalidating layout in a non obvious way, is doing things like this now 'dangerous?' Shouldn't AppKit just block the layout from being invalidated from within -viewDidLayout - and leave whatever the layout is as is when viewDidLayout returns (thus making -viewDidLayout a useful place to override layout in the rare cases where you need a sledgehammer?)

Views placed inside tabViewBottomAccessory that access @Environment values or contain @State properties experience unstable identity, as shown by Self._printChanges(). The identity changes on every structural update to the TabView, even though the view's actual identity should remain stable. This causes unnecessary view recreation and breaks SwiftUI's expected identity and lifecycle behavior. Environment Xcode Version 26.2 (17C52) iOS 26.2 simulator and device struct ContentView: View { @State var showMoreTabs = true struct DemoTab: View { var body: some View { Text(String(describing: type(of: self))) } } var body: some View { TabView { Tab("Home", systemImage: "house") { DemoTab() } Tab("Alerts", systemImage: "bell") { DemoTab() } if showMoreTabs { TabSection("Categories") { Tab("Climate", systemImage: "fan") { DemoTab() } Tab("Lights", systemImage: "lightbulb") { DemoTab() } } } Tab("Settings", systemImage: "gear") { List { Toggle("Show more Tabs", isOn: $showMoreTabs) } } } .tabViewBottomAccessory { AccessoryView() } .task { while true { try? await Task.sleep(for: .seconds(5)) if Task.isCancelled { break } print("toggling showMoreTabs") showMoreTabs.toggle() } } .tabBarMinimizeBehavior(.onScrollDown) } } struct AccessoryView: View { var body: some View { HStack { EnvironmentAccess() WithState() Stateless() } } } struct EnvironmentAccess: View { @Environment(\.tabViewBottomAccessoryPlacement) var placement var body: some View { // FIXME: EnvironmentAccess: @self, @identity, _placement changed. // Identity should be stable let _ = Self._printChanges() Text(String(describing: type(of: self))) } } struct WithState: View { @State var int = Int.random(in: 0...100) var body: some View { // FIXME: WithState: @self, @identity, _id changed. // Identity should be stable let _ = Self._printChanges() Text(String(describing: type(of: self))) } } struct Stateless: View { var body: some View { // Works as expected: Stateless: @self changed. let _ = Self._printChanges() Text(String(describing: type(of: self))) } } This bug seems to make accessing TabViewBottomAccessoryPlacement impossible without losing view identity; the demo code is affected by the bug. Accessing a value like @Environment(\.colorScheme) is similarly affected, making visually adapting the contents of the accessory to the TabView content without losing identity challenging if not impossible. Submitted as FB21627918.