“swiftui”

Thanks for posting. I built a minimal test to try to reproduce this — a SwiftUI NSViewRepresentable-wrapped NSTextView with a custom NSTextAttachment subclass and a viewProvider returning a custom NSView. I then stress-tested it against five plausible causes, and none of them reproduced any flicker: Baseline pattern — custom attachment + view provider returning a tinted layer-backed view, type in the same paragraph as the inserted attachment: stable. No caching in loadView() — every call constructs a brand-new NSView with fresh subviews and constraints: stable. Aggressive layout invalidation on every keystroke — NSTextLayoutManager.invalidateLayout(for: documentRange) from a textDidChange: delegate: stable. Mixed content sources — both attachment.image set to a programmatically drawn NSImage and a custom viewProvider returning a separate NSView: stable. Raster image content — loadView() returns an NSView containing an NSImageView with a real NSBitmapImageRep-backed NSImage instead of a layer-tinted p

Thanks for the focused reproducer and the video — they made this easy to investigate. There are two separate problems in what you're seeing, and the right answer is to switch to a different SwiftUI API for this kind of programmatic text editing. The bug in your code: String.Index invalidation after replaceSubrange RangeReplaceableCollection.replaceSubrange(_:with:) invalidates all indices into the collection (per the documentation), not just indices at or after the modified range. In your code: self.text.replaceSubrange(from..

@hydrudcatt3 Thanks for the post. The thread is 4 years old, I think will be a great idea if you could post a new thread with all the details of the issue and the code you have posted. Is what you experiencing like SwiftUI's implementation of .searchable sometimes holds onto the Binding longer than the view's lifecycle? Is that what you are seeing? Looking forward to see your new post with all the details. Albert
  Worldwide Developer Relations.

Thanks for the post. So interesting and there are many SwiftUI people that are probably going to jump into the thread. In my case I wanted to test the use .clear.interactive(), SwiftUI generates a visual highlight layer that responds to user touches. To optimize this highlight animation, the system tries to resolve the shape provided in the in: parameter into a standard primitive. Because .concentric corners are dynamic, the interaction highlight engine currently fails to resolve the exact bezier path for the mask? In this case manifests as a highly rounded rectangle. Sometimes the interaction engine needs an explicit contentShape to properly map the hit-testing and highlight bounds, rather than relying solely on the in: parameter of the glass effect. struct ContentView: View { var body: some View { VStack { Text(Hello, World!) .frame(maxWidth: .infinity, maxHeight: .infinity) .glassEffect(.clear.interactive(), in: .rect(cornerRadius: 32)) .padding(36) .ignoresSafeArea() .preferredColorSchem

// // ARUserAuth.swift // XRSandbox // // Created by Andy Wyatt on 3/15/26. // import SwiftUI import RealityKit import ARKit import AVFoundation import CoreMotion public struct ARUserAuth { public static var isAvailableAndAuthorizedByUser: Bool { guard ARWorldTrackingConfiguration.isSupported else { return false } return hasCameraAuthorization && hasMotionAuthorization } public static var hasCameraAuthorization: Bool { let authStatus = AVCaptureDevice.authorizationStatus(for: .video) if authStatus == .notDetermined { requestUserAuthorizationForCamera() } return authStatus == .authorized } public static func requestUserAuthorizationForCamera() { print(ARUserAuth: Camera access not determined, requesting user authorization) AVCaptureDevice.requestAccess(for: .video) { granted in if granted { print(ARUserAuth: App access to Camera authorized by user) // since these are modal popups, request Motion & Fitness only after Camera access granted if coreMotionAuthorizationStatus == .notDetermined {

// // XRSandboxApp.swift // XRSandbox // // Created by Andy Wyatt on 3/6/26. // import SwiftUI @main struct XRSandboxApp: App { var body: some Scene { WindowGroup { ContentView() } } }

FYI: // // ContentView.swift // XRSandbox // // Created by Andy Wyatt on 3/15/26. // import SwiftUI import RealityKit struct ContentView: View { private let rootEntity = Entity() var body: some View { RealityView { content in content.add(rootEntity) } update: { content in updateARState(&content) } .ignoresSafeArea() .onAppear() { configureVirtualCamera() rootEntity.addChild(makeThing()) } .onTapGesture { spinThing() } .overlay { overlayView } } //MARK: - overlay with toggles at bottom @State private var arToggleState: Bool = false @State private var showARView: Bool = false @State private var perspectiveCameraInAR: Bool = false private var overlayView: some View { VStack { Spacer() VStack { Toggle(Enable AR, isOn: $arToggleState) .onChange(of: arToggleState) { handleARToggle() } // If PerspectiveCamera is in the RealityView entity heirarchy // the content is anchored to the screen rather than the floor Toggle(Keep PerspectiveCamera in AR, isOn: $perspectiveCameraInAR) .disabled(arToggleState) //

Hi @coastalDev On visionOS, sheets don't dismiss when you tap outside them — that's a deliberate platform behavior, and SwiftUI doesn't expose a modifier to opt into iPadOS-style tap-outside dismissal. The Human Interface Guidelines describe a sheet on visionOS (along with macOS, tvOS, and watchOS) as always modal, meaning people can't interact with the parent view until they explicitly dismiss it. This also matches how system presentations behave on visionOS — .alert, .confirmationDialog, .fileImporter, .photosPicker, and the share sheet are all dismissed via an explicit control rather than a tap outside. Following the same pattern in your custom sheet will feel native. For a data-entry Form like yours, consider pairing a Cancel button with a Done (or Save) button as text buttons in the sheet's toolbar, as many system apps do. The Best practices section of the HIG codifies this pairing — The Cancel (or Close) button dismisses a sheet without saving any changes… The Done button dismisses a sheet afte

In the same way, @IBDesignable, @IBInspectable have disappeared some time ago. Is it only with objC code or Swift as well ? I do hope I'm wrong, but sometimes, looks like they are silently killing IB to force developers to SwiftUI. That would be very very negative evolution.