I've got an iOS app with a custom top toolbar view that uses a UIScrollEdgeElementContainerInteraction to achieve the iOS 26 progressive blur background. It's over top of a web view, and I've set the top edge effect style on its scroll view to .hard so the toolbar's edges are more defined.
I'm noticing that the blur doesn't extend fully to the bottom edge of the toolbar, and I'm curious to know if this is a bug or expected behavior. If the latter, what exactly are the details of what's expected? What determines the bottom extent of the blur?
I've got this result in a sample project on iOS 26.0. The white border is the label, and the red border is the title bar view itself. Note that the Daring Fireball logo visible inside the bounds of the bar view, and is cut off at the bottom edge of the label.
This is the code from the demo app that produced the screenshot.
let config = WKWebViewConfiguration()
let webView = WKWebView(frame: .zero, configuration: config)
self.view.addSubview(webView)
webView.translatesAutoresizingMaskIntoConstraints = false
webView.topAnchor.constraint(equalTo: self.view.topAnchor).isActive = true;
webView.bottomAnchor.constraint(equalTo: self.view.bottomAnchor).isActive = true;
webView.leftAnchor.constraint(equalTo: self.view.leftAnchor).isActive = true;
webView.rightAnchor.constraint(equalTo: self.view.rightAnchor).isActive = true;
webView.scrollView.topEdgeEffect.style = .hard
webView.load(URLRequest(url: URL(string: "https://daringfireball.net")!))
let barView = UIView()
self.view.addSubview(barView)
barView.translatesAutoresizingMaskIntoConstraints = false
barView.topAnchor.constraint(equalTo: self.view.topAnchor).isActive = true;
barView.leftAnchor.constraint(equalTo: self.view.leftAnchor).isActive = true
barView.rightAnchor.constraint(equalTo: self.view.rightAnchor).isActive = true
let edgeEffect = UIScrollEdgeElementContainerInteraction()
edgeEffect.scrollView = webView.scrollView
edgeEffect.edge = .top
barView.addInteraction(edgeEffect)
barView.layer.borderColor = UIColor.red.cgColor
barView.layer.borderWidth = 1
let titleLabel = UILabel()
barView.addSubview(titleLabel)
titleLabel.translatesAutoresizingMaskIntoConstraints = false
titleLabel.leftAnchor.constraint(equalTo: barView.leftAnchor).isActive = true
titleLabel.rightAnchor.constraint(equalTo: barView.rightAnchor).isActive = true
titleLabel.bottomAnchor.constraint(equalTo: barView.bottomAnchor, constant: -20).isActive = true
titleLabel.topAnchor.constraint(equalTo: barView.safeAreaLayoutGuide.topAnchor, constant: 8).isActive = true
titleLabel.textAlignment = .center
titleLabel.text = "Title Here"
titleLabel.layer.borderColor = UIColor.green.cgColor
titleLabel.layer.borderWidth = 1
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
Hello,
I'm exploring the new SwiftUI WebView and WebPage APIs introduced in iOS 26, and I have a question about configuring media playback behavior.
In our app, we currently use WKWebView with the mediaTypesRequiringUserActionForPlayback property set to [] (or WKAudiovisualMediaTypeNone) to allow HTML videos with an "autoplay" attribute to play automatically without requiring user interaction. This property is part of WKWebViewConfiguration and controls which media types require a user gesture to begin playing. According to the official documentation (WKWebViewConfiguration.mediaTypesRequiringUserActionForPlayback), this allows us to support video content that needs to autoplay for our specific use case.
With the new iOS 26 WebView and WebPage APIs, I haven't been able to find a way to configure this behavior. Looking through the available configuration options, there doesn't appear to be an equivalent setting.
My questions are:
Has the default behavior changed for the new SwiftUI WebView? Does it now allow media autoplay by default?
If not, is there a way to configure this behavior that I'm missing?
If this configuration is intentionally not exposed, what is the recommended approach for apps that need to enable media autoplay?
Currently, we're wrapping WKWebView in a UIViewRepresentable to maintain this functionality, but we'd love to migrate to the native SwiftUI WebView later this year if possible.
Thank you for any guidance you can provide!
Hello,
I'm exploring the new SwiftUI WebView and WebPage APIs introduced in iOS 26, and I have a question about configuring JavaScript window opening behavior.
In our app, we currently use WKWebView with the javaScriptCanOpenWindowsAutomatically property set to true to support a specific use case. This property is part of WKPreferences and controls whether JavaScript can open windows without user interaction. According to the official documentation (WKPreferences.javaScriptCanOpenWindowsAutomatically), this property defaults to false on iOS and true on macOS.
With the new iOS 26 WebView and WebPage APIs, I haven't been able to find a way to configure this behavior. Looking through the available configuration options, there doesn't appear to be an equivalent setting.
My questions are:
Has the default behavior changed for the new SwiftUI WebView? Does it now allow JavaScript to open windows automatically by default on iOS?
If not, is there a way to configure this behavior that I'm missing?
If this configuration is intentionally not exposed, what is the recommended approach for apps that need to enable automatic window opening?
Currently, we're wrapping WKWebView in a UIViewRepresentable to maintain this functionality, but we'd love to migrate to the native SwiftUI WebView later this year if possible.
Thank you for any guidance you can provide!
I have an app that uses a Share Extension that allows the user to share videos, from Files and Photos etc., the video URL and some related data is then persisted with SwiftData and synchronized with CloudKit.
This code has worked consistently for a long time although recently, with iOS 26 and recent builds of iOS 18, I have observed that the video is either not saved to SwiftData (iOS 26.0), or available locally when the app is opened on the same device where the share occurred, but not synchronized to other devices (iOS 18.7 and iOS 26.1 beta).
Assuming the video is opened locally after being shared into the app, it is typically synchronized with CloudKit to other devices although it's not as reliable as it should be.
Is there a reliable approach in the Share Extension to ensure that the data is saved to the local SwiftData database and then synchronized with CloudKit. I suspect it could be that the lifetime of the Share Extension has become even more constrained in recent OS updates that the process ends before it has the opportunity to save and synchronize the data.
Any thoughts on how to ensure this is reliable would be greatly appreciated.
The data saved is not too large as it consists only of the video URL and not the data of the video itself.
I was looking at the new iOS 26 Mail app and it has these tab/filters of some sort and I was wondering if there is a default API/code in swiftui that I am supposed to be using.
Looked everywhere for this, thank you!!
We have a UICollectionView whose cells have custom context menu highlight previews.
In the delegate method collectionView(_:contextMenuConfiguration:highlightPreviewForItemAt:), we build a UITargetedPreview whose custom view contains some action buttons.
Up until iOS 18, our setup has been working perfectly. But since iOS 26, the custom view is not responding to touches. When the user taps one of its buttons, the context menu gets dismissed as if the touch was outside of the custom view.
Is there any UICollectionView-related API change in version 26?
in iOS, user can set focus on UItextField and tapping a key in the virtual keyboard updates the text in the textfield. This user action causes the relevant delegates of UITextFieldDelegate to get invoked, i.e the handlers associated with action of user entering some text in the textfield.
I m trying to simulate this user action where I am trying to do this programatically. I want to simulate it in a way such that all the handlers/listeners which otherwise would have been invoked as a result of user typing in the textfield should also get invoked now when i am trying to do it programatically. I have a specific usecase of this in my application.
Below is how I m performing this simulation.
I m manually updating the text field associated(UITextField.text) and updating its value.
And then I m invoking the delegate manually as textField.delegate?.textField?(textField, shouldChangeCharactersIn: nsRange, replacementString: replacementString)
I wanted to know If this is the right way to do this. Is there something better available that can be used, such that simulation has the same affect as the user performing the update?
We’ve recently updated our app to adopt the native iOS 26 tab bar. Since then, we’ve started seeing crashes on iOS 26 devices with swift_getObjectType appearing in the stack.
I’ve reviewed the logs in Organizer but couldn’t find anything conclusive. The issue seems isolated to iOS 26 and doesn’t reproduce on earlier versions.
com.grofers.consumer_issue_2cc3a4a209ab2b47bfbdab919a320fa7_crash_session_68148be54ef5441fac56d3138d055bac_DNE_5_v2_stacktrace.txt
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 use the .zoom transition in a navigation stack, I get a glitch when interrupting the animation by swiping back before it completes.
When doing this, the source view disappears. I can still tap it to trigger the navigation again, but its not visible on screen.
This seems to be a regression in iOS 26, as it works as expected when testing on iOS 18.
Has someone else seen this issue and found a workaround? Is it possible to disable interrupting the transition?
Filed a feedback on the issue FB19601591
Screen recording:
https://share.icloud.com/photos/04cio3fEcbR6u64PAgxuS2CLQ
Example code
@State var showDetail = false
@Namespace var namespace
var body: some View {
NavigationStack {
ScrollView {
showDetailButton
}
.navigationTitle("Title")
.navigationBarTitleDisplayMode(.inline)
.navigationDestination(isPresented: $showDetail) {
Text("Detail")
.navigationTransition(.zoom(sourceID: "zoom", in: namespace))
}
}
}
var showDetailButton: some View {
Button {
showDetail = true
} label: {
Text("Show detail")
.padding()
.background(.green)
.matchedTransitionSource(id: "zoom", in: namespace)
}
}
}
Topic:
UI Frameworks
SubTopic:
SwiftUI
We are observing that for devices with iPadOS 26, table views within apps are unexpectedly auto scrolling. The issue can be reproduced as follows:
The table view has enough cells to the point where not all cells can fit on the screen and the table view is scrollable
User has scrolled to the bottom of the tableView and tableView.reloadData() is called.
One of the following applies:
The ViewController containing the tableView is embedded in a UINavigationController, and ViewController sets self.edgesForExtendedLayout = .bottom
The ViewController containing the tableView is embedded in a UINavigationController, and UINavigationController sets navigationBar.isTranslucent = false
The following constraints are applied to the tableView:
tableView.topAnchor.constraint(equalTo: view.layoutMarginsGuide.topAnchor).isActive = true
tableView.leftAnchor.constraint(equalTo: view.leftAnchor).isActive = true
tableView.bottomAnchor.constraint(equalTo: view.bottomAnchor).isActive = true
tableView.rightAnchor.constraint(equalTo: view.rightAnchor).isActive = true
After thorough testing, we've found that the bug is only present in iPads with iPadOS 26. It does not show for iPhone devices or for iPads on iPadOS 18. We are hoping that this can be fixed as it is causing poor user experience.
Full code needed to reproduce the issue:
Use this willConnectTo function in SceneDelegate:
func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
guard let windowScene = scene as? UIWindowScene else { return }
window = UIWindow(windowScene: windowScene)
let navigationControllerWithVC = UINavigationController(rootViewController: ViewController())
// ⚠️ CASE 1 - Comment out the .isTranslucent setter below, or set the value to true, and the scrolling issue will be gone, granted that the other issue-causing lines in ViewController.swift
// are also commented.
navigationControllerWithVC.navigationBar.isTranslucent = false
window?.rootViewController = navigationControllerWithVC // Replace this line with window?.rootViewController = ViewController() to get rid of UINavigationController
window?.makeKeyAndVisible()
}
Use this ViewController class that is referenced from the SceneDelegate willConnectTo function:
import UIKit
class ViewController: UIViewController, UITableViewDelegate, UITableViewDataSource {
var tableView: UITableView!
var safeArea: UILayoutGuide!
var timer: Timer!
override func viewDidLoad() {
super.viewDidLoad()
// ⚠️ CASE 2 - Uncomment the line below when this view is inside a UINavigationController to cause the scrolling issue.
//self.edgesForExtendedLayout = .bottom
tableView = UITableView()
safeArea = view.layoutMarginsGuide
setupTableView()
timer = Timer.scheduledTimer(timeInterval: 3.0, target: self, selector: #selector(fireTimer), userInfo: nil, repeats: true)
}
@objc public func fireTimer() {
tableView.reloadData()
print("Reloaded table")
}
func setupTableView() {
tableView.delegate = self
tableView.dataSource = self
view.addSubview(tableView)
tableView.translatesAutoresizingMaskIntoConstraints = false
// ⚠️ CASE 3 - Replace view.topAnchor in the next line below with safeArea.topAnchor to see the scrolling issue, regardless if view is inside a UINavigationController.
tableView.topAnchor.constraint(equalTo: view.topAnchor).isActive = true
tableView.leftAnchor.constraint(equalTo: view.leftAnchor).isActive = true
tableView.bottomAnchor.constraint(equalTo: view.bottomAnchor).isActive = true
tableView.rightAnchor.constraint(equalTo: view.rightAnchor).isActive = true
}
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
40
}
public func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
50.0
}
public func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = UITableViewCell()
cell.textLabel?.text = indexPath.row == 39 ? "END" : "Row \(indexPath.row)"
return cell
}
public func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
tableView.deselectRow(at: indexPath, animated: true)
}
}
For reproducing this on iPadOS 26 simulators, I can confirm that simulators under Xcode 26.0.1 (17A400) and Xcode 26.1 Beta (17B5025f) will show the issue. The issue is present in iPadOS 26 and iPadOS 26.1 beta.
I've also submitted Apple Feedback for this (FB20357980) with all this code in a Xcode project.
So I normally use the below as quick reference guide:
https://mar.codes/apple-colors
however, what is the reason that iOS colors are not available on tvOS? Especially the system/grays that are available on iOS.
What does everyone else use for alternatives to these to get close matches between their multi platform apps?
I have a triple-column UISplitViewController setup in "tile" mode. Each of the 3 columns has a table view controller. Under iPadOS 26, the section headers and row selection in the middle table extends all the way to the left of the screen, behind the primary column. It looks terrible. The documentation for "Adopting Liquid Glass" makes it sound like you can add this behavior by using UIBackgroundExtensionView. But I get this behavior automatically in a UISplitViewController. How do I turn this off?
I created a simpler sample using a double-column split view with two table view controllers. Here's a screenshot of the result:
Note how the section headers and the row selection appear all the way to the left edge of the screen. I don't want that effect. How do you turn off this effect in a UISplitViewController?
Here is the code used to setup the split view and the app's main window:
func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
guard let winScene = (scene as? UIWindowScene) else { return }
let primary = PrimaryViewController(style: .plain)
let primaryNC = UINavigationController(rootViewController: primary)
let detail = DetailViewController(style: .plain)
let detailNC = UINavigationController(rootViewController: detail)
let sv = UISplitViewController(style: .doubleColumn)
sv.preferredDisplayMode = .oneBesideSecondary
sv.preferredSplitBehavior = .tile
sv.primaryBackgroundStyle = .none
sv.displayModeButtonVisibility = .automatic
sv.setViewController(primaryNC, for: .primary)
sv.setViewController(detailNC, for: .secondary)
let win = UIWindow(windowScene: winScene)
win.rootViewController = sv
win.makeKeyAndVisible()
window = win
}
The PrimaryViewController and DetailViewController are simple UITableViewController subclasses that only add a few rows and section headers as needed.
Hi.
I tried to launch SwiftUI preview.
But I got an error "AppLaunchTimeoutError"
I attach the diagnostics.
Does anyone know how to fix this problem?
memo.txt
Topic:
UI Frameworks
SubTopic:
SwiftUI
Hi.
Since Xcode 16 and/or iOS 18.0 (I upgraded at the same time), I have an strange effect in the lower (let's say) 20% section of the Navigation Bar when changing to another tab, and this independently if large titles are used or not. Mentioned section is brighter or darker than the rest of the Navigation Bar background, depending on which background tint is used. This effect lasts about 0.3 seconds, but is clearly visible, quite disturbing and new as of Xcode 16 and/or iOS 18.0.
I use the code below in AppDelegate to get a gradient coloured Navigation Bar background.
let appearance = UINavigationBarAppearance()
UINavigationBar.appearance().standardAppearance = appearance
UINavigationBar.appearance().compactAppearance = appearance
UINavigationBar.appearance().scrollEdgeAppearance = appearance
UINavigationBar.appearance().compactScrollEdgeAppearance = appearance
If I don't use above code., the background color is filled and without gradient. Subject effect doesn't show in this case.
The effect basically looks like when changing tab, the new Navigation Bar background doesn't clear right away, and keeps the background from the previous Navigation Bar for 0.3 seconds before new one Navigation Bar background is rendered.
I spent quite some time on changing every possible setting, in code as well as storyboard ... no success so far.
Any ideas how to disable this undesired animation?
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?
On iPhone .inspector is presented as a sheet so you can use .presentationDetents to determine its detents. However, SwiftUI doesn't update the presentationDetents selection binding in this case. See attached minimum example of the problem - onChange will not run and print when you swipe and change the detent of the inspector sheet.
import SwiftUI
@main
struct TestingApp: App {
var body: some Scene {
WindowGroup {
ContentView()
}
}
}
struct ContentView: View {
@State var showInspector = false
@State var detent: PresentationDetent = .medium
var body: some View {
Button("Toggle Inspector") {
showInspector.toggle()
}
.inspector(isPresented: $showInspector) {
Text("Inspector Content")
.presentationDetents([.medium, .large], selection: $detent)
}
.onChange(of: detent) { _, detent in
print(detent)
}
}
}
#Preview {
ContentView()
}
Hi everyone:
I'm experiencing an issue in iOS 26. I've implemented a custom ViewController. It's super simple to edit images with flip, crop, zoom in, and zoom out. My question is that it seems very strange to me. It works without problems in iOS 17.5 and iOS 18. However, when I try to run it with iOS 26, the entire ViewController seems disabled; it doesn't recognize touches or anything. When I checked the UI hierarchy, I saw a strange FloatingBarContainerView overlaying the entire ViewController.
I searched the documentation for information about this view, but I couldn't find anything. Any help on how to hide or remove this view in iOS 26? This hasn't been implemented anywhere.
Hi everyone,
I’m building a simple sticky notes app that allows users to place a note widget on their home screen. Each widget displays a user-created sticky note.
To let users choose which note to show, I’ve implemented an Intent that presents a list of existing sticky notes. The list is built using IntentItems, and for each item I assign an image to visually represent the note.
Each sticky note can have a different background color and optional image, so I generate a small PNG (150×150, ~30 KB) and include it in the app bundle.
However, when I try to display the selection list, I get the following error:
The action Select sticky note could not run because an unknown error occurred.
If I tap OK and try again, the intent selector appears and works.
Here’s what I’d like to understand:
What could cause this unknown error when using images in IntentItems?
Are there known limitations on image size, source, or format for intent item images?
Can I supply a unique image per sticky note, or must all intent items share a common image?
Any guidance or insights would be greatly appreciated — I haven’t been able to find clear documentation about image handling in IntentItem for widget configuration.
Thanks!