“swiftui”

A ToolbarItem(placement: .bottomBar) inside a NavigationSplitView detail/destination view is missing after a device rotation on iOS 26. The bottom toolbar is missing until the view has been presented in both orientations, after which it renders correctly from then on. The issue does not reproduce on iOS 18. Environment iOS 26 only — does not reproduce on iOS 18 iPhone 17 Pro Max and iPhone 17 Air (i.e. devices that expose the landscape size class Regular width / compact height) SwiftUI NavigationSplitView with .balanced style Steps to reproduce Run the sample below on an iPhone 17 Pro Max or Air (or a simulator of either). Open the detail view (which contains a .bottomBar toolbar item) while the device is in either orientation. Rotate the device. Observe that the bottom toolbar is now missing. Expected behavior The .bottomBar button remains visible across rotation, regardless of which orientation the view was first presented in. Actual behavior On first presentation, rotating the device causes the bo

I’m using a standard DisclosureGroup in SwiftUI and noticed that the disclosure indicator (chevron) no longer adopts the tint color. Example: DisclosureGroup(Details) { Text(Content) } .tint(.indigo) The label text becomes indigo, but the chevron remains the default system color. I also tried creating a custom DisclosureGroupStyle to render my own chevron, but that approach appears to break some of the built-in disclosure animation behavior and interaction. Questions: Is there a supported way to customize the disclosure indicator color in DisclosureGroup? Has the behavior of .tint(_:) changed for DisclosureGroup in recent iOS releases? If customization is not currently supported, is there a recommended alternative that preserves the native disclosure animations and accessibility behavior? Tested on: iOS 26.3 and Xcode 26.3

Hi all, Hoping someone has hit and resolved this exact pattern, or can point me to the right escalation path. I'm trying to enrol in the Apple Developer Program as an Individual (Bengaluru, India). The Apple Developer iOS app shows ID Verification Rejected under the Apple Developer Program status — but with no specific reason and no retry button. The app does not surface what was actually wrong with the verification. What I have already done: Confirmed my Apple Account name (Adarsh P S) exactly matches my Passport and PAN card (no extra spaces, correct initials). Opened Developer Support case #102900128848 — the agent replied once on 2026-05-28 asking for a screenshot, which I provided the same day. No follow-up in 3+ business days. Filed a parallel case #102905434551 on 2026-06-02 explicitly referencing the first as escalation, not a duplicate. Apple ID has 2FA enabled, trusted device active, billing address on file. Questions for anyone who has gotten past this: Did the verification reset come from support,

Is there any documentation or advice on printing from a Safari webapp (in JavaScript)? My app needs to print labels, and printing from Safari presents few options. For example, you can't turn off backgrounds or the URL/date/time footer. And it wants to print a full-size page, which ends up printing miles of label. (I've also tried printing from SwiftUI on a macOS app, and even that is just terrible to try to get right. Why is printing so hard?)

