Update:I create a plain app and a keyboard extension to test the touch events. The plain app can respond the touch immediately but the keyboard extension has about 1s lag.--------------------------------------------------------Hi, Recently I test my app on the iPhone 6s and the iPhone 6sp with 3D touch ON. I notice 3 strange things:When my finger touches on the left edge of the screen, the app responds the touch events after about 1s delay.When I touch on the left edge of the screen and push with force, the 3D touch task switcher shows.But if I tap the left edge of the screen, the app can respond the touch events immediately.I test many other 3rd apps and system apps (notes, contacts) this phenomenon exists too with 3D touch ON. When I turn 3D touch OFF, the app responds the touch events immediately as usual.On the other hand, the system keyboard responds the touch events immediately whether the 3D touch is ON or OFF.I guess it’s because the touch events responding conflicts with the 3D touch task switcher. I have tried many 3D touch APIs but have no effects.Does anyone have an idea? Thanks!

Hello,I have some question regarding the alternative icons feature that comes with iOS 10.3.I'm working on a app, that allow user to select a broker from a list, after being logged. I would like to change the icon of the app to be the one of the selected broker. A user will all the time a have access to several brokers. The problem is that we have +3000 broker registered in our platform. So it will be really difficult for us to place the icon of all the 3000 broker in the app, because it will lead to some issue regarding the size of the app. What i would to do, is to set the name of all the broker app icon in the info.plist without having them locally in the app. After that, when the user is logged in the app and have selected the broker, i will do a call to our server and get back the broker app icon, save it and use it. Is it possible ? Will i have some problem with Apple regarding the approval of my app ? Thank a lot for your help.

I have noticed that in iOS 14 the UIPickerView has by default a light grey background on the selected Row like shown here. https://developer.apple.com/design/human-interface-guidelines/ios/controls/pickers/ I noticed also that pickerView.showsSelectionIndicator is deprecated on iOS 14. Is there a way to change the background color to white and add separators to achieve a pre iOS 14 UIPickerView style? Thank you

I'm developing a rhythm game for iOS which has four buttons spanning the width of the screen in portrait. I noticed that my testers were having some missed inputs on the buttons on the left and right due to the fact that iOS, by default, tries to ignore accidental touches on the edges of the screen. So I enabled "Defer System Gestures" on the left and right edges, but then quickly started to notice a new, very specific, issue. Description of the issue If you have finger #1 touching and holding anywhere in the middle of the screen, and finger #2 touches on the far right or left edge of the screen just below the horizontal position of finger #1, those touches are inconsistently not recognized. If finger #1 is not present, this issue does not occur. If finger #2 is above or well below finger #1, this issue also does not occur. A dead zone is created on the right and left edges of the screen just below the horizontal position of the first touch. Here is a rough representative example of where touches #1 and #2 need to be for this issue to manifest, in case the text above is not clear. |				| |				| |				| |				| |	 1		| |			 2| |				| It just so happens that this issue is causing major usability problems with my game, as it results in what the user sees as sporadic and inconsistent response when the game calls for two notes to be played at the same time. Steps to recreate the issue Here are the steps if you want to recreate the problem yourself using the "Create New Gesture" pane in "Assistive Touch" (Note that this problem is not specific to the Settings app, but rather is an issue across the system—however this panel defers system gestures and shows where touches are being read, so it is a great place to demonstrate): (1) Go to Settings > Accessibility > Touch > Assistive Touch > Create New Gesture...; (2) With one finger, touch the middle of the screen and hold it through step 3; (3) With a second finger, tap 4 times along the right (or left) edge of the screen in the following places: (a) well above the vertical position of the first touch, (b) just above the vertical position of the first touch, (c) just below the vertical position of the first touch, and (d) well below the vertical position of the first touch; (4) Notice how, more than half the time, touch (c) does not register. I have found that this problem is more replicatable when the first touch is on the lower half of the screen, but I have been able to replicate it when the finger is higher as well, just not as consistently. Here are the four positions described in the steps above: Position a: both touches register |				| |				| |				| |			 2| |	 1		| |				| |				| Position b: both touches usually register |				| |				| |				| |				| |	 1	 2| |				| |				| Position c: only touch 1 registers |				| |				| |				| |				| |	 1		| |			 2| |				| Position d: both touches register |				| |				| |				| |				| |	 1		| |				| |			 2| Is there anything I can do to resolve this behavior? My app requires gesture deferment to be on for the expected experience by the user, and this bug is causing other issues for my testers that kind of need to be resolved before I can confidently release the game.

