I'm seeing a camera preview rotation issue on iPadOS 27 that depends only on the SDK the app is linked against. I've filed it as FB25106148 and wanted to share it in case others hit the same problem. Sample project: https://github.com/bc-lee/avfoundation-rotation-coordinator-discrete-resizing-poc Setup Portrait-only iPad app with UIRequiresFullScreen = YES Front camera AVCaptureVideoPreviewLayer, rotated with AVCaptureDevice.RotationCoordinator, as in the AVCam sample: let coordinator = AVCaptureDevice.RotationCoordinator(device: device, previewLayer: previewLayer) // On every change of videoRotationAngleForHorizonLevelPreview: previewLayer.connection?.videoRotationAngle = coordinator.videoRotationAngleForHorizonLevelPreview iPad Pro 11-inch (4th generation), iPadOS 27.0.1, Stage Manager on, Rotation Lock off What happens after rotating the iPad from portrait to landscape Xcode 26.5 (iOS 26.5 SDK) Xcode 27.1 RC (iOS 27.1 SDK) App UI Stays upright for the user, letterboxed Stays in portrait and lies on its side with the device (discrete resizing, TN3192) videoRotationAngleForHorizonLevelPreview 180° 180° Camera preview Upright Sideways The source code and Info.plist are the same for both builds. interfaceOrientation, effectiveGeometry, window and screen bounds, and isInterfaceOrientationLocked are also identical between the two builds, so I couldn't find a public value that tells the two presentations apart. In the iOS 27 SDK build, applying videoRotationAngleRelative(toDeviceOrientation:) (new in iOS 27) for the scene's interface orientation, which gives 90°, instead of the horizon-level preview angle restores an upright preview. Questions Is videoRotationAngleForHorizonLevelPreview expected to reflect the discrete resizing presentation in iPadOS 27? Until that is resolved, is using videoRotationAngleRelative(toDeviceOrientation:) with the scene's interface orientation, only when linked against the iOS 27 SDK and running on iOS 27, a reasonable workaround? Has anyone else seen this, or found a better approach?

Summary: After upgrading to Xcode 26.4, app-hosted XCTest execution on physical devices running iOS 16 fails at test-planning time with "Logic Testing Unavailable." The same project and same device work under Xcode 26.2. The failure reproduces with a standalone minimal Xcode project, which suggests this is an Xcode regression rather than a project-configuration issue. Environment: Xcode: 26.4 (17E192) macOS: Tahoe 26.4 Failing device: iPhone 11 (iPhone12,1), iOS 16.0.3 Working comparisons: Xcode 26.2 + same iPhone 11 (iOS 16.0.3): works Xcode 26.4 + iPad Pro 11-inch (4th generation) on iOS 26.3: works Regression: Yes. Works on Xcode 26.2. Fails on Xcode 26.4. Same project, same signing setup, same physical iOS 16 device. Minimal reproduction: A minimal sample project with: one iOS app target one app-hosted unit-test target one UI-test target (for comparison; not required to reproduce) Steps for the unit-test repro on a physical device running iOS 16: Build for testing: xcodebuild -project TestProject.xcodeproj \ -scheme TestProject-UnitTests \ -sdk iphoneos \ -destination 'platform=iOS,id=<DEVICE_UDID>' \ -derivedDataPath DerivedData-Device-Unit \ -resultBundlePath Results-Device-Unit-Build.xcresult \ DEVELOPMENT_TEAM=<TEAM_ID> \ CODE_SIGN_STYLE=Automatic \ build-for-testing Run tests without building: xcodebuild -project TestProject.xcodeproj \ -scheme TestProject-UnitTests \ -sdk iphoneos \ -destination 'platform=iOS,id=<DEVICE_UDID>' \ -derivedDataPath DerivedData-Device-Unit \ -resultBundlePath Results-Device-Unit-Test.xcresult \ DEVELOPMENT_TEAM=<TEAM_ID> \ CODE_SIGN_STYLE=Automatic \ test-without-building Note: xcodebuild test (combined build and test) also fails with the same error. Expected result: The hosted unit tests run successfully on the connected physical device, as they do under Xcode 26.2. Actual result: Step 1 (build-for-testing) succeeds. Step 2 (test-without-building) fails immediately (within ~1 second) with: 2026-03-26 11:23:28.683 xcodebuild[51930:731004] DVTDeviceOperation: Encountered a build number "" that is incompatible with DVTBuildVersion. 2026-03-26 11:23:28.725 xcodebuild[51930:730966] [MT] DVTDeviceOperation: Encountered a build number "" that is incompatible with DVTBuildVersion. 2026-03-26 11:23:29.239 xcodebuild[51930:730966] Writing error result bundle to /var/folders/jl/knmkq18x4cg_3w087zgpfldm0000gn/T/ResultBundle_2026-26-03_11-23-0029.xcresult xcodebuild: error: Failed to build project TestProject with scheme TestProject-UnitTests.: Cannot test target “redacted” on “redacted”: Logic Testing Unavailable Logic Testing on iOS devices is not supported. You can run logic tests on the Simulator. Why this looks like an Xcode regression: The same project and same physical iOS 16.0.3 device work under Xcode 26.2. Under Xcode 26.4, build-for-testing still succeeds, so signing, provisioning, and bundle construction appear valid. The failure happens only when Xcode plans or launches the on-device test run. Before the failure, Xcode 26.4 logs: DVTDeviceOperation: Encountered a build number "" that is incompatible with DVTBuildVersion. A newer physical device running iOS 26.3 works under Xcode 26.4 without this warning. The issue also reproduces with a minimal standalone Xcode project, which makes a project-specific configuration problem unlikely. The Xcode-generated .xctestrun files for the passing Xcode 26.2 case and failing Xcode 26.4 case are structurally equivalent, making an .xctestrun format difference unlikely to be the cause.

