How do we know the user denied access to Local Networks access?

Thank you for the response. Well I can always implement and compare, but implementing the most optimal strategy and finding the most optimal set of instructions may be hard in a multilayer setup with so many visual element types. If we just keep black video(1 frame of size 480x320 stretched to fit timerange) in the below layers of passthrough tracks, will the decoder have any extra hard time decoding the black videos? In other words, passthrough track + black video vs passthrough track, is it any different?

Well I already mention app name, but still they rejected. I could go longer by saying <Appname> requires microphone to record audio for video tracks. Without this permission, video clips would be silent. But this becomes unnecessarily long and confusing. I checked tons of other video camera apps and they write stuff such as "this allows app to record audio". The thing is in a video camera app, isn't it obvious that microphone permission is needed to record audio?

I have filed a bug and captured all the videos & photos as the problem happened. Because when the problem happens, nothing can be extracted from the device, nothing can be saved on the device, the device fails to sync to computer. I didn't hear back from Apple so far as it is a very critical iOS bug threatening severe data loss. The feedback ID is FB8334182. Core iOS engineering team must investigate the issue as there is no guarantee that the problem is fixed in iOS 14 beta 5 or not. Reproducing the problem is a nightmare which everyone would avoid.

Thanks for response. May I know what is the limitation on devices running iOS13 and above? Can they safely support 6-8 decoders? Because I heard AVFoundation can support simultaneous eight AVAssetWriter sessions for encoding. I believe decoding is easier so should support atleast 8 tracks?

There is another solution I found. Present &amp; dismiss a custom dummy view controller which should be full screen and whose supportedInterfaceOrientations are precisely the orientation you want your view controller to be set to. This does not use unofficial APIs but is a hack to force autorotation.

The only unofficial solution to forcefully rotate the device is by using this code, but it is undocumented. Can't use it in production code as one day it may be broken. &#9;&#9;&#9;&#9; if view.bounds.width > view.bounds.height {        &#9;     UIDevice.current.setValue(UIDeviceOrientation.portrait.rawValue, forKey: "orientation")         } else {             UIDevice.current.setValue(UIDeviceOrientation.landscapeLeft.rawValue, forKey: "orientation")         } This works no matter whether the portrait orientation is locked on device or not.

Dear UIKit Engineers, Do you have any inputs on this, still looks unresolved on iOS14!

FYI, the problem is more accurately described in the following SO link with images: https://stackoverflow.com/questions/63418881/uikit-glitch-on-ios14-for-projects-without-uiscenedelegate

Dear UIKit Engineers, This is a bug with XCode projects not having UISceneDelegate (pre iOS 13) and is very simple to reproduce. Just have an XCode project without UISceneDelegate and have a hidden subview with white background in the Storyboard. Unhide this subview in viewDidLoad and see the glitch on startup in landscape mode. I have filed feedback FB8400870. Is there any known workaround? This is causing very bad app load experience.

Dear Apple Engineers, thanks for replying. I found that tmp folder was growing by leaps and bounds and had to clear gigabytes of space by removing everything in tmp folder. My question now is why iOS never deleted storage in the tmp folder? Doesn't iOS periodically clear space in tmp folder?

I found that setting GPU Frame Capture to "Disable" or "Metal" fixes it. The default choice in Scheme option is "Automatically Enabled" which is the culprit.

I found the bug. This is caused by a single line of code such as&#9; public var metalDevice:MTLDevice? = MTLCreateSystemDefaultDevice() Can't believe such a terrible bug is not encountered by anyone so far?

The problem happens on iOS 14 beta 3 as well. When using XCode 12 beta 3 and connecting the device to debugger, view controller doesn't autorotate. Using XCode11 solves the problem though, but I need XCode 12! Apple Engineers, are you aware of this issue?

I found it eventually but this is driving me crazy to share projects between XCode11 and XCode12. At times I need XCode12 to test new iOS14 APIs but then XCode12 beta 3 is too buggy so coming back to XCode11 is painful. There are lot of code changes required to make the project compatible with XCode11. For instance, this code if usingFrontCamera {    preferredAutoMicrophoneOrientation = AVAudioSession.Orientation.front } else {  preferredAutoMicrophoneOrientation = AVAudioSession.Orientation.back } It requires a different approach altogether in XCode11. Setting it to AVAudioSession.Orientation.orientationFront doesn't work!