I have figured out a solution. This post on StackOverflow helped out immensely: The secret is to use an SKRenderer() in addition to the SKView renderer. They are not mutually exclusive. The example referenced above uses a SceneKit view as the source, grabs a metal texture from the SceneKit scene, and then uses that metal texture as the texture of a second SceneKit scene that has a single plane object using the metal texture as its diffuse texture. The same setup works with SpriteKit: For my use case, I was able to implement using a single SKScene, rendered to both an SKView() and an SKRenderer() - just call the SKRenderer.render() method inside your SKScene.update() method. The SKRenderer is what is used to render the scene into a MTLTexture using a renderPassDescriptor. I found that I had to call SKRenderer.render() and commandBuffer.commit() prior to updating any SpriteKit nodes - but it works great. That MTLTexture can then be used however is necessary. In my test setup, I also rendered it to a separate SCNView using a single plane node.

Same issue. I went through a whole bunch of permuations - and it seems this is limited to any 16.4 tvOS simulator - tested both 3rd gen and 2nd gen with 16.4 and both show black screen for video. Note that older versions of the simulator (16.1, 16.0) work just fine. So far, video seems to be working on real device with 16.4.1

Found the answer on SO... you can set these values using the AVMetadataItem with the identifiers: AVKitMetadataIdentifierExactStartDate, AVKitMetadataIdentifierExactEndDate

Same issue. tvOS application Does not use Unity at all.

This is one of the most annoying issues I have found with tvOS. What I have found is that when a UIScrollView enters in this "fastFocus" scroll mode, the focus moves to UIView of type "UIFocusFastScrollingIndexBarView". So what I did was put a check in my didUpdateFocus() function like so: if let tempNextFocusView = context.nextFocusedView { let desc = type(of: tempNextFocusView).description() let isFastFocusMode = desc.contains("_UIFocusFastScrollingIndexBarView") } At least now I know when I am in this mode. One of the biggest issues I have is that it can be difficult to get a notification that the user has exited out of this mode. There are use-cases where none of my UIScrollView delegate functions are called - typically if the user does a bunch of fast swiping and then clicks to stop scrolling then scrolls again... No items will receive focus and none of the scrollView delegates are called. i.e., our QA can break this pretty easily.

I am also getting this crash. Same circumstances. Starting up a video stream using AVPlayerViewController. I also set up both a AVPlayerItem.status observer as well as a "timeControlStatus" observer. Then when I change to a different stream, I remove the observers, stop the current stream using player.replaceCurrentItem(with:nil) - nil out properties holding on the playerItem & player properties. Then start a new stream, creating all new playerItem (AVPlayerItem) & player (AVPlayer) objects. Is there a known workaround or a way to prevent this crash? Am I doing something wrong? This current strategy has worked for years. Getting reports from the customers about this crash.

Update: Problem has been found. The 3rd party framework has an invalid UIDeviceFamily in their info.plist file. The framework has both "3" and "5" as properties, but the app and framework is only for tvOS (which is "3"). Interestingly, Apple developer support kept insisting that the app was getting stuck in "processing" because it was too large - which at a whopping 24 MB (compressed @ 12 MB compressed) seemed a little far fetched to me. So as I was going through the steps of proving that the app was indeed only 12 MB, I decided to an AdHoc build locally and export it so I can send it to the Apple dev support engineer. Well, that produced the first clue - as exporting that archive failed with the following error: ipatool failed with an exception: #RuntimeError: Unknown UIDeviceFamily: '5' from '[\"3\", \"5\"]' Apparently a UIDeviceFamily of "5" is the Apple HomePod. I have no idea why the info.plist for the 3rd party library includes this in their info.plist file for a framework that is tvOS only - but that was the problem. I was able to edit the .plist file and remove the "5" from the UIDeviceFamily list and it now processes immediately on the TestFlight app store. The interesting thing in all of this is that I never saw a warning or error when archiving and uploading to the App Store. It was only when I tried to export an AdHoc build that the export process produced and error.

We are having this issue as well. This seems rather serious. I can see Apple offering an official "swipe-up" implementation - however, there has to be a way to disable this so that apps that have already rolled their own swipe-up are not borked. I was able to verify that Aleksandr's solution does work - but that feels like a very temporary workaround.