I've been using the iOS 27 beta and noticed in Messages app that the link presentation is now customisable. Upon tapping on the link it opens (what I assume is) an edit menu interaction, which allows customising which metadata is shown. I've seen some links offer more customisation than others, presumably based on available metadata. There's also an option in the menu to convert to a text link, and when highlighting a link in text there's an option to "show link preview" which converts it to an LPLinkView. I've been wondering for a while now if it was possible to add a similar feature to my own app, allowing the user more control over the link previews. How can I achieve similar? Especially "Customise Link" sheet seen in the middle two screenshots?

I set the flag isHidden to true and isEnabled to false, but seems both of them are not working on iOS 27 public beta. They were working fine on iOS 26 and priors. Will next version iOS 27 fix that or do i need to use another alternative like completely remove the uibarbuttonitem from the navigation tool bar?

When compiling the app on an iPhone running iOS 16, the following alerts appear. What steps should I take to resolve this? UIScene lifecycle will soon be required. Failure to adopt will result in an assert in the future. CoreUI: CUIThemeStore: No theme registered with id=0

On iOS 26, the auto-disabled state of the return key driven by UITextInputTraits.enablesReturnKeyAutomatically is lost whenever the user switches keyboard planes (letters ⇄ numbers/symbols via the 123/ABC key). The key renders as enabled even though the text is still empty. Tapping it does nothing (the disable is still honored functionally), but the visual state is wrong until the next re-evaluation. This is a regression: iOS/iPadOS 17 behaves correctly (verified on iPadOS 17.7). It also reproduces in Safari's own address bar on iOS 26, so it does not appear to be app-specific. Minimal reproduction (stock UIKit, no custom code): let textField = UITextField() textField.enablesReturnKeyAutomatically = true // present it, focus it, leave it empty Focus the empty text field — the return key is disabled (correct). Tap 123 to switch to the numeric plane → the return key becomes enabled (incorrect — text is still empty). Type one character and delete it (still in the numeric plane) → the key becomes disabled again (correct). Tap ABC to switch back to the letters plane → the key becomes enabled again (incorrect). Safari reproduction (stock behavior, physical device): Open Safari on iOS 26, focus the address bar, and delete all text → the Go key disables (correct). Switch to the numeric plane → the Go key re-enables (incorrect). Tapping it gives haptic feedback but performs no action — the disable is still honored functionally; only the rendered state is wrong. Still in the numeric plane, type something (e.g. 123.456) and delete it all → the key correctly disables again (the hasText round-trip re-syncs it?) Switch back to the letters plane → the key wrongly re-enables again. The glitch triggers on plane switches in either direction. Additional observations (from our app's UITextFields — the same enablesReturnKeyAutomatically mechanism, but driven by a stricter text-validity rule than plain empty/non-empty, which makes the desync observable in more states): Two further workarounds restore the correct state after the glitch: switching the keyboard language (globe key), or changing the text and then tapping anywhere in the text field. A text change that does not flip the hasText state, without a follow-up tap, does not repaint the key. The pattern suggests that the keyboard rebuild triggered by switching planes defaults the return key to enabled without consulting the text state, and that the keyboard otherwise repaints the key only when the hasText answer transitions, or on input-session changes (tapping into the field, switching keyboard language). Environment: all reproductions and verifications were done on physical devices, not simulators — reproduced on an iPhone SE (iOS 26.5.2) and an iPad Pro 12.9" 4th gen (iPadOS 26.4.2); not reproducible on an iPad 6th gen (iPadOS 17.7.10). Is this a known issue, and is there a supported way to force the keyboard to re-evaluate the return key state after a plane switch?

