There does not seem to be a public API for this right now. You should file a feedback to UIKit for this suggestion. (I filed one under FB8800520)

Please provide more information. When are you calling collectionView:scrollToItemAtIndexPath:animated:? If you are using UICollectionViewDiffableDataSource, based on the limited information, I'm going to assume that you are trying to call scrollToItemAtIndexPath: in the completion block of your data source update. In iOS 14, it seems like UICollectionView will not perform the first layout until the UICollectionView has entered the window. This means that if you are loading your data in viewDidLoad, then it is possible that cells won't actually have done laying out when the completion block is called. If this is the case, you can simply call collectionView:scrollToItemAtIndexPath:animated: during viewDidAppear: since that will guarantee that the UICollectionView is already in the UIWindow.

That is not possible as the necessary system APIs and frameworks for SwiftUI only exist on iOS 13 and later devices.

You cannot "push" a view controller as a different presentation style because it is not a presentation. In general, when we talk about UINavigationController and "push", it refers to the stack of view controllers that are transitioned from right-to-left when pushed, and left-to-right when popped. If the behaviour of Clock and Calendar that I think you are referring is the sheet presentation that comes up that when creating a new Alarm that will allows content to be pushed, then you should present the a UINavigationController that wraps the view controller you are trying to present. /* Instead of: */ self.present(destinationViewController, animated: true, completion: nil) /* You should instead: */ self.present(UINavigationController(rootViewController: destinationViewController), animated: true, completion: nil) This then allows you to have a navigation stack to push/pop in the presented hierarchy.

Yes, that is because the default (and only) date picker style available on iOS 13 was .wheels whereas UIKit introduced new (default) styles for iOS 14. If you want to use it as an inputView, you should set your UIDatePicker.preferredDatePickerStyle to .wheels That being said, the better solution would be to use the new styles and having the date pickers inline in your input form instead of needing to create a separate text field and attaching a date picker as the input view.

This seems to be a conflict with the bridging between Objective-C and Swift. In Objective-C, allTargets is an NSSet, which bridges into Swift.Set<AnyHashable> when used in Swift. NSSets can only contain objective-c objects whereas Sets in Swift can be any hashable element. You can either make ButtonHandler conform to Hashable or subclass from NSObject.

Unfortunately, no. Diffable data source maps to one tableView. An alternative you could consider is to create a wrapper object that manages the data sources by applying the same changes.

That is an implementation detail on Catalyst. I do not believe you can change that with existing APIs.

Unless you require some of the animations (like page curl), I would highly recommend using UICollectionView as a basis for a paging view. It can handle more flexible cases and allows you to very easily change pages by doing scrollToItem(at:at:animated:). Plus, if you need a paging indicator, you can add a UIPageControl separately into the view and be able to position it anywhere, unlike UIPageViewController which only shows the page indicator when you implement some of the dataSource methods and it is only positioned underneath the content and not overlaid.

In iOS 14, you should not use the UIDatePicker as the inputView, in fact, you can replace the text field with the UIDatePicker directly. If you use the .inline preferred style, then your uses will just get an inline date picker that has all the input fields configured. If you don't configure the style, the automatic style by default will provide .compact and will display a label that will open the input fields on tap. Check the UIDatePickerStyle - https://developer.apple.com/documentation/uikit/uidatepickerstyle API page for more detail or the WWDC20 session Build with iOS pickers, menus and actions - https://developer.apple.com/wwdc20/10052 to find out more about the new design.

Assuming you are using Swift, you can use the if #available conditional to check branch your code between different iOS versions that support something your minimum deployment target does not. You will also need to annotate any types that requires iOS versions higher than your minimum deployment target with the @available macro. For example, suppose you want to create ExampleView and ExampleViewController for in SwiftUI (iOS 13+) and UIKit (iOS 11 and iOS 12), you can do the following: @available(iOS 13.0, *) struct ExampleView : View { /* ... */ } class ExampleViewController : UIViewController { /* ...	*/ } /* Branching between SwiftUI vs UIKit based on iOS versioning */ let destinationViewController: UIViewController if #available(iOS 13.0, *) { destinationViewController = UIHostingController(rootView: ExampleView()) } else { destinationViewController = ExampleViewController() } self.present(destinationViewController, animated: true, completion: nil) Similarly, if you use Objective-C, you can do the following: if (@available(iOS 13.0, *)) { /* ... using APIs for iOS 13 and above. */ } else { /* ... fallback on iOS 12 and below */ } Anyone running iOS 12 and below will see ExampleViewController, whereas anyone on iOS 13 and above will see the SwiftUI view.

Check out the sample project found in the Implementing Modern Collection Views - https://developer.apple.com/documentation/uikit/views_and_controls/collection_views/implementing_modern_collection_views page. These is an example on creating custom cells in there. Look for CustomListCell and you will find what you are looking for.

If I had to guess, those menu APIs were deprecated in favour of the UIContextMenuInteraction - https://developer.apple.com/documentation/uikit/uicontextmenuinteraction APIs introduced in iOS 13. There are UICollectionView convenience APIs for them too, found here - https://developer.apple.com/documentation/uikit/uicollectionviewdelegate/3295917-collectionview. You can learn more about them in the WWDC2019 session Modernizing Your UI for iOS 13 - https://developer.apple.com/wwdc19/224 at about the 38 minute mark; or the new APIs and enhancements for them in iOS 14 in the Build with iOS pickers, menus, and actions - https://developer.apple.com/wwdc20/10052 talk.

You can (and should) use the visibleItemsInvalidationHandler on orthogonal sections for the most accurate detail on your current scrolling context. let section = NSCollectionViewSection(group: group) section.visibleItemsInvalidationHandler = { visibleItems, scrollOffset, environment in /* ... use scrollOffset to determine the paging behaviour */ } /* ...other setup */ let layout = UICollectionViewCompositionalLayout(section: section)

You can ignore the Auto Layout warnings from UIContextMenuInteraction since that can only be resolved by Apple. There should be no effect on your or your users though, so it is fine to ignore it.