Apple in all their wisdom has deprecated almost every API that can be used to get the interface orientation because they want developers to treat an orientation change as a simple size change. However, there are other uses for the interface orientation other than adjusting the UI. Since the camera is fixed to the device, and does not rotate with the interface, images from the camera need to be adjusted for orientation when displaying and/or processing them for computer vision tasks. Using traits is not a reliable way of determining the orientation, especially when running on an iPad. What is the recommended way to determine the relative angle of the camera in relation to the interface now all the interfaceOrientation APIs are deprecated? And specifically: how to get a notification of an interface orientation change?

I have a metal compute kernel that crashes MTLCompiler when I try to load the .metallib on an iPhone SE running iOS 14.4. I get the following error: MTLCompiler: Compilation failed with XPC_ERROR_CONNECTION_INTERRUPTED on 3 try Unable to init metal: Compiler encountered an internal error By selectively commenting out code I narrowed it down to the use of SIMD permute functions. These functions are supported by the iOS/Metal version running on the device, but not by the actual hardware (according to the metal features set table). I have 2 variants of this code, one that uses the SIMD permute functions and one that doesn't. My thought was to check the GPU family in Swift, then set a function constant supportsSIMDPermute and use this to ensure the correct variation runs on the device, like this: constant bool supportsSIMDPermute [[ function_constant(1) ]]; // kernel code if(supportsSIMDPermute) { // variant of code that uses SIMD permute } else { // Variant that uses slightly slower code that does not use SIMD permute } The library compiles without complaints in Xcode, but then crashes the on-device compiler when loading the library. Is this expected behaviour?

When I try to debug a metal shader on a device (iPhone 13 Pro), I get the following error: ' "Unable to create shader debug session Could not find any thread execution data for the dispatch call You may select a different thread position to debug and try again" The metal library is compiled with debug symbols/source code. If I go to the performance view it does give me per-line performance statistics like usual. Frame capture, statistics, etc. all work as expected. When I run the same code on the iOS simulator it can be debugged without issues. This only happens on device, and on multiple devices / iOS versions. Debugging also works on these devices in other projects. I also can't find any kind of logging anywhere that could give me a hint as to why it failed to collect execution data.

After updating to XCode 13, our library no longer works on XCode 12, even though module stability is enabled The XC12 build fails with the following error: arm64-apple-ios.swiftinterface:14:8: error: no such module '_Concurrency' import _Concurrency failed to build module 'XXXXX' from its module interface; the compiler that produced it, 'Apple Swift version 5.5 (swiftlang-1300.0.31.1 clang-1300.0.29.1)', may have used features that aren't supported by this compiler, 'Apple Swift version 5.4.2 (swiftlang-1205.0.28.2 clang-1205.0.19.57)' To be clear: my code does not use any of the Swift 5.5 concurrency features.

I am working on an app that uses some Metal compute shaders and trying to get this to work on the simulator. I am having an issue where the simulator freezes the entire OS (which eventually results in either a panic or WindowServer being killed and dumping me on the login screen). After some trial and error, and many reboots, I isolated the problem to a combination of 2 things: Using an atomic_fetch_add_explicit on an MTLBuffer from a compute kernel. Having the simulator set to prefer the discrete GPU. Without the atomic operation, everything runs fine on either GPU. With the atomic operation, it runs fine on the integrated GPU, but if I select the discrete GPU it freezes WindowServer, the GUI is completely unresponsive and frozen, but I can SSH into the machine (until it decides to panic). When it's frozen there aren't any processes using significant amounts of CPU time. I can reproduce this 100% of the time. I'm using a MacBook Pro 15" (2018, radeon 560X 4GB). It doesn't matter wether or not the discrete GPU is used by the OS.