On iOS 26, UISearchController becomes non-interactive when presenting a second UISearchController from another tab of a UITabBarController. let tabBar = UITabBarController() let first = FirstViewController() first.title = "First" let second = SecondViewController() second.title = "Second" let nav1 = UINavigationController(rootViewController: first) let nav2 = UINavigationController(rootViewController: second) nav1.tabBarItem = UITabBarItem( title: "First", image: nil, tag: 0 ) nav2.tabBarItem = UITabBarItem( title: "Second", image: nil, tag: 1 ) tabBar.viewControllers = [ nav1, nav2 ] The app has two tabs. Each tab has its own UINavigationController. Tab 1: A UISearchController is assigned to navigationItem.searchController. class FirstViewController: UIViewController { private let searchController = UISearchController( searchResultsController: nil ) override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .systemBackground searchController.obscuresBackgroundDuringPresentation = false searchController.searchResultsUpdater = self navigationItem.searchController = searchController navigationItem.hidesSearchBarWhenScrolling = false definesPresentationContext = true } } Tab 2: A button presents another UISearchController using present(_:animated:). class SecondViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .systemBackground let button = UIButton( type: .system ) button.setTitle( "Open Search", for: .normal ) button.addTarget( self, action: #selector(openSearch), for: .touchUpInside ) button.translatesAutoresizingMaskIntoConstraints = false view.addSubview(button) NSLayoutConstraint.activate([ button.centerXAnchor.constraint( equalTo: view.centerXAnchor ), button.centerYAnchor.constraint( equalTo: view.centerYAnchor ) ]) definesPresentationContext = true } @objc private func openSearch() { let searchController = UISearchController( searchResultsController: nil ) navigationController?.present( searchController, animated: true ) } } On iOS 17 and iOS 18 this works correctly. On iOS 26: The search controller appears. The Cancel button works. The search text field cannot receive touches and does not become first responder. If I remove: navigationItem.searchController = searchController from Tab 1, the search controller in Tab 2 works correctly. This looks like a UIKit regression introduced in iOS 26.

Hi, I'm trying to add Shortcuts using AppIntents but unable to get past this error: 'AppShortcutsProvider' property 'appShortcuts' requires builder syntax This is the AppShortcutsProvider struct: import AppIntents struct MyAppShortcuts: AppShortcutsProvider { @AppShortcutsBuilder static var appShortcuts: [AppShortcut] { AppShortcut( intent: OpenDashboardIntent(), phrases: [ "Open dashboard in \(.applicationName)", "Show my \(.applicationName) dashboard" ], shortTitle: "Open Dashboard", systemImageName: "square.grid.2x2" ) } } And I have only one intent: import AppIntents struct OpenDashboardIntent: AppIntent { static var title: LocalizedStringResource = "Open Dashboard" static var openAppWhenRun: Bool = true @MainActor func perform() async throws -> some IntentResult & ProvidesDialog { return .result(dialog: "Opening dashboard") } } I searched the error online but the fixes were to use @AppShortcutsBuilder and skipping commas in case of registering multiple app intents - I'm already following all that. What am I missing? Thanks.

When adopting the Scene Delegate, the applicationState changes from indicating app state to indicating scene state. I previously used this as a signal to determine whether my iOS app was launched in the background or launched by the user. Given the change, it seems like applicationState should no longer be used in that manner in the App Delegate. Would you recommend using UIApplication.shared.backgroundTimeRemaining to distinguish a background launch from a user launch? assuming this is a very large value for user launches. Are there corner cases that I may not expect?

This is UIKit app, in Xcode 26.3 (but same issue in 16.4). I create (in IB) a segmentedControl, with 2 segments. I set the images that are stored in assets. They show properly in Xcode. But when running (26.1 simulator), they just show a black image. In Xcode                                                                           On simulator at runtime I've tried to set background to clear as well as tint, to no avail. What am I missing ?

What is the recommended architecture for a native iPadOS application that automatically creates an interactive external workspace on a connected display while preserving pointer interaction and allowing custom layouts?

We are currently having an issue with our app hanging for some (not all) of our iOS 26.x users. The hang lasts long enough for the system to kill the app after a while. As of now we are unable to reproduce the issue on our own test devices, yet users dealing with the issue can produce it consistently. Looking at the stack traces we managed to retrieve, the hangup seems to occur in the layout rendering cycle of the navigation bar in the UINavigationController. The hangup doesn't happen at the exact same stack trace every time. But it always seems to be in the rendering cycle. Stack trace 1 Stack trace 2 Stack trace 3 Since the issue not reproducable in our own test environment it's hard to properly debug. The only adjustments to the navigationbar/navigationitem in our code is setting the title and a few bar buttons: self.navigationItem.title = NSLocalizedString("main_list_title", comment: "") let cancelItem = UIBarButtonItem(barButtonSystemItem: .stop, target: self, action: #selector(cancelListSelection)) let addPostItem = UIBarButtonItem(image: UIImage(named: "AddButton"), style: .plain, target: self, action: #selector(addItemTapped)) let extraMenuItem = UIBarButtonItem(image: UIImage(named: "ExtraButton"), style: .plain, target: self, action: #selector(extraItemTapped)) self.navigationItem.setLeftBarButton(cancelItem, animated: true) self.navigationItem.setRightBarButtonItems([addPostItem, extraMenuItem], animated: true) let previousButton = UIBarButtonItem(image: UIImage(named: "LeftArrow"), style: .plain, target: self, action: #selector(openPrevious)) let nextButton = UIBarButtonItem(image: UIImage(named: "RightButton"), style: .plain, target: self, action: #selector(openNext)) self.setToolbarItems([previousButton, nextButton], animated: true) And for one or two controllers the title is replaced by a UISegmentControl: let segControl = UISegmentedControl(items: ["1", "2", "3"]); segControl.selectedSegmentIndex = 0 segControl.addTarget(self, action: #selector(segmentValueChanged), for: .valueChanged) self.navigationItem.titleView = segControl Is anyone familiar with hangs at these particular stack traces and their cause?

Hello, Could someone from Apple clarify the support and behavior of the UIDesignRequiresCompatibility property? The UIDesignRequiresCompatibility documentation states that this property will be ignored for builds targeting iOS 27 or later. I have a couple of questions: Does "builds targeting iOS 27 or later" refer to an app that was built using Xcode 27 or later? iOS 27 is expected to be released in Fall 2026. Suppose that after iOS 27 is released, I create a new build using Xcode 26, with UIDesignRequiresCompatibility set to true, and install that build on an iOS 27 device. Will UIDesignRequiresCompatibility still be honored in this scenario, or will it be ignored and the app will use the Liquid Glass UI? Thanks!

Issue Description: On iOS 26 and later, a CoreGraphics crash occurs when rendering images using -[UIImage drawInRect:blendMode:alpha:]. Based on the call stack, the crash happens inside CoreGraphics. Under what circumstances does the function upscale_provider_get_bytes_at_position_inner in the stack get called? When attempting to reproduce locally, this code path is never reached even when scaling images. Steps to Reproduce: There are a large number of crash reports in production, but the issue cannot be reproduced locally/offline. Expected Results: Explain under what conditions calling -[UIImage drawInRect:blendMode:alpha:] will reach the upscale_provider_get_bytes_at_position_inner logic. Ideally, provide a code example or demo. Provide the root cause of the crash and a workaround/mitigation. Current Behavior: Calling -[UIImage drawInRect:blendMode:alpha:] causes intermittent crashes in production. Xcode Version Used: Xcode Version 26.0 (17A324)

Our app is using react native and native swift code to build an iOS app. We have some screens in both sides need to be protected if user is trying to capture a screenshots of it. We are trying to workaround to implement this screen protection by using UITextField and set isSecureTextEntry = true But there are some issues that we are facing as below: App is hang after go back from a screen that's is protected When app go back from a protected screen there is a black screen show up when screen is transiting back If we do protect entire screen from React Native side, there are leaking memory in react native screen and it can not be free up Do we have any other solution to prevent screenshot or can we fix above issues and continue using UITextField to implement it?

Since iPadOS 18, UIDocumentViewController has contained a document browser that shows a white page with rounded corners against a background of your choice, with the app name and "Create Document" buttons on the page. For instance, when you launch Pages, you see a white rounded page rectangle against a background of swirly orange, with “Choose a Template” and “Start Writing” buttons on the white page. In Numbers, there’s a green swirly background. In apps built and run on iPadOS 27, however, the white page with rounded corners is entirely missing, making the browser screen very ugly, with the “New Document” button translucent directly against whatever background is set. This can be reproduced simply by creating a new iOS "Document App" in Xcode 27 and building on iPadOS 27. I assume this is a bug, since if you turn on exception breakpoints, you see the following exception breakpoint triggered during launch: Exception = (NSException *) "[<_UIDocumentLaunchViewController 0x10732b200> valueForUndefinedKey:]: this class is not key value coding-compliant for the key _pageContainerView." I have thus reported it as FB23418746. I am curious, though, whether it is a design decision to remove the page background on iPadOS 27, or whether I am missing some sort of setting in the UIDocumentViewController’s launch options for restoring the page. (I hope it’s not intentional, as I like the page, and without it, the black app name gets lost against darker or busier backgrounds.) (I did try to include screenshots showing the issue when I first went to post this message, but doing so resulted in my IP address being blocked access to the forums for a week because of the forums’ new security measures.)

All system colors are displayed incorrectly on the popover view. Those are the same views present as a popover in light and dark mode. And those are the same views present as modal. And there is also a problem that when the popover is presented, switching to dark/light mode will not change the appearance. That affected all system apps. The following screenshot is already in dark mode. All those problem are occured on iOS 26 beta 3.

I have an app that uses UIToolbar and UIBarButtonItem, I create the bar button items using init(customView:), but I need them to be larger than the default toolbar item size, so I constrain the custom views to be larger, such as 50x50. Example: let button = UIButton(type: .system) button.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ button.widthAnchor.constraint(equalToConstant: 50), button.heightAnchor.constraint(equalToConstant: 50), ]) let item = UIBarButtonItem(customView: button) toolbar.items = [item] This worked on iOS 26 and would show a circular glass button. But on iOS 27 the button shows as an oval where the height seems capped at 44pt, and can't be made any taller. This has been an issue for all iOS 27 betas so far, and I've already filed this as a feedback (FB23641020). Has anyone else seen this issue or found a workaround?

