I'm currently using the extension below to determine whether an iPhone has a notch so I can adjust my UI accordingly.
extension UIDevice {
var hasNotch: Bool {
if userInterfaceIdiom == .phone, let window = (UIApplication.shared.connectedScenes
.compactMap { $0 as? UIWindowScene }
.flatMap { $0.windows }
.first { $0.isKeyWindow }) {
return window.safeAreaInsets.bottom > 0
}
return false
}
}
(Adapted from https://stackoverflow.com/questions/73946911/how-to-detect-users-device-has-dynamic-island-in-uikit)
This no longer works in iOS 26, and I have yet to find a similar method that works. Does anyone have any fixes?
UI Frameworks
RSS for tagDiscuss the different user interface frameworks available for your app.
Posts under UI Frameworks tag
44 Posts
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I’m not seeing Liquid Glass on any standard components. A month ago around July 17th I ran our app and saw Liquid Glass on our tab view and various standard components. Those components have not been changed and yet I’m no longer seeing Liquid Glass in our app at all.
Components that were previously liquid glass but now are not include TabView and back navigation buttons.
I set the UIDesignRequiresCompatibility key explicitly to false but no luck. I was seeing this in Beta 7 and Beta 8 on a real device and on a sim.
Hello,
We received a rejection on one of our IOS applications because we were doing Microsoft MSAL login through the user's browser. The representative recommended that we use Webview to do in-app logins. However when we tried to handle the custom app uri redirection (looking like myapp://auth/), Webview does not seem to send the user back to the application. Does anyone have a fix for this?
Thanks!
Topic:
Privacy & Security
SubTopic:
General
Tags:
Safari and Web
UI Frameworks
Authentication Services
WebKit
Hi everybody,
I use a very old photo software called Snapseed v 1.2.1 on 2 MacBook, one runs with El Capitan and the second runs with Mojave. These app has no language selection during install, and no preferences language choice in menu when running.
When I execute app on El Capitan, all menus and topics are translate in French, but on Mojave no translation is done.
I looked Contents of app and found differents languages files (structured as xx.po where xx=country) located in Resources folder. I deduced translation was executed after getting language param. I checked values on both systems and there are same (LANG=fr_FR.UTF-8).
So I tried to change Info.plist file to force code langage to 'fr' in CFBundleLocalizations key. Result is same.
Does somebody has a idea of reason of issue and how to solve it ?
Snapseed release was 2012, El Capitan 2015 and Mojave 2018, it seems framework used to code app runs differently and can't get language value.
When I compiled my legacy project with Tahoe's macOS 26 SDK, NSRulerViews are showing a very different design:
Under prior macOS versions the horizontal and verrical ruler's background were blurring the content view, which was extending under the rulers, showing through their transparency.
With Tahoe the horizontal ruler is always reflecting the scrollview's background color, showing the blurred content view beneath.
And the vertical ruler is always completely transparent (without any blurring), showing the content together with the ruler's markers and ticks.
It's difficult to describe, I'll try to replicate this behavior with a minimal test project, and probably file a bug report / enhancement request.
But before I take next steps, can anyone confirm this observation? Maybe it is an intentional design decision by Apple?
We're trying to implement a backup/restore data feature in our business productivity iPad app using UIDocumentPickerViewController and AppleArchive, but discovered odd behavior of [UIDocumentPickerViewController initForOpeningContentTypes: asCopy:YES] when reading large archive files from a USB drive.
We've duplicated this behavior with iPadOS 16.6.1 and 17.7 when building our app with Xcode 15.4 targeting minimum deployment of iPadOS 16. We haven't tested this with bleeding edge iPadOS 18.
Here's our Objective-C code which presents the picker:
NSArray* contentTypeArray = @[UTTypeAppleArchive];
UIDocumentPickerViewController* docPickerVC = [[UIDocumentPickerViewController alloc] initForOpeningContentTypes:contentTypeArray asCopy:YES];
docPickerVC.delegate = self;
docPickerVC.allowsMultipleSelection = NO;
docPickerVC.shouldShowFileExtensions = YES;
docPickerVC.modalPresentationStyle = UIModalPresentationPopover;
docPickerVC.popoverPresentationController.sourceView = self.view;
[self presentViewController:docPickerVC animated:YES completion:nil];
The UIDocumentPickerViewController remains visible until the selected external archive file has been copied from the USB drive to the app's local tmp sandbox. This may take several seconds due to the slow access speed of the USB drive. During this time the UIDocumentPickerViewController does NOT disable its tableview rows displaying files found on the USB drive. Even the most patient user will tap the desired filename a second (or third or fourth) time since the user's initial tap appears to have been ignored by UIDocumentPickerViewController, which lacks sufficient UI feedback showing it's busy copying the selected file.
When the user taps the file a second time, UIDocumentPickerViewController apparently begins to copy the archive file once again. The end result is a truncated copy of the selected file based on the time between taps. For instance, a 788 MB source archive may be copied as a 56 MB file. Here, the UIDocumentPickerDelegate receives a 56 MB file instead of the original 788 MB of data.
Not surprisingly, AppleArchive fails to decrypt the local copy of the archive because it's missing data. Instead of failing gracefully, AppleArchive crashes in AAArchiveStreamClose() (see forums post 765102 for details).
Does anyone know if there's a workaround for this strange behavior of UIDocumentPickerViewController?
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.)
Hello everybody!
TLDR: Issues with visibleItemsInvalidationHandler. Minimal code to reproduce available.
I've been working with Compositional Layout for a while now and recently I've found myself needing to implement custom animation based on scroll position of UI elements. Once I found visibleItemsInvalidationHandler it felt like the exact solution that I needed. Once I implement I've found out it doesn't quite behave as you'd expect.
To put it simply, it seems like the animations only work if your whole layout does not use .estimated nor .uniformAcrossSiblings. As soon as you use them then the animations will stop working, I've debugged it deeper and it seems like the invalidation context generated by it does not include the indexPath of the cells, which is always included in the version in which it works.
Feel free to swap the line 51 with its comment to flip between the working and failing version of it.
Playground Example
My final question therefore is... Is this the expected behavior? The documentation doesn't give any clues about such behavior and although I've tried relentlessly to find a workaround for this specific hiccup I was not successful with it.
Double-tap three fingers and drag to change zoom” should suppress “Three Finger to Drag”. Currently these gestures are triggered simultaneously, for no real reasons. I saw different behaviors for different environments, but none is desired.
Current and desired behavior:
This seems an issue so I filed a feedback.
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?
Reference Feedback FB19152594
Occurs with my 3rd Party UIKit App called "Lifeorities".
Latest occurrence was 7/27/25 at 13:49 pm.
Launch app (actual device running iPadOS 26 or iPadOS 26 simulator)
Initial screen displays view content and floating tab bar at top of screen (both portrait orientation and landscape).
Floating tab bar items respond to liquid glass effect (but liquid glass appearance of the whole tab bar doesn't comply with new glass pill shaped tab bar area).
Selected tab bar item obeys selected app designated color (assets).
Unselected tab bar items are using black text which is unreadable on app background which used dark mode as default (as intended).
Selecting another tab bar item shows the liquid glass effect as you navigate to the new tab bar item and shows the app designated color (assets).
Previous tab bar item that was selected, now is unselected and shows black text.
NOTE: iOS tab bar items work fine (show white foreground color as desired for unselected tab bar items).
when in portrait, the UINavigationBar shows normal:
when in landscape:
The top is white and blank.
In our project, we defined a CustomTabBar that inherits UITabBar, and we add some subviews and these subviews' frame is beyond UITabBar, see below picture(a beyond area button, this button is a subview of UITabBar, but frame is out of UITabBar's area):
and in order to let this button response to click action, we override the UITabBar's hitTest method, this works well below OS 26 with Xcode version below 26:
override public func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {
let pointInCollectionView = self.beyondAreaButton.convert(point, from: self)
if self.beyondAreaButton.bounds.contains(pointInCollectionView) {
return self.beyondAreaButton.hitTest(pointInCollectionView, with: event)
}
return super.hitTest(point, with: event)
}
but when using Xcode26 build app on OS 26, I noticed the UITabBar is wrapped by a UIKit._UITabBarContainerView and UIKit._UITabBarContainerWrapperView, and it can not trigger the hitTest method.
since the hitTest is not triggered, so the button action is no chance to trigger too.
Any suggestions to solve this problem, thank you~
And I have file a feedback assistant: FB19252973
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?
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.
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.
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!
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 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)
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()
}