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.

All subtopics
Posts under UI Frameworks topic

Post

Replies

Boosts

Views

Activity

macOS 27 Golden Gate – Serious UI rendering issues on two different Apple Silicon Macs
Hello everyone, Since upgrading to macOS 27 Golden Gate, I've been experiencing numerous graphical interface issues on both of my Macs: MacBook Pro M4 Pro (work computer) MacBook Air M4 (personal computer) Both machines use completely separate Apple Accounts, yet they exhibit the same problems. The issues mainly affect window controls, menus, buttons, and title bars. For example: The red, yellow, and green window control buttons sometimes disappear completely. Safari's toolbar or title bar occasionally fails to render properly. When closing another application, such as Microsoft Word, parts of the Safari interface can disappear or become blank. Certain interface elements are not properly redrawn when switching between applications or rearranging windows. I've attached screenshots illustrating these problems. I don't use Stage Manager or any third-party window management utilities. Both Macs are running standard macOS configurations. These issues only started after upgrading to Golden Gate. Given that they occur on two different Apple Silicon Macs with separate Apple Accounts, I strongly suspect a macOS-level window rendering bug rather than a hardware or user-specific issue. The problems are quite disruptive during everyday work. Is anyone else experiencing similar issues? Has Apple acknowledged these rendering bugs, and is there any indication of when a fix might be released? Thanks in advance for your feedback.
Topic: UI Frameworks SubTopic: AppKit
0
0
203
3w
iPhone Duo: Making a custom popup avoid the hinge by presenting it as an arrowless popover
Background On iPhone Duo, when the device is unfolded and then partially folded, system alerts (UIAlertController) are automatically repositioned so they stay clear of the hinge. Apple's Tech Talk confirms this: "The system automatically repositions components around the reserved region." Our app uses a custom popup: a view controller presented with .overFullScreen that lays out its own dimming view and a custom-drawn view (here, a coupon ticket with notched edges) in the center of the screen. This popup is not repositioned. It stays centered on screen, right on top of the fold. The recommended approach for custom UI is to query view.reservedRegions(kind: .division) and lay out around the fold manually. Before going that route, I tried something simpler. What I tried The Tech Talk lists popovers among the components the system repositions. So I presented the same custom view as a popover with no arrow, anchored to the center of the presenting view: final class CouponPopoverViewController: UIViewController, UIPopoverPresentationControllerDelegate { private let ticketView = CouponTicketView() // the custom popup view init(centeredIn sourceView: UIView) { super.init(nibName: nil, bundle: nil) modalPresentationStyle = .popover guard let popover = popoverPresentationController else { return } popover.sourceView = sourceView popover.sourceRect = Self.centerPoint(of: sourceView.bounds) popover.permittedArrowDirections = [] // Drop the system popover chrome so only the custom view (and its own shadow) is visible. popover.popoverBackgroundViewClass = ClearPopoverBackgroundView.self popover.delegate = self } required init?(coder: NSCoder) { fatalError() } override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .clear ticketView.translatesAutoresizingMaskIntoConstraints = false view.addSubview(ticketView) NSLayoutConstraint.activate([ ticketView.topAnchor.constraint(equalTo: view.topAnchor), ticketView.bottomAnchor.constraint(equalTo: view.bottomAnchor), ticketView.leadingAnchor.constraint(equalTo: view.leadingAnchor), ticketView.trailingAnchor.constraint(equalTo: view.trailingAnchor) ]) preferredContentSize = ticketView.systemLayoutSizeFitting( CGSize(width: 300, height: UIView.layoutFittingCompressedSize.height), withHorizontalFittingPriority: .required, verticalFittingPriority: .fittingSizeLevel ) } private static func centerPoint(of bounds: CGRect) -> CGRect { CGRect(x: bounds.midX, y: bounds.midY, width: 0, height: 0) } // Keep it a popover on iPhone instead of adapting to a sheet. func adaptivePresentationStyle(for controller: UIPresentationController, traitCollection: UITraitCollection) -> UIModalPresentationStyle { .none } // Re-anchor to the center after rotation or fold changes. func popoverPresentationController(_ popoverPresentationController: UIPopoverPresentationController, willRepositionPopoverTo rect: UnsafeMutablePointer<CGRect>, in view: AutoreleasingUnsafeMutablePointer<UIView>) { rect.pointee = Self.centerPoint(of: view.pointee.bounds) } } /// A popover background that draws nothing: no arrow, no insets, no default appearance. final class ClearPopoverBackgroundView: UIPopoverBackgroundView { override class func arrowBase() -> CGFloat { 0 } override class func arrowHeight() -> CGFloat { 0 } override class func contentViewInsets() -> UIEdgeInsets { .zero } override class var wantsDefaultContentAppearance: Bool { false } override var arrowOffset: CGFloat { get { 0 } set {} } override var arrowDirection: UIPopoverArrowDirection { get { .any } set {} } } Result Partially folded, portrait (hinge runs horizontally across the middle of the screen): Before: the custom popup (.overFullScreen) stays centered, right across the hinge. After: the same view presented as an arrowless popover moves into the top half, clear of the hinge. Partially folded, book pose (vertical hinge): the popover moves to the leading page, clear of the hinge. This matches where a system UIAlertController goes in the same pose. I also checked that the popover shows correctly on the outer display (closed) and on a non-Duo iPhone (iPhone 18 Pro, iOS 27.0). Tested on: iPhone Duo simulator (iOS 27.1), Xcode 27.1 RC (27A9275) iPhone 18 Pro simulator (iOS 27.0) Things to handle when switching to a popover Tap-outside dismissal: Popovers dismiss on outside taps by default. Set isModalInPresentation = true or return false from presentationControllerShouldDismiss(_:) if the popup should only close via its buttons. Dimming: Popovers don't dim the background like a typical custom popup (compare the before and after screenshots). Add your own dimming view if needed. Chrome: By default, the system draws its own background behind the content. For a custom-shaped view, this shows through any transparent areas and clips the view's shadow. A UIPopoverBackgroundView subclass that draws nothing (above) removes it. Sizing: Set preferredContentSize explicitly. Recompute it for dynamic content and Dynamic Type. Questions This works well in my testing, but I couldn't find any documentation saying that an arrowless popover anchored to the center gets the same hinge avoidance as alerts. Is this supported behavior that we can rely on going forward? Or is reservedRegions(kind:options:) with manual layout the only recommended approach for custom popups? It would also be great to have a public API that lets custom presentations opt into the same hinge-avoidance placement that system alerts use. Hope this helps anyone else dealing with custom popups on iPhone Duo.
Topic: UI Frameworks SubTopic: UIKit Tags:
2
0
276
3w
iPhone Duo - Current SDK State
We are just 9 days before the iPhone Duo release, and the SDK is still in a pretty bad state, at least for the Keyboard Extension: Hinge detection doesn't work Reserved area detection doesn't work needsInputModeSwitchKey returns false even though iOS doesn't display its own globe button Switching between closed and fully open state loses text field focus and the keyboard disappears (regression bug - it worked in Beta 1) It's unacceptable that, with such a short release date, we still don't have a stable SDK... I expect the iPhone Duo release to be one of the buggiest releases Apple has ever done.
7
0
668
3w
(iPhone Duo) Toolbar Items are misplaced for RTL layout-direction
On iPhone Duo, when I use .environment(\.layoutDirection, .rightToLeft) for a navigation view, the toolbar items sometimes appear on the left side instead of the right side, below the camera. This results in a view with two sides, and in some cases, it displays in an unexpected place. For example, in the code below, the button is placed behind the camera, as shown in the attachment. NavigationSplitView { Text("Sidebar") .toolbar { ToolbarItem(placement: .cancellationAction) { Button("X", systemImage: "xmark", action: {}) } } } detail: { Text("Detail") } .environment(\.layoutDirection, .rightToLeft) Is this intended behavior for RTL layout direction, a known issue, or a simulator issue?
5
1
410
3w
How to get UISheetPresentationController width to adjust for vertical toolbar on iPhone Duo?
If you run Safari in the iPhone Duo simulator and choose to share something you get a screen similar to the following: In my own app, if I present a UIActivityViewController I get a similar result. Note that the share sheet does not cover the vertical toolbar at all. So my question is how to present a UISheetPresentationController to look the same way. In other words, how to get the width of the UISheetPresentationController to take into account the vertical toolbar? All of my existing code to create and present a UISheetPresentationController result in the UISheetPresentationController taking the full width of the screen. The contents of the sheet take the safe area into account, but that's not the same result. I need the sheet itself to be narrower. I don't see an API for this. Or does this require more complicated presentation controller / delegate setup? Here is some relevant code in the view controller that I want displayed in the sheet: self.modalPresentationStyle = .popover self.presentationController?.delegate = self if let sheet = popoverPresentationController?.adaptiveSheetPresentationController { popoverPresentationController?.passthroughViews = [] sheet.detents = [ .medium(), .large() ] sheet.largestUndimmedDetentIdentifier = nil sheet.prefersGrabberVisible = false sheet.prefersScrollingExpandsWhenScrolledToEdge = true sheet.prefersEdgeAttachedInCompactHeight = true sheet.widthFollowsPreferredContentSizeWhenEdgeAttached = true } Or maybe UISheetPresentationController is the wrong approach.
Topic: UI Frameworks SubTopic: UIKit Tags:
0
0
147
3w
UIAlertController.addTextField results in broken text field in 27.1
I just downloaded Xcode 27.1 to test out the iPhone Duo simulator, and I notice that UIAlertController.addTextField, which was working fine in 27, is now very broken, resulting in a text field that is squashed vertically and pushed over to the right in the alert sheet. This is very easy to reproduce - the following code will show the problem if you build in Xcode 27.1 and run on iOS 27.1 or iOS 27.2: let alert = UIAlertController(title: "Create Something", message: "Enter a title.", preferredStyle: .alert) alert.addTextField { textField in textField.placeholder = "Title" } alert.addAction(UIAlertAction(title: "Cancel", style: .cancel)) present(alert, animated: true) The bug isn't limited to the Duo, but can also be seen on an iPad (and probably a regular phone). I would post a screenshot, but the last time I tried that, the forum software erroneously banned me for two weeks. I have reported this as bug #FB24889500, but given that we use alerts with text fields for users adding new items to the outline in our app, something the user does a lot, I'm wondering if there is a workaround, since this is going to make our app look very buggy.
Topic: UI Frameworks SubTopic: UIKit Tags:
1
3
390
3w
How to preserve collection view scroll anchor when folding/unfolding iPhone Duo
The following question was asked in the Oct 13 iPhone Duo group lab: when you unfold iPhone Duo after you’ve scrolled down, does UIKit keep the position or should we re-anchor ourselves? The answer was various scroll views like collection views and text views will handle this for you to keep visible items visible, which also works when resizing the window on iPad. This is not working for me with a simple UICollectionView. What do I need to do to obtain this behavior? class ViewController: UIViewController, UICollectionViewDataSource { override func viewDidLoad() { super.viewDidLoad() let layout = UICollectionViewFlowLayout() layout.itemSize = CGSize(width: 80, height: 80) layout.minimumInteritemSpacing = 8 layout.minimumLineSpacing = 8 layout.sectionInsetReference = .fromLayoutMargins let collectionView = UICollectionView(frame: .zero, collectionViewLayout: layout) collectionView.translatesAutoresizingMaskIntoConstraints = false collectionView.backgroundColor = .systemBackground collectionView.dataSource = self collectionView.insetsLayoutMarginsFromSafeArea = true collectionView.register(UICollectionViewCell.self, forCellWithReuseIdentifier: "Cell") view.addSubview(collectionView) NSLayoutConstraint.activate([ collectionView.topAnchor.constraint(equalTo: view.topAnchor), collectionView.leadingAnchor.constraint(equalTo: view.leadingAnchor), collectionView.trailingAnchor.constraint(equalTo: view.trailingAnchor), collectionView.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) } func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int { 5000 } func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell { let cell = collectionView.dequeueReusableCell(withReuseIdentifier: "Cell", for: indexPath) var content = UIListContentConfiguration.cell() content.text = String(indexPath.item) content.textProperties.alignment = .center cell.contentConfiguration = content var background = UIBackgroundConfiguration.clear() background.backgroundColor = .secondarySystemBackground cell.backgroundConfiguration = background return cell } } Run the app on iPhone Duo Scroll down to cell 100 on the outer display Unfold the device Expected: It should stay scrolled to item 100 Actual: It scrolled down to item 225 (or more accurately, the content offset did not change, more content was added higher up with the contentSize shrinking due to the expanded width) In the past I've put so much work into trying to maintain the expected scroll position for orientation changes on iPhone and iPad/Mac Catalyst resize events, it's surprisingly incredibly hard to get working in every scenario, so I am SUPER interested to learn the system can do it for us!
0
0
268
3w
How to set custom height for keyboard extension without resize flicker?
Description I'm developing a custom keyboard extension using UIInputViewController and need to set a specific height of 268 points. The keyboard functions correctly, but there's a visible flicker and resize animation during launch that I cannot eliminate. The Problem When the keyboard launches, iOS provides incorrect heights before settling on the correct one. At launch, the view starts at 0×0. Around 295ms later, iOS sets the frame to 440×956 which is full screen height and wrong. Around 373ms, iOS changes it to 440×452 which is still wrong. Finally around 390ms, iOS settles at 440×268 which matches our constraint. This causes visible flicker as the view resizes three times rapidly. The keyboard appears to shrink from full screen down to the correct height, and users can clearly see this animation happening. What I've Tried I've tried adding a height constraint on self.view which gives me the correct height but causes the visible flicker. I created a custom UIInputView subclass and overrode intrinsicContentSize to return my desired height. iOS completely ignores this and gives random heights like 471pt, 680pt, or 956pt instead. I set allowsSelfSizing to true on my UIInputView subclass. iOS ignores this property. I set preferredContentSize on the view controller. iOS ignores this as well. I tried adding the constraint in viewDidAppear instead of viewDidLoad, thinking iOS might have settled by then. It still causes flicker. I overrode the frame and bounds setters on my UIInputView to clamp the height to my desired value. iOS bypasses these overrides somehow. I overrode layoutSubviews to force the correct height after the super call. iOS still applies its own height. Specific Question What is the correct API or technique to specify a keyboard extension's height that iOS will respect immediately upon launch, without triggering the resize animation sequence? Other third-party keyboards like Grammarly and SwiftKey appear to have solved this problem. Their keyboards appear at the correct height without any visible flicker. How do they achieve this? Expected Outcome The keyboard should appear at 268pt height on the first frame with no visible resize animation. Steps to Reproduce Create a new iOS App project in Xcode and add a Keyboard Extension target. In KeyboardViewController.swift, add a height constraint in viewDidLoad: override func viewDidLoad() { super.viewDidLoad() let heightConstraint = view.heightAnchor.constraint(equalToConstant: 268) heightConstraint.priority = .defaultHigh heightConstraint.isActive = true let label = UILabel() label.text = "Demo Keyboard" label.textAlignment = .center label.translatesAutoresizingMaskIntoConstraints = false view.addSubview(label) NSLayoutConstraint.activate([ label.centerXAnchor.constraint(equalTo: view.centerXAnchor), label.centerYAnchor.constraint(equalTo: view.centerYAnchor) ]) } Build and run on a physical device. Enable the keyboard in Settings, then General, then Keyboard, then Keyboards. Open any app with a text field and switch to the custom keyboard using the globe button. Observe the height changing from around 956pt to 452pt to 268pt with visible animation. Environment iOS 17 and iOS 18 and 26.2, Xcode 16 and Xcode 26, affects all iPhone models tested, reproducible on both simulator and physical device.
4
6
1.3k
3w
Tapping saved login does nothing after typing when .autocorrectionDisabled() or .textInputAutocapitalization(.never) modifier is applied
If a username field has .autocorrectionDisabled() or .textInputAutocapitalization(.never), tapping the saved login above the keyboard stops working once the user has typed part of their email. Nothing gets filled in. Seen on iPhone 16, iOS 27.0 (24A437). I've also reported this to Apple through Feedback Assistant (FB24825410). Steps to reproduce You need an app with Password AutoFill set up (a webcredentials associated domain) and a saved login for that domain. Tap the email field. The saved login appears above the keyboard. Type a few letters of the email. Tap the saved login. Expected: the email and password fields fill in, replacing what was typed. Actual: nothing happens. What works A username field with only .textContentType(.username) and .keyboardType(.emailAddress). Tapping the saved login fills both fields, no matter how much the user has typed. What breaks With .autocorrectionDisabled(), the tap works after 1 typed character, but does nothing after 2 or more. With .textInputAutocapitalization(.never), the tap does nothing after even 1 typed character. UIKit has the same problem: a UITextField with autocorrectionType = .no behaves like .autocorrectionDisabled(). In all of these cases, choosing the login from the key icon's Passwords sheet still fills both fields. Only the tap on the suggestion above the keyboard fails. Sample struct LoginView: View { @State private var email = "" @State private var password = "" var body: some View { VStack { TextField("Email", text: $email) .textContentType(.username) .keyboardType(.emailAddress) // Either of these breaks AutoFill once the user types: .autocorrectionDisabled() // fails after 2+ typed characters .textInputAutocapitalization(.never) // fails after 1 typed character SecureField("Password", text: $password) .textContentType(.password) } } } Workaround I removed both modifiers from our username field and it works. Typed emails still didn't get autocorrected in my testing. Has anyone found a way to keep these modifiers on a username field without breaking AutoFill? Possibly related: https://developer.apple.com/forums/thread/702970
2
0
513
3w
iOS 27: print(to:) silently drops every job after the first
The problem On iOS 27, UIPrintInteractionController.print(to:completionHandler:) works on its first call in a process. Every subsequent call is accepted (print(to:) returns true and printInteractionControllerWillStartJob fires), but the completion handler is never invoked: nothing prints, didFinishJob never fires, no error is produced, and no job appears in Print Center. I expected each call to submit an independent job and invoke its completion handler, as it does on iOS 26 and earlier with the identical binary. Steps to reproduce Build an app that prints without the print panel, using a retained UIPrinter from UIPrinterPickerController. Submit a job: let controller = UIPrintInteractionController.shared let info = UIPrintInfo(dictionary: nil) info.outputType = .general info.jobName = "job-\(n)" controller.printInfo = info controller.printingItem = pdfData // valid PDF, canPrint(data) == true controller.delegate = self let started = controller.print(to: savedPrinter) { _, completed, error in print("completion", completed, String(describing: error)) } print("started", started) First job: started == true, both willStartJob and didFinishJob fire, the completion handler runs with completed == true, and the page prints. Submit a second job the same way, same process. started == true and willStartJob fires with printInfo.printerID populated and printPaper negotiated to the same values as the successful job. Then nothing. No didFinishJob, no completion handler, no error, no page, nothing in Print Center. A third job: print(to:) returns false synchronously, since the shared controller still considers job two in flight. System information iPad, iPadOS 27.0 developer beta 6 Built against iOS 26.2 SDK (Xcode 26.2). Same binary works on iOS 26. Reproduced on two unrelated printers: Brother QL-820NWB and Canon MF420 Series. Content is a small PDF (~11 to 13 KB); canPrintData: returns true. Troubleshooting tried Restarted the iPad and reinstalled the app. Each buys exactly one successful print before the failure returns. Compared observable state between the working and hung jobs. Identical in every respect. During a hang, printed the same content to the same printer from Files via the share sheet. Worked normally, including on repeat. Paused in the debugger during the hang. No blocked thread; no PrintKit frame, XPC wait, or semaphore anywhere in bt all. Called contactPrinter before each job on the retained printer. Returned true quickly, and the job still hung. Implemented printInteractionControllerParentViewController(_:) in case a presentation context was missing. UIKit never calls it on this path. Workaround Creating a new UIPrintInteractionController per job resolves it completely. A long-lived instance the app creates itself fails exactly like .shared does, so the issue is reuse of a controller that has already run a job, not the shared singleton specifically. Is per-job instantiation the supported pattern? The docs say the shared instance "represents a print job" but don't state whether a controller may be reused for a second job, and every sample I can find uses sharedPrintController with the present… methods rather than print(to:).
5
7
1.6k
3w
Layout margins guides are still broken the iPhone Duo (sim) and 27.1 RC
Layout margin guides are broken throughout UIKit and SwiftUI on the iPhone Duo sim in iOS 27.1 RC. For example, a cell which looks perfectly fine on a normal iPhone sim (which has a compact horizontal size class), has zero vertical layout margins on iPhone Duo. Here's some screenshots. The red dotted lines are supposed to show the margins in the cell content view, i.e., the boundary between default padding around the cell (for its background) and the content of the cell. On every other device and size class these all work, and will have some vertical margin. iPhone 18 Pro: iPhone Duo: As you can see, the border is cut off. No vertical margins at all. iPhone Duo Unfolded: Not only is it busted just in UICollectionViews. Check out this segmented control (also configured with layout margins). This works fine on catalyst, iPhone, and iPad. This makes me very nervous about shipping with the 27.1 SDK. Is this a known issue? If so, what is the recommended workaround in the meantime? FB25097501
5
0
576
3w
What would be the expectation for view invalidations and compositing cost when compositing mixed frame rate TimelineView items
In my app there are two main layers both animate. Due to performance reasons the lower of the two layers is completely opaque and animates at 12fps via a TimelineView. It has a lot of views that move per frame however everything moves slowly so that lower frame rate is fine. The second layer however has only one View and uses a Canvas rather than various SwiftUI views. It however does look better running at 60fps. It fills the screen but is mostly transparent. My hope would be that despite having the 60fps layer on top that the lower layer is still invalidating at a lower frame rate. I would furthermore hope that the compositing step would recognize it doesn't need to re-render layer one for a least half of the frames and can just composite layer two on top. Does anyone happen to know how SwiftUI and layout step and render server behave in this scenario?
1
0
244
3w
Trackpad “Use inertia when scrolling” setting appears to be ignored by native scroll views
Trackpad “Use inertia when scrolling” setting appears to be ignored by native scroll views I'm seeing inconsistent trackpad scrolling behavior on macOS where the system setting Accessibility → Pointer Control → Trackpad Options → Use inertia when scrolling appears to be ignored by many native applications. According to the macOS description of this setting, when inertia is disabled, scrolling should stop immediately when the fingers are lifted from the trackpad. However, in many native or heavily AppKit/SwiftUI-based applications, momentum scrolling remains active even with this option disabled. Examples include built-in macOS applications and other applications that use native scrolling extensively. Steps to reproduce Open System Settings → Accessibility → Pointer Control → Trackpad Options. Disable Use inertia when scrolling. Open a native application containing a scrollable view. Perform a reasonably fast two-finger scroll on the built-in trackpad. Lift both fingers while they are still moving. Expected behavior As soon as the fingers leave the trackpad, scrolling should stop immediately, since Use inertia when scrolling is disabled. Actual behavior In many native scroll views, scrolling continues after the fingers have been lifted, as if inertia were still enabled. More importantly, there also appears to be an abnormal transition between the direct finger-controlled phase and the momentum phase. If the fingers are lifted while still moving, the content often makes an additional sudden jump immediately after finger release before continuing its deceleration. If I stop my fingers completely before lifting them from the trackpad, this jump is either absent or much less noticeable. This makes scrolling feel uneven even when the frame rate itself is stable. Additional observations The behavior seems strongly related to the native macOS scrolling implementation. Applications or scrolling implementations that perform their own smooth scrolling do not show the same behavior, even on the same machine and display. This does not look like a general rendering-performance or low-frame-rate issue. The actual scroll trajectory appears incorrect around the transition from the physical gesture to momentum scrolling. There is an existing Developer Forums report titled “NSScrollView scrolling hitch” describing a very similar jump on the first frame after a scroll gesture transitions into momentum scrolling. In that report, disabling NSScrollView.isCompatibleWithResponsiveScrolling reportedly removes the large jump. My observation may be related, but there is an additional issue here: the user-facing system setting that is supposed to disable scroll inertia does not appear to disable this momentum behavior in many native scroll views at all. Questions Is NSScrollView expected to respect the system Use inertia when scrolling preference? Should NSEvent.momentumPhase events still be generated when this setting is disabled? Is there a separate native scrolling path that bypasses this preference? Could this be related to responsive scrolling or the transition from the regular phase to momentumPhase? Is there currently any workaround for applications or users affected by this behavior? Environment: MacBook Air with Apple M4, built-in trackpad, macOS 27 Beta (26B5112a).
Topic: UI Frameworks SubTopic: AppKit
0
0
79
3w
UISearchBar’s delegate method searchBarCancelButtonClicked is not called on search cancel when search bar is integrated into the navigation bar on iOS 27
Hi, I would like to share an issue with UISearchBar's delegate method searchBarCancelButtonClicked on iOS 27 beta. On iOS 27 beta, when search bar is integrated into navigation bar’s items, tapping search cancel button doesn’t invoke UISearchBar’s delegate method searchBarCancelButtonClicked:. Steps to reproduce: Create UINavigationController with one UIViewController Set up searchController. Set searchController.searchBar.delegate, preferredSearchBarPlacement = .integratedButton, searchBarPlacementAllowsToolbarIntegration = false Tap the search button and type a query Tap the search cancel button Expected: On iOS 26, the searchBarCancelButtonClicked delegate method is called. Actual: On iOS 27 beta, the searchBarCancelButtonClicked delegate method is NOT called. On iOS 27 beta, if search bar is “stacked” or placed in the toolbar rather than the navigation bar, the bug does not reproduce. I’m using Xcode Version 27.0 beta 6 with latest available iOS 27 iPhone 17 Pro simulator (24A5423a). I reported the issue via Feedback Assistant with a minimal reproduction example and 2 videos comparing the behavior between iOS 26 and iOS 27 beta. Here is the report ID: FB24636315. Here is the minimal reproduction example: // SceneDelegate.swift import UIKit class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let windowScene = scene as? UIWindowScene else { return } let window = UIWindow(windowScene: windowScene) window.rootViewController = UINavigationController(rootViewController: ViewController()) window.makeKeyAndVisible() self.window = window } } // ViewController.swift import UIKit final class ViewController: UITableViewController { private let allItems = (1...30).map { "Item \($0)" } private var items: [String] = [] private var cancelCount = 0 override func viewDidLoad() { super.viewDidLoad() items = allItems updateTitle() let searchController = UISearchController(searchResultsController: nil) searchController.searchBar.delegate = self navigationItem.searchController = searchController navigationItem.preferredSearchBarPlacement = .integratedButton navigationItem.searchBarPlacementAllowsToolbarIntegration = false tableView.register(UITableViewCell.self, forCellReuseIdentifier: "cell") } private func updateTitle() { title = "Cancel presses: \(cancelCount)" } override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { items.count } override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { let cell = tableView.dequeueReusableCell(withIdentifier: "cell", for: indexPath) cell.contentConfiguration = { var config = cell.defaultContentConfiguration() config.text = items[indexPath.row] return config }() return cell } } extension ViewController: UISearchBarDelegate { func searchBarCancelButtonClicked(_ searchBar: UISearchBar) { print("searchBarCancelButtonClicked(_:)") cancelCount += 1 updateTitle() items = allItems tableView.reloadData() } } Thank you in advance!
Topic: UI Frameworks SubTopic: UIKit Tags:
2
2
480
4w
iOS 27 beta 1: .scrollEdgeEffectStyle(.soft) renders fully transparent above safeAreaBar
Feedback ID: FB23086400 On iOS 27 beta 1, .scrollEdgeEffectStyle(.soft, for: .top) on a List underneath a custom .safeAreaBar(edge: .top) no longer renders the progressive fade-blur. The top edge is fully transparent — scrolled rows pass under the bar with no visual treatment at all, as if scrollEdgeEffectDisabled() had been applied. What I've verified so far: .hard renders correctly in the exact same hierarchy; only .soft is affected. The same binary works correctly on iOS 26.x Xcode preview. I'm building with Xcode 26.3 (iOS 26 SDK). Minimal reproduction: import SwiftUI struct EdgeEffectRepro: View { enum Style: String, CaseIterable, Identifiable { case automatic, soft, hard var id: Self { self } var value: ScrollEdgeEffectStyle { switch self { case .automatic: .automatic case .soft: .soft case .hard: .hard } } } @State private var style: Style = .soft @State private var useSystemBarOnly = false var body: some View { NavigationStack { List(0..<60, id: \.self) { i in Text("Row \(i)") .frame(maxWidth: .infinity, alignment: .leading) .listRowBackground( i.isMultiple(of: 2) ? Color.orange.opacity(0.45) : Color.teal.opacity(0.45) ) } .scrollIndicators(.hidden) .scrollEdgeEffectStyle(style.value, for: .top) .safeAreaBar(edge: .top) { if !useSystemBarOnly { VStack(spacing: 8) { HStack { Text("Custom Top Bar") .font(.system(size: 28, weight: .bold)) Spacer() } HStack { Text("Second row (e.g. date range picker)") .font(.caption) .foregroundStyle(.secondary) Spacer() } } .padding(.horizontal) } } .safeAreaInset(edge: .bottom) { VStack(spacing: 8) { Picker("Edge effect style", selection: $style) { ForEach(Style.allCases) { Text($0.rawValue).tag($0) } } .pickerStyle(.segmented) Toggle("System bar only (control group)", isOn: $useSystemBarOnly) .font(.caption) } .padding() .background(.regularMaterial) } .navigationTitle("EdgeEffect Repro") .navigationBarTitleDisplayMode(.inline) } } } Steps: run on iOS 27 beta 1, set the picker to soft, scroll rows under the bar. Expected: fade-blur as on iOS 26. Actual: fully transparent. Switch to hard: renders fine.
25
14
5.4k
4w
CODM stutters whenever iOS system UI appears (Notification Center, Volume HUD, etc.) on iPhone 13 - iOS 27 Public Beta
Hi everyone, I'm using an iPhone 13 running the iOS 27 Public Beta, and overall the experience has been excellent. Battery life is better than I expected, and the system feels very smooth during everyday use. However, I'm experiencing one persistent issue while playing Call of Duty: Mobile (CODM). Whenever an iOS system UI appears, the game briefly stutters or drops frames. This happens with: Pulling down the Notification Center The volume indicator (Volume HUD) Other iOS overlays or system UI animations The stutter only lasts for a moment while the UI is displayed, and gameplay immediately returns to normal if I open the full control center (swiping down). The frame drops will be also gone when I change the frame rate from MAX to Low then Low to MAX frame rate. Things I've already tried: Restarting the device -Enabling Shader Preload in CODM -Closing background apps -Testing different graphics and frame rate settings (which is a temporary solution) -Updating to the latest iOS 27 Public Beta The issue was also present on my previous iOS version, so it doesn't appear to be new to this beta. During normal gameplay, the game runs smoothly. The frame drops only occur when iOS overlays are rendered. Has anyone else experienced this on iPhone, particularly on iPhone 13 or other models? I'm also curious whether this is an iOS compositor issue, a CODM optimization issue, or simply expected behavior when system UI interrupts a game. Any feedback or suggestions would be greatly appreciated. Thank you!
Topic: UI Frameworks SubTopic: General
2
1
746
4w
iOS App QuickType Bar Credit Card Autofill Not Working
According to this autofill credit card documentation we should be able to autofill credit card fields using the QuickType Bar for credit card fields, but it does not work. The QuickType Bar does not display for credit card fields (see screenshots) I have tested this on a physical device running iOS 27 (iPhone 16e), have added a card to the Autofill setting in the Wallet app, and have made sure my text fields have the correct textContentType values. I am able to autofill using the backup autofill menu, but it is less than ideal. It takes a minimum of 5 taps to autofill one field. It would be far less painful to just pull out the credit card and manually enter the information (see screenshot). Here is a link to my test project demonstrating the issue: https://drive.google.com/file/d/1wMGOUNhVnmt3rBAD0TSMf9NV39-JS9ij/view?usp=sharing
1
0
442
4w
Dock magnification loses the hovering focus while a folder in dock is open
In macOS Sequoia 15, the Dock magnification properly to the current hovering app/folder, even when a folder in dock is open. Steps to reproduce: Dock two folders on dock in continuous position. Enable dock magnification effect. Click one of the docked folder to open it in the dock. Click the adjacent folder In macOS Sequoia 15, the step 4 gracefully open the adjacent folder and close the previous one with all magnification animation working property. However, in the latest macOS version 27.0.1, the dock magnification stops working after step 3, and it causes the trigger point for the adjacent item shifted. Thus in step 4, the clicking just trigger as clicking on empty area, so the previous folder close without the step 4 folder open. Also, a buggy glitch can be seen on dock returning to original small size.
0
0
55
4w
iOS 26 beta3 Custom keyboard always displays a gray bar above it
Problem description: When using the Custom keyboard in various system application scenarios, a gray area is always displayed at the top of the Custom keyboard. Although the system has been restarted and the Custom keyboard has been restarted, and the pull-down operation has been repeated in multiple system application environments, the gray bar still appears. This problem also has the same problem on other input method software. Reproduction steps: Set the current input method to "CustomKeybaord" In the memo app or any other system app, pull up the Custom keyboard, or switch to the Custom keyboard. Observe whether a gray area is always displayed above the Custom keyboard. Request: I would like to understand whether the current behavior is a bug or if it requires Custom keyboards to adapt their style accordingly. However, I not found that currently unable to modify the style or color of the gray bar in question, and I do not have a suitable adaptation solution at this time. I would appreciate further assistance
Topic: UI Frameworks SubTopic: UIKit
6
2
720
4w
macOS 27 Golden Gate – Serious UI rendering issues on two different Apple Silicon Macs
Hello everyone, Since upgrading to macOS 27 Golden Gate, I've been experiencing numerous graphical interface issues on both of my Macs: MacBook Pro M4 Pro (work computer) MacBook Air M4 (personal computer) Both machines use completely separate Apple Accounts, yet they exhibit the same problems. The issues mainly affect window controls, menus, buttons, and title bars. For example: The red, yellow, and green window control buttons sometimes disappear completely. Safari's toolbar or title bar occasionally fails to render properly. When closing another application, such as Microsoft Word, parts of the Safari interface can disappear or become blank. Certain interface elements are not properly redrawn when switching between applications or rearranging windows. I've attached screenshots illustrating these problems. I don't use Stage Manager or any third-party window management utilities. Both Macs are running standard macOS configurations. These issues only started after upgrading to Golden Gate. Given that they occur on two different Apple Silicon Macs with separate Apple Accounts, I strongly suspect a macOS-level window rendering bug rather than a hardware or user-specific issue. The problems are quite disruptive during everyday work. Is anyone else experiencing similar issues? Has Apple acknowledged these rendering bugs, and is there any indication of when a fix might be released? Thanks in advance for your feedback.
Topic: UI Frameworks SubTopic: AppKit
Replies
0
Boosts
0
Views
203
Activity
3w
iPhone Duo: Making a custom popup avoid the hinge by presenting it as an arrowless popover
Background On iPhone Duo, when the device is unfolded and then partially folded, system alerts (UIAlertController) are automatically repositioned so they stay clear of the hinge. Apple's Tech Talk confirms this: "The system automatically repositions components around the reserved region." Our app uses a custom popup: a view controller presented with .overFullScreen that lays out its own dimming view and a custom-drawn view (here, a coupon ticket with notched edges) in the center of the screen. This popup is not repositioned. It stays centered on screen, right on top of the fold. The recommended approach for custom UI is to query view.reservedRegions(kind: .division) and lay out around the fold manually. Before going that route, I tried something simpler. What I tried The Tech Talk lists popovers among the components the system repositions. So I presented the same custom view as a popover with no arrow, anchored to the center of the presenting view: final class CouponPopoverViewController: UIViewController, UIPopoverPresentationControllerDelegate { private let ticketView = CouponTicketView() // the custom popup view init(centeredIn sourceView: UIView) { super.init(nibName: nil, bundle: nil) modalPresentationStyle = .popover guard let popover = popoverPresentationController else { return } popover.sourceView = sourceView popover.sourceRect = Self.centerPoint(of: sourceView.bounds) popover.permittedArrowDirections = [] // Drop the system popover chrome so only the custom view (and its own shadow) is visible. popover.popoverBackgroundViewClass = ClearPopoverBackgroundView.self popover.delegate = self } required init?(coder: NSCoder) { fatalError() } override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .clear ticketView.translatesAutoresizingMaskIntoConstraints = false view.addSubview(ticketView) NSLayoutConstraint.activate([ ticketView.topAnchor.constraint(equalTo: view.topAnchor), ticketView.bottomAnchor.constraint(equalTo: view.bottomAnchor), ticketView.leadingAnchor.constraint(equalTo: view.leadingAnchor), ticketView.trailingAnchor.constraint(equalTo: view.trailingAnchor) ]) preferredContentSize = ticketView.systemLayoutSizeFitting( CGSize(width: 300, height: UIView.layoutFittingCompressedSize.height), withHorizontalFittingPriority: .required, verticalFittingPriority: .fittingSizeLevel ) } private static func centerPoint(of bounds: CGRect) -> CGRect { CGRect(x: bounds.midX, y: bounds.midY, width: 0, height: 0) } // Keep it a popover on iPhone instead of adapting to a sheet. func adaptivePresentationStyle(for controller: UIPresentationController, traitCollection: UITraitCollection) -> UIModalPresentationStyle { .none } // Re-anchor to the center after rotation or fold changes. func popoverPresentationController(_ popoverPresentationController: UIPopoverPresentationController, willRepositionPopoverTo rect: UnsafeMutablePointer<CGRect>, in view: AutoreleasingUnsafeMutablePointer<UIView>) { rect.pointee = Self.centerPoint(of: view.pointee.bounds) } } /// A popover background that draws nothing: no arrow, no insets, no default appearance. final class ClearPopoverBackgroundView: UIPopoverBackgroundView { override class func arrowBase() -> CGFloat { 0 } override class func arrowHeight() -> CGFloat { 0 } override class func contentViewInsets() -> UIEdgeInsets { .zero } override class var wantsDefaultContentAppearance: Bool { false } override var arrowOffset: CGFloat { get { 0 } set {} } override var arrowDirection: UIPopoverArrowDirection { get { .any } set {} } } Result Partially folded, portrait (hinge runs horizontally across the middle of the screen): Before: the custom popup (.overFullScreen) stays centered, right across the hinge. After: the same view presented as an arrowless popover moves into the top half, clear of the hinge. Partially folded, book pose (vertical hinge): the popover moves to the leading page, clear of the hinge. This matches where a system UIAlertController goes in the same pose. I also checked that the popover shows correctly on the outer display (closed) and on a non-Duo iPhone (iPhone 18 Pro, iOS 27.0). Tested on: iPhone Duo simulator (iOS 27.1), Xcode 27.1 RC (27A9275) iPhone 18 Pro simulator (iOS 27.0) Things to handle when switching to a popover Tap-outside dismissal: Popovers dismiss on outside taps by default. Set isModalInPresentation = true or return false from presentationControllerShouldDismiss(_:) if the popup should only close via its buttons. Dimming: Popovers don't dim the background like a typical custom popup (compare the before and after screenshots). Add your own dimming view if needed. Chrome: By default, the system draws its own background behind the content. For a custom-shaped view, this shows through any transparent areas and clips the view's shadow. A UIPopoverBackgroundView subclass that draws nothing (above) removes it. Sizing: Set preferredContentSize explicitly. Recompute it for dynamic content and Dynamic Type. Questions This works well in my testing, but I couldn't find any documentation saying that an arrowless popover anchored to the center gets the same hinge avoidance as alerts. Is this supported behavior that we can rely on going forward? Or is reservedRegions(kind:options:) with manual layout the only recommended approach for custom popups? It would also be great to have a public API that lets custom presentations opt into the same hinge-avoidance placement that system alerts use. Hope this helps anyone else dealing with custom popups on iPhone Duo.
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
2
Boosts
0
Views
276
Activity
3w
iPhone Duo - Current SDK State
We are just 9 days before the iPhone Duo release, and the SDK is still in a pretty bad state, at least for the Keyboard Extension: Hinge detection doesn't work Reserved area detection doesn't work needsInputModeSwitchKey returns false even though iOS doesn't display its own globe button Switching between closed and fully open state loses text field focus and the keyboard disappears (regression bug - it worked in Beta 1) It's unacceptable that, with such a short release date, we still don't have a stable SDK... I expect the iPhone Duo release to be one of the buggiest releases Apple has ever done.
Replies
7
Boosts
0
Views
668
Activity
3w
(iPhone Duo) Toolbar Items are misplaced for RTL layout-direction
On iPhone Duo, when I use .environment(\.layoutDirection, .rightToLeft) for a navigation view, the toolbar items sometimes appear on the left side instead of the right side, below the camera. This results in a view with two sides, and in some cases, it displays in an unexpected place. For example, in the code below, the button is placed behind the camera, as shown in the attachment. NavigationSplitView { Text("Sidebar") .toolbar { ToolbarItem(placement: .cancellationAction) { Button("X", systemImage: "xmark", action: {}) } } } detail: { Text("Detail") } .environment(\.layoutDirection, .rightToLeft) Is this intended behavior for RTL layout direction, a known issue, or a simulator issue?
Replies
5
Boosts
1
Views
410
Activity
3w
How to get UISheetPresentationController width to adjust for vertical toolbar on iPhone Duo?
If you run Safari in the iPhone Duo simulator and choose to share something you get a screen similar to the following: In my own app, if I present a UIActivityViewController I get a similar result. Note that the share sheet does not cover the vertical toolbar at all. So my question is how to present a UISheetPresentationController to look the same way. In other words, how to get the width of the UISheetPresentationController to take into account the vertical toolbar? All of my existing code to create and present a UISheetPresentationController result in the UISheetPresentationController taking the full width of the screen. The contents of the sheet take the safe area into account, but that's not the same result. I need the sheet itself to be narrower. I don't see an API for this. Or does this require more complicated presentation controller / delegate setup? Here is some relevant code in the view controller that I want displayed in the sheet: self.modalPresentationStyle = .popover self.presentationController?.delegate = self if let sheet = popoverPresentationController?.adaptiveSheetPresentationController { popoverPresentationController?.passthroughViews = [] sheet.detents = [ .medium(), .large() ] sheet.largestUndimmedDetentIdentifier = nil sheet.prefersGrabberVisible = false sheet.prefersScrollingExpandsWhenScrolledToEdge = true sheet.prefersEdgeAttachedInCompactHeight = true sheet.widthFollowsPreferredContentSizeWhenEdgeAttached = true } Or maybe UISheetPresentationController is the wrong approach.
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
0
Boosts
0
Views
147
Activity
3w
UIAlertController.addTextField results in broken text field in 27.1
I just downloaded Xcode 27.1 to test out the iPhone Duo simulator, and I notice that UIAlertController.addTextField, which was working fine in 27, is now very broken, resulting in a text field that is squashed vertically and pushed over to the right in the alert sheet. This is very easy to reproduce - the following code will show the problem if you build in Xcode 27.1 and run on iOS 27.1 or iOS 27.2: let alert = UIAlertController(title: "Create Something", message: "Enter a title.", preferredStyle: .alert) alert.addTextField { textField in textField.placeholder = "Title" } alert.addAction(UIAlertAction(title: "Cancel", style: .cancel)) present(alert, animated: true) The bug isn't limited to the Duo, but can also be seen on an iPad (and probably a regular phone). I would post a screenshot, but the last time I tried that, the forum software erroneously banned me for two weeks. I have reported this as bug #FB24889500, but given that we use alerts with text fields for users adding new items to the outline in our app, something the user does a lot, I'm wondering if there is a workaround, since this is going to make our app look very buggy.
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
1
Boosts
3
Views
390
Activity
3w
How to preserve collection view scroll anchor when folding/unfolding iPhone Duo
The following question was asked in the Oct 13 iPhone Duo group lab: when you unfold iPhone Duo after you’ve scrolled down, does UIKit keep the position or should we re-anchor ourselves? The answer was various scroll views like collection views and text views will handle this for you to keep visible items visible, which also works when resizing the window on iPad. This is not working for me with a simple UICollectionView. What do I need to do to obtain this behavior? class ViewController: UIViewController, UICollectionViewDataSource { override func viewDidLoad() { super.viewDidLoad() let layout = UICollectionViewFlowLayout() layout.itemSize = CGSize(width: 80, height: 80) layout.minimumInteritemSpacing = 8 layout.minimumLineSpacing = 8 layout.sectionInsetReference = .fromLayoutMargins let collectionView = UICollectionView(frame: .zero, collectionViewLayout: layout) collectionView.translatesAutoresizingMaskIntoConstraints = false collectionView.backgroundColor = .systemBackground collectionView.dataSource = self collectionView.insetsLayoutMarginsFromSafeArea = true collectionView.register(UICollectionViewCell.self, forCellWithReuseIdentifier: "Cell") view.addSubview(collectionView) NSLayoutConstraint.activate([ collectionView.topAnchor.constraint(equalTo: view.topAnchor), collectionView.leadingAnchor.constraint(equalTo: view.leadingAnchor), collectionView.trailingAnchor.constraint(equalTo: view.trailingAnchor), collectionView.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) } func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int { 5000 } func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell { let cell = collectionView.dequeueReusableCell(withReuseIdentifier: "Cell", for: indexPath) var content = UIListContentConfiguration.cell() content.text = String(indexPath.item) content.textProperties.alignment = .center cell.contentConfiguration = content var background = UIBackgroundConfiguration.clear() background.backgroundColor = .secondarySystemBackground cell.backgroundConfiguration = background return cell } } Run the app on iPhone Duo Scroll down to cell 100 on the outer display Unfold the device Expected: It should stay scrolled to item 100 Actual: It scrolled down to item 225 (or more accurately, the content offset did not change, more content was added higher up with the contentSize shrinking due to the expanded width) In the past I've put so much work into trying to maintain the expected scroll position for orientation changes on iPhone and iPad/Mac Catalyst resize events, it's surprisingly incredibly hard to get working in every scenario, so I am SUPER interested to learn the system can do it for us!
Replies
0
Boosts
0
Views
268
Activity
3w
How to set custom height for keyboard extension without resize flicker?
Description I'm developing a custom keyboard extension using UIInputViewController and need to set a specific height of 268 points. The keyboard functions correctly, but there's a visible flicker and resize animation during launch that I cannot eliminate. The Problem When the keyboard launches, iOS provides incorrect heights before settling on the correct one. At launch, the view starts at 0×0. Around 295ms later, iOS sets the frame to 440×956 which is full screen height and wrong. Around 373ms, iOS changes it to 440×452 which is still wrong. Finally around 390ms, iOS settles at 440×268 which matches our constraint. This causes visible flicker as the view resizes three times rapidly. The keyboard appears to shrink from full screen down to the correct height, and users can clearly see this animation happening. What I've Tried I've tried adding a height constraint on self.view which gives me the correct height but causes the visible flicker. I created a custom UIInputView subclass and overrode intrinsicContentSize to return my desired height. iOS completely ignores this and gives random heights like 471pt, 680pt, or 956pt instead. I set allowsSelfSizing to true on my UIInputView subclass. iOS ignores this property. I set preferredContentSize on the view controller. iOS ignores this as well. I tried adding the constraint in viewDidAppear instead of viewDidLoad, thinking iOS might have settled by then. It still causes flicker. I overrode the frame and bounds setters on my UIInputView to clamp the height to my desired value. iOS bypasses these overrides somehow. I overrode layoutSubviews to force the correct height after the super call. iOS still applies its own height. Specific Question What is the correct API or technique to specify a keyboard extension's height that iOS will respect immediately upon launch, without triggering the resize animation sequence? Other third-party keyboards like Grammarly and SwiftKey appear to have solved this problem. Their keyboards appear at the correct height without any visible flicker. How do they achieve this? Expected Outcome The keyboard should appear at 268pt height on the first frame with no visible resize animation. Steps to Reproduce Create a new iOS App project in Xcode and add a Keyboard Extension target. In KeyboardViewController.swift, add a height constraint in viewDidLoad: override func viewDidLoad() { super.viewDidLoad() let heightConstraint = view.heightAnchor.constraint(equalToConstant: 268) heightConstraint.priority = .defaultHigh heightConstraint.isActive = true let label = UILabel() label.text = "Demo Keyboard" label.textAlignment = .center label.translatesAutoresizingMaskIntoConstraints = false view.addSubview(label) NSLayoutConstraint.activate([ label.centerXAnchor.constraint(equalTo: view.centerXAnchor), label.centerYAnchor.constraint(equalTo: view.centerYAnchor) ]) } Build and run on a physical device. Enable the keyboard in Settings, then General, then Keyboard, then Keyboards. Open any app with a text field and switch to the custom keyboard using the globe button. Observe the height changing from around 956pt to 452pt to 268pt with visible animation. Environment iOS 17 and iOS 18 and 26.2, Xcode 16 and Xcode 26, affects all iPhone models tested, reproducible on both simulator and physical device.
Replies
4
Boosts
6
Views
1.3k
Activity
3w
Tapping saved login does nothing after typing when .autocorrectionDisabled() or .textInputAutocapitalization(.never) modifier is applied
If a username field has .autocorrectionDisabled() or .textInputAutocapitalization(.never), tapping the saved login above the keyboard stops working once the user has typed part of their email. Nothing gets filled in. Seen on iPhone 16, iOS 27.0 (24A437). I've also reported this to Apple through Feedback Assistant (FB24825410). Steps to reproduce You need an app with Password AutoFill set up (a webcredentials associated domain) and a saved login for that domain. Tap the email field. The saved login appears above the keyboard. Type a few letters of the email. Tap the saved login. Expected: the email and password fields fill in, replacing what was typed. Actual: nothing happens. What works A username field with only .textContentType(.username) and .keyboardType(.emailAddress). Tapping the saved login fills both fields, no matter how much the user has typed. What breaks With .autocorrectionDisabled(), the tap works after 1 typed character, but does nothing after 2 or more. With .textInputAutocapitalization(.never), the tap does nothing after even 1 typed character. UIKit has the same problem: a UITextField with autocorrectionType = .no behaves like .autocorrectionDisabled(). In all of these cases, choosing the login from the key icon's Passwords sheet still fills both fields. Only the tap on the suggestion above the keyboard fails. Sample struct LoginView: View { @State private var email = "" @State private var password = "" var body: some View { VStack { TextField("Email", text: $email) .textContentType(.username) .keyboardType(.emailAddress) // Either of these breaks AutoFill once the user types: .autocorrectionDisabled() // fails after 2+ typed characters .textInputAutocapitalization(.never) // fails after 1 typed character SecureField("Password", text: $password) .textContentType(.password) } } } Workaround I removed both modifiers from our username field and it works. Typed emails still didn't get autocorrected in my testing. Has anyone found a way to keep these modifiers on a username field without breaking AutoFill? Possibly related: https://developer.apple.com/forums/thread/702970
Replies
2
Boosts
0
Views
513
Activity
3w
iOS 27: print(to:) silently drops every job after the first
The problem On iOS 27, UIPrintInteractionController.print(to:completionHandler:) works on its first call in a process. Every subsequent call is accepted (print(to:) returns true and printInteractionControllerWillStartJob fires), but the completion handler is never invoked: nothing prints, didFinishJob never fires, no error is produced, and no job appears in Print Center. I expected each call to submit an independent job and invoke its completion handler, as it does on iOS 26 and earlier with the identical binary. Steps to reproduce Build an app that prints without the print panel, using a retained UIPrinter from UIPrinterPickerController. Submit a job: let controller = UIPrintInteractionController.shared let info = UIPrintInfo(dictionary: nil) info.outputType = .general info.jobName = "job-\(n)" controller.printInfo = info controller.printingItem = pdfData // valid PDF, canPrint(data) == true controller.delegate = self let started = controller.print(to: savedPrinter) { _, completed, error in print("completion", completed, String(describing: error)) } print("started", started) First job: started == true, both willStartJob and didFinishJob fire, the completion handler runs with completed == true, and the page prints. Submit a second job the same way, same process. started == true and willStartJob fires with printInfo.printerID populated and printPaper negotiated to the same values as the successful job. Then nothing. No didFinishJob, no completion handler, no error, no page, nothing in Print Center. A third job: print(to:) returns false synchronously, since the shared controller still considers job two in flight. System information iPad, iPadOS 27.0 developer beta 6 Built against iOS 26.2 SDK (Xcode 26.2). Same binary works on iOS 26. Reproduced on two unrelated printers: Brother QL-820NWB and Canon MF420 Series. Content is a small PDF (~11 to 13 KB); canPrintData: returns true. Troubleshooting tried Restarted the iPad and reinstalled the app. Each buys exactly one successful print before the failure returns. Compared observable state between the working and hung jobs. Identical in every respect. During a hang, printed the same content to the same printer from Files via the share sheet. Worked normally, including on repeat. Paused in the debugger during the hang. No blocked thread; no PrintKit frame, XPC wait, or semaphore anywhere in bt all. Called contactPrinter before each job on the retained printer. Returned true quickly, and the job still hung. Implemented printInteractionControllerParentViewController(_:) in case a presentation context was missing. UIKit never calls it on this path. Workaround Creating a new UIPrintInteractionController per job resolves it completely. A long-lived instance the app creates itself fails exactly like .shared does, so the issue is reuse of a controller that has already run a job, not the shared singleton specifically. Is per-job instantiation the supported pattern? The docs say the shared instance "represents a print job" but don't state whether a controller may be reused for a second job, and every sample I can find uses sharedPrintController with the present… methods rather than print(to:).
Replies
5
Boosts
7
Views
1.6k
Activity
3w
Layout margins guides are still broken the iPhone Duo (sim) and 27.1 RC
Layout margin guides are broken throughout UIKit and SwiftUI on the iPhone Duo sim in iOS 27.1 RC. For example, a cell which looks perfectly fine on a normal iPhone sim (which has a compact horizontal size class), has zero vertical layout margins on iPhone Duo. Here's some screenshots. The red dotted lines are supposed to show the margins in the cell content view, i.e., the boundary between default padding around the cell (for its background) and the content of the cell. On every other device and size class these all work, and will have some vertical margin. iPhone 18 Pro: iPhone Duo: As you can see, the border is cut off. No vertical margins at all. iPhone Duo Unfolded: Not only is it busted just in UICollectionViews. Check out this segmented control (also configured with layout margins). This works fine on catalyst, iPhone, and iPad. This makes me very nervous about shipping with the 27.1 SDK. Is this a known issue? If so, what is the recommended workaround in the meantime? FB25097501
Replies
5
Boosts
0
Views
576
Activity
3w
What would be the expectation for view invalidations and compositing cost when compositing mixed frame rate TimelineView items
In my app there are two main layers both animate. Due to performance reasons the lower of the two layers is completely opaque and animates at 12fps via a TimelineView. It has a lot of views that move per frame however everything moves slowly so that lower frame rate is fine. The second layer however has only one View and uses a Canvas rather than various SwiftUI views. It however does look better running at 60fps. It fills the screen but is mostly transparent. My hope would be that despite having the 60fps layer on top that the lower layer is still invalidating at a lower frame rate. I would furthermore hope that the compositing step would recognize it doesn't need to re-render layer one for a least half of the frames and can just composite layer two on top. Does anyone happen to know how SwiftUI and layout step and render server behave in this scenario?
Replies
1
Boosts
0
Views
244
Activity
3w
Trackpad “Use inertia when scrolling” setting appears to be ignored by native scroll views
Trackpad “Use inertia when scrolling” setting appears to be ignored by native scroll views I'm seeing inconsistent trackpad scrolling behavior on macOS where the system setting Accessibility → Pointer Control → Trackpad Options → Use inertia when scrolling appears to be ignored by many native applications. According to the macOS description of this setting, when inertia is disabled, scrolling should stop immediately when the fingers are lifted from the trackpad. However, in many native or heavily AppKit/SwiftUI-based applications, momentum scrolling remains active even with this option disabled. Examples include built-in macOS applications and other applications that use native scrolling extensively. Steps to reproduce Open System Settings → Accessibility → Pointer Control → Trackpad Options. Disable Use inertia when scrolling. Open a native application containing a scrollable view. Perform a reasonably fast two-finger scroll on the built-in trackpad. Lift both fingers while they are still moving. Expected behavior As soon as the fingers leave the trackpad, scrolling should stop immediately, since Use inertia when scrolling is disabled. Actual behavior In many native scroll views, scrolling continues after the fingers have been lifted, as if inertia were still enabled. More importantly, there also appears to be an abnormal transition between the direct finger-controlled phase and the momentum phase. If the fingers are lifted while still moving, the content often makes an additional sudden jump immediately after finger release before continuing its deceleration. If I stop my fingers completely before lifting them from the trackpad, this jump is either absent or much less noticeable. This makes scrolling feel uneven even when the frame rate itself is stable. Additional observations The behavior seems strongly related to the native macOS scrolling implementation. Applications or scrolling implementations that perform their own smooth scrolling do not show the same behavior, even on the same machine and display. This does not look like a general rendering-performance or low-frame-rate issue. The actual scroll trajectory appears incorrect around the transition from the physical gesture to momentum scrolling. There is an existing Developer Forums report titled “NSScrollView scrolling hitch” describing a very similar jump on the first frame after a scroll gesture transitions into momentum scrolling. In that report, disabling NSScrollView.isCompatibleWithResponsiveScrolling reportedly removes the large jump. My observation may be related, but there is an additional issue here: the user-facing system setting that is supposed to disable scroll inertia does not appear to disable this momentum behavior in many native scroll views at all. Questions Is NSScrollView expected to respect the system Use inertia when scrolling preference? Should NSEvent.momentumPhase events still be generated when this setting is disabled? Is there a separate native scrolling path that bypasses this preference? Could this be related to responsive scrolling or the transition from the regular phase to momentumPhase? Is there currently any workaround for applications or users affected by this behavior? Environment: MacBook Air with Apple M4, built-in trackpad, macOS 27 Beta (26B5112a).
Topic: UI Frameworks SubTopic: AppKit
Replies
0
Boosts
0
Views
79
Activity
3w
UISearchBar’s delegate method searchBarCancelButtonClicked is not called on search cancel when search bar is integrated into the navigation bar on iOS 27
Hi, I would like to share an issue with UISearchBar's delegate method searchBarCancelButtonClicked on iOS 27 beta. On iOS 27 beta, when search bar is integrated into navigation bar’s items, tapping search cancel button doesn’t invoke UISearchBar’s delegate method searchBarCancelButtonClicked:. Steps to reproduce: Create UINavigationController with one UIViewController Set up searchController. Set searchController.searchBar.delegate, preferredSearchBarPlacement = .integratedButton, searchBarPlacementAllowsToolbarIntegration = false Tap the search button and type a query Tap the search cancel button Expected: On iOS 26, the searchBarCancelButtonClicked delegate method is called. Actual: On iOS 27 beta, the searchBarCancelButtonClicked delegate method is NOT called. On iOS 27 beta, if search bar is “stacked” or placed in the toolbar rather than the navigation bar, the bug does not reproduce. I’m using Xcode Version 27.0 beta 6 with latest available iOS 27 iPhone 17 Pro simulator (24A5423a). I reported the issue via Feedback Assistant with a minimal reproduction example and 2 videos comparing the behavior between iOS 26 and iOS 27 beta. Here is the report ID: FB24636315. Here is the minimal reproduction example: // SceneDelegate.swift import UIKit class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let windowScene = scene as? UIWindowScene else { return } let window = UIWindow(windowScene: windowScene) window.rootViewController = UINavigationController(rootViewController: ViewController()) window.makeKeyAndVisible() self.window = window } } // ViewController.swift import UIKit final class ViewController: UITableViewController { private let allItems = (1...30).map { "Item \($0)" } private var items: [String] = [] private var cancelCount = 0 override func viewDidLoad() { super.viewDidLoad() items = allItems updateTitle() let searchController = UISearchController(searchResultsController: nil) searchController.searchBar.delegate = self navigationItem.searchController = searchController navigationItem.preferredSearchBarPlacement = .integratedButton navigationItem.searchBarPlacementAllowsToolbarIntegration = false tableView.register(UITableViewCell.self, forCellReuseIdentifier: "cell") } private func updateTitle() { title = "Cancel presses: \(cancelCount)" } override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { items.count } override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { let cell = tableView.dequeueReusableCell(withIdentifier: "cell", for: indexPath) cell.contentConfiguration = { var config = cell.defaultContentConfiguration() config.text = items[indexPath.row] return config }() return cell } } extension ViewController: UISearchBarDelegate { func searchBarCancelButtonClicked(_ searchBar: UISearchBar) { print("searchBarCancelButtonClicked(_:)") cancelCount += 1 updateTitle() items = allItems tableView.reloadData() } } Thank you in advance!
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
2
Boosts
2
Views
480
Activity
4w
iOS 27 beta 1: .scrollEdgeEffectStyle(.soft) renders fully transparent above safeAreaBar
Feedback ID: FB23086400 On iOS 27 beta 1, .scrollEdgeEffectStyle(.soft, for: .top) on a List underneath a custom .safeAreaBar(edge: .top) no longer renders the progressive fade-blur. The top edge is fully transparent — scrolled rows pass under the bar with no visual treatment at all, as if scrollEdgeEffectDisabled() had been applied. What I've verified so far: .hard renders correctly in the exact same hierarchy; only .soft is affected. The same binary works correctly on iOS 26.x Xcode preview. I'm building with Xcode 26.3 (iOS 26 SDK). Minimal reproduction: import SwiftUI struct EdgeEffectRepro: View { enum Style: String, CaseIterable, Identifiable { case automatic, soft, hard var id: Self { self } var value: ScrollEdgeEffectStyle { switch self { case .automatic: .automatic case .soft: .soft case .hard: .hard } } } @State private var style: Style = .soft @State private var useSystemBarOnly = false var body: some View { NavigationStack { List(0..<60, id: \.self) { i in Text("Row \(i)") .frame(maxWidth: .infinity, alignment: .leading) .listRowBackground( i.isMultiple(of: 2) ? Color.orange.opacity(0.45) : Color.teal.opacity(0.45) ) } .scrollIndicators(.hidden) .scrollEdgeEffectStyle(style.value, for: .top) .safeAreaBar(edge: .top) { if !useSystemBarOnly { VStack(spacing: 8) { HStack { Text("Custom Top Bar") .font(.system(size: 28, weight: .bold)) Spacer() } HStack { Text("Second row (e.g. date range picker)") .font(.caption) .foregroundStyle(.secondary) Spacer() } } .padding(.horizontal) } } .safeAreaInset(edge: .bottom) { VStack(spacing: 8) { Picker("Edge effect style", selection: $style) { ForEach(Style.allCases) { Text($0.rawValue).tag($0) } } .pickerStyle(.segmented) Toggle("System bar only (control group)", isOn: $useSystemBarOnly) .font(.caption) } .padding() .background(.regularMaterial) } .navigationTitle("EdgeEffect Repro") .navigationBarTitleDisplayMode(.inline) } } } Steps: run on iOS 27 beta 1, set the picker to soft, scroll rows under the bar. Expected: fade-blur as on iOS 26. Actual: fully transparent. Switch to hard: renders fine.
Replies
25
Boosts
14
Views
5.4k
Activity
4w
CODM stutters whenever iOS system UI appears (Notification Center, Volume HUD, etc.) on iPhone 13 - iOS 27 Public Beta
Hi everyone, I'm using an iPhone 13 running the iOS 27 Public Beta, and overall the experience has been excellent. Battery life is better than I expected, and the system feels very smooth during everyday use. However, I'm experiencing one persistent issue while playing Call of Duty: Mobile (CODM). Whenever an iOS system UI appears, the game briefly stutters or drops frames. This happens with: Pulling down the Notification Center The volume indicator (Volume HUD) Other iOS overlays or system UI animations The stutter only lasts for a moment while the UI is displayed, and gameplay immediately returns to normal if I open the full control center (swiping down). The frame drops will be also gone when I change the frame rate from MAX to Low then Low to MAX frame rate. Things I've already tried: Restarting the device -Enabling Shader Preload in CODM -Closing background apps -Testing different graphics and frame rate settings (which is a temporary solution) -Updating to the latest iOS 27 Public Beta The issue was also present on my previous iOS version, so it doesn't appear to be new to this beta. During normal gameplay, the game runs smoothly. The frame drops only occur when iOS overlays are rendered. Has anyone else experienced this on iPhone, particularly on iPhone 13 or other models? I'm also curious whether this is an iOS compositor issue, a CODM optimization issue, or simply expected behavior when system UI interrupts a game. Any feedback or suggestions would be greatly appreciated. Thank you!
Topic: UI Frameworks SubTopic: General
Replies
2
Boosts
1
Views
746
Activity
4w
iOS App QuickType Bar Credit Card Autofill Not Working
According to this autofill credit card documentation we should be able to autofill credit card fields using the QuickType Bar for credit card fields, but it does not work. The QuickType Bar does not display for credit card fields (see screenshots) I have tested this on a physical device running iOS 27 (iPhone 16e), have added a card to the Autofill setting in the Wallet app, and have made sure my text fields have the correct textContentType values. I am able to autofill using the backup autofill menu, but it is less than ideal. It takes a minimum of 5 taps to autofill one field. It would be far less painful to just pull out the credit card and manually enter the information (see screenshot). Here is a link to my test project demonstrating the issue: https://drive.google.com/file/d/1wMGOUNhVnmt3rBAD0TSMf9NV39-JS9ij/view?usp=sharing
Replies
1
Boosts
0
Views
442
Activity
4w
Dock magnification loses the hovering focus while a folder in dock is open
In macOS Sequoia 15, the Dock magnification properly to the current hovering app/folder, even when a folder in dock is open. Steps to reproduce: Dock two folders on dock in continuous position. Enable dock magnification effect. Click one of the docked folder to open it in the dock. Click the adjacent folder In macOS Sequoia 15, the step 4 gracefully open the adjacent folder and close the previous one with all magnification animation working property. However, in the latest macOS version 27.0.1, the dock magnification stops working after step 3, and it causes the trigger point for the adjacent item shifted. Thus in step 4, the clicking just trigger as clicking on empty area, so the previous folder close without the step 4 folder open. Also, a buggy glitch can be seen on dock returning to original small size.
Replies
0
Boosts
0
Views
55
Activity
4w
iOS 26 beta3 Custom keyboard always displays a gray bar above it
Problem description: When using the Custom keyboard in various system application scenarios, a gray area is always displayed at the top of the Custom keyboard. Although the system has been restarted and the Custom keyboard has been restarted, and the pull-down operation has been repeated in multiple system application environments, the gray bar still appears. This problem also has the same problem on other input method software. Reproduction steps: Set the current input method to "CustomKeybaord" In the memo app or any other system app, pull up the Custom keyboard, or switch to the Custom keyboard. Observe whether a gray area is always displayed above the Custom keyboard. Request: I would like to understand whether the current behavior is a bug or if it requires Custom keyboards to adapt their style accordingly. However, I not found that currently unable to modify the style or color of the gray bar in question, and I do not have a suitable adaptation solution at this time. I would appreciate further assistance
Topic: UI Frameworks SubTopic: UIKit
Replies
6
Boosts
2
Views
720
Activity
4w