Why is the UIKeyboard implementation still holding a reference to this UITextField, thus keeping it from being deallocated? The memory debugger shows: UIKeyboardImpl -> UIKBAutofillController -> NSMutableDictionary -> NSMutable...(Storage) -> UITextField Any idea what's going on there?

Dear random Apple UIKit engineer. This is a question for you. Today let's speak about keyboard notifications. In particular, UIResponder.keyboardWillShowNotification and UIResponder.keyboardWillHideNotification. While working with those, I noticed some undocumented behaviour. First, let me give you some context: extension UIViewController { func registerForKeyboardNotifications() { NotificationCenter.default.addObserver(self, selector: #selector(keyboardNotification), name: UIResponder.keyboardWillShowNotification, object: nil) NotificationCenter.default.addObserver(self, selector: #selector(keyboardNotification), name: UIResponder.keyboardWillHideNotification, object: nil) } /// Override this method to handle keyboard notifications. @objc func keyboardNotification(_ notification: Notification) { ... } } Eventually, I found that latter method with 3 dots has an implicit animation inside it's scope. Here is the [proof.](https://medium.com /uptech-team/why-does-uiresponder-keyboard-notification-handler-animate-10cc96bce372) Another thing I noticed, is that this property definition is perfectly valid let curve = UIView.AnimationCurve(rawValue: 7)!. The 7 btw comes from UIResponder.keyboardAnimationCurveUserInfoKey as a default value during my tests. So, the enum with 4 possible values (0...3) can be initialized with a value out of enum's cases range. Also, how can I initialize UIView.AnimationOption from 7? I will pollute my OptionSet which I feed to options parameter on UIView.animate(...) My questions: Why implicit animation is not documented and can I trust it or it's a subject to change. Why UIView.AnimationCurve(rawValue: 7)! does not crash. How can I convert UIResponder.keyboardAnimationCurveUserInfoKey's value into UIView.AnimationOption properly if I don't want to use implicit value. I don't encroach on UIKit secrets. I just need to know how to work with the API. Thank you!

I'm using UIDocumentPickerViewController to open a url. Works fine in debug mode but version on the App Store is failing. Code to create the document picker is like: NSArray *theTypes = [UTType typesWithTag:@"docxtensionhere" tagClass:UTTagClassFilenameExtension conformingToType:nil]; UIDocumentPickerViewController *documentPicker = [[UIDocumentPickerViewController alloc]initForOpeningContentTypes:theTypes]; documentPicker.delegate = self;   [self presentViewController:documentPicker animated:YES completion:nil]; So in debug mode this is all gravy. -documentPicker:didPickDocumentsAtURLs: passes back a URL and I can read the file. In release mode I get a URL but my app is denied access to read the file. After inspecting some logging it appears the sandbox is not granting my app permission. error Domain=NSCocoaErrorDomain Code=257 "The file “Filename.fileextensionhere” couldn’t be opened because you don’t have permission to view it." UserInfo={NSFilePath=/private/var/mobile/Library/Mobile Documents/comappleCloudDocs/Filename.fileextensionhere, NSUnderlyingError=0x2834c9da0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}} -- If I'm doing something wrong with UIDocumentPickerViewController it is a real shame that permission is not being denied in Debug mode, as devs are more likely to catch in prior to release. Anyone know where I'm going wrong and if not have a workaround? Thanks in advance.

I am trying to understand if what I am seeing is expected behavior or not with the following UIKit components. 1.I have a view controller "A" embedded in a navigation controller (part of a multi-step flow). Large titles are active on this navigation controller. In this view controller "A", I have a container view that contains another view controller "B" (I want to reuse the contents of B in other flows) Inside view controller "B" I have a UICollectionView using a diffable data source. When you load view controller "A" it appears to work fine. My collection view loads data, I see a nice list and when I scroll it... ... the expectation is it scrolls inside it's container and has no impact on the parent controller "B" However, the navigation bar and title in "A" reflect the content offset of the collection view. Scroll a couple lines, the large title turns small and centered on top. If I turn off large title, I still see the background color of the navigation bar change as it would if you were scrolling a view directly inside controller "A" without the container view. Am I supposed to be manually capturing the gesture recognizer in B and somehow preventing the gesture to bubble up to A? It seems like strange behavior to have to correct. Any suggestions? Thanks!

I recently was thinking about which is the best format to use for my little icons in the app, and was considering the performance of PNG versus SVG . I know that PNG decoders are hardware accelerated and parallelized, and the rendering is as simple as placing the pixels on the screen. On the other hand, SVG requires computation to determine the placement of pixels based on mathematical equations. Considering this, my current assumption is that PNG is faster to render than SVG. However, if SVG is also hardware-accelerated, it could alter the situation, although this may not be the case.

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

This crash has been troubling us for a long time. We have this crash report in every release of our App, but can't reproduce it. Here is part of the crash info: Incident Identifier: xxxx Hardware Model: iPhone13,3 Process: MyApp [34550] Path: /private/var/containers/Bundle/Application/xxxx/MyApp.app/MyApp Identifier: xxx.xxx Version: xxx (296) AppStoreTools: 15F31c AppVariant: 1:iPhone13,3:15 Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: xxx.xxx [466] Date/Time: 2024-05-19 13:59:10.9716 +0800 Launch Time: 2024-05-19 12:18:24.8753 +0800 OS Version: iPhone OS 16.6.1 (20G81) Release Type: User Baseband Version: 3.80.01 Report Version: 104 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x322e323400000000 -> 0x0000003400000000 (possible pointer authentication failure) Exception Codes: 0x0000000000000001, 0x322e323400000000 VM Region Info: 0x3400000000 is in 0x1000000000-0x7000000000; bytes after start: 154618822656 bytes before end: 257698037759 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL commpage (reserved) fc0000000-1000000000 [ 1.0G] ---/--- SM=NUL ...(unallocated) ---> GPU Carveout (reserved) 1000000000-7000000000 [384.0G] ---/--- SM=NUL ...(unallocated) UNUSED SPACE AT END Triggered by Thread: 0 Thread 0 name: Thread 0 Crashed: 0 CoreGraphics 0x00000001bd1d0780 CGFontStrikeRelease + 76 (CGFontStrike.c:126) 1 CoreGraphics 0x00000001bd1dd0cc CGGlyphBuilderUnlockBitmaps + 476 (CGGlyphBuilder.cc:113) 2 CoreGraphics 0x00000001bd1eb8c8 render_glyphs + 412 (RIPContextDrawGlyphs.c:127) 3 CoreGraphics 0x00000001bd202ea4 draw_glyph_bitmaps + 1132 (RIPContextDrawGlyphs.c:210) 4 CoreGraphics 0x00000001bd21a0ec ripc_DrawGlyphs + 1320 (RIPContextDrawGlyphs.c:558) 5 CoreGraphics 0x00000001bd1d26d8 CG::DisplayList::executeEntries(std::__1::__wrap_iter<std::__1::unique_ptr<CG::DisplayListEntry const, std::__1::default_delete<CG::DisplayListEntry const> >*>, std::__1::__wrap_iter<std::__1::uniq... + 5852 (DisplayList.cpp:1657) 6 CoreGraphics 0x00000001bd1c86a8 CGDisplayListDrawInContextDelegate + 268 (DisplayList.cpp:2151) 7 QuartzCore 0x00000001bcc797d4 CABackingStoreUpdate_ + 468 (CABackingStore.cpp:1388) 8 QuartzCore 0x00000001bccf0c34 invocation function for block in CA::Layer::display_() + 64 (CALayer.mm:9699) 9 QuartzCore 0x00000001bcc78d54 -[CALayer _display] + 1720 (CALayer.mm:9732) 10 QuartzCore 0x00000001bcc785b4 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 412 (CALayer.mm:2521) 11 QuartzCore 0x00000001bcc898d8 CA::Context::commit_transaction(CA::Transaction*, double, double*) + 444 (CAContextInternal.mm:2714) 12 QuartzCore 0x00000001bccb8e80 CA::Transaction::commit() + 648 (CATransactionInternal.mm:432) 13 QuartzCore 0x00000001bcca2df0 CA::Transaction::flush_as_runloop_observer(bool) + 88 (CATransactionInternal.mm:940) 14 UIKitCore 0x00000001bdca34d0 _UIApplicationFlushCATransaction + 52 (UIApplication.m:3286) 15 UIKitCore 0x00000001bddf3d94 _UIUpdateSequenceRun + 84 (_UIUpdateSequence.mm:114) 16 UIKitCore 0x00000001be458894 schedulerStepScheduledMainSection + 144 (_UIUpdateScheduler.m:1015) 17 UIKitCore 0x00000001be457df0 runloopSourceCallback + 92 (_UIUpdateScheduler.m:1164) 18 CoreFoundation 0x00000001bb80a128 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 (CFRunLoop.c:1957) 19 CoreFoundation 0x00000001bb8167b4 __CFRunLoopDoSource0 + 176 (CFRunLoop.c:2001) 20 CoreFoundation 0x00000001bb79b5e8 __CFRunLoopDoSources0 + 244 (CFRunLoop.c:2038) 21 CoreFoundation 0x00000001bb7b10d4 __CFRunLoopRun + 828 (CFRunLoop.c:2953) 22 CoreFoundation 0x00000001bb7b63ec CFRunLoopRunSpecific + 612 (CFRunLoop.c:3418) 23 GraphicsServices 0x00000001f6ccc35c GSEventRunModal + 164 (GSEvent.c:2196) 24 UIKitCore 0x00000001bdb42f58 -[UIApplication _run] + 888 (UIApplication.m:3782) 25 UIKitCore 0x00000001bdb42bbc UIApplicationMain + 340 (UIApplication.m:5372) 26 MyApp 0x000000010468f978 main + 80 (main.m:15) 27 dyld 0x00000001dace8dec start + 2220 (dyldMain.cpp:1165) Thread 1 name: Thread 1: 0 libsystem_kernel.dylib 0x00000001fa6f6ca4 mach_msg2_trap + 8 (:-1) 1 libsystem_kernel.dylib 0x00000001fa709b74 mach_msg2_internal + 80 (mach_msg.c:201) 2 libsystem_kernel.dylib 0x00000001fa709e4c mach_msg_overwrite + 540 (mach_msg.c:0) 3 libsystem_kernel.dylib 0x00000001fa6f71e8 mach_msg + 24 (mach_msg.c:323) 4 CoreFoundation 0x00000001bb7b0024 __CFRunLoopServiceMachPort + 160 (CFRunLoop.c:2622) 5 CoreFoundation 0x00000001bb7b1250 __CFRunLoopRun + 1208 (CFRunLoop.c:3005) 6 CoreFoundation 0x00000001bb7b63ec CFRunLoopRunSpecific + 612 (CFRunLoop.c:3418) 7 Foundation 0x00000001b5a2efb4 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 (NSRunLoop.m:373) 8 Foundation 0x00000001b5a2ee9c -[NSRunLoop(NSRunLoop) runUntilDate:] + 64 (NSRunLoop.m:420) 9 UIKitCore 0x00000001bdc75cc8 -[UIEventFetcher threadMain] + 416 (UIEventFetcher.m:1376) 10 Foundation 0x00000001b5a48524 __NSThread__start__ + 716 (NSThread.m:963) 11 libsystem_pthread.dylib 0x000000021b5766b8 _pthread_start + 148 (pthread.c:893) 12 libsystem_pthread.dylib 0x000000021b575b88 thread_start + 8 (:-1) Thread 2: 0 libsystem_kernel.dylib 0x00000001fa6f7164 __semwait_signal + 8 (:-1) 1 libsystem_c.dylib 0x00000001c2c50888 nanosleep + 220 (nanosleep.c:104) 2 libsystem_c.dylib 0x00000001c2c61b1c sleep + 52 (sleep.c:62) 3 MyApp 0x00000001075ccb14 -[UTDCacheManager synchronizeData] + 104 (UTDCacheManager.m:133) 4 Foundation 0x00000001b5a48524 __NSThread__start__ + 716 (NSThread.m:963) 5 libsystem_pthread.dylib 0x000000021b5766b8 _pthread_start + 148 (pthread.c:893) 6 libsystem_pthread.dylib 0x000000021b575b88 thread_start + 8 (:-1)

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.

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?

We're trying to implement a backup/restore data feature in our business productivity iPad app using UIDocumentPickerViewController and AppleArchive, but discovered odd behavior of [UIDocumentPickerViewController initForOpeningContentTypes: asCopy:YES] when reading large archive files from a USB drive. We've duplicated this behavior with iPadOS 16.6.1 and 17.7 when building our app with Xcode 15.4 targeting minimum deployment of iPadOS 16. We haven't tested this with bleeding edge iPadOS 18. Here's our Objective-C code which presents the picker: NSArray* contentTypeArray = @[UTTypeAppleArchive]; UIDocumentPickerViewController* docPickerVC = [[UIDocumentPickerViewController alloc] initForOpeningContentTypes:contentTypeArray asCopy:YES]; docPickerVC.delegate = self; docPickerVC.allowsMultipleSelection = NO; docPickerVC.shouldShowFileExtensions = YES; docPickerVC.modalPresentationStyle = UIModalPresentationPopover; docPickerVC.popoverPresentationController.sourceView = self.view; [self presentViewController:docPickerVC animated:YES completion:nil]; The UIDocumentPickerViewController remains visible until the selected external archive file has been copied from the USB drive to the app's local tmp sandbox. This may take several seconds due to the slow access speed of the USB drive. During this time the UIDocumentPickerViewController does NOT disable its tableview rows displaying files found on the USB drive. Even the most patient user will tap the desired filename a second (or third or fourth) time since the user's initial tap appears to have been ignored by UIDocumentPickerViewController, which lacks sufficient UI feedback showing it's busy copying the selected file. When the user taps the file a second time, UIDocumentPickerViewController apparently begins to copy the archive file once again. The end result is a truncated copy of the selected file based on the time between taps. For instance, a 788 MB source archive may be copied as a 56 MB file. Here, the UIDocumentPickerDelegate receives a 56 MB file instead of the original 788 MB of data. Not surprisingly, AppleArchive fails to decrypt the local copy of the archive because it's missing data. Instead of failing gracefully, AppleArchive crashes in AAArchiveStreamClose() (see forums post 765102 for details). Does anyone know if there's a workaround for this strange behavior of UIDocumentPickerViewController?

If I put the phone flat on a table, the left and right swipe gestures is not working but up and down gestures works. Only when I put the iPhone to some vertical degree, the left and right swipe works. Tested on 2 iPhone 7 Plus and 2 iPhone 13. Anyone has similar experience? If yes, why?

Hi. Since Xcode 16 and/or iOS 18.0 (I upgraded at the same time), I have an strange effect in the lower (let's say) 20% section of the Navigation Bar when changing to another tab, and this independently if large titles are used or not. Mentioned section is brighter or darker than the rest of the Navigation Bar background, depending on which background tint is used. This effect lasts about 0.3 seconds, but is clearly visible, quite disturbing and new as of Xcode 16 and/or iOS 18.0. I use the code below in AppDelegate to get a gradient coloured Navigation Bar background. let appearance = UINavigationBarAppearance() UINavigationBar.appearance().standardAppearance = appearance UINavigationBar.appearance().compactAppearance = appearance UINavigationBar.appearance().scrollEdgeAppearance = appearance UINavigationBar.appearance().compactScrollEdgeAppearance = appearance If I don't use above code., the background color is filled and without gradient. Subject effect doesn't show in this case. The effect basically looks like when changing tab, the new Navigation Bar background doesn't clear right away, and keeps the background from the previous Navigation Bar for 0.3 seconds before new one Navigation Bar background is rendered. I spent quite some time on changing every possible setting, in code as well as storyboard ... no success so far. Any ideas how to disable this undesired animation?

Summary In iOS 18, the UICollectionViewDelegate method collectionView(_:targetIndexPathForMoveOfItemFromOriginalIndexPath:atCurrentIndexPath:toProposedIndexPath:) is not being called when moving items in a UICollectionView. This method works as expected in iOS 17.5 and earlier versions. Steps to Reproduce Create a UICollectionView with drag and drop enabled. Implement the UICollectionViewDelegate method: func collectionView(_ collectionView: UICollectionView, targetIndexPathForMoveOfItemFromOriginalIndexPath originalIndexPath: IndexPath, atCurrentIndexPath currentIndexPath: IndexPath, toProposedIndexPath proposedIndexPath: IndexPath) -> IndexPath { print("🐸 Move") return proposedIndexPath } Run the app on iOS 18. Attempt to drag and drop items within the collection view. Expected Behavior The method should be called during the drag and drop operation, and "🐸 Move" should be printed to the console. Actual Behavior The method is not called, and nothing is printed to the console. The drag and drop operation still occurs, but without invoking this delegate method. Configuration iOS Version: 18 Xcode Version: Xcode 16.0.0

Hello I'm working on implementing some changes to my app's tab bar, particularly to support some features in the new iPad floating tab bar, which has required me to adopt some of the new tab APIs from iOS 18. The issue I've encountered is that I would like the tabs visible in regular (floating tab bar) and compact (bottom tab bar) to be slightly different. The compact variant should show a subset of the tabs visible on iPad. For example: Floating tab bar: Use tabs A, B, C Bottom tab bar: Use tabs A, B I'm finding this quite difficult, especially in the scenario of split view on iPad, where the size class and tab bar location can change as the user interacts with the app. I went down the route of changing my tab bar controller's tabs property when the trait collection changed tabBarController.tabs = eligibleTabs where eligibleTabs for compact passes tabs AB, and when in regular - ABC. This throws an exception UIViewController cannot be shared between multiple UITab *** Assertion failure in -[UITab viewController], UITab.m:173 I'm not sharing view controllers between tabs. I can only assume that the system doesn't like me passing the same values (always at least tabs A & B) multiple times to the tabs property. I then later noticed a new iOS 18 property on UITabBarController - compactTabIdentifiers. This seemed like exactly what I was looking for: An optional filter to display only select root-level tabs when in a compact appearance. Default is nil, which would make all tabs available. So I changed my implementation: tabBarController.tabs = [tabA, tabB, tabC] tabBarController.compactTabIdentifiers = [tabAIdentifier, tabBIdentifier] and don't make any explicit updates when split view is enabled. Unfortunately this doesn't seem to work, at least not how I would expect it to. When enabling split view on iPad, the bottom tab bar appears, but it doesn't respect the tab identifiers I passed in tabBarController.compactTabIdentifiers. I'm not sure if this a bug or that I'm not really understanding how to use tabBarController.compactTabIdentifiers. Does anyone have any insight on this?

I have a Catalyst app that uses popovers frequently, and I'd love to have them stay active when the app loses focus. It appears this is controlled in a native AppKit app via NSPopover.Behavior. Is this functionality exposed somewhere in Catalyst?

The Apple documentation for [UIViewController willMoveToParentViewController:] states, Called just before the view controller is added or removed from a container view controller. Hence, the view controller being popped should appear at the top of the navStack when willMoveToParentViewController: is called. In iPadOS 16 and 17 the view controller being popped appears at the top of the navStack when willMoveToParentViewController: is called. In iPadOS 18 the view controller being popped has already been (incorrectly) removed from the navStack. We confirmed this bug using iPadOS 18.2 as well as 18.0. Our app relies upon the contents of the navStack within willMoveToParentViewController: to track the user's location within a folder hierarchy. Our app works smoothly on iPadOS 16 and 17. Conversely, our customers running iPadOS 18 have lost client data and corrupted their data folders as a result of this bug! These customers are angry -- not surprisingly, some have asked for refunds and submitted negative app reviews. Why doesn't willMoveToParentViewController: provide the correct navStack in iPadOS 18.2?