I would appreciate some feedback on this simple technical point. When a gesture is defined in code, it is simply added to the view with myFirstView.addGestureRecognizer(someGesture) That's fine. But, if by mistake, the same gesture is added later to another view myOtherView.addGestureRecognizer(someGesture) myFirstView will not receive anymore the notification. That's well known and documented, because in fact the gesture references the view and can only reference one. So my point: this may be a bit misleading, as API let one believe that the gesture is attached to the view ; hence, why not attach to a second view ? wouldn't it be better to have API where view is explicitly "attached" to gesture ? someGesture.attach(to: myFirstView) Doing so, if I later someGesture.attach(to: myOtherView) it would be clearer I am changing the attached view. I noted that when we define a gesture in IB, we can only connect from the view to the gesture, not from gesture to the view which seems to follow the same logic. A simple extension does it: extension UITapGestureRecognizer { func attach(to view: UIView) { view.addGestureRecognizer(self) } } Any thought ? PS: I'm amazed by code completion. I just typed extension UITapGestureRecognizer { func attach(to view: UIView) and it completed automatically the code with view.addGestureRecognizer(self)

I’m seeing inconsistent UISegmentedControl background-color behavior on certain devices running iOS 26. The same code works as expected on other devices and iOS versions, but on affected devices the control does not display the assigned backgroundColor. The issue occurs using standard UIKit colors and does not depend on custom fonts, images, or appearance extensions. Here is a simplified example using only public UIKit APIs: private let segmentedControl = UISegmentedControl(items: ["Card", "Email"]) private func setupSegmentedControl() { segmentedControl.selectedSegmentIndex = 0 guard let cardIcon = UIImage( systemName: "creditcard.fill", withConfiguration: UIImage.SymbolConfiguration( pointSize: 14, weight: .semibold ) ), let emailIcon = UIImage( systemName: "envelope.fill", withConfiguration: UIImage.SymbolConfiguration( pointSize: 14, weight: .semibold ) ) else { return } segmentedControl.setImage( cardIcon, forSegmentAt: 0 ) segmentedControl.setImage( emailIcon, forSegmentAt: 1 ) segmentedControl.backgroundColor = .systemGray5 segmentedControl.selectedSegmentTintColor = .systemBlue segmentedControl.layer.cornerRadius = 8 segmentedControl.clipsToBounds = true let font = UIFont.systemFont( ofSize: 14, weight: .medium ) segmentedControl.setTitleTextAttributes( [ .foregroundColor: UIColor.label, .font: font ], for: .normal ) segmentedControl.setTitleTextAttributes( [ .foregroundColor: UIColor.white, .font: font ], for: .selected ) segmentedControl.addTarget( self, action: #selector(segmentChanged(_:)), for: .valueChanged ) view.addSubview(segmentedControl) } @objc private func segmentChanged( _ sender: UISegmentedControl ) { print("Selected segment: \(sender.selectedSegmentIndex)") } UISegmentedControl Apple Documentation

Our app crashes when compiled with the iOS 27 beta 3 SDK and run as an iOS app on Mac, on both macOS 26 and macOS 27, as soon as a UISearchBar receives focus. The crash is due to this exception: *** Assertion failure in BOOL _screenBasedFocusUnsupported(void)(), UIScreen.m:3.725 Accessing the focus system through UIScreen is no longer supported. ( 0 CoreFoundation 0x000000018bea31c0 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x000000018b91e91c objc_exception_throw + 88 2 Foundation 0x000000018e092644 -[NSMutableDictionary(NSMutableDictionary) initWithContentsOfFile:] + 0 3 UIKitCore 0x00000001c5dae8ec _screenBasedFocusUnsupported + 272 4 UIKitCore 0x00000001c5dae960 -[UIScreen _preferredFocusedWindow] + 24 5 UIKitCore 0x00000001c4ea3a60 -[UIScreen _mainSceneReferenceBounds] + 200 6 UIKitCore 0x00000001c4ea3914 -[UIScreen _mainSceneBoundsForInterfaceOrientation:] + 40 7 UIKitCore 0x00000001c5708134 +[UINavigationBar defaultSizeForOrientation:] + 76 8 UIKitCore 0x00000001c6222c88 -[_UISearchPresentationController _layoutPresentationWithSize:transitionCoordinator:] + 704 9 UIKitCore 0x00000001c622296c -[_UISearchPresentationController containerViewWillLayoutSubviews] + 84 10 UIKitCore 0x00000001c549304c block_destroy_helper.13 + 25112 11 UIKitCore 0x00000001c549344c block_destroy_helper.13 + 26136 12 UIKitCore 0x00000001c4ea26a8 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1648 13 QuartzCore 0x0000000196103dbc _ZN2CA5Layer15perform_update_EPS0_P7CALayerjNS_17LayerUpdateReasonEPNS_11TransactionE + 460 14 QuartzCore 0x000000019610390c _ZN2CA5Layer17update_if_needed_EPNS_11TransactionENS_17LayerUpdateReasonE + 692 15 QuartzCore 0x0000000196035d2c _ZN2CA7Context18commit_transactionEPNS_11TransactionEdPd + 608 16 QuartzCore 0x0000000195e69520 _ZN2CA11Transaction6commitEv + 652 17 AppKit 0x0000000190fe116c __37+[NSDisplayCycle currentDisplayCycle]_block_invoke.7 + 44 18 CoreFoundation 0x000000018be34ad0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 19 CoreFoundation 0x000000018be34a10 __CFRunLoopDoBlocks + 396 20 CoreFoundation 0x000000018be33e54 __CFRunLoopRun + 2356 21 CoreFoundation 0x000000018bf06234 _CFRunLoopRunSpecificWithOptions + 532 22 HIToolbox 0x0000000198c1f560 RunCurrentEventLoopInMode + 320 23 HIToolbox 0x0000000198c228bc ReceiveNextEventCommon + 488 24 HIToolbox 0x0000000198dac14c _BlockUntilNextEventMatchingListInMode + 48 25 AppKit 0x00000001909163d0 _DPSBlockUntilNextEventMatchingListInMode + 228 26 AppKit 0x000000019026a084 _DPSNextEvent + 576 27 AppKit 0x0000000190dff96c -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 28 AppKit 0x0000000190dff678 -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:] + 72 29 AppKit 0x000000019025d13c -[NSApplication run] + 368 30 AppKit 0x00000001902357b0 NSApplicationMain + 880 31 AppKit 0x000000019047c958 +[NSWindow _savedFrameFromString:] + 0 32 UIKitMacHelper 0x00000001aa2651bc UINSApplicationMain + 972 33 UIKitCore 0x00000001c4e1aed4 UIApplicationMain + 144 34 UIKitCore 0x00000001c548bda0 block_destroy_helper.31 + 8880 35 DigitalConcertHall.debug.dylib 0x0000000106e41bd8 $sSo21UIApplicationDelegateP5UIKitE4mainyyFZ + 128 36 DigitalConcertHall.debug.dylib 0x0000000106e41b4c $s18DigitalConcertHall11AppDelegateC5$mainyyFZ + 32 37 DigitalConcertHall.debug.dylib 0x0000000106e4afc0 __debug_main_executable_dylib_entry_point + 28 38 dyld 0x000000018b9ac4e4 start + 6992 ) I could not test with the iOS 27 beta 4 SDK due to this blocking issue: https://developer.apple.com/forums/thread/839012 However, when I tried to set up a simple sample project, I could not reproduce the issue. Does anybody know what might be causing this? I filed feedback FB24201508

My app is themeable, and uses window.overrideUserInterfaceStyle to set the userInterfaceStyle independently from the system setting. This works great, except this does not change the userInterfaceStyle of the menus. So I'm occasionally experiencing light menus with a dark themed app, and vice versa. Question: how to override the userInterfaceStyle of the menus managed by UIMainMenuSystem?

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?

In my apps, I have a requirement to display an image of the application icon is certain circumstances. This is fairly straightforward for iOS/iPadOS and it used to be straightforward for macCatalyst. For MacCatalyst, this is no longer true (at least since macOS 26). This is because the app icon is now stored as an .icns file and (in the case of using an IconComposer icon), the `'png' in the Asset Catalog now has an unknown name. So the following code no longer works: public extension Bundle { var icon: UIImage? { #if targetEnvironment(macCatalyst) guard let iconName = infoDictionary?["CFBundleIconName"] as? String else { return nil } return UIImage(named: iconName, in: self, compatibleWith: nil) #else guard let icons = infoDictionary?["CFBundleIcons"] as? [String : Any] else { return nil } guard let primaryIcon = icons["CFBundlePrimaryIcon"] as? [String : Any] else { return nil } guard let iconFiles = primaryIcon["CFBundleIconFiles"] as? [String] else { return nil } guard let file = iconFiles.last else { return nil } return UIImage(named: file, in: self, compatibleWith: nil) #endif } The obvious solution is to place an Image in the Asset Catalog which I can access, but this is a maintenance headache. What I would actually like to do is either create a UIImage directly from the .icns file, or access the .png file in the Asset Catalog (which has a name beginning with the icon file name, but has additional characters in its name that I don't know). Can you help?

Hello, I found a difference in application lifecycle behavior between iPadOS 26.5 and iPadOS 27 beta when the app is running in the foreground and the iPad top button is pressed to put the device into sleep. Test condition Device: iPad App state: app is running in foreground (active) Action: press the top button once to put the device to sleep Observed via UIApplicationDelegate lifecycle callbacks Observed behavior iPadOS 26.5 The following callbacks are called in this order: applicationWillResignActive applicationDidEnterBackground iPadOS 27 beta The following callbacks are called in this order: applicationWillResignActive applicationDidBecomeActive applicationWillResignActive applicationDidEnterBackground Expected behavior I expected the lifecycle sequence on iPadOS 27 beta to be the same as, or at least consistent with, iPadOS 26.5 when the device is put to sleep from the foreground app state. In particular, I did not expect applicationDidBecomeActive to be called during the transition to sleep/background. Question Is this changed behavior expected in iPadOS 27 beta, or could this be a bug in the beta? If this is expected, could you clarify the intended lifecycle behavior when the top button is pressed and the device transitions to sleep? Thank you.

I’m seeing a physical shake detection issue on an iPhone 17 Pro running iOS 27.0 (24A5380h). The issue reproduces in both Apple’s Notes app and a UIKit app: “Shake to Undo” is enabled under Settings > Accessibility > Touch. After entering text in Notes, physically shaking the iPhone does not display the Undo Typing interface. In the UIKit app, neither the UIWindow nor UIViewController responder receives motionBegan:withEvent: for UIEventSubtypeMotionShake. The issue still reproduces after restarting the iPhone and removing the device case. This is direct physical-device testing and is not related to iPhone Mirroring. I filed this through Feedback Assistant as FB24200727. Is anyone else able to reproduce this on iOS 27, either on the same build or a later build? If so, please file a separate Feedback Assistant report and reference FB24200727.

Hello, I found a difference in application lifecycle behavior between iPadOS 26.5 and iPadOS 27 beta when the app is running in the foreground and the iPad top button is pressed to put the device into sleep. Test condition Device: iPad App state: app is running in foreground (active) Action: press the top button once to put the device to sleep Observed via UIApplicationDelegate lifecycle callbacks Observed behavior iPadOS 26.5 The following callbacks are called in this order: applicationWillResignActive applicationDidEnterBackground iPadOS 27 beta The following callbacks are called in this order: applicationWillResignActive applicationDidBecomeActive applicationWillResignActive applicationDidEnterBackground Expected behavior I expected the lifecycle sequence on iPadOS 27 beta to be the same as, or at least consistent with, iPadOS 26.5 when the device is put to sleep from the foreground app state. In particular, I did not expect applicationDidBecomeActive to be called during the transition to sleep/background. Question Is this changed behavior expected in iPadOS 27 beta, or could this be a bug in the beta? If this is expected, could you clarify the intended lifecycle behavior when the top button is pressed and the device transitions to sleep? Thank you.

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 ?

Hi everyone,I am noticing that the UI color icon is red on the CoreNFC sheet. This is happening on an iPhone SE 2022 running iOS 16.6.Is anyone else experiencing this issue? How can I fix this? Any help would be greatly appreciated!

I am building an iOS text composer with an attachment panel. When its UITextField is first responder and the system keyboard is visible, tapping the attachment button should present a panel that can extend into the region occupied by the keyboard. When the panel closes, the user should return to the same keyboard state without a visible dismissal and re-presentation. The required continuity is: The same UITextField remains first responder. The active input mode remains alphabet, 123, or Emoji. Emoji preserves its selected category, search state, and scroll position. The composer remains positioned above the keyboard throughout the transition. I have investigated the public UIKit approaches: A normal app-window overlay cannot render above the remotely hosted system keyboard. inputAccessoryView remains in the accessory region and cannot cover the keycaps. Resigning first responder visibly dismisses the keyboard and loses continuity. Assigning a custom inputView to the same UITextField and calling reloadInputViews() publicly replaces the keyboard. However, restoring inputView to nil reconstructs the system keyboard and does not preserve the exact Emoji or keyplane state. UIKeyboardLayoutGuide provides geometry but no presentation control. Is there a supported public API or recommended architecture that allows an app to: Temporarily obscure or visually hide the system keyboard while keeping it active and preserving its state? Present app-owned content in a layer above the keyboard keycaps? Temporarily replace the keyboard and restore the same mode, Emoji category, and scroll position? If these are unsupported, what is Apple's recommended way to create an attachment panel that visually occupies the keyboard region while maintaining input continuity? This occurs on iOS 26.x in Simulator and on a physical iPhone using a UIKit-backed text field inside a SwiftUI interface. I am specifically looking for a public API solution and do not want to access private keyboard windows or views.

Filed as FB24092251. On macOS 27.0 beta (26A5388g), clicking into any text input inside a WKWebView in a Mac Catalyst app makes focus oscillate forever and typing does nothing. CPU pegs at 100% while the editor is focused. The same binary works fine on macOS 26. The DOM element never actually loses focus. Only the window does: window focus -> activeElement=TEXTAREA.inputarea JS focus -> activeElement=TEXTAREA.inputarea window blur -> activeElement=TEXTAREA.inputarea <- window loses key status JS blur -> activeElement=TEXTAREA.inputarea <- element did not ...repeats indefinitely... Pausing during the loop shows why. Focusing the element sends WebKit into UIKit's software-keyboard machinery, on a platform that has no software keyboard: -[UIKeyboardSceneDelegate containerWindowForViewService:] -[UIKeyboardSceneDelegate _setKeyWindowSceneInputViews:animationStyle:] -[UIKeyboardSceneDelegate _reloadInputViewsForResponder:force:fromBecomeFirstResponder:] -[UIResponder(UIResponderInputViewAdditions) reloadInputViews] -[WKContentView(WKInteraction) _continueElementDidFocus:...] -[WKContentView(WKInteraction) _elementDidFocus:...] WebKit::WebPageProxy::elementDidFocus(...) Building that container steals key status from the web view. First responder ends up on the enclosing _UIHostingView, so key presses are delivered there and immediately cancelled: pressesBegan: [...], focusedItem: monacoEditor firstResponder at keypress: _UIHostingView<...> pressesCancelled: [...] The catch: -becomeFirstResponder cannot be used to recover, because it is the trigger. Calling it re-enters _elementDidFocus and re-arms the loop permanently. So there is no app-side way back — the only API that reclaims the keyboard is the one that breaks it. Minimal repro is just a WKWebView in a UIViewRepresentable inside a SwiftUI hierarchy, with any focusable . No Monaco needed. Partial mitigation, if you hit this: do not echo focus/blur commands back at the web view in response to its own focus events, and treat a blur where document.hasFocus() is false but activeElement is unchanged as a window-level blur rather than an editing-ended event. That stops the runaway loop and keeps your focus state correct — but it does not restore typing. Has anyone found a way to get first responder back to the web view without calling -becomeFirstResponder? Or a way to stop the keyboard scene delegate engaging on Catalyst in the first place? If you can reproduce on 27 beta, please file a duplicate referencing FB24092251.

Is there a way you can customize the look of the red dots? to offset the position or the size of the dots etc.?

I have inserted a Static cells table with configuration items and a normal dynamic table for displaying results in a UITableViewController in a StoryBoard. I get no error, but still just the header is shown, none of the navigation bar or any hint of the two tables, as you may see in the pictures:

I’m using MFMailComposeViewController to send emails from my app. Since updating to iPadOS 26.4, there is no way to cancel the mail composer because the “X” button in the top-left corner has disappeared. On iPhone with iOS 26.4, everything still seems to work as expected. Is this a known issue, or am I missing something? Has anyone else experienced this, or found a workaround?

in iOS26.4, after installing the app for the first time, opening the app and clicking on the UITextField input box will trigger the system to pop up the network permission application interface. This issue did not exist before iOS 26.3, only in iOS 26.4. This is a fatal bug where the network permission request box should not pop up when the developer has not called the network related API.

Hello, we are updating our application to adopt the new Liquid Glass design introduced in iOS 26 with UIGlassEffect and UIGlassContainerEffect. Since our minimum supported version is iOS 16, we'd like to provide a visually similar effect on earlier iOS versions using only public APIs. Could you please advise the recommended App Store–compliant approach? In particular: is there any public API on iOS 16–25 that provides a system glass effect comparable to UIGlassEffect? If not, is the recommended fallback to use UIVisualEffectView with UI BlurEffect, plus custom borders and decoration? Would a custom implementation using Metal or Core Image, relying only on public APIs and application-owned content (for example, our chat wallpaper), be acceptable for App Store distribution if it is used solely to achieve a visually similar appearance? Are there any public APIs, sample code, or best practices that Apple recommends for approximating the Liquid Glass look on iOS 16–25 without private APIs? Our goal is to fully comply with App Store Review Guideline 2.5.1 and ensure the approach we choose follows Apple's recommendations. thank you We understand that responses on the Developer Forums do not constitute formal App Review pre-approval. We are specifically seeking guidance on the recommended use of public APIs and any known compliance concerns.

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?

I'm trying to require a minimum size in my UIKit-based iOS app. I added code to set that using the UIWindowScene.sizeRestrictions property to my app's scene delegate as recommended in Apple's documentation: func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let currentScene = (scene as? UIWindowScene) else { return } currentScene.sizeRestrictions?.minimumSize.height = 400 currentScene.sizeRestrictions?.minimumSize.width = 320 print("*** Size restrictions: \(String(describing: currentScene.sizeRestrictions))") ... } When I run that in the simulator for an iOS 27 iPhone, the size restrictions property prints out as being nil. That's surprising to me, since the documentation states that "The system provides this object only when it supports variable-sized windows.", and iPhone windows are resizable in iOS 27. If this is working as expected, is there another way to restrict the size of an iPhone window in iOS 27?