Construct and manage graphical, event-driven user interfaces for iOS or tvOS apps using UIKit.

Posts under UIKit tag

200 Posts

Post

Replies

Boosts

Views

Activity

Pinch gesture not recognized on MTKView when attaching it to a RealityView using a ViewAttachmentComponent in a immersive space
Hello! We are seeing a problem with a SwiftUI view that wraps an MTKView and that MTKView uses gesture recognizers from UIKit. One of those gestures we are using is UIPinchGestureRecognizer. And that gesture isn’t recognized at all when the SwiftUI view is attached to a RealityView using the ViewAttachmentComponent AND the RealityView is being shown in an ImmersiveSpace. If the SwiftUI view is attached to the RealityView using the init that has an attachment closure then pinching works fine there. So this definitely seems like a bug. Here is some code to help you reproduce the problem. Run this on a Vision Pro device. A simple red square will be rendered and if a single tap or pinch gesture is recognized on the red square, it will print to the console. App Code: import SwiftUI @main struct VisionPinchProblemsApp: App { var body: some Scene { WindowGroup { MenuView() } ImmersiveSpace(id: "RedSquare") { RedSquareView() } } } View code: import MetalKit import RealityKit import SwiftUI import UIKit struct MenuView: View { @Environment(\.openImmersiveSpace) private var openImmersiveSpace @Environment(\.dismissImmersiveSpace) private var dismissImmersiveSpace @State private var showImmersiveSpace = false @State private var immersiveSpaceIsOpen = false var body: some View { Form { Toggle("Show red square", isOn: $showImmersiveSpace) .task(id: showImmersiveSpace) { if showImmersiveSpace { await openImmersiveSpace(id: "RedSquare") immersiveSpaceIsOpen = true } else { if immersiveSpaceIsOpen { await dismissImmersiveSpace() immersiveSpaceIsOpen = false } } } } .onDisappear { // Attempt to close the immersive space on the way out. Task { if immersiveSpaceIsOpen { await dismissImmersiveSpace() } } } } } struct RedSquareView: View { let metalViewAttachmentID = "metalID" var body: some View { // Adds SwiftUI view using attachments closure. // Pinching and single taps are recognized here! // RealityView { content, attachments in // if let metalViewEntity = attachments.entity(for: metalViewAttachmentID) { // metalViewEntity.position = [0, 1, -1.25] // content.add(metalViewEntity) // } // } placeholder: { // ProgressView() // } attachments: { // Attachment(id: metalViewAttachmentID) { // MetalView() // } // } // Add SwiftUI view using ViewAttachmentComponent. // Pinching is not recognized here! // Single tapping is recognized ! // Why doesn't the red square show up in the Vision Pro simulator? RealityView { content in let metalViewEntity = Entity() let metalView = MetalView() .frame(width: 500, height: 500) let component = ViewAttachmentComponent(rootView: metalView) metalViewEntity.components.set(component) metalViewEntity.position = [0, 1, -1.25] content.add(metalViewEntity) } placeholder: { ProgressView() } } } struct MetalView: UIViewRepresentable { var device: MTLDevice? init() { self.device = MTLCreateSystemDefaultDevice() } func makeUIView(context: Context) -> MTKView { let mtkView = MTKView() mtkView.device = device mtkView.clearColor = MTLClearColor(red: 1.0, green: 0.0, blue: 0.0, alpha: 1.0) mtkView.delegate = context.coordinator let pinchGesture = UIPinchGestureRecognizer(target: context.coordinator, action: #selector(context.coordinator.handlePinch(_:))) mtkView.addGestureRecognizer(pinchGesture) let tapGesture = UITapGestureRecognizer(target: context.coordinator, action: #selector(context.coordinator.handleTap(_:))) mtkView.addGestureRecognizer(tapGesture) return mtkView } func updateUIView(_ uiView: MTKView, context: Context) { } func makeCoordinator() -> Coordinator { Coordinator(self) } class Coordinator: NSObject, MTKViewDelegate { var parent: MetalView init(_ parent: MetalView) { self.parent = parent } func mtkView(_ view: MTKView, drawableSizeWillChange size: CGSize) { } func draw(in view: MTKView) { guard let drawable = view.currentDrawable else { return } guard let descriptor = view.currentRenderPassDescriptor else { return } let commandQueue = parent.device?.makeCommandQueue() let commandBuffer = commandQueue?.makeCommandBuffer() let renderEncoder = commandBuffer?.makeRenderCommandEncoder(descriptor: descriptor) renderEncoder?.endEncoding() commandBuffer?.present(drawable) commandBuffer?.commit() } @objc func handlePinch(_ sender: UIPinchGestureRecognizer) { print("Pinch detected") } @objc func handleTap(_ sender: UITapGestureRecognizer) { print("Tap detected") } } }
1
0
1.3k
Aug ’26
How to achieve the UIEditMenuInteraction (?) for Link Preview used in iOS 27 Messages
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?
0
0
981
Aug ’26
iOS 26 regression? `enablesReturnKeyAutomatically`'s disabled return key re-enables after switching keyboard planes (letters ⇄ numbers)
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?
0
1
825
Jul ’26
UISearchController text field not receiving touches when another UISearchController is attached to navigationItem.searchController on iOS 26
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.
Topic: UI Frameworks SubTopic: UIKit Tags:
1
0
428
Jul ’26
Unable to use AppIntents
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.
0
0
712
Jul ’26
Distinguishing background from user app launches
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?
1
0
986
Jul ’26
iPadOS extended display architecture
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?
Topic: Design SubTopic: General Tags:
4
0
1.9k
Jul ’26
App hangs on navigation bar rendering cycle
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?
Topic: UI Frameworks SubTopic: UIKit Tags:
4
0
853
Jul ’26
UIDesignRequiresCompatibility support clarification.
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!
1
0
1.6k
Jul ’26
iOS app crashes in CoreGraphics with upscale_provider_get_bytes_at_position_inner when rendering images using the Texture library
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)
1
0
1k
Jul ’26
Is it possible to implement screenshot protection for iOS app?
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?
2
0
477
Jul ’26
Incorrect system color on popover view, and does not update while switching dark mode on iOS 26 beta 3
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.
22
1
3.6k
Jul ’26
UIBarButtonItem shown with incorrect height on iOS 27
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?
0
1
799
Jul ’26
UIActivityViewController renders oversized activity icons on iOS 26
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.
Topic: UI Frameworks SubTopic: UIKit Tags:
2
0
542
Jul ’26
iPadOS 26 — Apple Pencil (Scribble) produces garbled, accented gibberish when handwriting into some text fields
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.
0
0
918
Jul ’26
iOS 26: Interactive sheet dismissal causes layout hitch in underlying SwiftUI view
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.
2
0
1k
Jul ’26
iOS 27: viewSafeAreaInsetsDidChange callback issue
viewSafeAreaInsetsDidChange system callback stopped firing on iOS 27 when compiled with iOS 26 SDK (Xcode 26). more context: whenever tabBar's minimize behaviour changes for example on scroll-down viewSafeAreaInsetsDidChange was being called correctly on iOS 26 but it stopped on iOS 27. when compiling on Xcode 27 it is being called correctly just callback stopped firing on iOS 27 when compiled with iOS 26 SDK (Xcode 26).
1
0
803
Jul ’26
Pinch gesture not recognized on MTKView when attaching it to a RealityView using a ViewAttachmentComponent in a immersive space
Hello! We are seeing a problem with a SwiftUI view that wraps an MTKView and that MTKView uses gesture recognizers from UIKit. One of those gestures we are using is UIPinchGestureRecognizer. And that gesture isn’t recognized at all when the SwiftUI view is attached to a RealityView using the ViewAttachmentComponent AND the RealityView is being shown in an ImmersiveSpace. If the SwiftUI view is attached to the RealityView using the init that has an attachment closure then pinching works fine there. So this definitely seems like a bug. Here is some code to help you reproduce the problem. Run this on a Vision Pro device. A simple red square will be rendered and if a single tap or pinch gesture is recognized on the red square, it will print to the console. App Code: import SwiftUI @main struct VisionPinchProblemsApp: App { var body: some Scene { WindowGroup { MenuView() } ImmersiveSpace(id: "RedSquare") { RedSquareView() } } } View code: import MetalKit import RealityKit import SwiftUI import UIKit struct MenuView: View { @Environment(\.openImmersiveSpace) private var openImmersiveSpace @Environment(\.dismissImmersiveSpace) private var dismissImmersiveSpace @State private var showImmersiveSpace = false @State private var immersiveSpaceIsOpen = false var body: some View { Form { Toggle("Show red square", isOn: $showImmersiveSpace) .task(id: showImmersiveSpace) { if showImmersiveSpace { await openImmersiveSpace(id: "RedSquare") immersiveSpaceIsOpen = true } else { if immersiveSpaceIsOpen { await dismissImmersiveSpace() immersiveSpaceIsOpen = false } } } } .onDisappear { // Attempt to close the immersive space on the way out. Task { if immersiveSpaceIsOpen { await dismissImmersiveSpace() } } } } } struct RedSquareView: View { let metalViewAttachmentID = "metalID" var body: some View { // Adds SwiftUI view using attachments closure. // Pinching and single taps are recognized here! // RealityView { content, attachments in // if let metalViewEntity = attachments.entity(for: metalViewAttachmentID) { // metalViewEntity.position = [0, 1, -1.25] // content.add(metalViewEntity) // } // } placeholder: { // ProgressView() // } attachments: { // Attachment(id: metalViewAttachmentID) { // MetalView() // } // } // Add SwiftUI view using ViewAttachmentComponent. // Pinching is not recognized here! // Single tapping is recognized ! // Why doesn't the red square show up in the Vision Pro simulator? RealityView { content in let metalViewEntity = Entity() let metalView = MetalView() .frame(width: 500, height: 500) let component = ViewAttachmentComponent(rootView: metalView) metalViewEntity.components.set(component) metalViewEntity.position = [0, 1, -1.25] content.add(metalViewEntity) } placeholder: { ProgressView() } } } struct MetalView: UIViewRepresentable { var device: MTLDevice? init() { self.device = MTLCreateSystemDefaultDevice() } func makeUIView(context: Context) -> MTKView { let mtkView = MTKView() mtkView.device = device mtkView.clearColor = MTLClearColor(red: 1.0, green: 0.0, blue: 0.0, alpha: 1.0) mtkView.delegate = context.coordinator let pinchGesture = UIPinchGestureRecognizer(target: context.coordinator, action: #selector(context.coordinator.handlePinch(_:))) mtkView.addGestureRecognizer(pinchGesture) let tapGesture = UITapGestureRecognizer(target: context.coordinator, action: #selector(context.coordinator.handleTap(_:))) mtkView.addGestureRecognizer(tapGesture) return mtkView } func updateUIView(_ uiView: MTKView, context: Context) { } func makeCoordinator() -> Coordinator { Coordinator(self) } class Coordinator: NSObject, MTKViewDelegate { var parent: MetalView init(_ parent: MetalView) { self.parent = parent } func mtkView(_ view: MTKView, drawableSizeWillChange size: CGSize) { } func draw(in view: MTKView) { guard let drawable = view.currentDrawable else { return } guard let descriptor = view.currentRenderPassDescriptor else { return } let commandQueue = parent.device?.makeCommandQueue() let commandBuffer = commandQueue?.makeCommandBuffer() let renderEncoder = commandBuffer?.makeRenderCommandEncoder(descriptor: descriptor) renderEncoder?.endEncoding() commandBuffer?.present(drawable) commandBuffer?.commit() } @objc func handlePinch(_ sender: UIPinchGestureRecognizer) { print("Pinch detected") } @objc func handleTap(_ sender: UITapGestureRecognizer) { print("Tap detected") } } }
Replies
1
Boosts
0
Views
1.3k
Activity
Aug ’26
How to achieve the UIEditMenuInteraction (?) for Link Preview used in iOS 27 Messages
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?
Replies
0
Boosts
0
Views
981
Activity
Aug ’26
iOS 26 regression? `enablesReturnKeyAutomatically`'s disabled return key re-enables after switching keyboard planes (letters ⇄ numbers)
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?
Replies
0
Boosts
1
Views
825
Activity
Jul ’26
UISearchController text field not receiving touches when another UISearchController is attached to navigationItem.searchController on iOS 26
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.
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
1
Boosts
0
Views
428
Activity
Jul ’26
Unable to use AppIntents
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.
Replies
0
Boosts
0
Views
712
Activity
Jul ’26
Distinguishing background from user app launches
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?
Replies
1
Boosts
0
Views
986
Activity
Jul ’26
iPadOS extended display architecture
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?
Topic: Design SubTopic: General Tags:
Replies
4
Boosts
0
Views
1.9k
Activity
Jul ’26
App hangs on navigation bar rendering cycle
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?
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
4
Boosts
0
Views
853
Activity
Jul ’26
UIDesignRequiresCompatibility support clarification.
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!
Replies
1
Boosts
0
Views
1.6k
Activity
Jul ’26
iOS app crashes in CoreGraphics with upscale_provider_get_bytes_at_position_inner when rendering images using the Texture library
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)
Replies
1
Boosts
0
Views
1k
Activity
Jul ’26
Is it possible to implement screenshot protection for iOS app?
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?
Replies
2
Boosts
0
Views
477
Activity
Jul ’26
Incorrect system color on popover view, and does not update while switching dark mode on iOS 26 beta 3
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.
Replies
22
Boosts
1
Views
3.6k
Activity
Jul ’26
UIBarButtonItem shown with incorrect height on iOS 27
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?
Replies
0
Boosts
1
Views
799
Activity
Jul ’26
UIActivityViewController renders oversized activity icons on iOS 26
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.
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
2
Boosts
0
Views
542
Activity
Jul ’26
iPadOS 26 — Apple Pencil (Scribble) produces garbled, accented gibberish when handwriting into some text fields
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.
Replies
0
Boosts
0
Views
918
Activity
Jul ’26
iOS 26: Interactive sheet dismissal causes layout hitch in underlying SwiftUI view
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.
Replies
2
Boosts
0
Views
1k
Activity
Jul ’26
iOS 27: viewSafeAreaInsetsDidChange callback issue
viewSafeAreaInsetsDidChange system callback stopped firing on iOS 27 when compiled with iOS 26 SDK (Xcode 26). more context: whenever tabBar's minimize behaviour changes for example on scroll-down viewSafeAreaInsetsDidChange was being called correctly on iOS 26 but it stopped on iOS 27. when compiling on Xcode 27 it is being called correctly just callback stopped firing on iOS 27 when compiled with iOS 26 SDK (Xcode 26).
Replies
1
Boosts
0
Views
803
Activity
Jul ’26