In one of my apps, i am using .glassEffect(_:In) to add glass effect on various elements. The app always crushes when a UI element with glassEffect(_in:) modifier is being rendered. This only happens on device running iOS 26 public beta. I know this for certain because I connected the particular device to xcode and run the app on the device. When i comment out the glassEffect modifier, app doesn't crush.
Is it possible to check particular realeases with #available? If not, how should something like this be handled. Also how do i handle such os level erros without the app crushing. Thanks.
Explore the various UI frameworks available for building app interfaces. Discuss the use cases for different frameworks, share best practices, and get help with specific framework-related questions.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
My app is a SwiftUI document based app using DocumentGroupLaunchScene. In iOS(iPadOS) 18.4, when it launches, it has duplicate toolbar items, and when I close the current document and open other documents, it adds more duplicates. It also shows a wrong document name, which shows the first opened document name. This issue can be reproduced in the sample code (Building a document-based app with SwiftUI).
I have submitted Feedback (FB17025216), but not sure if this is a known bug or if I'm missing anything.
I have the following view hierarchy in my app:
[UINavigationController] -> [MainViewController] -> [MyTabBarController] -> [DashboardViewController]
In my MainViewController I have a button that pushes the MyTabBarController onto the navigation controllers stack. In the tab bar controller I only have one tab in this example showing the DashboardViewController.
That all works fine, and when I tap the back button on MyTabBarController, everything works fine and the MainViewController is shown again. The UI works exactly how I want it, but when I load up the 'Debug Memory Graph' view, I can see that my DashboardViewController is still in memory and it seems the UITab has a reference to it. The MyTabBarController is NOT in memory anymore.
MyTabBarController is very simple:
class MyTabBarController: UITabBarController {
override func viewDidLoad() {
super.viewDidLoad()
self.mode = .tabSidebar
var allTabs:[UITab] = []
let mainTab = UITab(title: "Dashboard",
image: UIImage(systemName: "chart.pie"),
identifier: "dashboard",
viewControllerProvider: { _ in
return UINavigationController(rootViewController: DashboardViewController())
})
allTabs.append(mainTab)
setTabs(allTabs, animated: false)
}
}
And the DashboardViewController is empty:
class DashboardViewController: UIViewController {
}
The only reason I created as a seperate class in this example is so I can easily see if it's visible in the memory debug view.
I have uploaded the simple sample app to GitHub:
https://github.com/fwaddle/TabbarMemoryLeakCheck
Anyone have any suggestions?
Here is a screen grab of the memory debug view showing the UITab having a reference to the DashboardViewController even though MyTabBarController has been dealloc'd:
Topic:
UI Frameworks
SubTopic:
UIKit
Hello!
My question is about 1) if we can use any and or all accessibility features within a sandboxed app and 2) what steps we need to take to do so.
Using accessibility permissions, my app was working fine in Xcode. It used NSEvent.addGlobalMonitorForEvents and localMoniter, along with CGEvent.tapCreate. However, after downloading the same app from the App Store, the code was not working. I believe this was due to differences in how permissions for accessibility are managed in Xcode compared to production.
Is it possible for my app to get access to all accessibility features, while being distributed on the App Store though? Do I need to add / request any special entitlements like com.apple.security.accessibility?
Thanks so much for the help. I have done a lot of research on this online but found some conflicting information, so wanted to post here for a clear answer.
I have a UIKit app with a custom navigation controller. I want my view title to go up into the navigation bar when the user scrolls down the screen. It looks like UIScrollEdgeElementContainerInteraction should do what I want, but I am having trouble using it.
Below is a sample, where a header view represents a title. I added the interaction to the header view, but it seems to have no effect. Am I missing a step? Perhaps I misunderstand what this is supposed to do, or perhaps I do not understand the preconditions to make this work.
I am hoping someone can tell me what I am doing wrong, or point me to some working sample code.
Thank you.
John
class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
var headerView: UIVisualEffectView!
var tableView: UITableView!
var interaction: UIScrollEdgeElementContainerInteraction!
override func viewDidLoad() {
super.viewDidLoad()
self.tableView = UITableView()
self.tableView.translatesAutoresizingMaskIntoConstraints = false
self.tableView.topEdgeEffect.style = .soft
self.tableView.delegate = self
self.tableView.dataSource = self
self.tableView.register(UITableViewCell.self, forCellReuseIdentifier: "cell")
self.view.addSubview(self.tableView)
self.view.addConstraints([
self.tableView.topAnchor.constraint(equalTo: self.view.topAnchor),
self.tableView.leadingAnchor.constraint(equalTo: self.view.leadingAnchor),
self.tableView.trailingAnchor.constraint(equalTo: self.view.trailingAnchor),
self.tableView.bottomAnchor.constraint(equalTo: self.view.bottomAnchor),
])
self.headerView = UIVisualEffectView(effect: UIGlassEffect(style: .regular))
self.headerView.translatesAutoresizingMaskIntoConstraints = false
self.headerView.backgroundColor = .green
self.view.addSubview(self.headerView)
self.view.addConstraints([
self.headerView.topAnchor.constraint(equalTo: self.view.topAnchor),
self.headerView.leadingAnchor.constraint(equalTo: self.view.leadingAnchor),
self.headerView.trailingAnchor.constraint(equalTo: self.view.trailingAnchor),
self.headerView.heightAnchor.constraint(equalToConstant: 100.0),
])
let label = UILabel()
label.translatesAutoresizingMaskIntoConstraints = false
label.text = "my text"
self.headerView.contentView.addSubview(label)
self.headerView.contentView.addConstraints([
label.centerXAnchor.constraint(equalTo: self.headerView.contentView.centerXAnchor),
label.centerYAnchor.constraint(equalTo: self.headerView.contentView.centerYAnchor),
])
self.interaction = UIScrollEdgeElementContainerInteraction()
self.interaction.scrollView = self.tableView
self.interaction.edge = .top
self.headerView.addInteraction(self.interaction)
}
func numberOfSections(in tableView: UITableView) -> Int {
return 1
}
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
return 100
}
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = self.tableView.dequeueReusableCell(withIdentifier: "cell", for: indexPath)
cell.textLabel?.text = "row \(indexPath.row + 1)"
return cell
}
}
Hi,
I have a NavigationSplitView with a view in the detail section:
NavigationSplitView {
ZStack {
Color.black.ignoresSafeArea()
gradientBlack2Blue.opacity(0.25)
.ignoresSafeArea()
GeometryReader { p in
VStack {
List {
SidebarViewCell(id: "1",
text: "Steuersätze" ,
type: .TAX_MASTERDATA ,
selectedMasterdataType: $selectedMasterdataType)
}.listRowSpacing(size.height * 1.25 / 100 )
.scrollContentBackground(.hidden)
.toolbar(.hidden, for: .navigationBar)
.frame(width: p.size.width * 98 / 100 , height: p.size.height,
alignment: .topLeading).
}alignment: .topLeading)
}
}
}
detail: {
MasterdataDetailView().ignoresSafeArea()
}
}.navigationSplitViewStyle(.balanced)
When I place a Button-Control in the MasterdataDetailView it cannot be clicked because it is in the safe area. How can I make it clickable?
Best Regards,
Frank
I've encountered a potential bug where a TextField connected to an optional value (not a string) works as expected when bound to a @State property, but won't update a @Binding property.
Here is some example code
import SwiftUI
struct ContentView: View
{
@Binding var boundValue: Double?
@State private var stateValue: Double? = 55
var body: some View
{
TextField("Bound value", value: $boundValue, format: .number)
Text("\(boundValue ?? .nan)")
TextField("State value", value: $stateValue, format: .number)
Text("\(stateValue ?? .nan)")
}
}
#Preview
{
ContentView(boundValue: .constant(42.00))
}
It's as though the optional value stored externally is preventing the value updating. Can anyone confirm whether this is intentional, or a bug?
This is in Xcode 26b6, on macOS Tahoe 26b8, but from this query it looks like the problem has existed for years.
Topic:
UI Frameworks
SubTopic:
SwiftUI
Please has anyone found a workaround for duplicate back buttons appearing on the toolbar of a ContentView launched from a DocumentGroup?
The problem occurs with Xcode 14.0 running a basic DocumentGroup App on iOS 16.0.
To reproduce, simply build a new project using the "Document App" template. Build and run in the iOS/iPadOS simulator or on an iOS/iPadOS device.
Two back buttons appear. Only one functions. I've not found a way to eliminate the dud.
This problem has occurred throughout the Xcode 14.0 beta program.
My app has the following UI layout:
NSSplitViewController as the windows contentViewController
NSPageController in the content (right) split item
NSTabViewController as the root items of the NSPageController
NSViewController with a collection view in the first tab of that NSTabViewController
The collection view is using a NSCollectionViewCompositionalLayout in which the sections are set up to have a header using NSCollectionLayoutBoundarySupplementaryItem with pinToVisibleBounds=true and alignment=top
With macOS 26, the pinned supplementary item automatically gets a blurred/semi-transparent background that seamlessly integrates with the toolbar. When the window's title bar has a NSTitlebarAccessoryViewController added, the said semi-transparent background gets a bottom hard edge and a hairline to provide more visual separation from the main content.
During runtime, my NSPageController transitions from the NSTabViewController to another view controller. When transitioning back, the semi-transparent blur bleeds into the entire section. This happens no matter if there's a NSTitlebarAccessoryViewController added or not.
It doesn't happen 100% of the cases, it seems to depend on section size, header visibility and/or scroll position. But it happens more often than not.
Most of the time, a second or so after the back transition - shortly after pageControllerDidEndLiveTransition: of the NSPageControllerDelegate is called - the view updates and the supplementary views are back to normal.
Sometimes, the issue also appears not when transitioning using NSPageController, but simply by scrolling through the collection view.
Anyone has an idea what is happening here? Below are two screenshots of both the "ok" and "not ok" state
I'm on macOS 26.0.1 and I'm using XCode 26.0.1
I have SwiftData models containing arrays of Codable structs that worked fine before adding CloudKit capability. I believe they are the reason I started seeing errors after enabling CloudKit.
Example model:
@Model
final class ProtocolMedication {
var times: [SchedulingTime] = [] // SchedulingTime is Codable
// other properties...
}
After enabling CloudKit, I get this error logged to the console:
'NSKeyedUnarchiveFromData' should not be used to for un-archiving and will be removed in a future release
CloudKit Console shows this times data as "plain text" instead of "bplist" format.
Other struct/enum properties display correctly (I think) as "bplist" in CloudKit Console.
The local SwiftData storage handled these arrays fine - this issue only appeared with CloudKit integration.
What's the recommended approach for storing arrays of Codable structs in SwiftData models that sync with CloudKit?
On WWDC25 session "Meet Liquid Glass", two Liquid Glass variants are mentioned: "regular" and "clear". "Regular" seems to be the default setting for UIGlassEffect, but I was not able to find an option for clear.
Is there a native element that uses clear? Is it coming to later betas for iOS 26?
I have a SwiftUI Mac Catalyst app. I create a toolbar like this
NavigationSplitView(columnVisibility: $sceneModel.columnVisibility, preferredCompactColumn: $preferredColumn) {
sidebarView()
} detail: {
contentView()
.toolbar {
ToolbarItemGroup(placement: .topBarTrailing) {
HStack {
Button {
sceneModel.onMaps(sender: self)
} label: {
Image(systemName: "map")
.font(.title2)
}
Button {
sceneModel.onSearch(sender: self)
} label: {
Image(systemName: "magnifyingglass")
.font(.title2)
}
...
}
}
}
}
When my Mac Appearance is set to dark mode and the content under the toolbar is dark the toolbar looks good like this.
But then if I have light content under the toolbar, the glass effect changes to light, but the tint on the icons stays white instead of changing to black and it is hard to see the icon. It looks like this.
When I set the Appearance on my Mac to light, then the toolbar works just fine on both dark and light colored backgrounds.
Does anyone know how I can fix this when the appearance is Dark?
I have a custom document-based iOS app that also runs on macOS. After implementing -activityItemsConfiguration to enable sharing from the context menu, I found that the app crashes on macOS when selecting Share… from the context menu and then selecting Save (i.e. Save to Files under iOS). This problem does not occur on iOS, which behaves correctly.
- (id<UIActivityItemsConfigurationReading>)activityItemsConfiguration {
NSItemProvider * provider = [[NSItemProvider alloc] initWithContentsOfURL:self.document.presentedItemURL];
UIActivityItemsConfiguration * configuration = [UIActivityItemsConfiguration activityItemsConfigurationWithItemProviders:@[ provider ]];
// XXX crashes with com.apple.share.System.SaveToFiles
return configuration;
}
Additionally, I found that to even reach this crash, the workaround implemented in the NSItemProvider (FBxxx) category of the sample project is needed. Without this, the app will crash much earlier, due to SHKItemIsPDF() erroneously invoking -pathExtension on an NSItemProvider. This appears to be a second bug in Apple’s private ShareKit framework.
#import <UniformTypeIdentifiers/UniformTypeIdentifiers.h>
@implementation NSItemProvider (FBxxx)
// XXX SHKItemIsPDF() invokes -pathExtension on an NSItemProvider (when running under macOS, anyway) -> crash
- (NSString *)pathExtension {
return self.registeredContentTypes.firstObject.preferredFilenameExtension;
}
@end
Again, this all works fine on iOS (17.5) but crashes when the exact same app build is running on macOS (14.5).
I believe these bugs are Apple's. Any idea how to avoid the crash? Is there a way to disable the "Save to Files" option in the sharing popup?
I filed FB13819800 with a sample project that demonstrates the crash on macOS. I was going to file a TSI to get this resolved, but I see that DTS is not responding to tech support incidents until after WWDC.
Topic:
UI Frameworks
SubTopic:
UIKit
Using desaturated mode on an image in a widget will break any links or buttons that use the image as their 'label'.
Using the following will just open the app as if there was no link at all - therefore just using the fallback userActivity handler, or any .widgetURL() urls provided.
Link(destination: URL(string: "bug://never-works")!) {
Image("puppy")
.widgetAccentedRenderingMode(.desaturated)
}
The same goes for buttons:
Button(intent: MyDemoIntent()) {
Image("puppy")
.widgetAccentedRenderingMode(.desaturated)
}
I've tried hacky solutions like putting the link behind the image using a ZStack, and disabling hit testing on the image, but they don't work. Anything else to try?
Logged as Feedback #15152620.
I have an existing Mac app which has evolved through over twenty years of development. It is currently written in a mixture of C++ and Objective-C, with a bit of C and Swift in a few places. For a few years now, I have been tinkering with replacing the UI with SwiftUI. The model has been completely rewritten in Swift and works fine. After a few tries, no version has been working acceptably, so I'm thinking that I need to rethink the architecture.
The UI consists of a window with a master-detail view. The detail view is what users spend most of their time with. It contains a lot of subviews, around 100 typically. Keyboard events affect the display, so I've had a dedicated data structure to hold the state that is needed for displaying all the subviews. Using Instruments, I see that the view seems to recreate the subviews three times per keyboard event, so I'm clearly doing something wrong.
A second factor is that there are a couple of dozen commands that are applicable to the detail view, driven either by menu items, keyboard shortcut, or toolbar button. Adding all of those to the view makes for a massive SwiftUI View, which seems unlikely to be good practice. The current implementation has the controller class broken up with categories, but still they are big classes.
Most SwiftUI stuff on the web is iOS-oriented, and typically has a focus on fairly simple apps, so the whole topic of dealing with menu commands doesn't get a lot of coverage, so I've been doing all that through my own solutions, which are probably nothing like optimal.
What I've been able to find is not particularly helpful for a full-fledged application like mine, so I'm looking for advice on how to structure the app. The existing one is largely MVC, but I've tried a similar approach and a shot at MVVM, but I'm not getting good results so far.
So, pointers, places I can read more, or samples of real-world apps is what I'm after. Anyone?
Hi all,
After upgrading to the iOS 26 beta, the scrolling in my SwiftUI chat view is completely broken. The exact same code works perfectly on iOS 18.
Context:
I have a chat view using ScrollViewReader and a vertically-reversed ScrollView (with .rotationEffect(.degrees(180))). Each message row (MessageBubble) uses multiple simultaneousGesture handlers:
Horizontal drag for swipe-to-reply (and other actions: pin, delete)
Long press for showing popover/actions
Vertical scroll for normal chat scrolling
This was working great on iOS 18. In iOS 26 beta, the vertical scroll is either completely disabled, jittery, or hijacked by the message row’s drag gestures, even though .simultaneousGesture is used (see code below).
Minimal Repro Sample
MessageListView.swift
swift
Copy
Edit
ScrollViewReader { proxy in
ScrollView(.vertical, showsIndicators: false) {
LazyVStack(spacing: 0) {
// ... grouped messages
ForEach(...) { ...
MessageBubble(...) // see below
}
Color.clear.frame(height: 8).id("BOTTOM_ANCHOR")
}
.padding(.horizontal, 4)
.rotationEffect(.degrees(180))
}
.rotationEffect(.degrees(180))
}
MessageBubble.swift
struct MessageBubble: View {
// ...
var body: some View {
// horizontal swipe-to-reply gesture
let dragGesture = DragGesture(minimumDistance: 10)
// ...
ZStack {
// ...
HStack { ... }
// ...
.simultaneousGesture(
DragGesture(minimumDistance: 0) // for long press
// ...
)
.simultaneousGesture(dragGesture) // for horizontal swipe
}
// ...
}
}
Hi! I develop an iOS library and I met an issue with SwiftUI previews in iOS app project with my library integrated. After I open preview, build for preview finishes successfully, but preview itself never appears. I failed to find any error messages or any other indicators of what went wrong or how to fix it. Switching to legacy preview execution seems to fix problem, but I think that is not ideal. Could you help fixing this?
Xcode 16.2, Simulator iPhone 16, iOS 18.2
Project to reproduce -
https://drive.google.com/file/d/1cU6JKwshK_wQfe9YIqcMg3UGWq45OYlx/view?usp=sharing
Preview diagnostics - https://drive.google.com/file/d/1kPcgVSSqreiepGuqhdIoCW2rLSicgsWr/view?usp=sharing
It seems like it is no longer possible to open the main window of an app after the app has been launched by the system if the "Auto Start" functionality has been enabled.
I am using SMAppService.mainApp to enable to auto start of my app. It is shown in the macOS system settings and the app is automatically started - but the main window is not visible.
How can I change this behaviour so the main window of the app is always visible when started automatically?
I have not noticed this behaviour before the release of macOS Sequoia. My app is using Swift 6 and the latest version of macOS and Xcode.
Regards
Topic:
UI Frameworks
SubTopic:
SwiftUI
For information I stumbled upon a regression with SwiftUI Slider on iOS 26. Its onEditingChanged closure might be called twice when interaction ends, with a final Boolean incorrect value of true provided to the closure.
As a result apps cannot reliably rely on this closure to detect when an interaction with the slider starts or ends.
I filed a feedback under FB20283439 (iOS 26.0 regression: Slider onEditingChanged closure is unreliable).
I Am interested in coding, and built my fist app that is an app that has a picture of Niagara Falls with corner radius of 10, But, every time I start the build, it says: Thread 1: EXC_BAD_ACCESS (code=2, address=0x16b123f20) not sure what to do now.