On iOS 26 (reproduced on both Simulator and iPhone), the system share sheet (UIActivityViewController) displays the row of activity/app icons at a greatly oversized scale. The app's approximate hierarchy is like UIWindow.rootViewController → a plain container UIViewController → UITabBarController → an embedded container child → UINavigationController → the visible screen. When the share sheet is presented from a view controller inside such an hierarchy, the icons are oversized. When the same UIActivityViewController, with the exact same activity items, is presented from a full-screen modal view controller (modalPresentationStyle = .fullScreen / .overFullScreen), the icons render correctly. Is this a bug of iOS 26+? On iOS 27 the behaviour is the same.

On iPadOS 26.x, multiple users of our iPad app report that handwriting English words with Apple Pencil (Scribble) into a text field produces garbled output full of accented / non‑English characters instead of the English letters they wrote. Example of what shows up when a user handwrites a normal English word: -4ęśïćïá. Those accented letters (Polish / Spanish / French‑style diacritics: ę ś ï ć á) are not what the user wrote. Key facts from the reports Happens only on iPadOS 26.x — not seen on earlier iPadOS versions. Happens only with Apple Pencil / Scribble handwriting. Typing into the same field with the on‑screen keyboard is fine. The same users say Scribble works normally in other apps. The affected field is restricted to English‑only input; when that English‑only restriction is turned off, Scribble recognizes the handwriting correctly again. So the trigger appears to be Scribble writing into an English‑restricted field on iPadOS 26. No third‑party keyboards or input methods are involved. Steps (as reported by users) iPad on iPadOS 26.x with an Apple Pencil. Open the spelling/answer screen that has an English‑only input field. Handwrite an English word with the Pencil. The field fills with accented gibberish instead of the word. Question Is this a known iPadOS 26 Scribble regression? Is anyone else seeing garbled / accented output when Scribble writes into an English‑restricted text field? Any workaround short of removing the English‑only restriction? Environment Multiple end users, all on iPadOS 26.x (exact builds / iPad models being collected). I'm the developer and haven't been able to reproduce locally yet, so this is based on user reports.