Hello, I recently implemented a lock that uses OSAllocatedUnfairLock on iOS 16+ and os_unfair_lock on below iOS 16. I know that using os_unfair_lock with Swift is tricky, and it is error-prone. For example, the famous open-source library Alamofire has even been using os_unfair_lock incorrectly in terms of Swift's lifecycle view. (They fixed it as in the link [1] ) So, I implemented a lock like below. To use os_unfair_lock safely, I used the Noncopyable protocol which was added in Swift 5.9 [2]. Also, I allocated memory on the heap to use os_unfair_lock. public struct UnfairLock: ~Copyable { public init() { if #available(iOS 16.0, *) { _osAllocatedUnfairLock = OSAllocatedUnfairLock() } else { self.unfairLock = UnsafeMutablePointer.allocate(capacity: 1) } } deinit { if #unavailable(iOS 16.0) { unfairLock!.deallocate() } } public func lock() { if #available(iOS 16.0, *) { osAllocatedUnfairLock.lock() } else { os_unfair_lock_lock(unfairLock!) } } public func unlock() { if #available(iOS 16.0, *) { osAllocatedUnfairLock.unlock() } else { os_unfair_lock_unlock(unfairLock!) } } public func with<T>(_ closure: () -> T) -> T { lock() defer { unlock() } return closure() } private var _osAllocatedUnfairLock: Any? private var unfairLock: UnsafeMutablePointer<os_unfair_lock_s>? @available(iOS 16.0, *) private var osAllocatedUnfairLock: OSAllocatedUnfairLock<Void> { // swiftlint:disable force_cast _osAllocatedUnfairLock as! OSAllocatedUnfairLock // swiftlint:enable force_cast } } However, I got several crashes on iOS 14-15 users like this (This app targets iOS 14+ and on iOS 16+, it uses OSAllocatedUnfairLock): (Sorry for using a third-party crash reporting tool's log, but I think it is enough to understand the issue) BUG IN CLIENT OF LIBPLATFORM: os_unfair_lock is corrupt Crashed: com.foo.bar.queue 0 libsystem_platform.dylib 0x6144 _os_unfair_lock_corruption_abort + 88 1 libsystem_platform.dylib 0xa20 _os_unfair_lock_lock_slow + 320 2 FoooBarr 0x159416c closure #1 in static FooBar.baz() + 6321360 3 FoooBarr 0x2e65b8 thunk for @escaping @callee_guaranteed @Sendable () -> () + 4298794424 (<compiler-generated>:4298794424) 4 libdispatch.dylib 0x1c04 _dispatch_call_block_and_release + 32 5 libdispatch.dylib 0x3950 _dispatch_client_callout + 20 6 libdispatch.dylib 0x6e04 _dispatch_continuation_pop + 504 7 libdispatch.dylib 0x6460 _dispatch_async_redirect_invoke + 596 8 libdispatch.dylib 0x14f48 _dispatch_root_queue_drain + 388 9 libdispatch.dylib 0x15768 _dispatch_worker_thread2 + 164 10 libsystem_pthread.dylib 0x1174 _pthread_wqthread + 228 11 libsystem_pthread.dylib 0xf50 start_wqthread + 8 ( libplatform's source code [3] suggests that __ulock_wait returns error, but I don't know the details) Per @eskimo 's suggestion in [4], I will change my code to use NSLock until OSAllocatedUnfairLock is available on all users' devices (i.e. iOS 16+), but I still want to know why this crash happens. I believe that making a struct Noncopyable is enough to use os_unfair_lock safely, but it seems that it is not enough. Did I miss something? Or is there any other way to use os_unfair_lock safely? [1] https://github.com/Alamofire/Alamofire/commit/1b89a57c2f272408b84d20132a2ed6628e95d3e2 [2] https://github.com/apple/swift-evolution/blob/1b0b339bc3072a83b5a6a529ae405a0f076c7d5d/proposals/0390-noncopyable-structs-and-enums.md [3] https://github.com/apple-open-source/macos/blob/ea4cd5a06831aca49e33df829d2976d6de5316ec/libplatform/src/os/lock.c#L555 [4] https://forums.developer.apple.com/forums/thread/712379