What follows is about tvOS 15 but may also apply to iOS 15. Our app may display several types of UICollectionView cells and it depends on the content sent by our backend. Prior to tvOS 15, we used to lazily instantiate UICollectionView cell registrations when needed for the first time while building a UICollectionViewDiffableDataSource. Eventually, each cell registration is only instantiated once (or never). Now tvOS 15 throws an exception when doing so, pretending to prevent the app from creating a new cell registration each time. And it does not care whether it's actually a new cell registration each time or one that is lazily instantiated once. Here is the exception: *** Assertion failure in -[UICollectionView dequeueConfiguredReusableCellWithRegistration:forIndexPath:item:], UICollectionView.m:7413 *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Attempted to dequeue a cell using a registration that was created inside -collectionView:cellForItemAtIndexPath: or inside a UICollectionViewDiffableDataSource cell provider. Creating a new registration each time a cell is requested will prevent reuse and cause created cells to remain inaccessible in memory for the lifetime of the collection view. Registrations should be created up front and reused. Registration: <UICollectionViewCellRegistration: 0x6000000f8c60>' I understand the concern but lazy instantiation is a thing and it should not be for forbidden for the sake of best practices that are not related to it. In my humble opinion, this assert should be removed and apps should be allowed to create cell registrations on the fly.

When using rounding methods (rounded(), rounded(toPlaces:), round(_: CGFloat)) on CGFloats with the simulator, the returned value is not rounded at all or sometimes makes no sense at all. (lldb) po (398.0 / 165.0).rounded()e-321 The expression may even crash when called from an attached debugger (the following expression returns 2.4121212... when no debugger attached): (lldb) po (availableWidth / (cellRatio * (tileType.sectionHeight - 50))).rounded() error: Execution was interrupted, reason: EXC_BAD_ACCESS (code=1, address=0x7c). The process has been returned to the state before expression evaluation. The same operations are OK on a real device or in a playground on a Mac. It's also OK when converting the CGFloat to a Float and calling roundf() as follows: (lldb) po CGFloat(roundf(Float(availableWidth / (cellRatio * (tileType.sectionHeight - 50)))))0 Finally here are the results when passing various rounding rules to the rounded() method: .toNearestOrAwayFromZero: crash in debugger .toNearestOrEven: 2.412121212121212 (unchanged value) .up: inf .down: 2.412121212121212 (unchanged value) .towardZero: 2.412121212121212 (unchanged value) .awayFromZero: inf Is there something wrong with computing rounded values of CGFloats on a simulator?