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

UIKit Documentation

Posts under UIKit subtopic

Post

Replies

Boosts

Views

Activity

UISearchBar’s delegate method searchBarCancelButtonClicked is not called on search cancel when search bar is integrated into the navigation bar on iOS 27
Hi, I would like to share an issue with UISearchBar's delegate method searchBarCancelButtonClicked on iOS 27 beta. On iOS 27 beta, when search bar is integrated into navigation bar’s items, tapping search cancel button doesn’t invoke UISearchBar’s delegate method searchBarCancelButtonClicked:. Steps to reproduce: Create UINavigationController with one UIViewController Set up searchController. Set searchController.searchBar.delegate, preferredSearchBarPlacement = .integratedButton, searchBarPlacementAllowsToolbarIntegration = false Tap the search button and type a query Tap the search cancel button Expected: On iOS 26, the searchBarCancelButtonClicked delegate method is called. Actual: On iOS 27 beta, the searchBarCancelButtonClicked delegate method is NOT called. On iOS 27 beta, if search bar is “stacked” or placed in the toolbar rather than the navigation bar, the bug does not reproduce. I’m using Xcode Version 27.0 beta 6 with latest available iOS 27 iPhone 17 Pro simulator (24A5423a). I reported the issue via Feedback Assistant with a minimal reproduction example and 2 videos comparing the behavior between iOS 26 and iOS 27 beta. Here is the report ID: FB24636315. Here is the minimal reproduction example: // SceneDelegate.swift import UIKit class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let windowScene = scene as? UIWindowScene else { return } let window = UIWindow(windowScene: windowScene) window.rootViewController = UINavigationController(rootViewController: ViewController()) window.makeKeyAndVisible() self.window = window } } // ViewController.swift import UIKit final class ViewController: UITableViewController { private let allItems = (1...30).map { "Item \($0)" } private var items: [String] = [] private var cancelCount = 0 override func viewDidLoad() { super.viewDidLoad() items = allItems updateTitle() let searchController = UISearchController(searchResultsController: nil) searchController.searchBar.delegate = self navigationItem.searchController = searchController navigationItem.preferredSearchBarPlacement = .integratedButton navigationItem.searchBarPlacementAllowsToolbarIntegration = false tableView.register(UITableViewCell.self, forCellReuseIdentifier: "cell") } private func updateTitle() { title = "Cancel presses: \(cancelCount)" } override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { items.count } override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { let cell = tableView.dequeueReusableCell(withIdentifier: "cell", for: indexPath) cell.contentConfiguration = { var config = cell.defaultContentConfiguration() config.text = items[indexPath.row] return config }() return cell } } extension ViewController: UISearchBarDelegate { func searchBarCancelButtonClicked(_ searchBar: UISearchBar) { print("searchBarCancelButtonClicked(_:)") cancelCount += 1 updateTitle() items = allItems tableView.reloadData() } } Thank you in advance!
Topic: UI Frameworks SubTopic: UIKit Tags:
0
2
51
1d
UIViewControllerAnimatedTransitioning bug in iOS 27
In all iOS 27 Beta 1-8 UIViewControllerAnimatedTransitioning is broken, it shows black screen when a new screen is opened. This Transitioning works correctly on previous iOS (<27) versions. Check out the attached file with example of source code. Example.txt This bug needs to be fixed ASAP, as it will affect a large number of users upon the public release of iOS 27. Visual demonstration: iOS 27 with broken transition iOS 26 works correctly
Topic: UI Frameworks SubTopic: UIKit
0
1
47
1d
UIContextualAction becomes circular on iOS 26 with Liquid Glass — can the rectangular appearance be preserved?
Hello, After building with the iOS 26 SDK, a table-view swipe action created with UIContextualAction is displayed as a circular Liquid Glass button instead of the rectangular action used on earlier iOS versions. This is how my code look UIContextualAction *action = [UIContextualAction contextualActionWithStyle:UIContextualActionStyleNormal title:@"" handler:^(UIContextualAction *action, UIView *sourceView, void (^completionHandler)(BOOL)) { completionHandler(YES); }]; action.backgroundColor = UIColor.systemPurpleColor; action.image = [UIImage imageNamed:@"my_action_image"]; UISwipeActionsConfiguration *configuration = [UISwipeActionsConfiguration configurationWithActions:@[action]]; configuration.performsFirstActionWithFullSwipe = NO; return configuration; Has anyone found a supported workaround that does not require a completely custom swipe implementation? This occurs only with the new iOS 26 appearance. The same implementation displays correctly on earlier iOS versions. Thank you.
Topic: UI Frameworks SubTopic: UIKit
0
0
13
1d
USSD calls with * and # dont work iOS
I have an application that needs to make a USSD call, but on some devices the * and # don't work on the dialer, on others it does. if let phoneNumber = ussdNumberTextfield.text { let encoded = "telprompt:\(phoneNumber)".addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed)! if let url = URL(string: encoded) { if application.canOpenURL(url){ DispatchQueue.main.async { self.application.open(url, options: [:]) { success in } } } } }
7
0
2.0k
2d
iOS 27: Scroll edge effect region sizes on UIRefreshControl presence, not its height
Summary On iOS 27 the top scroll edge effect of a UITableView is sized around the UIRefreshControl as an edge element, but appears to key on the control's presence in the scroll view rather than its current height. After endRefreshing(), the control collapses to zero height but stays attached, and the effect region keeps reserving a refresh-control's worth of space. The first row stays blurred and dimmed even though it is scrolled fully clear of the navigation bar. Environment iOS 27 (beta), iPhone Xcode 27.0.0 Beta 4 UIKit, UITableView inside a UINavigationController Reproduces with the default edge effect style and with an explicit .soft Steps to reproduce Push a UITableViewController with a UIRefreshControl onto a navigation stack. Ensure content extends under the navigation bar (default for UITableViewController). Pull to refresh and let the refresh end. Observe the first row after the refresh control has retracted. Expected Once the control retracts, the edge effect returns to its pre-pull height and the first row renders crisply. Actual The region stays roughly one refresh-control height too tall and the first row stays blurred. Row positions are unaffected — content offset and adjustedContentInset are correct. Only the extent of the effect is wrong. It corrects itself on the next push/pop. Two probes that isolate it These narrow the cause to the control's presence rather than a general staleness: Re-assigning tableView.topEdgeEffect.style after endRefreshing(), including on a later runloop turn, does NOT correct the region. The style is not what is stale. Detaching the control DOES correct it immediately: tableView.refreshControl = nil So the region is measured from the control being in the hierarchy, and is never re-measured when the control merely collapses. Secondary issue A UIRefreshControl that has been detached is inert if the same instance is re-assigned: tableView.refreshControl = nil tableView.refreshControl = sameInstance // never triggers again A freshly constructed UIRefreshControl must be assigned instead. This is not documented and looks like a second bug. Minimal sample Attached. A UITableViewController with a refresh control and a "Push" bar button that pushes and pops an empty view controller, so the incorrect region and the post-navigation correction can be compared in one run. Related FB20756572 reports the same "edge-effect extent is stale until the next navigation" behaviour for UIScrollEdgeElementContainerInteraction sizing, and notes a change in iOS 27 seed 1. That report received no reply.
1
0
593
2d
UITabBarItem badge goes behind the image during tab selection on iOS 27
Hi. I've noticed that on iOS 27 the UITabBarItem badge goes behind the tab image during tab selection. Here is a little screen recording of a simple Storyboard project with just a UITabBarController and two child UIViewControllers. On the left is iOS 26.5 and on the right is iOS 27.0 beta 6. While filled icons look more or less ok, the outline icons look the most concerning with this new behaviour. So, the question is whether this is a bug or a feature?
Topic: UI Frameworks SubTopic: UIKit Tags:
2
0
78
4d
iOS 18.4–18.x only: launch-time SIGTRAP in FBSScene _sendUpdate after UIWindow _noteOverlayInsetsDidChange
We are seeing an intermittent launch-time crash that increased sharply starting with iOS 18.4. The affected app version is 1.4.8, which uses the UISceneDelegate-based lifecycle. The primary UIWindow is created and managed for the UIWindowScene provided to the scene delegate. The OS-version distribution is very specific: iOS 18.3: no significant occurrence iOS 18.4 through the tested iOS 18.x releases: the crash occurs iOS 26: no occurrence observed This comparison uses the same application binary. Therefore, the issue appears to be specific to the iOS 18.4–18.x UIKit/FrontBoard implementation rather than a general behavior on all newer iOS versions. The crash occurs on the main thread: EXC_BREAKPOINT (SIGTRAP) 0 FrontBoardServices -[FBSScene _sendUpdate:].cold.1 + 244 1 FrontBoardServices -[FBSScene _sendUpdate:].cold.1 + 244 2 FrontBoardServices -[FBSScene _sendUpdate:] + 1156 3 FrontBoardServices -[FBSScene _updateClientSettings:] + 552 4 FrontBoardServices -[FBSScene updateClientSettingsWithBlock:] + 124 5 UIKitCore -[FBSScene(UIApp) updateUIClientSettingsWithBlock:] + 168 6 UIKitCore __39-[UIWindow _noteOverlayInsetsDidChange]_block_invoke + 248 7 UIKitCore -[_UIAfterCACommitBlock run] + 72 8 UIKitCore -[_UIAfterCACommitQueue flush] + 168 9 libdispatch.dylib _dispatch_call_block_and_release + 32 10 libdispatch.dylib _dispatch_client_callout + 16 11 libdispatch.dylib _dispatch_main_queue_drain.cold.5 + 812 12 libdispatch.dylib _dispatch_main_queue_drain + 180 13 libdispatch.dylib _dispatch_main_queue_callback_4CF + 44 14 CoreFoundation __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 15 CoreFoundation __CFRunLoopRun + 1980 16 CoreFoundation CFRunLoopRunSpecific + 572 17 GraphicsServices GSEventRunModal + 168 18 UIKitCore -[UIApplication _run] + 816 19 UIKitCore UIApplicationMain + 336 Another observed variant contains: -[FBSScene _sendUpdate:].cold.1 + 244 Some reports continue through: _UIApplicationFlushCATransaction _UIUpdateSequenceRun while others continue through the main dispatch queue. These reports appear to belong to the same crash family because they share the following path: UIWindow _noteOverlayInsetsDidChange → FBSScene updateUIClientSettingsWithBlock: → FBSScene _updateClientSettings: → FBSScene _sendUpdate: → SIGTRAP The crash occurs during cold launch, immediately after the root tab bar controller begins its first appearance. In affected launches, the last application-side lifecycle marker we observe is: MSKMainTabBarViewController.viewWillAppear(_:) The process then terminates while UIKit is flushing the first appearance-related Core Animation transaction. No later application-side lifecycle marker is observed before termination. We are treating viewWillAppear(_:) only as the last observable application-side marker. We do not assume that it directly causes the crash, because the failing UIWindow client-settings update is deferred until after the Core Animation commit. There are no application frames in the crashing portion of the stack, and the app does not call any private API. The affected app version has already adopted the UISceneDelegate lifecycle, so this does not appear to be caused by the legacy UIApplicationDelegate-only compatibility lifecycle. We have also observed the same FBSScene update path during a normal, non-crashing launch. The fatal reports differ in that FrontBoardServices triggers SIGTRAP inside _sendUpdate: or its compiler-generated cold path. Because the client-settings update is deferred, the crash report does not identify which UIWindow operation, overlay-insets change, or FBSScene client setting originally produced the rejected update. Has anyone encountered this exact FBSScene / _noteOverlayInsetsDidChange crash specifically on iOS 18.4–18.x? In particular: Is this a known UIKit or FrontBoardServices regression introduced in iOS 18.4? Was this behavior changed or fixed in iOS 26? Which UIWindow or FBSScene client setting can cause this internal assertion? Is there a supported way to identify the UIWindow responsible for the rejected update? Are there known launch-time restrictions involving multiple UIWindows, key-window transitions, overlay insets, status-bar updates, or first-appearance transactions? Is there a recommended diagnostic profile, breakpoint, or logging option for capturing the original producer of the deferred update?
Topic: UI Frameworks SubTopic: UIKit
0
0
73
4d
Display HDR images for PhotoKit assets
In my app I get a UIImage for a PHAsset via PHImageManager.requestImage(for:targetSize:contentMode:options:resultHandler:). I directly display that image in a UIImageView that has preferredImageDynamicRange set to .high. The problem is I do not see the high dynamic range. I see the HDRDemo23 sample code uses PhotosPicker to get a UIImage from Data through UIImageReader whose config enables prefersHighDynamicRange. Is there a way to support HDR when using the Photos APIs to request display images? And is there support for PHLivePhoto displayed in PHLivePhotoView retrieved via PHImageManager.requestLivePhoto?
5
1
2k
6d
iOS 27: print(to:) silently drops every job after the first
The problem On iOS 27, UIPrintInteractionController.print(to:completionHandler:) works on its first call in a process. Every subsequent call is accepted (print(to:) returns true and printInteractionControllerWillStartJob fires), but the completion handler is never invoked: nothing prints, didFinishJob never fires, no error is produced, and no job appears in Print Center. I expected each call to submit an independent job and invoke its completion handler, as it does on iOS 26 and earlier with the identical binary. Steps to reproduce Build an app that prints without the print panel, using a retained UIPrinter from UIPrinterPickerController. Submit a job: let controller = UIPrintInteractionController.shared let info = UIPrintInfo(dictionary: nil) info.outputType = .general info.jobName = "job-\(n)" controller.printInfo = info controller.printingItem = pdfData // valid PDF, canPrint(data) == true controller.delegate = self let started = controller.print(to: savedPrinter) { _, completed, error in print("completion", completed, String(describing: error)) } print("started", started) First job: started == true, both willStartJob and didFinishJob fire, the completion handler runs with completed == true, and the page prints. Submit a second job the same way, same process. started == true and willStartJob fires with printInfo.printerID populated and printPaper negotiated to the same values as the successful job. Then nothing. No didFinishJob, no completion handler, no error, no page, nothing in Print Center. A third job: print(to:) returns false synchronously, since the shared controller still considers job two in flight. System information iPad, iPadOS 27.0 developer beta 6 Built against iOS 26.2 SDK (Xcode 26.2). Same binary works on iOS 26. Reproduced on two unrelated printers: Brother QL-820NWB and Canon MF420 Series. Content is a small PDF (~11 to 13 KB); canPrintData: returns true. Troubleshooting tried Restarted the iPad and reinstalled the app. Each buys exactly one successful print before the failure returns. Compared observable state between the working and hung jobs. Identical in every respect. During a hang, printed the same content to the same printer from Files via the share sheet. Worked normally, including on repeat. Paused in the debugger during the hang. No blocked thread; no PrintKit frame, XPC wait, or semaphore anywhere in bt all. Called contactPrinter before each job on the retained printer. Returned true quickly, and the job still hung. Implemented printInteractionControllerParentViewController(_:) in case a presentation context was missing. UIKit never calls it on this path. Workaround Creating a new UIPrintInteractionController per job resolves it completely. A long-lived instance the app creates itself fails exactly like .shared does, so the issue is reuse of a controller that has already run a job, not the shared singleton specifically. Is per-job instantiation the supported pattern? The docs say the shared instance "represents a print job" but don't state whether a controller may be reused for a second job, and every sample I can find uses sharedPrintController with the present… methods rather than print(to:).
2
4
695
1w
UIKit AppIntentSceneDelegate: connectionOptions.appIntent is nil on cold launch (iOS Beta) -
Hi everyone, I am currently implementing the new Search API in a UIKit app using @AppIntent(schema: .system.search), ShowInAppSearchResultsIntent, and UISceneAppIntent. While testing on the iOS beta, I’ve hit a significant lifecycle disparity between how UIKit and SwiftUI apps process system intents during a process-cold launch. According to the documentation for UIScene.ConnectionOptions.appIntent, this property should contain the intent that triggered the scene creation. However, in a UIKit app with a single-window scene lifecycle, this isn't happening consistently. Here is the behaviour breakdown I am seeing: Cold Launch (Siri/Search → App completely closed) SwiftUI App: Works as documented. The intent is present in connection options. scene(_:willPerformAppIntent:) is not called. UIKit App (with AppIntentSceneDelegate): The connectionOptions.appIntent property is completely nil inside scene(:willConnectTo:options:). Instead, the intent is delivered late via scene(:willPerformAppIntent:) right after scene connection completes. Warm Launch (Siri/Search → App already suspended in memory) Both SwiftUI and UIKit: Behave identically. The intent is delivered directly to scene(_:willPerformAppIntent:). The Problem Because of this gap, there is no unified way to handle a process-cold launch under UIKit. There is no LaunchOptionsKey available to identify that an App Intent initiated the launch, and the missing connection option forces us to bifurcate our routing logic. I have already filed a bug report via Feedback Assistant: FB24513291 and attached a minimal reproducible sample project. Has anyone else run into this specific AppIntentSceneDelegate race condition on the iOS beta? If so, what architecture or unified pattern are you using to normalize the lifecycle routing between cold and warm launches in UIKit? Any insights or clean workaround ideas would be highly appreciated!
0
0
261
1w
Third-party keyboards get an extra 17pt gap at the top after switching apps on iOS 27 beta.
Feedback submitted: FB24460699 The sample projects are attached to the feedback report. Environment:iOS27 Beta6; iPhone 17Pro Problem:I have encountered a consistently reproducible third-party custom keyboard layout issue in iOS 27.0 beta 1 through beta 6. The custom keyboard initially appears correctly. If I switch apps while the text input remains focused and the keyboard remains visible, and then return to the host app, the system adds a 17-point area above the custom keyboard extension. Steps to reproduce Install and enable a third-party custom keyboard. Switch to the sample custom keyboard and open the host app so that the text editor in the center receives focus. Do not dismiss the keyboard or remove focus from the editor. Return to the Home Screen or switch to another app. Return to the host app. A new blank area now appears above the custom keyboard content. I tested both a system-determined extension view height and an extension view explicitly constrained to 180 points. Both configurations produce exactly the same change. After the foreground transition, the following extension-side values remain unchanged: view.bounds inputView.bounds extension.window.bounds view.safeAreaInsets, which remains {0, 0, 0, 0} The requested 180-point extension height Only the system keyboard frame received by the host app increases by 17 points. I also drew a rounded pink boundary inside the transparent extension root view. When the issue occurs, the new area appears outside that boundary. I tested several third-party keyboards and reproduced the issue with all of them. This suggests that the behavior is caused by iOS rather than by my app. Questions On iOS 27, is it expected behavior for a custom keyboard to gain a 17pt top area after its host app returns from the background? If this is a system issue, is there any workaround that can be used until it is fixed?
1
1
420
1w
Cells resize during interactive pop gesture when preservesSuperviewLayoutMargins = true
When using the interactive swipe gesture to back in a navigation controller, cells in a collection view resize during the transition. It does not happen when using the back button. This can lead to very strange glitches. Most of the time it looks like the leading side gets bigger and smaller when animating. The trigger seems to be preservesSuperviewLayoutMargins = true. Sample project: https://gist.github.com/nicoreese/32080748babee9d10cfd151d4ad94622 Video of the issue as seen in the Health app: https://mastodon.social/@nicoreese/117138839377696127 Filed under: FB24461877 There's a similar issue with UIStackViews: FB22340191 Looks like both issues were introduced with iOS 26. Does anyone know a fix for this. I suspect this won't get fixed very fast at the system level.
Topic: UI Frameworks SubTopic: UIKit Tags:
0
0
85
1w
Editable text disappears during iOS 27 grammar checking
I’m seeing in issue on iOS 27 with TextKit 1 backed UITextViews where grammar checking makes part of the text disappear. For TextKit 2 views, there's a blue underline and a shimmer effect that's applied to the text when a grammatical error is detected. For TextKit 1 views the underline appears but instead of the shimmer effect, the text just disappears. Steps to reproduce: Create a UITextView using TextKit 1: UITextView(usingTextLayoutManager: false) Fill it with a very long document (makes the bug easier to reproduce). Type a phrase that triggers a grammar correction, such as “self aware”. Wait for the system to suggest “self-aware”. The blue underline appears but the two words disappear. I've found a partial workaround by overriding NSLayoutManager.drawGlyphsForGlyphRange and calling CGContextSetFillColorWithColor on the affected range, but this isn't great. Filed as FB24319258. Has anyone else encountered this on the iOS 27 betas? Would appreciate any guidance.
3
0
514
2w
Is it possible to intercept hardware (Bluetooth) keyboard events in an iOS Custom Keyboard Extension?
I'm developing an iOS custom keyboard extension and need to intercept external Bluetooth hardware keystrokes in the background. Can I capture these events within a UIInputViewController (e.g., using UIKeyCommand), or does iOS strictly route them directly to the host app? Are there any specific APIs or workarounds for this, or is it completely blocked by Apple's sandboxing policies?
1
0
416
2w
VNRecognizeTextRequest does not recognise single letters
I use VNRecognizeTextRequest to recognise a series of letters drawn by hand in the app. When I draw a few letters, it usually works fine. is recognised as "LV" But if I draw a single letter: or in most cases, I get zero observation, even using recognitionLevel3. But this was recognized as "V": It is apparently not a question of how well drawn letters, as even this was recognised as "LI": However, this one was not I have even tried to add custom words, to no avail: request.customWords = ["I", "V", "L"] General observation is that single letters are rarely or never recognised, dual letters may be recognised ; 3 letters are systematically recognised. But, I have now increased the brushWidth, and it works much better, even with single letter: What tuning of VNRecognizeTextRequest do I miss ?
5
0
178
2w
UISegmentedControl backgroundColor not applied on some iOS 26 devices
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
1
0
339
2w
Rotating iPhone to landscape mode causes previously hidden navigation bar of detail view to appear but navigation bar of sidebar to remain hidden
My app has a split view with a root view and a detail view, both of which are inside their own navigation view controller. The navigation bar of the detail view can be hidden to allow the user to stay more focused on the content. The problem is that when the navigation bar of the content view is hidden in portrait mode and the iPhone is rotated to landscape mode, the navigation bar of the content view becomes visible automatically and the sidebar appears on the left side, but the navigation bar of the sidebar is hidden. Is it expected that the navigation bar becomes visible automatically when rotating the device? Why is the navigation bar of the sidebar hidden? Is this related to hiding the navigation bar of the content view and why does this happen? What am I supposed to do so that the navigation bar of the sidebar remains visible at all times? For comparison the two cases: After rotation when navigation bar of content view was visible: After rotation when navigation bar of content view was hidden: import UIKit class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { window = UIWindow(windowScene: scene as! UIWindowScene) window!.rootViewController = SplitViewController() window!.makeKeyAndVisible() } } class SplitViewController: UISplitViewController, UISplitViewControllerDelegate { var detailNavigationViewController: UINavigationController! init() { super.init(nibName: nil, bundle: nil) detailNavigationViewController = UINavigationController(rootViewController: DetailViewController()) viewControllers = [UINavigationController(rootViewController: RootViewController())] } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } func showDetail() { showDetailViewController(detailNavigationViewController, sender: nil) } } class RootViewController: UIViewController { override func loadView() { navigationItem.title = "Root" navigationItem.rightBarButtonItem = UIBarButtonItem(systemItem: .add) let button = UIButton(primaryAction: UIAction(handler: { [self] _ in (splitViewController as! SplitViewController).showDetail() })) button.setTitle("Show detail", for: .normal) button.translatesAutoresizingMaskIntoConstraints = false view = UIView() view.layer.backgroundColor = UIColor(white: 0.9, alpha: 1).cgColor view.addSubview(button) NSLayoutConstraint.activate([NSLayoutConstraint(item: button, attribute: .centerX, relatedBy: .equal, toItem: view, attribute: .centerX, multiplier: 1, constant: 0), NSLayoutConstraint(item: button, attribute: .centerY, relatedBy: .equal, toItem: view, attribute: .centerY, multiplier: 1, constant: 0)]) } } class DetailViewController: UIViewController { override func loadView() { navigationItem.title = "Detail" navigationItem.leftBarButtonItem = UIBarButtonItem(image: UIImage(systemName: "sidebar.leading"), primaryAction: UIAction(handler: { _ in UIView.animate(withDuration: 0.3) { [self] in self.splitViewController!.preferredDisplayMode = .oneOverSecondary } })) navigationItem.rightBarButtonItem = UIBarButtonItem(systemItem: .add) let button = UIButton(primaryAction: UIAction(handler: { [self] _ in navigationController!.setNavigationBarHidden(!navigationController!.isNavigationBarHidden, animated: true) })) button.setTitle("Toggle navigation bar", for: .normal) button.translatesAutoresizingMaskIntoConstraints = false view = UIView() view.addSubview(button) NSLayoutConstraint.activate([NSLayoutConstraint(item: button, attribute: .centerX, relatedBy: .equal, toItem: view, attribute: .centerX, multiplier: 1, constant: 0), NSLayoutConstraint(item: button, attribute: .centerY, relatedBy: .equal, toItem: view, attribute: .centerY, multiplier: 1, constant: 0)]) } } I created FB24413608.
Topic: UI Frameworks SubTopic: UIKit Tags:
2
0
144
2w
Unexpected lifecycle callback sequence when pressing the top button to put iPad to sleep on iPadOS 27 beta
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.
7
2
728
2w
Invalid parameter not satisfying: parentEnvironment != nil
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)
19
4
2.7k
2w
UISearchBar’s delegate method searchBarCancelButtonClicked is not called on search cancel when search bar is integrated into the navigation bar on iOS 27
Hi, I would like to share an issue with UISearchBar's delegate method searchBarCancelButtonClicked on iOS 27 beta. On iOS 27 beta, when search bar is integrated into navigation bar’s items, tapping search cancel button doesn’t invoke UISearchBar’s delegate method searchBarCancelButtonClicked:. Steps to reproduce: Create UINavigationController with one UIViewController Set up searchController. Set searchController.searchBar.delegate, preferredSearchBarPlacement = .integratedButton, searchBarPlacementAllowsToolbarIntegration = false Tap the search button and type a query Tap the search cancel button Expected: On iOS 26, the searchBarCancelButtonClicked delegate method is called. Actual: On iOS 27 beta, the searchBarCancelButtonClicked delegate method is NOT called. On iOS 27 beta, if search bar is “stacked” or placed in the toolbar rather than the navigation bar, the bug does not reproduce. I’m using Xcode Version 27.0 beta 6 with latest available iOS 27 iPhone 17 Pro simulator (24A5423a). I reported the issue via Feedback Assistant with a minimal reproduction example and 2 videos comparing the behavior between iOS 26 and iOS 27 beta. Here is the report ID: FB24636315. Here is the minimal reproduction example: // SceneDelegate.swift import UIKit class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { guard let windowScene = scene as? UIWindowScene else { return } let window = UIWindow(windowScene: windowScene) window.rootViewController = UINavigationController(rootViewController: ViewController()) window.makeKeyAndVisible() self.window = window } } // ViewController.swift import UIKit final class ViewController: UITableViewController { private let allItems = (1...30).map { "Item \($0)" } private var items: [String] = [] private var cancelCount = 0 override func viewDidLoad() { super.viewDidLoad() items = allItems updateTitle() let searchController = UISearchController(searchResultsController: nil) searchController.searchBar.delegate = self navigationItem.searchController = searchController navigationItem.preferredSearchBarPlacement = .integratedButton navigationItem.searchBarPlacementAllowsToolbarIntegration = false tableView.register(UITableViewCell.self, forCellReuseIdentifier: "cell") } private func updateTitle() { title = "Cancel presses: \(cancelCount)" } override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { items.count } override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { let cell = tableView.dequeueReusableCell(withIdentifier: "cell", for: indexPath) cell.contentConfiguration = { var config = cell.defaultContentConfiguration() config.text = items[indexPath.row] return config }() return cell } } extension ViewController: UISearchBarDelegate { func searchBarCancelButtonClicked(_ searchBar: UISearchBar) { print("searchBarCancelButtonClicked(_:)") cancelCount += 1 updateTitle() items = allItems tableView.reloadData() } } Thank you in advance!
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
0
Boosts
2
Views
51
Activity
1d
UIViewControllerAnimatedTransitioning bug in iOS 27
In all iOS 27 Beta 1-8 UIViewControllerAnimatedTransitioning is broken, it shows black screen when a new screen is opened. This Transitioning works correctly on previous iOS (<27) versions. Check out the attached file with example of source code. Example.txt This bug needs to be fixed ASAP, as it will affect a large number of users upon the public release of iOS 27. Visual demonstration: iOS 27 with broken transition iOS 26 works correctly
Topic: UI Frameworks SubTopic: UIKit
Replies
0
Boosts
1
Views
47
Activity
1d
UIContextualAction becomes circular on iOS 26 with Liquid Glass — can the rectangular appearance be preserved?
Hello, After building with the iOS 26 SDK, a table-view swipe action created with UIContextualAction is displayed as a circular Liquid Glass button instead of the rectangular action used on earlier iOS versions. This is how my code look UIContextualAction *action = [UIContextualAction contextualActionWithStyle:UIContextualActionStyleNormal title:@"" handler:^(UIContextualAction *action, UIView *sourceView, void (^completionHandler)(BOOL)) { completionHandler(YES); }]; action.backgroundColor = UIColor.systemPurpleColor; action.image = [UIImage imageNamed:@"my_action_image"]; UISwipeActionsConfiguration *configuration = [UISwipeActionsConfiguration configurationWithActions:@[action]]; configuration.performsFirstActionWithFullSwipe = NO; return configuration; Has anyone found a supported workaround that does not require a completely custom swipe implementation? This occurs only with the new iOS 26 appearance. The same implementation displays correctly on earlier iOS versions. Thank you.
Topic: UI Frameworks SubTopic: UIKit
Replies
0
Boosts
0
Views
13
Activity
1d
USSD calls with * and # dont work iOS
I have an application that needs to make a USSD call, but on some devices the * and # don't work on the dialer, on others it does. if let phoneNumber = ussdNumberTextfield.text { let encoded = "telprompt:\(phoneNumber)".addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed)! if let url = URL(string: encoded) { if application.canOpenURL(url){ DispatchQueue.main.async { self.application.open(url, options: [:]) { success in } } } } }
Replies
7
Boosts
0
Views
2.0k
Activity
2d
iOS 27: Scroll edge effect region sizes on UIRefreshControl presence, not its height
Summary On iOS 27 the top scroll edge effect of a UITableView is sized around the UIRefreshControl as an edge element, but appears to key on the control's presence in the scroll view rather than its current height. After endRefreshing(), the control collapses to zero height but stays attached, and the effect region keeps reserving a refresh-control's worth of space. The first row stays blurred and dimmed even though it is scrolled fully clear of the navigation bar. Environment iOS 27 (beta), iPhone Xcode 27.0.0 Beta 4 UIKit, UITableView inside a UINavigationController Reproduces with the default edge effect style and with an explicit .soft Steps to reproduce Push a UITableViewController with a UIRefreshControl onto a navigation stack. Ensure content extends under the navigation bar (default for UITableViewController). Pull to refresh and let the refresh end. Observe the first row after the refresh control has retracted. Expected Once the control retracts, the edge effect returns to its pre-pull height and the first row renders crisply. Actual The region stays roughly one refresh-control height too tall and the first row stays blurred. Row positions are unaffected — content offset and adjustedContentInset are correct. Only the extent of the effect is wrong. It corrects itself on the next push/pop. Two probes that isolate it These narrow the cause to the control's presence rather than a general staleness: Re-assigning tableView.topEdgeEffect.style after endRefreshing(), including on a later runloop turn, does NOT correct the region. The style is not what is stale. Detaching the control DOES correct it immediately: tableView.refreshControl = nil So the region is measured from the control being in the hierarchy, and is never re-measured when the control merely collapses. Secondary issue A UIRefreshControl that has been detached is inert if the same instance is re-assigned: tableView.refreshControl = nil tableView.refreshControl = sameInstance // never triggers again A freshly constructed UIRefreshControl must be assigned instead. This is not documented and looks like a second bug. Minimal sample Attached. A UITableViewController with a refresh control and a "Push" bar button that pushes and pops an empty view controller, so the incorrect region and the post-navigation correction can be compared in one run. Related FB20756572 reports the same "edge-effect extent is stale until the next navigation" behaviour for UIScrollEdgeElementContainerInteraction sizing, and notes a change in iOS 27 seed 1. That report received no reply.
Replies
1
Boosts
0
Views
593
Activity
2d
UITabBarItem badge goes behind the image during tab selection on iOS 27
Hi. I've noticed that on iOS 27 the UITabBarItem badge goes behind the tab image during tab selection. Here is a little screen recording of a simple Storyboard project with just a UITabBarController and two child UIViewControllers. On the left is iOS 26.5 and on the right is iOS 27.0 beta 6. While filled icons look more or less ok, the outline icons look the most concerning with this new behaviour. So, the question is whether this is a bug or a feature?
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
2
Boosts
0
Views
78
Activity
4d
iOS 18.4–18.x only: launch-time SIGTRAP in FBSScene _sendUpdate after UIWindow _noteOverlayInsetsDidChange
We are seeing an intermittent launch-time crash that increased sharply starting with iOS 18.4. The affected app version is 1.4.8, which uses the UISceneDelegate-based lifecycle. The primary UIWindow is created and managed for the UIWindowScene provided to the scene delegate. The OS-version distribution is very specific: iOS 18.3: no significant occurrence iOS 18.4 through the tested iOS 18.x releases: the crash occurs iOS 26: no occurrence observed This comparison uses the same application binary. Therefore, the issue appears to be specific to the iOS 18.4–18.x UIKit/FrontBoard implementation rather than a general behavior on all newer iOS versions. The crash occurs on the main thread: EXC_BREAKPOINT (SIGTRAP) 0 FrontBoardServices -[FBSScene _sendUpdate:].cold.1 + 244 1 FrontBoardServices -[FBSScene _sendUpdate:].cold.1 + 244 2 FrontBoardServices -[FBSScene _sendUpdate:] + 1156 3 FrontBoardServices -[FBSScene _updateClientSettings:] + 552 4 FrontBoardServices -[FBSScene updateClientSettingsWithBlock:] + 124 5 UIKitCore -[FBSScene(UIApp) updateUIClientSettingsWithBlock:] + 168 6 UIKitCore __39-[UIWindow _noteOverlayInsetsDidChange]_block_invoke + 248 7 UIKitCore -[_UIAfterCACommitBlock run] + 72 8 UIKitCore -[_UIAfterCACommitQueue flush] + 168 9 libdispatch.dylib _dispatch_call_block_and_release + 32 10 libdispatch.dylib _dispatch_client_callout + 16 11 libdispatch.dylib _dispatch_main_queue_drain.cold.5 + 812 12 libdispatch.dylib _dispatch_main_queue_drain + 180 13 libdispatch.dylib _dispatch_main_queue_callback_4CF + 44 14 CoreFoundation __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 15 CoreFoundation __CFRunLoopRun + 1980 16 CoreFoundation CFRunLoopRunSpecific + 572 17 GraphicsServices GSEventRunModal + 168 18 UIKitCore -[UIApplication _run] + 816 19 UIKitCore UIApplicationMain + 336 Another observed variant contains: -[FBSScene _sendUpdate:].cold.1 + 244 Some reports continue through: _UIApplicationFlushCATransaction _UIUpdateSequenceRun while others continue through the main dispatch queue. These reports appear to belong to the same crash family because they share the following path: UIWindow _noteOverlayInsetsDidChange → FBSScene updateUIClientSettingsWithBlock: → FBSScene _updateClientSettings: → FBSScene _sendUpdate: → SIGTRAP The crash occurs during cold launch, immediately after the root tab bar controller begins its first appearance. In affected launches, the last application-side lifecycle marker we observe is: MSKMainTabBarViewController.viewWillAppear(_:) The process then terminates while UIKit is flushing the first appearance-related Core Animation transaction. No later application-side lifecycle marker is observed before termination. We are treating viewWillAppear(_:) only as the last observable application-side marker. We do not assume that it directly causes the crash, because the failing UIWindow client-settings update is deferred until after the Core Animation commit. There are no application frames in the crashing portion of the stack, and the app does not call any private API. The affected app version has already adopted the UISceneDelegate lifecycle, so this does not appear to be caused by the legacy UIApplicationDelegate-only compatibility lifecycle. We have also observed the same FBSScene update path during a normal, non-crashing launch. The fatal reports differ in that FrontBoardServices triggers SIGTRAP inside _sendUpdate: or its compiler-generated cold path. Because the client-settings update is deferred, the crash report does not identify which UIWindow operation, overlay-insets change, or FBSScene client setting originally produced the rejected update. Has anyone encountered this exact FBSScene / _noteOverlayInsetsDidChange crash specifically on iOS 18.4–18.x? In particular: Is this a known UIKit or FrontBoardServices regression introduced in iOS 18.4? Was this behavior changed or fixed in iOS 26? Which UIWindow or FBSScene client setting can cause this internal assertion? Is there a supported way to identify the UIWindow responsible for the rejected update? Are there known launch-time restrictions involving multiple UIWindows, key-window transitions, overlay insets, status-bar updates, or first-appearance transactions? Is there a recommended diagnostic profile, breakpoint, or logging option for capturing the original producer of the deferred update?
Topic: UI Frameworks SubTopic: UIKit
Replies
0
Boosts
0
Views
73
Activity
4d
Display HDR images for PhotoKit assets
In my app I get a UIImage for a PHAsset via PHImageManager.requestImage(for:targetSize:contentMode:options:resultHandler:). I directly display that image in a UIImageView that has preferredImageDynamicRange set to .high. The problem is I do not see the high dynamic range. I see the HDRDemo23 sample code uses PhotosPicker to get a UIImage from Data through UIImageReader whose config enables prefersHighDynamicRange. Is there a way to support HDR when using the Photos APIs to request display images? And is there support for PHLivePhoto displayed in PHLivePhotoView retrieved via PHImageManager.requestLivePhoto?
Replies
5
Boosts
1
Views
2k
Activity
6d
iOS 27: print(to:) silently drops every job after the first
The problem On iOS 27, UIPrintInteractionController.print(to:completionHandler:) works on its first call in a process. Every subsequent call is accepted (print(to:) returns true and printInteractionControllerWillStartJob fires), but the completion handler is never invoked: nothing prints, didFinishJob never fires, no error is produced, and no job appears in Print Center. I expected each call to submit an independent job and invoke its completion handler, as it does on iOS 26 and earlier with the identical binary. Steps to reproduce Build an app that prints without the print panel, using a retained UIPrinter from UIPrinterPickerController. Submit a job: let controller = UIPrintInteractionController.shared let info = UIPrintInfo(dictionary: nil) info.outputType = .general info.jobName = "job-\(n)" controller.printInfo = info controller.printingItem = pdfData // valid PDF, canPrint(data) == true controller.delegate = self let started = controller.print(to: savedPrinter) { _, completed, error in print("completion", completed, String(describing: error)) } print("started", started) First job: started == true, both willStartJob and didFinishJob fire, the completion handler runs with completed == true, and the page prints. Submit a second job the same way, same process. started == true and willStartJob fires with printInfo.printerID populated and printPaper negotiated to the same values as the successful job. Then nothing. No didFinishJob, no completion handler, no error, no page, nothing in Print Center. A third job: print(to:) returns false synchronously, since the shared controller still considers job two in flight. System information iPad, iPadOS 27.0 developer beta 6 Built against iOS 26.2 SDK (Xcode 26.2). Same binary works on iOS 26. Reproduced on two unrelated printers: Brother QL-820NWB and Canon MF420 Series. Content is a small PDF (~11 to 13 KB); canPrintData: returns true. Troubleshooting tried Restarted the iPad and reinstalled the app. Each buys exactly one successful print before the failure returns. Compared observable state between the working and hung jobs. Identical in every respect. During a hang, printed the same content to the same printer from Files via the share sheet. Worked normally, including on repeat. Paused in the debugger during the hang. No blocked thread; no PrintKit frame, XPC wait, or semaphore anywhere in bt all. Called contactPrinter before each job on the retained printer. Returned true quickly, and the job still hung. Implemented printInteractionControllerParentViewController(_:) in case a presentation context was missing. UIKit never calls it on this path. Workaround Creating a new UIPrintInteractionController per job resolves it completely. A long-lived instance the app creates itself fails exactly like .shared does, so the issue is reuse of a controller that has already run a job, not the shared singleton specifically. Is per-job instantiation the supported pattern? The docs say the shared instance "represents a print job" but don't state whether a controller may be reused for a second job, and every sample I can find uses sharedPrintController with the present… methods rather than print(to:).
Replies
2
Boosts
4
Views
695
Activity
1w
UIKit AppIntentSceneDelegate: connectionOptions.appIntent is nil on cold launch (iOS Beta) -
Hi everyone, I am currently implementing the new Search API in a UIKit app using @AppIntent(schema: .system.search), ShowInAppSearchResultsIntent, and UISceneAppIntent. While testing on the iOS beta, I’ve hit a significant lifecycle disparity between how UIKit and SwiftUI apps process system intents during a process-cold launch. According to the documentation for UIScene.ConnectionOptions.appIntent, this property should contain the intent that triggered the scene creation. However, in a UIKit app with a single-window scene lifecycle, this isn't happening consistently. Here is the behaviour breakdown I am seeing: Cold Launch (Siri/Search → App completely closed) SwiftUI App: Works as documented. The intent is present in connection options. scene(_:willPerformAppIntent:) is not called. UIKit App (with AppIntentSceneDelegate): The connectionOptions.appIntent property is completely nil inside scene(:willConnectTo:options:). Instead, the intent is delivered late via scene(:willPerformAppIntent:) right after scene connection completes. Warm Launch (Siri/Search → App already suspended in memory) Both SwiftUI and UIKit: Behave identically. The intent is delivered directly to scene(_:willPerformAppIntent:). The Problem Because of this gap, there is no unified way to handle a process-cold launch under UIKit. There is no LaunchOptionsKey available to identify that an App Intent initiated the launch, and the missing connection option forces us to bifurcate our routing logic. I have already filed a bug report via Feedback Assistant: FB24513291 and attached a minimal reproducible sample project. Has anyone else run into this specific AppIntentSceneDelegate race condition on the iOS beta? If so, what architecture or unified pattern are you using to normalize the lifecycle routing between cold and warm launches in UIKit? Any insights or clean workaround ideas would be highly appreciated!
Replies
0
Boosts
0
Views
261
Activity
1w
Inserting a SF Symbol in a textField or a Label, as text
In UIKit, Swift, I would need to insert a SF Symbol into a textField or a label. The symbol shows correctly in Xcode (in a string in code or in IB). But at runtime, the symbol is not found and replaced in the TextField by the unfound symbol: Is there a way to achieve this and display the symbol as a pure string, like we do with emoji ?
Replies
7
Boosts
0
Views
743
Activity
1w
Third-party keyboards get an extra 17pt gap at the top after switching apps on iOS 27 beta.
Feedback submitted: FB24460699 The sample projects are attached to the feedback report. Environment:iOS27 Beta6; iPhone 17Pro Problem:I have encountered a consistently reproducible third-party custom keyboard layout issue in iOS 27.0 beta 1 through beta 6. The custom keyboard initially appears correctly. If I switch apps while the text input remains focused and the keyboard remains visible, and then return to the host app, the system adds a 17-point area above the custom keyboard extension. Steps to reproduce Install and enable a third-party custom keyboard. Switch to the sample custom keyboard and open the host app so that the text editor in the center receives focus. Do not dismiss the keyboard or remove focus from the editor. Return to the Home Screen or switch to another app. Return to the host app. A new blank area now appears above the custom keyboard content. I tested both a system-determined extension view height and an extension view explicitly constrained to 180 points. Both configurations produce exactly the same change. After the foreground transition, the following extension-side values remain unchanged: view.bounds inputView.bounds extension.window.bounds view.safeAreaInsets, which remains {0, 0, 0, 0} The requested 180-point extension height Only the system keyboard frame received by the host app increases by 17 points. I also drew a rounded pink boundary inside the transparent extension root view. When the issue occurs, the new area appears outside that boundary. I tested several third-party keyboards and reproduced the issue with all of them. This suggests that the behavior is caused by iOS rather than by my app. Questions On iOS 27, is it expected behavior for a custom keyboard to gain a 17pt top area after its host app returns from the background? If this is a system issue, is there any workaround that can be used until it is fixed?
Replies
1
Boosts
1
Views
420
Activity
1w
Cells resize during interactive pop gesture when preservesSuperviewLayoutMargins = true
When using the interactive swipe gesture to back in a navigation controller, cells in a collection view resize during the transition. It does not happen when using the back button. This can lead to very strange glitches. Most of the time it looks like the leading side gets bigger and smaller when animating. The trigger seems to be preservesSuperviewLayoutMargins = true. Sample project: https://gist.github.com/nicoreese/32080748babee9d10cfd151d4ad94622 Video of the issue as seen in the Health app: https://mastodon.social/@nicoreese/117138839377696127 Filed under: FB24461877 There's a similar issue with UIStackViews: FB22340191 Looks like both issues were introduced with iOS 26. Does anyone know a fix for this. I suspect this won't get fixed very fast at the system level.
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
0
Boosts
0
Views
85
Activity
1w
Editable text disappears during iOS 27 grammar checking
I’m seeing in issue on iOS 27 with TextKit 1 backed UITextViews where grammar checking makes part of the text disappear. For TextKit 2 views, there's a blue underline and a shimmer effect that's applied to the text when a grammatical error is detected. For TextKit 1 views the underline appears but instead of the shimmer effect, the text just disappears. Steps to reproduce: Create a UITextView using TextKit 1: UITextView(usingTextLayoutManager: false) Fill it with a very long document (makes the bug easier to reproduce). Type a phrase that triggers a grammar correction, such as “self aware”. Wait for the system to suggest “self-aware”. The blue underline appears but the two words disappear. I've found a partial workaround by overriding NSLayoutManager.drawGlyphsForGlyphRange and calling CGContextSetFillColorWithColor on the affected range, but this isn't great. Filed as FB24319258. Has anyone else encountered this on the iOS 27 betas? Would appreciate any guidance.
Replies
3
Boosts
0
Views
514
Activity
2w
Is it possible to intercept hardware (Bluetooth) keyboard events in an iOS Custom Keyboard Extension?
I'm developing an iOS custom keyboard extension and need to intercept external Bluetooth hardware keystrokes in the background. Can I capture these events within a UIInputViewController (e.g., using UIKeyCommand), or does iOS strictly route them directly to the host app? Are there any specific APIs or workarounds for this, or is it completely blocked by Apple's sandboxing policies?
Replies
1
Boosts
0
Views
416
Activity
2w
VNRecognizeTextRequest does not recognise single letters
I use VNRecognizeTextRequest to recognise a series of letters drawn by hand in the app. When I draw a few letters, it usually works fine. is recognised as "LV" But if I draw a single letter: or in most cases, I get zero observation, even using recognitionLevel3. But this was recognized as "V": It is apparently not a question of how well drawn letters, as even this was recognised as "LI": However, this one was not I have even tried to add custom words, to no avail: request.customWords = ["I", "V", "L"] General observation is that single letters are rarely or never recognised, dual letters may be recognised ; 3 letters are systematically recognised. But, I have now increased the brushWidth, and it works much better, even with single letter: What tuning of VNRecognizeTextRequest do I miss ?
Replies
5
Boosts
0
Views
178
Activity
2w
UISegmentedControl backgroundColor not applied on some iOS 26 devices
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
Replies
1
Boosts
0
Views
339
Activity
2w
Rotating iPhone to landscape mode causes previously hidden navigation bar of detail view to appear but navigation bar of sidebar to remain hidden
My app has a split view with a root view and a detail view, both of which are inside their own navigation view controller. The navigation bar of the detail view can be hidden to allow the user to stay more focused on the content. The problem is that when the navigation bar of the content view is hidden in portrait mode and the iPhone is rotated to landscape mode, the navigation bar of the content view becomes visible automatically and the sidebar appears on the left side, but the navigation bar of the sidebar is hidden. Is it expected that the navigation bar becomes visible automatically when rotating the device? Why is the navigation bar of the sidebar hidden? Is this related to hiding the navigation bar of the content view and why does this happen? What am I supposed to do so that the navigation bar of the sidebar remains visible at all times? For comparison the two cases: After rotation when navigation bar of content view was visible: After rotation when navigation bar of content view was hidden: import UIKit class SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { window = UIWindow(windowScene: scene as! UIWindowScene) window!.rootViewController = SplitViewController() window!.makeKeyAndVisible() } } class SplitViewController: UISplitViewController, UISplitViewControllerDelegate { var detailNavigationViewController: UINavigationController! init() { super.init(nibName: nil, bundle: nil) detailNavigationViewController = UINavigationController(rootViewController: DetailViewController()) viewControllers = [UINavigationController(rootViewController: RootViewController())] } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } func showDetail() { showDetailViewController(detailNavigationViewController, sender: nil) } } class RootViewController: UIViewController { override func loadView() { navigationItem.title = "Root" navigationItem.rightBarButtonItem = UIBarButtonItem(systemItem: .add) let button = UIButton(primaryAction: UIAction(handler: { [self] _ in (splitViewController as! SplitViewController).showDetail() })) button.setTitle("Show detail", for: .normal) button.translatesAutoresizingMaskIntoConstraints = false view = UIView() view.layer.backgroundColor = UIColor(white: 0.9, alpha: 1).cgColor view.addSubview(button) NSLayoutConstraint.activate([NSLayoutConstraint(item: button, attribute: .centerX, relatedBy: .equal, toItem: view, attribute: .centerX, multiplier: 1, constant: 0), NSLayoutConstraint(item: button, attribute: .centerY, relatedBy: .equal, toItem: view, attribute: .centerY, multiplier: 1, constant: 0)]) } } class DetailViewController: UIViewController { override func loadView() { navigationItem.title = "Detail" navigationItem.leftBarButtonItem = UIBarButtonItem(image: UIImage(systemName: "sidebar.leading"), primaryAction: UIAction(handler: { _ in UIView.animate(withDuration: 0.3) { [self] in self.splitViewController!.preferredDisplayMode = .oneOverSecondary } })) navigationItem.rightBarButtonItem = UIBarButtonItem(systemItem: .add) let button = UIButton(primaryAction: UIAction(handler: { [self] _ in navigationController!.setNavigationBarHidden(!navigationController!.isNavigationBarHidden, animated: true) })) button.setTitle("Toggle navigation bar", for: .normal) button.translatesAutoresizingMaskIntoConstraints = false view = UIView() view.addSubview(button) NSLayoutConstraint.activate([NSLayoutConstraint(item: button, attribute: .centerX, relatedBy: .equal, toItem: view, attribute: .centerX, multiplier: 1, constant: 0), NSLayoutConstraint(item: button, attribute: .centerY, relatedBy: .equal, toItem: view, attribute: .centerY, multiplier: 1, constant: 0)]) } } I created FB24413608.
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
2
Boosts
0
Views
144
Activity
2w
Unexpected lifecycle callback sequence when pressing the top button to put iPad to sleep on iPadOS 27 beta
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.
Replies
7
Boosts
2
Views
728
Activity
2w
Invalid parameter not satisfying: parentEnvironment != nil
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)
Replies
19
Boosts
4
Views
2.7k
Activity
2w