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?

Our iOS apps use to embed and sign third party frameworks built for various architectures (i386 x86&#92;&#95;64 armv7 arm64). When building an archive, a script phase strips unwanted architectures (simulator ones) from the build. Everything was working fine until XCode 12.3 (updated this morning). Now, what seems to be a "Target integrity" check always reports the following error for these embedded frameworks (example with GoogleCast framework): error: Building for iOS, but the linked and embedded framework 'GoogleCast.framework' was built for iOS + iOS Simulator. Also, as these frameworks are synced from a server at build time using a script phase, if I delete the frameworks before compiling, there are no errors and the app is built properly. But if the frameworks are already synced, the compilation systematically fails right away. Finally, other frameworks with the same architectures but that are not embedded don't trigger this error. I've tried to changes some build settings regarding the architectures but with no success. Could you please tell me how to embed these frameworks, keeping in mind they are third-party frameworks? Cheers, Aurélien

For Q&amp;amp;A and logging purposes, I need to know whether the response to an URLSessionDataTask comes from the URLCache or not. I've read here and there that it was just a matter of comparing the cachedResponse before and after receiving the dataTask response. But it does not work as each call to URLCache.shared.cachedResponse(for: urlRequest) returns a new instance of CachedURLResponse (each one having another new instance of HTTPURLResponse). Am I missing something? Is there another way to tell if the response comes from the cache?