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.

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 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.

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.

Thanks azhukov for your response. To give a bit of context, the content displayed by our app is mostly defined by the data the app receives from our backend (including the content hierarchy). It does not know beforehand which kinds of cells it will be asked to display. Most of the screens are base on the very same UIViewController (embedding a collectionView) which is highly configurable and controlled by the server data. For now we use 8 different cells types but it regularly increases as we include more various types of content, hence ways to present it. Our cells registrations lazy instantiation are global and are done once and for all; these instantiations are not local to a UIViewController (in the viewDidLoad() as you assumed). Moreover, the collectionView data describes the cells to use for each section and it makes no sense to parse the data before building the data source in order to force the lazy instantiation of cells registration that will be used. Finally, the cell registrations being only necessary in the UICollectionViewDiffableDataSource cell provider block, it seems absurd to instantiate all cell registrations beforehand whereas only some of them may be used during the app lifetime.      // sections cells registration     dataSource = UICollectionViewDiffableDataSource<Section, SectionItem>(collectionView: collectionView) { collectionView, indexPath, item in       let cellRegistration = item.section.widgetConfig.tileConfig.type.cellRegistration // lazily instantiated       return collectionView.dequeueConfiguredReusableCell(using: cellRegistration, for: indexPath, item: item)     } Instantiating objects once and for all and only when required to is definitely a good practice, just as are Swift class properties. And forbidding cell registrations instantiation inside a diffableDataSource cell provider block seems to me a false good idea introduced in iOS/tvOS 15.

Issue reported to Apple with the Feedback Assistant: FB9650519.

Turns out the Xcode "Validate App" action does not provide an explicit error whereas the "Distribute App" action does. And I've been able to fix my issue: the TV Top Shelf executable name in its Info.plist did not match the bundle folder name.

Apple documentation indicates that it is supported (https://developer.apple.com/documentation/mediaplayer/handling_external_player_events_notifications) but I haven not found any sample code nor been able to make it work my self. My goal is to allow the user to control the GoogleCast playback from the CommandCenter.

Many thanks for your reply. I indeed ended up with the two changes: For HTTP 1.1 requests, I added the "Connection: close" request header For HTTP 2 requests, I implemented the (empirical) detection of such errors and a one-time retry Both changes allow the app to either avoid the issue (1) or seamlessly handle it (2). Unfortunately, it does not help with the related issue (which is fortunately far less systematic) as the requests fail several (tens of) seconds after the dataTask is sent, time during which the user waits for his action to be performed or information to be displayed. But maybe this related issue is not as related as I think...

Same logs when opening the share sheet on iOS 17.

Have you received any feedback from Apple or even found out what was the problem? It may not be related but I'm currently having a CoreMediaErrorDomain -12035 error using the same AV adapter when streaming FairPlay-protected content but only on iOS 18+. It works fine on iOS 17.7. https://developer.apple.com/forums/thread/770159

Thanks for your response. I filed a bug report on Feedback Assistant with the following id: FB16047318 (CoreMediaErrorDomain -12035 error when playing a Fairplay-protected HLS stream on iOS 18+ through the Apple lightning AV Adapter).

Sure: https://feedbackassistant.apple.com/feedback/16902752

Actually the problem is even worse: the AVPlayer.currentTime() does not change anymore after the playback transitions from AirPlay (to an Apple TV) to local despite the playback still ongoing. Also, it's worth noting that when the issue occurs, AVPlayer.currentDate() is properly updated. So the problem is probably not related to the periodic time observation but rather to the AVPlayer.currentTime() not being updated anymore when switching from AirPlay to local playback.

I have reported the issue with Feedback assistant: https://feedbackassistant.apple.com/feedback/17172515 I have also included a sample project allowing to easily reproduce the issue.