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

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:).

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

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?

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).

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!

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.

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!

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

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.

Finder Sidebar can not resize if the current tab is an iPhone device. OS: macOS Golden Gate 27.0.1

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

I'm trying to do something so seemingly basic, yet I can't get it to work and I'm flummoxed. In a basic, vanilla SwiftUI app for tvOS, embed a single Text element with a very long string (hundreds of lines) in it: struct ContentView: View { var body: some View { ScrollView(.vertical) { Text(veryLargeString) .focusable() } } } Then fire up the app on tvOS, and it will not scroll. No matter what I do. Pressing arrow keys, swiping fast with my thumb, and nothing. It will not move. Ironically, in the Xcode SwiftUI Preview window—it does scroll, so that's always a fun tease. What I do know is that the focus engine is throwing a few errors, so it's leading me to believe the issue is with how I have the focusable element attached. I'm using a combination of -UIFocusLoggingEnabled YES as well as listening for UIFocusSystem.movementDidFailNotification. Unfortunately since this is SwiftUI, the notification failure and debugging logs aren't really all that actionable. Help appreciated!

I have an app that connects to an external display, the app controls content for the external display, but the external display is not active and uses the UIWindowSceneSessionRoleExternalDisplayNonInteractive role. I migrated the app to use UIScene lifecycle last year and everything seemed to be working. I use - (UISceneConfiguration *) application:(UIApplication *) application configurationForConnectingSceneSession:(UISceneSession *) connectingSceneSession options:(UISceneConnectionOptions *) options; in the AppDelegate to provide the configurations. But now at XCode 27/ iOS 27, that code is not called when I connect the external display with a dislpay adapter to my iPhone. But the device connects and shows a mirror of my iPhone display. What's going on?

When creating a UIBarButtonItem using the standard UIBarButtonSystemItem values of UIBarButtonSystemItemSave or UIBarButtonSystemEdit you end up with text-only buttons. The text-only buttons are an issue with the iPhone Duo since such buttons do not get put in the vertical sidebar. This is a problem with a view controller with scrollable content. The text-only Save or Edit buttons can scroll out of view leaving the user confused about how to complete their work on the screen. Related is the UIViewController editButtonItem which gives the standard Edit/Done toggle button. Since the button shows the text "Edit" the button doesn't get put in the vertical sidebar. This is despite the Done display being shown as a checkmark icon.

On the iPhone Duo the standard "Edit" button for navigation bars is a text-based button, and text-based buttons are not pushed to the vertical toolbars on the Duo. This looks sometimes silly, if it is the only remaining button that can not be placed in the vertical toolbar and which has the result that an almost empty horizontal navigation bar must be kept visible as well. So I guess it would be good idea to have an icon-based replacement for the Editor button to avoid having two toolbars on the Duo. Is there a best practice for the icon to pick for such an edit button? Would be "square.and.pencil" (SF Symbols) a good choice? Or better the "pencil .circle", because the "square" one is often used for text-based input? Anything better?

I have been trying to create snippet views for my AppShortcuts which fill the full width of the container. Doing this via either .frame(minWidth: 0, maxWidth. infinity) or .containerRelativeFrame() work perfectly fine when my snippet is presented from Shortcuts.app (though sometimes the wrong color scheme is displayed), but when I invoke my AppShortcut from Siri AI and it presents the snippet there, it's offset on the trailing side by sometimes up to over 30 points, which has frustrating effects on the UI I am trying to implement. I've noted the insets are different too depending on whether the snippet is presented from what AppIntents method invokes it requestConfirmation or .result respectively. Here's some screenshots showing the issue. All these use the exact same snippet view, but all have different results in how they look and are inset. In App (how I want it to look) In Shortcuts (fine I guess) And finally, in the Siri app. I have reproduced this is issue and distilled it in a sample project. Please ensure this routes to the correct team: FB25164368. Thanks!

When presenting a UINavigationController presented via UIViewControllerRepresentable in a sheet, the top nav bar buttons aren't correctly moving to the side bar on the front screen of the Duo. They do re-orient vertically, but they do so next to the side bar and not within it. What am I doing wrong? This is how I am setting the buttons: let trimButton = UIBarButtonItem(image: UIImage(systemName: "selection.pin.in.out"), style: .plain, target: self, action: #selector(enterTrimming(_:))) navigationItem.leftBarButtonItem = trimButton navigationItem.rightBarButtonItem = cancelButton navigationItem.leftBarButtonItem?.isEnabled = true navigationItem.rightBarButtonItem?.isEnabled = true

Apple's latest Vision 26.7, no longer recognizes Thai language( I haven't checked others), and crashes if request.recognitionLevel = .accurate Any ideas what is going on here, or just Apple's poor thoroughness at releasing an osx prematurely, as usual? let request = VNRecognizeTextRequest() request.recognitionLanguages = [language] if ProcessInfo.processInfo.isiOSAppOnMac { request.recognitionLevel = .fast // workaround for macOS 26.7.1 crash } else { request.recognitionLevel = .accurate } request.minimumTextHeight = 0

Hi, I would like to automatically vertically size the table's footer view so that it has a fixed pre-defined minimum height and maximum height that fills up the gap between the last cell and the bottom of the safe area. How can I do this? PS: It seems to be that the footer view's size is not included in the table view's content size, correct? Regards, Hardy