I’ve been investigating a noticeable animation hitch when interactively dismissing a sheet over a SwiftUI screen with moderate complexity. This was not the case on iOS 18, so I’m curious if others are seeing the same on iOS 26 or have found any mitigations. When dismissing a sheet via the swipe gesture, there’s a visible hitch right after lift-off. The hitch comes from layout work in the underlying view (behind the sheet) The duration scales with the complexity of that view (e.g. number of TextFields/layout nodes) The animation for programmatic dismiss (e.g. tapping a “Done” button) is smooth, although it hangs for a similar amount of time before dismissing, so it appears that the underlying work still happens. SwiftUI is not reevaluating the body during this (validated with Self._printChanges()), so that is not the cause. Using Instruments, the hitch shows up as a layout spike on the main thread: 54ms UIView layoutSublayersOfLayer 54ms └─ _UIHostingView.layoutSubviews 38ms └─ SwiftUI.ViewGraph.updateOutputs 11ms ├─ partial apply for implicit closure #1 in closure #1 │ in closure #1 in Attribute.init<A>(_:) 4ms └─ -[UIView For the same hierarchy with varying complexity: ~3 TextFields in a List: ~25ms (not noticeable) ~20+ TextFields: ~60ms (clearly visible hitch) The same view hierarchy on iOS 18 did not exhibit a visible hitch. I’ve tested this on an iOS 26.4 device and simulator. I’ve also included a minimum reproducible example that illustrates this: struct ContentView: View { @State var showSheet = false var body: some View { NavigationStack { ScrollView { ForEach(0..<120) { _ in RowView() } } .navigationTitle("Repro") .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Present") { showSheet = true } } } .sheet(isPresented: $showSheet) { PresentedSheet() } } } } struct RowView: View { @State var first = "" @State var second = "" var body: some View { VStack(alignment: .leading, spacing: 12) { Text("Row") .font(.headline) HStack(spacing: 12) { TextField("First", text: $first) .textFieldStyle(.roundedBorder) TextField("Second", text: $second) .textFieldStyle(.roundedBorder) } HStack(spacing: 12) { Text("Third") Text("Fourth") Image(systemName: "chevron.right") } } } } struct PresentedSheet: View { @Environment(\.dismiss) private var dismiss var body: some View { NavigationStack { List {} .navigationTitle("Swipe To Dismiss Me") .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Done") { dismiss() } } } } } } Is anyone else experiencing this and have any mitigations been found beyond reducing view complexity? I’ve filed a feedback report under FB22501630.

I would need to know which gender is used by the iOS system for speechSynthesis. I have tried let aVoice = AVSpeechSynthesisVoice() print(#function, #line, aVoice.gender.rawValue) But always get 0, for unspecified