I would like to implement a focus-based Menu-Bar command in my SwiftUI iPadOS app, or react to key command while certain elements are focused. Traditionally, this requires using @FocusedValue and focusable() and focused, however, it appears that setting a @FocusState on macOS will work, but setting a @FocusState on iPadOS will never work. How can this API work and support MenuBar commands and keyboard inputs? It kind of has an accessibility impact as well. Not all users are going to know, or want to turn on full keyboard control for basic interactions. Here's a small sample that doesn't appear to focus on iPadOS: struct FocusableTestView: View { @FocusState private var isRectFocused: Bool var body: some View { VStack { // This text field should focus the custom input when pressing return: TextField(Enter text, text: .constant()) .textFieldStyle(.roundedBorder) .onSubmit { isRectFocused = true } .onKeyPress(.return) { isRectFocused = true return .handled } // This custom input should focus itself when

I'm in the unenviable position of needing the current UIViewController to keep an external library happy. Essentially, I need to do this in SwiftUI: import LibraryOutOfMyControl ViewControllerReader { viewController in Button(Action) { LibraryOutOfMyControl.action(with: viewController) } } My simple attempt below functions correctly but I'm relying on makeUIViewController always being immediately followed by updateUIViewController. Is the a reasonable assumption or should I set everything up assuming updateUIViewController might never be called? struct ViewControllerReader: UIViewControllerRepresentable where Content: View { @ViewBuilder var content: (UIViewController) -> Content func makeUIViewController(context: Context) -> UIHostingController { UIHostingController(rootView: content(UIViewController())) } func updateUIViewController(_ uiViewController: UIHostingController, context: Context) { uiViewController.rootView = content(uiViewController) uiViewController.view.isUserInteractionEnabled

I'm trying to use SwiftUI views inside an NSToolbarItem, and I feel like I'm fighting the system. The goal is to create custom toolbar controls. I don't want AppKit or SwiftUI to recognize that there's a SwiftUI view in the toolbar and then try to style it automatically, which is what I think is happening. Consider this hierarchy: - NSToolbar - NSToolbarItem - view -> MyCustomNSView - addSubview(NSHostingView) So CustomView is inside an NSHostingView, which is inside an NSView, which is assigned to the .view property of an NSToolbarItem. For a while, I struggled to get this working at all because SwiftUI's layout metrics appeared to be affected by safe area insets. SwiftUI's ignoresSafeArea() only seemed to move the problem around. For now, I've disabled full-size content view, which I don't really need anyway. However, a SwiftUI Button or Menu still doesn't behave or style the way I would expect when placed inside an NSToolbarItem. They don't seem to h

I have a small example where adding a new property to a persisted Codable struct causes a crash on launch instead of decoding the missing property using its default value. Steps Run this app once and press Insert Event to persist data: import SwiftUI import SwiftData @main struct SwiftDataCrash: App { var body: some Scene { WindowGroup { ContentView() } .modelContainer(for: Event.self) } } struct ContentView: View { @Environment(.modelContext) private var modelContext @Query private var events: [Event] var body: some View { VStack(spacing: 12) { Text(Events: (events.count)) Button(Insert Event) { let event = Event( recurrence: Recurrence( interval: 1 ) ) modelContext.insert(event) try? modelContext.save() } List(events) { event in Text(String(describing: event.recurrence)) } } .padding() } } @Model final class Event { var recurrence: Recurrence? = nil init(recurrence: Recurrence? = nil) { self.recurrence = recurrence } } struct Recurrence: Codable { var interval: Int // STEP 2: // After first run + i

I have a SwiftUI view inside a NavigationStack with a custom navigation bar background color. I want the navigation bar buttons to have a consistent color throughout the app. The issue is that the navigation bar button color changes depending on the first/root view in the body. When the root view is a ScrollView var body: some View { ScrollView { // content } .toolbarBackground(Color(red: 0.02, green: 0.27, blue: 0.13), for: .navigationBar) .toolbarBackground(.visible, for: .navigationBar) .toolbarColorScheme(.dark, for: .navigationBar) } The navigation bar buttons appear white. However, if I replace the ScrollView with a VStack, while keeping the same modifiers, the navigation bar buttons appear black: var body: some View { VStack { // content } .toolbarBackground(Color(red: 0.02, green: 0.27, blue: 0.13), for: .navigationBar) .toolbarBackground(.visible, for: .navigationBar) .toolbarColorScheme(.dark, for: .navigationBar) } The navigation bar buttons appear black. How can I make the navigation bar

I'm getting a log error and a slight delay in the UI when displaying a system image that changes at the end of a sequence. I'm using a ternary operator to determine the image; the fact that the image changes seem to be the issue, rather than the value itself. The issue only occurs for a newly installed app, and not when the app is rerun. (I'm using similar code to display an onboarding sequence after installation.) This happens on device (iphone 15 pro v25.6) and simulator (iphone 17 pro v25.6 and iphone 16 pro v18.5); xcode 26.5 (17F42). Console errors (device and iphone 17 simulator): fopen failed for data file: errno = 2 (No such file or directory) fopen failed for data file: errno = 2 (No such file or directory) Repro Code: import SwiftUI struct ContentView: View { // NOTE: error only occurs with new install. @State private var currentItem = 0 @State private var totalItems: Int = 4 var body: some View { VStack(spacing: 0) { Spacer() Text(totalItems: (totalItems)) TabView(selection: $currentItem)

Hello everyone, My name is Keita Tomizu. I'm a university student in Japan, currently developing a personal app. I am facing a tricky SwiftUI layout issue that I have spent hours trying to solve, and I would really appreciate your insights. Context & Goal: I have an overlay UI layer (zIndex(4)) consisting of a VStack that contains top and bottom HStacks. • In the top-left, there is a back button (<). • In the top-right and bottom-right, there are action buttons. • When a user taps the bottom-right button, a state isShowingAddView becomes true. This brings up a keyboard and a custom view in the background. • My Goal: When isShowingAddView is true, the right-side buttons should scale up and fade out (opacity to 0) in place. The top-left < button should remain completely static and anchored in its exact position. The Issue: When the state toggles, the < button unexpectedly shifts horizontally (along the X-axis) and sometimes behaves erratically, moving off-screen or losing its static positi