My App development language is only Arabic. I am using textField to Login User, whenever user long pressed, ToolTip showed up. Problem is with tool tip text it is flipped. My device language is English

After updating to Mac OS Sonoma, we have encountered compatibility issues with our iPad-designed application, specifically with the AirPrint functionality, when it is run on MacOS. The AirPrint feature stopped working properly through UIPrintInteractionController.shared. We have noticed that when we compile the application using Catalyst, the AirPrint functionality is restored and works as expected. However, this solution is not viable for us due to the restrictions associated with the frameworks we are utilizing. We are seeking alternative solutions, and any help or guidance would be highly appreciated to resolve this issue and ensure a seamless and uninterrupted user experience in our application. STEPS TO REPRODUCE Create an app for ipad with just a button and this code var str = "TEST" let printInfo = UIPrintInfo(dictionary:nil) printInfo.outputType = .general printInfo.jobName = "Report" printInfo.orientation = .portrait let printController = UIPrintInteractionController.shared printController.printInfo = printInfo printController.showsNumberOfCopies = false printController.showsPageRange = false printController.showsNumberOfCopies = false let formatter = UIMarkupTextPrintFormatter(markupText: str) formatter.contentInsets = UIEdgeInsets(top: 72, left: 72, bottom: 72, right: 72) printController.printFormatter = formatter printController.present(animated: true, completionHandler: nil) 2.Run it on a MacOS with Sonoma, there is no error on console or anything but it don't work. -If you run it with Catalyst it just works when adding the Printing permission of App Sandbox in Signing & Capabilities.

Hello! I've been digging into this for a little bit now, and am hitting something of a wall. Our app is crashing occasionally, and googling the crash yields literally 0 results. Tl;dr: Something related to adaptivePresentationStyle(for:traitCollection:) is resulting in our app crashing. Context In our app, we have a custom UIPresentationController that we use to present a small sheet of content overlaying other app content - similar to a UISheetPresentationController with a medium-ish size. So we have a custom UIViewController to present, and it conforms to the UIAdaptivePresentationControllerDelegate protocol. We also have custom present and dismiss animators. The crash However, we seem to be running into a really odd crash. I've attached a crash report as well, but here's what one sees in xcode on reproducing the crash: The _computeToEndFrameForCurrentTransition block is nil inside the _transitionViewForCurrentTransition block, value of outerStrongSelf currently : <XxxYyyyyyZzz.PopupPresentationController: 0x12d017a40>. This most likely indicates that an adaptation is happening after a transtion cleared out _computeToEndFrameForCurrentTransition. Captured debug information outside block: presentationController : <XxxYyyyyyZzz.PopupPresentationController: 0x12d017a40> presentedViewController : <XxxYyyyyyZzz.SomeViewController: 0x12d03a690> presentingViewController : <UINavigationController: 0x12a817400> 2023-09-25_08-02-33.6523_-0500-7d355cd4a86427213389765ef070a777c4b4aaa3.crash Whenever we present one of these view controllers, things work just fine. When we try to present another one though, if someone is aggressively changing the phone orientation, the app crashes. This crash occurs somewhere in between dismissing the old VC and presenting the new one. It occurs before I ever hit any breakpoints in the "present" animator for the second view controller. I've narrowed things down a bit, and by commenting out our implementation of adaptivePresentationStyle(for:traitCollection:), the crash can't be reproduced anymore. The downside there being that the app no longer functions how we want it to. Our definition of that function (which causes crashes) looks like this: public func adaptivePresentationStyle(for controller: UIPresentationController, traitCollection: UITraitCollection) -> UIModalPresentationStyle { guard forceUsingFullScreenIfCompact else { return .none } return traitCollection.verticalSizeClass == .compact ? .overFullScreen : .none } A bit more testing, and it seems like if that function returns the same thing consistently, nothing crashes. Are we not allowed to put conditional logic in this function? In the crash, we can see that it occurs due to a failing assertion internal to UIPresentationController: Last Exception Backtrace: 0 CoreFoundation 0x1afa28cb4 __exceptionPreprocess + 164 (NSException.m:202) 1 libobjc.A.dylib 0x1a8abc3d0 objc_exception_throw + 60 (objc-exception.mm:356) 2 Foundation 0x1aa1b2688 -[NSAssertionHandler handleFailureInFunction:file:lineNumber:description:] + 172 (NSException.m:251) 3 UIKitCore 0x1b1d05610 __80-[UIPresentationController _initViewHierarchyForPresentationSuperview:inWindow:]_block_invoke + 2588 (UIPresentationController.m:1594) 4 UIKitCore 0x1b21f1ff4 __56-[UIPresentationController runTransitionForCurrentState]_block_invoke_3 + 300 (UIPresentationController.m:1228) The question This all leads us to wonder if we're doing something wrong, or if there could be a bug in one of the iOS APIs that we're consuming. Thus, posting here. Does anyone have any insight into how this could be occurring, or has seen this before and has ideas? Thanks! Miscellaneous info We target iOS 14+ We've seen this issue in debug and release builds from Xcode 14 and 15 We see the issue on users with iOS 15+, though it could be occurring on 14 in just incredibly low numbers This is a re-post of https://developer.apple.com/forums/thread/738257, because I accidentally closed that out as resolved

