Have you found any solution, workaround or fix for this issue? I'm having the same issue and I've not found any way to make it work, making the whole solution useless! Please Apple engineers, could you please let us know how to set the initial selected index when dealing with a TVCollectionViewFullScreenLayout? Thanks.

I ended up cleaning the entire Xcode "iOS DeviceSupport" folder as it proved to be useful in the past and I cannot reproduce the issue anymore! However, the other developer in my team has the same issue so it's not specific to my computer. I guess we will never know what was going on.

Hi eskimo, Yes, 2.0 is the expected result. Here is my detailed configuration: • MacBook Pro 2020, Intel processor • MacOS 11.4 (but reproduced yesterday with 11.3.x) • Xcode 12.5 • Simulators: iPhone 8 (14.5), iPhone 8 (12.4), iPhone 8 Plus (14.5), iPhone 12 Pro Max I always get the following result: (lldb) po (398.0 / 165.0).rounded()e-321 You don't even have to set a breakpoint to get an unexpected result (though different) as the instruction print("Rounded result: \((398.0 / 165.0).rounded())") logs Rounded result: 2.412121212121212 FYI I've filled in a bug report (FB9118612).

I'm having the same issue with consumable products in Sandbox environment (https://developer.apple.com/forums/thread/678105). The first purchase for a given product goes well but any subsequent purchase for this product will end up by the system restoring the first transaction instead of creating a new one. In the end, the purchase fails as our backend refuses to validate the receipt (the transaction identifier being already validated once). I made sure all transactions in purchased or restored states are properly finished (the removedTransactions callback being called each time), although the call to finishTransaction may be asynchronous (after our backend (in)validates the receipt). However, each time the app starts or goes to foreground again, the first successful finished transaction keeps on appearing in the SKPaymentQueue as if it had not been finished. Finishing this transaction right away does not change anything. One sentence worries me in the SKPaymentQueue finishTransaction documentation page : In rare circumstances, this call might fail, and you'll receive updates for that transaction again. It looks like we are experiencing this situation but we have no way to check if the call to finishTransaction failed nor why did it fail. Moreover, there's apparently no way to work around this issue and allow subsequent purchases (for the same product). Also I'm pretty sure I was not experiencing this issue last week (using the same app distributed via Testflight). I don't know if it's an issue with the Sandbox environment or with the Storekit libs and I cannot test the production environment yet. But I'm not confident at all releasing our first support of in-app purchases. Aurélien.