@FrameworksEngineer This fixed it! Thank you!

I should note that I'm not referring to .compact column mode (I have that working great). I'm referring to when the app is wide enough that the width class is still regular, so the triple column style is shown, but the screen is narrower due to portrait orientation or when another app is multitasked next to your app.

Not official, but I found this awesome sample project on GitHub: https://github.com/marcosatanaka/sidebar-ios14 It's very basic but gives a good idea of how to generally setup a UISplitViewController as root view and implement a Sidebar. It also gives some sample code for the new ways of setting up UICollectionViewCellRegistration and section snapshots with DiffableDataSource!

For any future readers: I figured out that it's important to set BOTH .preferredDisplayMode and .preferredSplitBehavior when the view transitions. Setting just one or the other will result in lots of weird behavior. What I figured out works for this case is setting preferredDisplayMode = .twoBesideSecondary and preferredSplitBehavior = .tile when the screen is wide enough to fit all 3 columns, and when it is not, set preferredDisplayMode = .oneBesideSecondary and preferredSplitBehavior = .displace. I used a function that checks if the view.frame.size.width < 1194 to determine if the screen is full width or not, as using orientation only would cause problems if the app is side by side with another. I'll probably tweak that value over time so don't take it as gospel, but it works for now. I call this function in viewDidLoad for initially setting the behaviors, then again in viewWillTransition(toSize:), using the size property there to update the behaviors.

I was having a similar issue, was basically trying to recreate the triple column behavior of the Contacts app on iPad in iOS14. Here's what I found works for me: I figured out that it's important to set BOTH .preferredDisplayMode and .preferredSplitBehavior when the view transitions. Setting just one or the other will result in lots of weird behavior. What I figured out works for this case is setting preferredDisplayMode = .twoBesideSecondary and preferredSplitBehavior = .tile when the screen is wide enough to fit all 3 columns, and when it is not, set preferredDisplayMode = .oneBesideSecondary and preferredSplitBehavior = .displace. I used a function that checks if the view.frame.size.width < 1194 to determine if the screen is full width or not, as using orientation only would cause problems if the app is side by side with another. I'll probably tweak that value over time so don't take it as gospel, but it works for now. I call this function in viewDidLoad for initially setting the behaviors, then again in viewWillTransition(toSize:), using the size property there to update the behaviors.

Having this issue on Xcode 12.5 & iOS 14.6 as well. Previously had no difficulty getting auto-height cells using NSCollectionLayoutSize.estimated() for heights, but now they only correct themselves after scroll begins. Any resolution yet?

Anyone found a solid solution for this? Calling collectionView.collectionViewLayout.invalidateLayout() immediately after my dataSource.apply() call gets the cells to display correctly prior to beginning scrolling, but it seems hacky and doesn't look great while the data loads into the cells.

This still seems to be an issue on Xcode 13.1 on M1Pro 14" MacBook Pro. I see the same error with trying run on on my iPhone 13 Pro Max. Stalls every time on a fresh build, but it will resolve itself after 5 or so minutes and then isn't an issue on subsequent runs. Quitting Xcode and re-opening repeats this process. It never resolves when trying to build to device via network, only when plugged in. Ugh.

Just downloaded the Xcode 13.2 Beta, which the release notes say has addressed this issue, and no luck. Seeing the same behavior for Xcode 13.2 Beta even after rebooting all devices again. Mac, iPhone, and Apple Watch are on the latest software.

We are seeing this issue on our large project. Any recommendations to resolve? M1 Pro (MacBook Pro, 2021, 16-inch) macOS Monterey 12.2 Xcode 13.1 iOS 15.0 simulator Running Xcode via Rosetta due to a dependency that has not supported arm yet. We just switched over our text entry methods from using XCUIElement.typeText(...) to using paste instead because of the slow typing bug on iOS 15.0+ simulators with the .typeText() method. We paste text into the simulator via setting the string in UIPasteboard.general.string, then triggering & tapping the "Paste" menu item for a text entry element. No errors are thrown or seen, the "<app_name> pasted from..." toast alert shows, but the text just never appears in the app. The issue persists in the same environment but on a iOS 14.5 simulator, so it doesn't seem to be specific to iOS 15.0+ simulators.

I had the same issue. macOS 12.4, downloaded the first Xcode 14 beta and noticed right away that "toggle appearance" in the simulator no longer works, even when going back to Xcode 13.4. Only option is to trigger manually via Settings > Developer in the simulator. I tried @bunnyhero 's approach and it worked! Thank you!

Here are the CustomHeader and CustomCell classes (restricted due to post character limit): CustomHeader: class CustomHeader: UICollectionReusableView { private lazy var label = makeLabel() override init(frame: CGRect) { super.init(frame: frame) backgroundColor = UIColor.systemBlue.withAlphaComponent(0.10) setupViews() } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } func set(headerText: String) { DispatchQueue.main.async { self.label.text = headerText } } private func setupViews() { addSubview(label) NSLayoutConstraint.activate([ label.topAnchor.constraint(equalTo: topAnchor), label.leadingAnchor.constraint(equalTo: leadingAnchor), label.trailingAnchor.constraint(equalTo: trailingAnchor), label.bottomAnchor.constraint(equalTo: bottomAnchor) ]) } private func makeLabel() -> UILabel { let label = UILabel() label.text = "Header Title" label.font = UIFont.systemFont(ofSize: 18, weight: .semibold) label.textColor = .label label.textAlignment = .left label.numberOfLines = 0 label.translatesAutoresizingMaskIntoConstraints = false return label } } CustomCell: class CustomCell: UICollectionViewCell { private lazy var label = makeLabel() private let padding: CGFloat = 20 override init(frame: CGRect) { super.init(frame: frame) setupViews() } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } func set(cellText: String) { DispatchQueue.main.async { self.label.text = cellText } } private func setupViews() { backgroundColor = .secondarySystemGroupedBackground layer.cornerRadius = 12 layer.cornerCurve = .continuous contentView.addSubview(label) NSLayoutConstraint.activate([ label.topAnchor.constraint(equalTo: contentView.topAnchor, constant: padding), label.leadingAnchor.constraint(equalTo: contentView.leadingAnchor, constant: padding), label.trailingAnchor.constraint(equalTo: contentView.trailingAnchor, constant: -padding), label.bottomAnchor.constraint(equalTo: contentView.bottomAnchor, constant: -padding) ]) } private func makeLabel() -> UILabel { let label = UILabel() label.text = "No text available." label.font = UIFont.systemFont(ofSize: 15, weight: .regular) label.textColor = .label label.textAlignment = .left label.numberOfLines = 0 label.translatesAutoresizingMaskIntoConstraints = false return label } }

Screen shot of what it's supposed to look like on first load, but instead currently it only looks like this after the supplementary view/cell have been reused:

Same here. M1 Pro MacBook Pro and iPhone 15 Pro Max, all on latest OS and Xcode (15.2). Connected via USB cable, and the app launches instantly but its just a blank screen for 20-40+ seconds. About 50% of the time I just have to kill the build and restart because it gets stuck and my app's UI just never shows. But when I turn wifi off on the device, it's nearly instant as expected. Also no issues at all building to a simulator. Building to a physical device is completely unusable for me currently.

Same. Hoping to find a non-beta solution as well.