“swiftui”

Hey all, I'm building a tile-based puzzle game for iOS and have been experimenting with using SwiftUI for the HUD (score, timer, pause menu, settings sheet) layered on top of a SpriteView that hosts the actual gameplay scene. So far the integration has been smoother than I expected — SpriteView drops cleanly into a ZStack, and I can drive SwiftUI state from the SpriteKit scene via an ObservableObject shared between them. That said, I've run into a few rough edges that I'd love some input on. The biggest one is touch handling: when a SwiftUI overlay (like a semi-transparent pause button) sits over the SpriteView, taps near the edges of the button occasionally get swallowed by the underlying scene, even when the button's hit area looks correct in the view debugger. I've tried .contentShape(Rectangle()) and bumping the frame, which helps but doesn't fully eliminate it. Curious if anyone has landed on a reliable pattern here, especially for transient overlays like toast notifications th

I’m seeing a layout regression in SwiftUI on iPadOS 26.4 involving NavigationSplitView inside a TabView. When a NavigationSplitView is embedded in a TabView, the sidebar toolbar appears to reserve too much vertical space. There is a large vertical gap between the top edge of the sidebar and the sidebar collapse/toggle icon. It looks as if the sidebar toolbar itself has become much taller than expected. The same NavigationSplitView layout is rendered correctly when it is shown directly without being embedded in a TabView. Environment: iPadOS 26.4 or later SwiftUI iPad TabView NavigationSplitView inside one tab Expected behavior The sidebar toolbar should use its normal height, as it does when the same NavigationSplitView is shown without a surrounding TabView. The sidebar collapse/toggle icon should appear close to the top of the sidebar, without a large empty gap above it. Actual behavior When the NavigationSplitView is hosted inside a TabView, the sidebar toolbar area becomes excessively ta

When interacting with RealityView’s realityViewCameraControls .orbit and setting a new RealityViewCameraContent .cameraTarget, the resulting camera target and camera orbit is incorrect. This can be demonstrated where one finger is orbiting the RealityView, and another pushes a button which changes the camera target. Instead of the camera facing the new target, some point in the scene is the new effective camera target and orbit point. This only occurs when an orbit interaction is currently taking place. If you stop interacting with the orbit, change target, then start orbit interacting again, everything works as expected. Though this example uses two-touches, any change of the camera target has this conflict with orbit interaction. This means interacting with orbit will result in the wrong camera view which is unexpected for users and difficult to reconcile or detect, for developers. Expected: Interacting (orbiting) the scene while setting a new camera target with the buttons on screen (at the same time), the

Environment: iOS 16.0+ SwiftUI Problem Description: I am using ImageRenderer to convert a SwiftUI view into a UIImage for sharing purposes. The view renders perfectly fine on-screen. However, in the generated UIImage, specific Text elements completely disappear. After debugging, I found that the issue is caused by the @AccessibilityFocusState property wrapper. Any Text view that has the .accessibilityFocused(_:) modifier applied to it will be completely missing from the ImageRenderer output. Other views (like Text without the modifier, or Image views) in the exact same hierarchy render perfectly. It seems that because ImageRenderer renders the view off-screen without a live accessibility environment/tree, the accessibility focus binding silently breaks the layout or rendering of that specific element. Minimal Reproducible Example: Here is a generic, drop-in example that demonstrates the bug. When you tap Capture with ImageRenderer, the resulting image will only contain the subtitle, while th

Hi everyone, I'm building a macOS SwiftUI app and I'm trying to intercept both: Tab Shift + Tab to perform custom actions (similar to how text editors indent/outdent items). Right now, plain Tab works fine, but Shift + Tab never reaches my .onKeyPress(.tab) handler. Here's what I'm currently trying: import SwiftUI struct ShiftTabNotIntercepted: View { @State private var shiftKeyPressed = false var body: some View { Text(Hello) .focusable() .onKeyPress(.tab) { print(tab pressed with shift: (shiftKeyPressed)) return .handled } .onModifierKeysChanged(mask: .shift) { old, new in shiftKeyPressed = new.contains(.shift) } } } Behavior: Pressing Tab prints: tab pressed with shift: false Pressing Shift + Tab does nothing — .onKeyPress(.tab) never fires. I also noticed: if a sidebar is visible, Shift + Tab moves focus to the sidebar if no sidebar is visible, it still doesn't trigger the handler So it seems macOS is intercepting Shift + Tab for focus navigation before SwiftUI sees it. My goal

How do you create a prominent glass button in SwiftUI? In UIKit it’s let button = UIButton(configuration: .prominentGlass()) button.configuration?.title = Agree I tried Button(Agree) {} .buttonStyle(.glassProminent) but the title text is white not glassified 🤨

Glancing through the APIs, SwiftUI can handle the open app, reopen app, open doc, and quit core events (with the “aevt” suite ID). What about the print doc and open content events? If there are no hooks (yet), how can I implement them the traditional way without clashing with SwiftUI?

I am facing an issue in SwiftUI on iOS 18.6.2 where passing a value to a destination view during navigation is not working as expected. In my implementation, I pass a billerId as a constant (let) to the destination view (BillersItemView) using NavigationLink. This approach works correctly across all previous iOS versions. However, on iOS 18.6.2, the destination view does not receive the updated value properly. Before triggering navigation, the value is correctly updated in the ViewModel, but the destination view seems to receive an incorrect or stale value, which affects further API calls and UI rendering. This pattern of passing immutable (let) values is used throughout the app and has always worked reliably, so this behavior appears inconsistent and possibly related to changes in SwiftUI navigation handling in iOS 18.6.2. Could you please confirm if this is a known issue or if there are any recommended changes or workarounds to ensure correct data passing in this scenario? It can be very l

Hello! I'm trying to implement an editor app (macOS) that allows the user to write code, which will be compiled and executed, showing the result in the editor window. Imagine it like SwiftUI previews, but the graphic output is created with Metal, not SwiftUI. I found that IOSurface can be used to share that kind of data over XPC, so I would not have to rely on the private NSRemoteView. However, I'm confused if it is, at all, possible for my editor app to connect to an XPC Service, that was NOT bundled with it (but compiled by it at runtime). I succeeded to launch an XPC service defined as: Label com.myteam.myproject.service MachServices com.myteam.myproject.service Program /Path/to/service/run_my_service.sh But the call to let connection = NSXPCConnection(machServiceName: com.myteam.myproject.service) let proxy = connection.remoteObjectProxyWithErrorHandler { error in continuation.resume(throwing: error) } as? MyServiceProtocol fails with The connection to service named com.myteam.m