Icons for macOS setups you build using this advanced installer, as well as apps you deploy with it, don't have to worry about their icons being placed in squircle jail:
installaware.com/iamp
The tool takes care of it all using documented macOS APIs, and overrides the squircle jail defaults to display your original icons - exactly as they were designed to appear!
Star the source code repository at github.com/installaware/iamp - and build it from sources free.
UI Frameworks
RSS for tagDiscuss the different user interface frameworks available for your app.
Posts under UI Frameworks tag
49 Posts
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
If the cell is expandable in List View, it will show slowly after deletion swipe.
the image shows how it looks like when this issue happens
and it should be easy to reproduce with this sample codes
// Model for list items
struct ListItem: Identifiable {
let id = UUID()
let title: String
let createdDate: Date
let description: String
}
struct ExpandableListView: View {
// Sample constant data
private let items: [ListItem] = [
ListItem(
title: "First Item",
createdDate: Date().addingTimeInterval(-86400 * 5),
description: "This is a detailed description for the first item. It contains two lines of text to show when expanded."
),
ListItem(
title: "Second Item",
createdDate: Date().addingTimeInterval(-86400 * 3),
description: "This is a detailed description for the second item. It provides additional information about this entry."
),
ListItem(
title: "Third Item",
createdDate: Date().addingTimeInterval(-86400 * 1),
description: "This is a detailed description for the third item. Tap to expand and see more details here."
),
ListItem(
title: "Fourth Item",
createdDate: Date(),
description: "This is a detailed description for the fourth item. It shows comprehensive information when tapped."
)
]
// Track which item is currently selected/expanded
@State private var selectedItemId: UUID? = nil
var body: some View {
NavigationView {
List {
ForEach(items) { item in
ExpandableCell(
item: item,
isExpanded: selectedItemId == item.id
) {
// Handle tap - toggle selection
withAnimation(.easeInOut(duration: 0.3)) {
if selectedItemId == item.id {
selectedItemId = nil
} else {
selectedItemId = item.id
}
}
}
}
.onDelete { indexSet in
for index in indexSet {
print("delete \(items[index].title)")
}
}
}
.navigationTitle("Items")
}
}
}
struct ExpandableCell: View {
let item: ListItem
let isExpanded: Bool
let onTap: () -> Void
private var dateFormatter: DateFormatter {
let formatter = DateFormatter()
formatter.dateStyle = .medium
formatter.timeStyle = .short
return formatter
}
var body: some View {
VStack(alignment: .leading, spacing: 8) {
// Always visible: Title and Date
HStack {
VStack(alignment: .leading, spacing: 4) {
Text(item.title)
.font(.headline)
.foregroundColor(.primary)
Text(dateFormatter.string(from: item.createdDate))
.font(.caption)
.foregroundColor(.secondary)
}
Spacer()
// Chevron indicator
Image(systemName: isExpanded ? "chevron.up" : "chevron.down")
.foregroundColor(.secondary)
.font(.caption)
}
// Expandable: Description (2 lines)
if isExpanded {
Text(item.description)
.font(.body)
.foregroundColor(.secondary)
.lineLimit(2)
.fixedSize(horizontal: false, vertical: true)
.transition(.opacity.combined(with: .move(edge: .top)))
.padding(.top, 4)
}
}
.padding(.vertical, 8)
.contentShape(Rectangle())
.onTapGesture {
onTap()
}
}
}
#Preview {
ExpandableListView()
}
Hi everyone,
I'm encountering an unexpected behavior with modal presentations in UIKit. Here’s what happens:
I have UIViewControllerA (let’s call it the "orange" VC) pushed onto a UINavigationController stack.
I present UIViewControllerB (the "red" VC, inside its own UINavigationController as a .formSheet) modally over UIViewControllerA.
After a short delay, I pop UIViewControllerA from the navigation stack.
Issue:
After popping UIViewControllerA, the modal UIViewControllerB remains visible on the screen and in memory. I expected that dismissing (popping) the presenting view controller would also dismiss the modal, but it stays.
Expected Behavior:
When UIViewControllerA (orange) is popped, I expect the modal UIViewControllerB (red) to be dismissed as well.
Actual Behavior:
The modal UIViewControllerB remains on screen and is not dismissed, even though its presenting view controller has been removed from the navigation stack.
Video example: https://youtube.com/shorts/sttbd6p_r_c
Question:
Is this the expected behavior? If so, what is the recommended way to ensure that the modal is dismissed when its presenting view controller is removed from the navigation stack?
Code snippet:
class MainVC: UIViewController {
private weak var orangeVC: UIViewController?
override func viewDidLoad() {
super.viewDidLoad()
self.view.backgroundColor = .blue
let dq = DispatchQueue.main
dq.asyncAfter(deadline: .now() + 1) { [weak self] in
let vc1 = UIViewController()
vc1.view.backgroundColor = .orange
vc1.modalPresentationStyle = .overCurrentContext
self?.navigationController?.pushViewController(vc1, animated: true)
self?.orangeVC = vc1
dq.asyncAfter(deadline: .now() + 1) { [weak self] in
let vc2 = UIViewController()
vc2.view.backgroundColor = .red
vc2.modalPresentationStyle = .formSheet
vc2.isModalInPresentation = true
let nav = UINavigationController(rootViewController: vc2)
if let sheet = nav.sheetPresentationController {
sheet.detents = [.medium()]
}
self?.orangeVC?.present(nav, animated: true)
dq.asyncAfter(deadline: .now() + 1) { [weak self] in
self?.navigationController?.popViewController(animated: true)
}
}
}
}
}
Thank you for your help!
All system colors are displayed incorrectly on the popover view.
Those are the same views present as a popover in light and dark mode.
And those are the same views present as modal.
And there is also a problem that when the popover is presented, switching to dark/light mode will not change the appearance. That affected all system apps.
The following screenshot is already in dark mode.
All those problem are occured on iOS 26 beta 3.
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 am using Button in my app, is push button and style is Momentary push in and bordered, added image icon on it also
bottom shows with image with white background , like below
But in Tahoe OS, it shows without white background(almost like border less)
Do I need to change button style?
I have an iPad app with a classic sidebar. It's been working fine for years. Now with iPadOS 26 the sidebar sometime gets this fake transparency that makes it really hard to quickly grok. A part of Liquid Glass seems to be to sometimes (but not always) take whatever is in the secondary area (the main big content), blur it, mirror it and then use as the background for the sidebar. This is silly and does not work at all for an app like mine. It maybe looks decent if your background is a photo or similar, but not for an app that manages data. Not all views cause the sidebar to get this ugly unreadable background. In most of the cases the sidebar keeps its normal opaque background that it has always had.
See this example for how it looks when it's really bad:
This is how it should look. Notice that the content of the "main view" is pretty similar to the case where it gets the ugly background. The difference is the segmented thing at the top, ie. a different "root view".
Is there some good way for me to force the sidebar to always have an opaque background? I guess I could make a ZStack and put a solid color as the background behind the sidebar, but those kinds of hacks are better to avoid.
This can not be how some UI designer envisioned that apps should look? Maybe I'm missing some new modifier or setting somewhere that would led me opt out from this aspect of Liquid Glass? Apart from this it looks pretty nice. There are some bugs where the contents of the main area gets clipped when the sidebar is shown, hidden and then shown again, but that's for another time (and it's surely known already (if the bug tracking system allowed me to search I could verify)).
So, any way to make my app look nice again?
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?
If I put the phone flat on a table, the left and right swipe gestures is not working but up and down gestures works.
Only when I put the iPhone to some vertical degree, the left and right swipe works.
Tested on 2 iPhone 7 Plus and 2 iPhone 13.
Anyone has similar experience? If yes, why?
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?
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.
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.