Hi,
I was wondering if it's possible (and advisable) to use the new glass effects available in iOS 26 in Swift Charts?
For example, in a chart like the one in the image I've attached to this post, I was looking to try adding a .glassEffect modifier to the BarMarks to see how that would look and feel.
However, it seems it's not available directly on the BarMark (ChartContent) type, and I'm having trouble adding it in other ways too, such as using in on the types I supply to modifiers like foregroundStyle or clipShape.
Am I missing anything? Maybe it's just not advisable or necessary to use glass effects within Charts?
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
When using a .zoom navigation transition, where .matchedTransitionSource is applied to a button in a toolbar and the destination view is a sheet which is presented with PresentationDetent.medium, the transition works initially, but shortly after it completes, the sheet's background is dimmed and the text of the source button reappears abruptly.
Code and a screenshot are below, though the effect is best observed when interacting with the view.
//
// ContentView.swift
// ZoomNavigationTransitionSample
//
// Created by Matthew DuBois on 6/15/25.
//
import SwiftUI
struct ContentView: View {
@State private var isPresentingSheet = false
@Namespace private var namespace
var body: some View {
NavigationStack {
List {
Text("Some content")
}
.navigationTitle("Sample")
.toolbar {
ToolbarItem(placement: .topBarTrailing) {
Button("Button") {
isPresentingSheet = true
}
.matchedTransitionSource(id: "button", in: namespace)
}
}
.sheet(isPresented: $isPresentingSheet) {
Text("Some sheet content")
.navigationTransition(.zoom(sourceID: "button", in: namespace))
.presentationDetents([.medium])
}
}
}
}
#Preview {
ContentView()
}
I have a memory leak for SVG image that located in Assets.xcassets file when using SwiftUI Image, but when I use UIImage then convert it to SwiftUI Image the issue is not found.
import SwiftUI
struct ContentView: View {
var body: some View {
NavigationStack {
VStack {
NavigationLink("Show", destination: SecondView())
}
.padding()
}
}
}
struct SecondView: View {
@Environment(\.dismiss) var dismiss
var body: some View {
NavigationStack {
VStack {
IM.svgImage
.resizable()
.scaledToFit()
.frame(width: 200, height: 200)
Button("Dismiss") {
dismiss()
}
}
}
}
}
enum IM {
static let testImage: Image = "test_image".image
static let svgImage: Image = "svgImage".image
}
extension String {
var image: Image {
Image(self) // Memory leak
}
var imageFromUIImage: Image {
guard let uiImage = UIImage(named: self) else {
return Image(self)
}
return Image(uiImage: uiImage) // No Memory leak
}
}
Environment that produces the issue:
Xcode: 16.2
Simulator: iPhone 15 Pro (iOS 17.5)
Overview
Starting with macOS 26 beta 1, a new NSGlassContainerView is added inside NSToolbarView.
This view intercepts mouse events, so any SwiftUI Button (or other interactive view) overlaid on the title‑bar / toolbar area no longer receives clicks.
(The same code works fine on macOS 15 and earlier.)
Filed as FB18201935 via Feedback Assistant.
Reproduction (minimal project)
macOS 15 or earlier → button is clickable
macOS 26 beta → button cannot be clicked (no highlight, no action call)
@main
struct Test_macOS26App: App {
init() {
// Uncomment to work around the issue (see next section)
// enableToolbarClickThrough()
}
var body: some Scene {
WindowGroup {
ContentView()
}
.windowStyle(.hiddenTitleBar) // ⭐️ hide the title bar
}
}
struct ContentView: View {
var body: some View {
NavigationSplitView {
List { Text("sidebar") }
} detail: {
HSplitView {
listWithOverlay
listWithOverlay
}
}
}
private var listWithOverlay: some View {
List(0..<30) { Text("item: \($0)") }
.overlay(alignment: .topTrailing) { // ⭐️ overlay in the toolbar area
Button("test") { print("test") }
.glassEffect()
.ignoresSafeArea()
}
}
}
Investigation
In Xcode View Hierarchy Debugger, a layer chain
NSToolbarView > NSGlassContainerView sits in front of the button.
-[NSView hitTest:] on NSGlassContainerView returns itself, so the event never reaches the SwiftUI layer.
Swizzling hitTest: to return nil when the result is the view itself makes the click go through:
func enableToolbarClickThrough() {
guard let cls = NSClassFromString("NSGlassContainerView"),
let m = class_getInstanceMethod(cls, #selector(NSView.hitTest(_:))) else { return }
typealias Fn = @convention(c)(AnyObject, Selector, NSPoint) -> Unmanaged<NSView>?
let origIMP = unsafeBitCast(method_getImplementation(m), to: Fn.self)
let block: @convention(block)(AnyObject, NSPoint) -> NSView? = { obj, pt in
guard let v = origIMP(obj, #selector(NSView.hitTest(_:)), pt)?.takeUnretainedValue()
else { return nil }
return v === (obj as AnyObject) ? nil : v // ★ make the container transparent
}
method_setImplementation(m, imp_implementationWithBlock(block))
}
Questions / Call for Feedback
Is this an intentional behavioral change?
If so, what is the recommended public API or pattern for allowing clicks to reach views overlaid behind the toolbar?
Any additional data points or confirmations are welcome—please reply if you can reproduce the issue or know of an official workaround.
Thanks in advance!
I was trying to adapt memoji in my app which write by objective-c.I have a textView for user input and I need to keep allowsEditingTextAttributes == NO for some reason.Is there any other way to show memoji sticker in system emoji keyboard?Thanks!
Verbatim of a feedback report (FB18431713) I submitted, duplicated here since we can't see each other's feedbacks, and I wanted a centralized place to track the resolution of this as I'm surely not the only one facing this.
When building the app using Xcode 26 beta 2 and running it in an iOS 26 simulator, I'm experiencing a retain cycle in the UINavigationController.
From the data I saw in Xcode's memory graph debugger, it seems that _UIViewControllerOneToOneTransitionContext is retaining it. I base this on the fact that the line connecting a view controller and _UIViewControllerOneToOneTransitionContext has a "strong" reference, as indicated in Xcode. (However, I'm reporting this as a retain cycle in UINavigationController, as that's what seems to hold onto this transition-context.)
Since updating my MacBook Air to macOS Tahoe 26.0 Developer Beta 2, I’ve encountered a persistent cursor misalignment issue:
When interacting with lists or contextual menus, the cursor’s visual position does not align with what it actually selects.
The system registers the cursor slightly above where it appears, causing clicks to select the wrong option or fail to register.
As a temporary workaround, I can sometimes position the cursor off-target and press Enter to select, but this is a frustrating and inefficient workaround.
The issue persists after a restart and appears across multiple areas of the OS:
Right-clicking an app in the Dock to open the contextual menu → cursor highlights an incorrect item relative to its position.
In System Settings menus.
Even on the Feedback Assistant site when selecting issue categories.
Steps to Reproduce:
1️⃣ Update to macOS Tahoe 26.0 Developer Beta 2 on MacBook Air.
2️⃣ Right-click on any open application in the Dock.
3️⃣ Attempt to select an option from the list that appears.
4️⃣ Observe that the cursor highlights or interacts with a different option than where the cursor is visibly located.
Notes:
Issue is consistent across reboots.
Affects workflow and general navigation.
Temporary workaround using keyboard navigation is insufficient for productivity.
FB Number: FB18531124
If others are seeing this as well, please confirm below so Apple can prioritize investigation.
Hello Developer Forums Team,
I’ve seen that some banking apps prevent screenshots on certain sensitive screens. I’m working on a similar feature in my SDK and want to confirm if my implementation complies with App Store guidelines.
Since there’s no public API to block screenshots, I’m using a workaround based on the secure rendering behavior of UITextField (isSecureTextEntry = true). I embed my custom content (e.g., a UITableView) inside the internal secure container of a UITextField, which results in blank content being captured during screenshots—similar to what some banking apps do.
Approach Summary
I create a UITextField
I detect its internal secure container by matching UIKit internal class names as strings
I embed my real UI content into that container
I do not use or call any private APIs, just match view class names via strings.
ScreenshotPreventingView.swift
final class ScreenshotPreventingView: UIView {
private let textField = UITextField()
private let recognizer = HiddenContainerRecognizer()
private var contentView: UIView?
public var preventScreenCapture = true {
didSet {
textField.isSecureTextEntry = preventScreenCapture
}
}
public init(contentView: UIView? = nil) {
super.init(frame: .zero)
self.contentView = contentView
setupUI()
}
private func setupUI() {
guard let container = try? recognizer.getHiddenContainer(from: textField) else { return }
addSubview(container)
NSLayoutConstraint.activate([
container.topAnchor.constraint(equalTo: topAnchor),
container.bottomAnchor.constraint(equalTo: bottomAnchor),
container.leadingAnchor.constraint(equalTo: leadingAnchor),
container.trailingAnchor.constraint(equalTo: trailingAnchor)
])
if let contentView = contentView {
setup(contentView: contentView, in: container)
}
DispatchQueue.main.async {
self.preventScreenCapture = true
}
}
private func setup(contentView: UIView) {
self.contentView?.removeFromSuperview()
self.contentView = contentView
guard let container = hiddenContentContainer else { return }
container.addSubview(contentView)
container.isUserInteractionEnabled = isUserInteractionEnabled
contentView.translatesAutoresizingMaskIntoConstraints = false
let bottomConstraint = contentView.bottomAnchor.constraint(equalTo: container.bottomAnchor)
bottomConstraint.priority = .required - 1
NSLayoutConstraint.activate([
contentView.leadingAnchor.constraint(equalTo: container.leadingAnchor),
contentView.trailingAnchor.constraint(equalTo: container.trailingAnchor),
contentView.topAnchor.constraint(equalTo: container.topAnchor),
bottomConstraint
])
}
}
HiddenContainerRecognizer.swift
struct HiddenContainerRecognizer {
private enum Error: Swift.Error {
case unsupportedOSVersion(version: Float)
case desiredContainerNotFound(_ containerName: String)
}
func getHiddenContainer(from view: UIView) throws -> UIView {
let containerName = try getHiddenContainerTypeInStringRepresentation()
let containers = view.subviews.filter { subview in
type(of: subview).description() == containerName
}
guard let container = containers.first else {
throw Error.desiredContainerNotFound(containerName)
}
return container
}
private func getHiddenContainerTypeInStringRepresentation() throws -> String {
if #available(iOS 15, *) {
return "_UITextLayoutCanvasView"
}
if #available(iOS 14, *) {
return "_UITextFieldCanvasView"
}
if #available(iOS 13, *) {
return "_UITextFieldCanvasView"
}
if #available(iOS 12, *) {
return "_UITextFieldContentView"
}
let currentIOSVersion = (UIDevice.current.systemVersion as NSString).floatValue
throw Error.unsupportedOSVersion(version: currentIOSVersion)
}
}
How I use it in my Screen
let container = ScreenshotPreventingView()
override func viewDidLoad() {
super.viewDidLoad()
container.preventScreenCapture = true
container.setup(contentView: viewContainer) //viewContainer is UIView in storyboard, in which all other UI elements are placed in e.g. UITableView
self.view.addSubview(container)
container.translatesAutoresizingMaskIntoConstraints = false
NSLayoutConstraint.activate([
container.topAnchor.constraint(equalTo: self.view.topAnchor),
container.bottomAnchor.constraint(equalTo: self.view.bottomAnchor),
container.leadingAnchor.constraint(equalTo: self.view.leadingAnchor),
container.trailingAnchor.constraint(equalTo: self.view.trailingAnchor)
])
}
What I’d Like to Confirm
Is this approach acceptable for App Store submission?
Is there a more Apple-recommended approach to prevent screen capture of arbitrary UI?
Thank you for your help in ensuring compliance.
Starting with iOS 26 beta, I'm encountering an intermittent crash in production builds related to Auto Layout and background threading. This crash did not occur on iOS 18 or earlier and has become reproducible only on devices running iOS 26 betas.
We have already performed a thorough audit of our code:
• Verified that all UIKit view hierarchy and layout mutations occur on the main thread.
• Re-tested with strict logging—confirmed all remaining layout/constraint/view updates are performed on the main thread.
• No third-party UI SDKs are used in the relevant flow.
Despite that, the crash still occurs and always from a background thread, during internal UIKit layout commits.
Fatal Exception: NSInternalInconsistencyException
Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread.
0 MyApp 0x7adbc8 FIRCLSProcessRecordAllThreads + 172
1 MyApp 0x7adfd4 FIRCLSProcessRecordAllThreads + 1208
2 MyApp 0x7bc4b4 FIRCLSHandler + 56
3 MyApp 0x7bc25c __FIRCLSExceptionRecord_block_invoke + 100
4 libdispatch.dylib 0x1b7cc _dispatch_client_callout + 16
5 libdispatch.dylib 0x118a0 _dispatch_lane_barrier_sync_invoke_and_complete + 56
6 MyApp 0x7bb1f0 FIRCLSExceptionRecord + 224
7 MyApp 0x7bbd1c FIRCLSExceptionRecordNSException + 456
8 MyApp 0x7badf4 FIRCLSTerminateHandler() + 396
9 Intercom 0x86684 IntercomSDK_sentrycrashcm_cppexception_getAPI + 308
10 libc++abi.dylib 0x11bdc std::__terminate(void (*)()) + 16
11 libc++abi.dylib 0x15314 __cxa_get_exception_ptr + 86
12 libc++abi.dylib 0x152bc __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 90
13 libobjc.A.dylib 0x3190c objc_exception_throw + 448
14 CoreAutoLayout 0x13a4 -[NSISEngine optimize] + 314
15 CoreAutoLayout 0x1734 -[NSISEngine _optimizeWithoutRebuilding] + 72
16 CoreAutoLayout 0x1404 -[NSISEngine optimize] + 96
17 CoreAutoLayout 0xee8 -[NSISEngine performPendingChangeNotifications] + 104
18 UIKitCore 0x27ac8 -[UIView(Hierarchy) layoutSubviews] + 136
19 UIKitCore 0xfe760 -[UIWindow layoutSubviews] + 68
20 UIKitCore 0x234228 -[UITextEffectsWindow layoutSubviews] + 44
21 UIKitCore 0x27674 -[UIImageView animationImages] + 912
22 UIKitCore 0x28134 -[UIView(Internal) _viewControllerToNotifyOnLayoutSubviews] + 40
23 UIKitCore 0x18c2898 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2532
24 QuartzCore 0xabd98 CA::Layer::perform_update_(CA::Layer*, CALayer*, unsigned int, CA::Transaction*) + 116
25 QuartzCore 0x8e810 CA::Layer::update_if_needed(CA::Transaction*, unsigned int, unsigned int) + 600
26 QuartzCore 0xad45c CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 200
27 QuartzCore 0x6e30c CA::Context::commit_transaction(CA::Transaction*, double, double*) + 540
28 QuartzCore 0x9afc4 CA::Transaction::commit() + 644
29 QuartzCore 0x16974c CA::Transaction::release_thread(void*) + 180
30 libsystem_pthread.dylib 0x4c28 _pthread_tsd_cleanup + 620
31 libsystem_pthread.dylib 0x4998 _pthread_exit + 84
32 libsystem_pthread.dylib 0x5e3c pthread_atfork + 54
33 libsystem_pthread.dylib 0x1440 _pthread_wqthread + 428
34 libsystem_pthread.dylib 0x8c0 start_wqthread + 8
Any ideas?