We have developed an iOS app using three fonts: PingFangSC Regular, PingFangSC Medium, and DINAlternate-Bold. Do all three fonts require commercial authorization to be used in the app?

I see viewIsAppearing is available on iOS 13 and above, but when I use it, found that the function not be called below iOS 16 https://developer.apple.com/documentation/uikit/uiviewcontroller/4195485-viewisappearing environment: Macos 14.4.1, Xcode 15.3 import UIKit class ViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() let sub = SubViewController() addChild(sub) view.addSubview(sub.view) } @available(iOS 13.0, *) override func viewIsAppearing(_ animated: Bool) { super.viewIsAppearing(animated) print("ViewController viewIsAppearing") } } class SubViewController: UIViewController { @available(iOS 13.0, *) override func viewIsAppearing(_ animated: Bool) { super.viewIsAppearing(animated) print("SubViewController viewIsAppearing") } } In iOS 15 devcice console log: ViewController viewIsAppearing iOS 16, 17: ViewController viewIsAppearing SubViewController viewIsAppearing

I have a Catalyst app that I'm adding a sidebar to via UISplitViewController. I have a toolbar on the window with buttons that I want to be enabled or disabled based on the state of the view controller in the split view's secondary column. But it seems to want to check the primary view controller instead. In the Catalyst tutorial Adding a Toolbar, this exact approach is demonstrated. The RecipeDetailViewController has methods for toggleFavorite and editRecipe, and the toolbar items are set up to reference those selectors in the ToolbarDelegate class. In the screenshots in the tutorial, the buttons are shown as enabled based on RecipeDetailViewController.canPerformAction. But when I download and run the complete project on my computer (macOS 14.4.1), the toolbar items are disabled. And if I add the methods to the RecipeListViewController (which is in the primary column of the UISplitViewController, the toolbar items get enabled. Is there a way to make the system ask the correct split view column for canPerformAction? Or is this a bug?

I have recently submitted a new app version to the Appstore with Xcode 15.0. Unfortunately, I have started to see the below crash in the Xcode organiser &gt; Crashes section occurring for more number of times. UIKitCore: +[UIAlertController _alertControllerContainedInViewController:] + 160 The exception trace is not leading to main() function but not pointing to any of the code line. I had used UIAlertController in the past versions to show the alerts but there is no code written in the current version code related to UIAlertController. Only from the latest version, this kind of crash started to surface. In the latest release, We have added a third party SDK and while implementing the SDK, we had added the Location and Bluetooth Permissions in Info.plist file. But as we don't want to use/track the Location and Bluetooth details from the app, the SDK team has disabled the Location and Bluetooth settings to not reflect in the tracked data. Is this behaviour creating any conflict with the UIAlertController and logging the crash? Because by default the OS tries to show the alert when the permissions exist in the plist file, but the alert will not come as the service is disabled on the SDK server settings. Is this creating any conflict and logging the crash. Please extend your help.

I have a custom document-based iOS app that also runs on macOS. After implementing -activityItemsConfiguration to enable sharing from the context menu, I found that the app crashes on macOS when selecting Share… from the context menu and then selecting Save (i.e. Save to Files under iOS). This problem does not occur on iOS, which behaves correctly. - (id<UIActivityItemsConfigurationReading>)activityItemsConfiguration { NSItemProvider * provider = [[NSItemProvider alloc] initWithContentsOfURL:self.document.presentedItemURL]; UIActivityItemsConfiguration * configuration = [UIActivityItemsConfiguration activityItemsConfigurationWithItemProviders:@[ provider ]]; // XXX crashes with com.apple.share.System.SaveToFiles return configuration; } Additionally, I found that to even reach this crash, the workaround implemented in the NSItemProvider (FBxxx) category of the sample project is needed. Without this, the app will crash much earlier, due to SHKItemIsPDF() erroneously invoking -pathExtension on an NSItemProvider. This appears to be a second bug in Apple’s private ShareKit framework. #import <UniformTypeIdentifiers/UniformTypeIdentifiers.h> @implementation NSItemProvider (FBxxx) // XXX SHKItemIsPDF() invokes -pathExtension on an NSItemProvider (when running under macOS, anyway) -> crash - (NSString *)pathExtension { return self.registeredContentTypes.firstObject.preferredFilenameExtension; } @end Again, this all works fine on iOS (17.5) but crashes when the exact same app build is running on macOS (14.5). I believe these bugs are Apple's. Any idea how to avoid the crash? Is there a way to disable the "Save to Files" option in the sharing popup? I filed FB13819800 with a sample project that demonstrates the crash on macOS. I was going to file a TSI to get this resolved, but I see that DTS is not responding to tech support incidents until after WWDC.

Problem Our app use UIPasteControl for people taps to place pasteboard contents in UITextView. It worked fine at first, but recently received a lot of user feedback and the button suddenly disappeared This problem usually occurs when an App switches between the front and back More Information When the button disappears, we find that the child view of the UIPasteControl control which name _UISlotView has a size of zero. we use UIKit and AutoLayout，limit button size (100, 36) let config = UIPasteControl.Configuration() config.displayMode = .labelOnly config.cornerStyle = .fixed config.baseForegroundColor = .white config.baseBackgroundColor = .black config.cornerRadius = 18 let btn = UIPasteControl(configuration: config) pasteBtn = btn addSubview(pasteBtn) pasteBtn.snp.makeConstraints { make in make.trailing.equalTo(-20) make.bottom.equalTo(-10) make.size.equalTo(CGSize(width: 100, height: 36)) } UI view information <UIPasteControl: 0x107dda810; frame = (0 0; 100 36); layer = <CALayer: 0x3010ff000>> (lldb) po [0x107dda810 subviews] <__NSSingleObjectArrayI 0x30152ff00>( <_UISlotView: 0x107dea630; frame = (0 0; 100 36); userInteractionEnabled = NO; layer = <CALayer: 0x3010eb460>> ) anyone meet before? is there a workaround?

I have a UITableView which contains a UICollectionView in the first row. It used to work fine in iOS17, but now I get a crash when running with Xcode 16 / iOS18 beta: Expected dequeued view to be returned to the collection view in preparation for display. When the collection view's data source is asked to provide a view for a given index path, ensure that a single view is dequeued and returned to the collection view. Avoid dequeuing views without a request from the collection view. For retrieving an existing view in the collection view, use -[UICollectionView cellForItemAtIndexPath:] or -[UICollectionView supplementaryViewForElementKind:atIndexPath:] This is my UITableView delegate call: AddEditDataCell *cell = nil; if (indexPath.section == 0) { if (indexPath.row == 0) { AddEditDataContactsCell *contactNameCell = (AddEditDataContactsCell *)[self cellForContactNamesCollectionAtIndexPath:indexPath tableView:tableView]; return contactNameCell; - (AddEditDataContactsCell *)cellForContactNamesCollectionAtIndexPath:(NSIndexPath *)indexPath tableView:(UITableView *)tableView { AddEditDataContactsCell *contactsCell = (AddEditDataContactsCell *)[self.tableView dequeueReusableCellWithIdentifier:@"ContactsCell" forIndexPath:indexPath]; if (self.collectionNameCell == nil) { self.collectionNameCell = [contactsCell.collectionView dequeueReusableCellWithReuseIdentifier:@"LogContactNameCollectionCellIdentifier" forIndexPath:[NSIndexPath indexPathForRow:0 inSection:0]]; contactsCell.nameCellDelegate = self; } contactsCell.frame = CGRectZero; [contactsCell setNeedsLayout]; [contactsCell.collectionView reloadData]; contactsCell.collectionViewHeightConstraint.constant = contactsCell.collectionView.collectionViewLayout.collectionViewContentSize.height; [contactsCell.collectionView.collectionViewLayout invalidateLayout]; return contactsCell; }

Based on the session content, it seems that setting the TextView property writingToolsBehavior = .complete should bring up the writing tools bottom panel view. However, it does not appear to be working. Is this a feature that will be added in a future update, or is there something additional I need to do? Test on: XCode 16.0 beta (16A5171c), iOS Simulator 18.0 Beta, iPhone 11 Pro iOS 18.0 Beta

We have a UITabBarController in our iPhone App which has 5 tabs with UITableViewControllers (constructed from the storyboard). Before iOS18 beta 1 (and 2) this was working fine without any problems (objective-C). Since iOS18 beta 1 (and beta 2 still has this problem) a strange render glitch occurs when activating a tab from the tab bar at the bottom. As soon as a tab is activated (by tapping on the icon at the bottom) the tab with the UITableViewController becomes visible and draws its content starting at the very top of the screen (pos 0,0) right through/over the Navigation bar which at that point is showing a title and a rightBarButtonItem. The tab with the UITableViewController seems not aware there is a navigation bar visible. Then after ~0.3 seconds the tab with the UITableViewContoller is automatically rendered again or moved down and now its content starts below the UINavigationBar as expected, this is 100% reproducible and occurs on every activation of a tab in the UITabBarController. Is anyone else also getting this behavior in their App since iOS18? I'm aware that UITabBarController is being renewed but I can't find any information on why this behavior might occur. I was hoping beta 2 would solve the problem but it doesn't. Constructing the UITabBarController in the code with the new UITab objects (instead of constructing them from the storyboard) also shows this problem.

After updating iOS, my Cordova app behaves incorrectly after receiving a voip push. When a push notification is received, my application launches CallKit, displays the Native Dialer screen and starts other necessary services. Until 17.5.1 (possibly 17.5) everything worked correctly. All services and sockets were established/ connected and working. After updating iOS to 17.5, the application crashes, and while voice connection is established the app is no longer active. Xcode logs have these error messages: Invalidating grant <invalid NS/CF object> failed Type: Error | Timestamp: 2024-06-20 13:27:44.719601+02:00 | Process: MyApp | Library: WebKit | Subsystem: com.apple.WebKit | Category: ProcessCapabilities | TID: 0x3a4929 Invalidating grant <invalid NS/CF object> failed Type: Error | Timestamp: 2024-06-20 13:27:44.732219+02:00 | Process: MyApp | Library: WebKit | Subsystem: com.apple.WebKit | Category: ProcessCapabilities | TID: 0x3a4929 Invalidating grant <invalid NS/CF object> failed Type: Error | Timestamp: 2024-06-20 13:27:44.733996+02:00 | Process: MyApp | Library: WebKit | Subsystem: com.apple.WebKit | Category: ProcessCapabilities | TID: 0x3a4929 I am using: Cordova iOS: 6.2 iOS 17.5.1 Can anyone please help?

I am running into an issue with UITabBarController in a Catalyst app when building under Xcode 16 and running on macOS 15. If a UITabBarController is used, the tabs are presented in an unwanted title/toolbar at the top of the window. If you have an app where your views run to the top of the window, this can obscure the content and controls that are near the top. I created a sample application that is attached to the Feedback record (FB14293963). When building under Xcode 15, this is what the app looks like: Under Xcode 16, it looks like this: Beyond this simple example, using UITabBarController in a presented view controller can result in the tabs not showing at all. Also, If you switch the view in the main window to something that isn't a UITabBarController, the tabs still remain at the top. This seems to stem from the tab bar/sidebar changes for iPadOS 18. While this approach can work for simpler apps, it may not work well at all for more complex apps and there really needs to be a way to opt out of this behavior so apps where it is not suited for can still take advantage of features in iPadOS/Catalyst 18. Has anyone discovered a workaround or way to disable the new tab bar behavior with having to write their own version of UITabBarController?

In iOS 18, with the elevated tab bar, the title of the primary view controller in a UISplitViewController automatically hides when the Split View is expanded. However, the title label is still present in the view hierarchy. How to resolve this issue?

iOS 18 introduced the elevated tab bar for iPad devices. However, the tint color for UITabBar items is not changing. Adjusting the barTintColor and tintColor properties of the tab bar items does not seem to have any effect.

FB14569448 Since iOS 18 beta came out, our app has been failing at some point when a view controller is dismissed and it appears the main thread ends up looping in layout logic and logs the following to the console. The app hangs until it's terminated due to a memory overallocation issue. Anyone else seen this? <_UINavigationBarItemStackEntry: 0x302ac73f0> normalLayout[active]=0x1391ad880 searchLayout=0x0 item=<UINavigationItem: 0x13913a080> style=navigator: Ignoring unexpected nonmatching counterpart: (null) This is an internal UIKit bug. Snapshotting a view (0x1391e7c00, _UIButtonBarStackView) that has not been rendered at least once requires afterScreenUpdates:YES. frame #0: 0x000000019bb07000 libobjc.A.dylibobjc_msgSend frame #1: 0x00000001a0fb4224 UIKitCore-[UIView(AdditionalLayoutSupport) _updateConstraintsIfNeededCollectingViews:forSecondPass:] + 144 frame #2: 0x00000001c270a030 CoreAutoLayout-[NSISEngine withBehaviors:performModifications:] + 84 frame #3: 0x00000001a0fe5424 UIKitCore__100-[UIView(AdditionalLayoutSupport) _updateConstraintsIfNeededWithViewForVariableChangeNotifications:]_block_invoke + 120 frame #4: 0x00000001a0fe3ae0 UIKitCore-[UIView(AdditionalLayoutSupport) _withUnsatisfiableConstraintsLoggingSuspendedIfEngineDelegateExists:] + 112 frame #5: 0x00000001a0fe2b4c UIKitCore-[UIView(AdditionalLayoutSupport) _updateConstraintsIfNeededWithViewForVariableChangeNotifications:] + 172 frame #6: 0x00000001a0fa9e90 UIKitCore-[UIView _updateConstraintsAtEngineLevelIfNeededWithViewForVariableChangeNotifications:] + 400 frame #7: 0x00000001a0fa9a18 UIKitCore-[UIView _updateConstraintsAsNecessaryAndApplyLayoutFromEngine] + 312 frame #8: 0x00000001a0fa97a4 UIKitCore-[UIView(Hierarchy) layoutSubviews] + 204 frame #9: 0x00000001a124fa78 UIKitCore-[_UIButtonBarStackView layoutSubviews] + 56 frame #10: 0x00000001a0f6430c UIKitCore-[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2492 frame #11: 0x00000001a029d8d0 QuartzCoreCA::Layer::layout_if_needed(CA::Transaction*) + 496 frame #12: 0x00000001a0fa81d0 UIKitCore-[UIView(Hierarchy) layoutBelowIfNeeded] + 300 frame #13: 0x00000001a1843fa4 UIKitCore-[_UINavigationBarTransitionContextCrossfade _prepareContentView] + 132 frame #14: 0x00000001a18443bc UIKitCore-[_UINavigationBarTransitionContextCrossfade prepare] + 84 frame #15: 0x00000001a184e59c UIKitCore-[_UINavigationBarVisualProviderModernIOS _performAnimationWithTransitionCompletion:transition:] + 1524 frame #16: 0x00000001a180f938 UIKitCore-[UINavigationBar _popNavigationItemWithTransitionAssistant:] + 220 frame #17: 0x00000001a180f5f8 UIKitCore-[UINavigationBar _popNavigationItemWithTransition:] + 224 frame #18: 0x00000001a13bec9c UIKitCore-[UINavigationBar _setItemsUpToItem:transition:] + 240 frame #19: 0x00000001a13be76c UIKitCore-[UIViewController _removeNavigationItemsFromNavigationController:transition:] + 232 frame #20: 0x00000001a19c9dc0 UIKitCore__89-[UINavigationController _immediatelyApplyViewControllers:transition:animated:operation:]_block_invoke_3 + 800 frame #21: 0x00000001a19d0b2c UIKitCore__98-[UINavigationController _shouldSkipHostedRefreshControlUpdateSchedulingDeferredUpdateIfNecessary]_block_invoke + 40 frame #22: 0x00000001a19d7574 UIKitCore-[UINavigationController transitionConductor:didStartDeferredTransition:context:] + 792 frame #23: 0x00000001a21c9600 UIKitCore-[_UIViewControllerTransitionConductor startDeferredTransitionIfNeeded] + 688 frame #24: 0x00000001a10ab040 UIKitCore-[UINavigationController __viewWillLayoutSubviews] + 84 frame #25: 0x00000001a1350bcc UIKitCore-[UILayoutContainerView layoutSubviews] + 172 frame #26: 0x00000001a0f6430c UIKitCore-[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 2492 frame #27: 0x00000001a029d8d0 QuartzCoreCA::Layer::layout_if_needed(CA::Transaction*) + 496 frame #28: 0x00000001a029d45c QuartzCoreCA::Layer::layout_and_display_if_needed(CA::Transaction*) + 148 frame #29: 0x00000001a02f64e0 QuartzCoreCA::Context::commit_transaction(CA::Transaction*, double, double*) + 472 frame #30: 0x00000001a02736c4 QuartzCoreCA::Transaction::commit() + 648 frame #31: 0x00000001a02b6584 QuartzCoreCA::Transaction::flush_as_runloop_observer(bool) + 88 frame #32: 0x00000001a1002c3c UIKitCore_UIApplicationFlushCATransaction + 52 frame #33: 0x00000001a10002dc UIKitCore_UIUpdateSequenceRun + 84 frame #34: 0x00000001a0ffff2c UIKitCoreschedulerStepScheduledMainSection + 172 frame #35: 0x00000001a1000df0 UIKitCorerunloopSourceCallback + 92 frame #36: 0x000000019e7edf90 CoreFoundation__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 frame #37: 0x000000019e7edf24 CoreFoundation__CFRunLoopDoSource0 + 176 frame #38: 0x000000019e7eba10 CoreFoundation__CFRunLoopDoSources0 + 244 frame #39: 0x000000019e7eac14 CoreFoundation__CFRunLoopRun + 840 frame #40: 0x000000019e7ea4c8 CoreFoundationCFRunLoopRunSpecific + 572 frame #41: 0x00000001eb06d1c4 GraphicsServicesGSEventRunModal + 164 frame #42: 0x00000001a1334a90 UIKitCore-[UIApplication _run] + 816 frame #43: 0x00000001a13e2d1c UIKitCoreUIApplicationMain + 340 frame #44: 0x000000010038ca7c LabWare Developmentmain at AppDelegate.swift:31:7 frame #45: 0x00000001c4f4e9b4 dyldstart + 2724

I have already searched for a lot of information about this issue. Many people have encountered it with UISplitViewController or on iPadOS, but I am experiencing this problem on iOS 18. It does occasionally occur on iOS 17, but it definitely happens on iOS 18. The error messages are as follow: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Layout requested for visible navigation bar, <UINavigationBar: 0x14a6b3c00; frame = (0 44; 375 44); autoresize = W; tintColor = UIExtendedGrayColorSpace 1 1; layer = <CALayer: 0x3026a9da0>> delegate=0x14a674600 standardAppearance=0x300d1d0a0 scrollEdgeAppearance=0x300d1cf50, when the top item belongs to a different navigation bar. topItem = <UINavigationItem: 0x14a7f8780> style=navigator leftBarButtonItems=0x302423b40, navigation bar = <UINavigationBar: 0x14adcb700; frame = (0 0; 375 44); autoresize = W; tintColor = UIExtendedGrayColorSpace 1 1; layer = <CALayer: 0x302680940>> delegate=0x14ade8c00 standardAppearance=0x300d7a7d0 scrollEdgeAppearance=0x300d7a610, possibly from a client attempt to nest wrapped navigation controllers.' *** First throw call stack: (0x193f3a08c 0x191242698 0x19330a8fc 0x196939290 0x1966847b4 0x1967cdc88 0x1959ba6d8 0x1966c86bc 0x196769d50 0x1967cae58 0x196771f28 0x196b0fcb8 0x196764800 0x196684280 0x1959ba6d8 0x1959ba264 0x195a12edc 0x195990560 0x1968295f0 0x193f1c218 0x193f0a4c0 0x193f09b84 0x193f09368 0x1e00fc1c4 0x196a569b0 0x196b04d54 0x10462b1fc 0x1ba144734) libc++abi: terminating due to uncaught exception of type NSException I am sure about the process on iOS 17, first I use UINavigationController.present(UINavigationController()) and then call keyWindow.rootViewController = UINavigationController(), it crashes. So I can dismiss the presentedViewController before assign keyWindow.rootViewController. However, on iOS 18, the app crash when launch.

I'm building a SwiftUI app with a UITextView subclass, and it seems that the software keyboard doesn't trigger the pressesBegan or pressesEnded functions of UITextView. With a hardware keyboard, pressesBegan works as expected, allowing us to intercept key presses in our subclass. I can't find any documentation about this, or any other forum posts (here or on Stack Overflow) that talk about a discrepancy between software and hardware keyboard behaviors, and I can't believe this is an intended behavior. Our app is a SwiftUI app, in case that's relevant. Does anyone have any guidance? Is this a bug or am I not understanding this API? Any information or work arounds would be greatly appreciated. I've made a sample project that demonstrates this issue, which you can grab from GitHub at https://github.com/nyousefi/KeyPressSample. To see this in action, run the sample project and start pressing keys. The hardware keyboard will print the key press at the top of the screen (above the text view), while the software keyboard won't.

I am writing to report an issue I encountered with iOS 18 beta that affects my application, which has been available on the App Store for over two years and currently has over 60,000 active users. My application utilizes a UITabBarController to manage multiple tabs, where each tab hosts a UIViewController embedded within a UINavigationController. The application operates in two different states, where users may have either 5, 4, or 3 tabBarItems depending on their configuration. The issue arises when fewer than 5 tabs are present. In these cases, I add child view controllers to the UITabBarController to ensure they are displayed above the tab bar, rather than below it. The relevant code snippet is as follows: tabBarController.addChild(childController) tabBarController.view.addSubview(childController.view) Prior to iOS 18, this implementation functioned as expected. However, with the release of iOS 18, adding a child view controller to the UITabBarController results in the child being incorrectly added as a UITabBarItem. This misbehavior leads to an application crash when the unintended tab is selected. The crash trace is as follows: "Inconsistency in UITabBar items and view controllers detected. No view controller matches the UITabBarItem '<UITabBarItem: 0x142d9c480> selected'." I have attached screenshots from iOS 18 and previous versions to illustrate the issue, which compares the expected behavior in earlier iOS versions with the problematic behavior in iOS 18. I appreciate your attention to this matter and look forward to any guidance or resolution you can provide.