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?

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.

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 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?

Device: iPhone 15 Affected Versions: • iOS 26.5 • iOS 26.6 Summary While using my iPhone 15 during charging, the touchscreen occasionally becomes less responsive. Some touches are delayed or not recognized, making the device difficult to use. This issue was present on iOS 26.5 and still occurs after updating to iOS 26.6. Steps to Reproduce Connect the iPhone 15 to a charger. Unlock the device. Use the touchscreen while the phone is charging. Continue interacting with the screen for several minutes. Expected Result The touchscreen should remain fully responsive while charging. Actual Result The touchscreen occasionally becomes less responsive. Some taps or gestures are delayed or not recognized. The issue is intermittent but noticeable during charging. Frequency Intermittent. It does not happen every time, but it has occurred multiple times on both iOS 26.5 and iOS 26.6. Additional Information • Device: iPhone 15 • The issue has persisted across two stable iOS versions. • I have restarted the device and updated to the latest iOS version, but the issue still occurs. Has anyone else experienced this issue on iPhone 15 or other iPhone models? If so, does it occur with the Apple charger, a third-party charger, or both?

Since the beta releases of iPadOS 26 we have been having some crashes about Invalid parameter not satisfying: parentEnvironment != nil We got to contact a couple of users and we found out that the crash appears when entering a screen in a UINavigationController with the iPad device connected to a Magic Keyboard. If the device is not connected to the keyboard then nothing happens and everything works ok. From our end we haven't managed to reproduce the crash so I am pasting part of the stacktrace if it can be of any help. 3 UIKitCore 0x19dfd2e14 -[_UIFocusContainerGuideFallbackItemsContainer initWithParentEnvironment:childItems:] + 224 (_UIFocusContainerGuideFallbackItemsContainer.m:23) 4 UIKitCore 0x19dae3108 -[_UIFocusContainerGuideImpl _searchForFocusRegionsInContext:] + 368 (_UIFocusGuideImpl.m:246) 5 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 6 UIKitCore 0x19db28900 -[_UIFocusMapSnapshot addRegionsInContainers:] + 160 (_UIFocusMapSnapshot.m:545) 7 UIKitCore 0x19d1313dc _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 632 (_UIFocusRegion.m:143) 8 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 9 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 10 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 11 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 12 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 13 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 14 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 15 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 16 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 17 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 18 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 19 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 20 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 21 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 22 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 23 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 24 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 25 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 26 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 27 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 28 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 29 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 30 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 31 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 32 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 33 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 34 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 35 UIKitCore 0x19d1320fc _UIFocusItemContainerAddChildItemsInContextWithOptions + 596 (UIFocusItemContainer.m:183) 36 UIKitCore 0x19d131b98 _UIFocusRegionSearchContextAddChildItemsInEnvironmentContainer + 648 (_UIFocusRegion.m:108) 37 UIKitCore 0x19d131398 _UIFocusRegionSearchContextSearchForFocusRegionsInEnvironment + 564 (_UIFocusRegion.m:140) 38 UIKitCore 0x19db1d244 -[_UIFocusRegionContainerProxy _searchForFocusRegionsInContext:] + 140 (_UIFocusRegionContainerProxy.m:184) 39 UIKitCore 0x19db28498 -[_UIFocusMapSnapshot addRegionsInContainer:] + 2720 (_UIFocusMapSnapshot.m:531) 40 UIKitCore 0x19d132e08 -[_UIFocusMapSnapshot _capture] + 424 (_UIFocusMapSnapshot.m:403) 41 UIKitCore 0x19db2675c -[_UIFocusMapSnapshot _initWithSnapshotter:mapArea:searchArea:] + 476 (_UIFocusMapSnapshot.m:171) 42 UIKitCore 0x19d130dcc -[_UIFocusMapSnapshotter captureSnapshot] + 192 (_UIFocusMapSnapshotter.m:137) 43 UIKitCore 0x19db2045c -[_UIFocusMap _inferredDefaultFocusItemInEnvironment:] + 136 (_UIFocusMap.m:168) 44 UIKitCore 0x19daffd2c -[_UIFocusEnvironmentPreferenceEnumerationContext _inferPreferencesForEnvironment:] + 140 (_UIFocusEnvironmentPreferenceEnumerator.m:313) 45 UIKitCore 0x19d127ab4 -[_UIFocusEnvironmentPreferenceEnumerationContext _resolvePreferredFocusEnvironments] + 104 (_UIFocusEnvironmentPreferenceEnumerator.m:250) 46 UIKitCore 0x19d127394 -[_UIFocusEnvironmentPreferenceEnumerationContext preferredEnvironments] + 36 (_UIFocusEnvironmentPreferenceEnumerator.m:184) 47 UIKitCore 0x19d126e94 _enumeratePreferredFocusEnvironments + 400 (_UIFocusEnvironmentPreferenceEnumerator.m:503)

UIKit app can not edit an event using EKEventEditViewController in iOS 27 Betas. The Done tick button at the top does not work after editing an event. Also does not work if EKEventViewController is first used to display the event. Then the "Edit" tapped to display the EKEventEditViewController. Anyone else seeing this?

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 ?

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?

previously, setting accessoryImage would display the image on the far right. Now, it appears right next to the detailText, and the image is extremely small. I am already using the latest beta, but the problem still exists.

I am not sure if this is an iOS 27 beta bug or if I should be able to see the accept/deny/'maybe' UI when using the EKEventViewController in my app.

Hey All! Curious if others are seeing this where UIAlertController style action sheets (and to some extent Alert type) in iPad OS 27.0 B1 seem to be very buggy. By that i mean if you have an action sheet that has 20 items or some, half of them are not visible until you scroll or move the mouse over them (in simulator), and when tapping on them its a hit or miss if it triggers the delegate, sometimes it triggers on the first tap (click) or sometimes it takes 2 to 3 taps (clicks) to the delegate to trigger and the actioinsheet to dismiss. On initial look it seems iOS 27.0 B1 is working just fine, seems iPad Specific. While the list of the items not showing is only for action sheets, the 'sometimes' takes 2 to 3 taps (clicks) to select and item happens in both type ActionSheet and Alert. Sometimes it takes 2 to 3 taps to tigger an alert button etc. Both the above described issues happen on both device and simulator. Ive attached a video and a sample Proj to FB22998239. Hoping one of the UIKit Engineers can take a look, thanks for everything!

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?