xcode github

The crash issue that @edorphy reported in FB21121092 is resolved when you build the app with the released Xcode 26.2 version that came out today, build number 17C52. This version is not the same build as the Xcode 16.2 Release Candidate, so make sure to update to the final release version. @edorphy, had a follow-up statement to me for a different but related issue: you or others may have already seen this one but just in case you haven't: FB21240249 - DeclaredAgeRange: DeclaredAgeRangeAction symbol unavailable on macOS catalyst apps causing crash - documentation says otherwise I appreciate that! I personally had not seen this report, though others within Apple have. We're looking in to it. — Ed Ford,  DTS Engineer

Even with the new Xcode (not release candidate), I get error when uploading from Xcode: Validation Failed: This bundle is invalid. Apple is not currently accepting applications built with this version of Xcode. This is with Xcode 26.2 which has Released December 12, 2025 and Build 17C52. Also, the file name is Xcode_26.2_Apple_silicon.xip.

This screenshot is with the Xcode 26.2 (175C2), which supersedes the RC version and was downloaded from the Apple Developer website directly. Not showing at the time of writing on the App Store and seemingly its builds are not accepted (yet).

The weird thing is, SecKeyCreateRandomKey() does create an entry with the correct ACL where only my program can access the key. In all cases I'm creating the ACL simply like so: SecAccessCreate(label as CFString, nil, &acl) The program should also have a valid code signature, because otherwise macOS doesn't even let it start up. Running from a terminal immediately results in Killed: 9, with the Console program showing an accompanying ASP: Security policy would not allow process, and opening from Finder results in The application “something.app” can’t be opened. And indeed, I do have a Personal Team set in Xcode, it's just not enrolled in the paid developer program. I did also notice that my signed executables actually ran even without updates within a year, so I simply figured that it works because my Personal Team's certificate was still in fact signed by Apple, it just doesn't have access to any restricted entitlements. Since I'm not using those, there's also no provisioning profile to deal wit

I also have the same problem on a MacStudio M1Max (and not on a MBP M1Max) after upgrading to Xcode 26.1.1: no MetalToolchain accessible from this application. Running on Tahoe 26.1 Running today xcodebuild -downloadComponent metalToolchain gives: `Beginning asset download... Downloaded asset to: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/68d8db6212b48d387d071ff7b905df796658e713.asset/AssetData/Restore/022-20369-066.dmg Done downloading: Metal Toolchain 17B54.` Then when I run xcrun metal --version, I got an error message: error: error: cannot execute tool 'metal' due to missing Metal Toolchain; use: xcodebuild -downloadComponent MetalToolchain Last when I run: xcodebuild -showComponent metalToolchain, I got: 2025-12-12 18:34:14.045 xcodebuild[27394:1591467] IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “com.apple.MobileAsset.MetalToolchain-v17.2.54.0.BttmuJ” couldn’t be opened because you don’t have permission to view it. 2025-12-12 18:3

First up, you’re correct that there’s a contradiction here: Apple has effectively deprecated the file-base keychain in favour of the data protection keychain. But the Personal Team limits, which come from iOS, run counter to the expectations of macOS developers. I don’t have any answers for you on that front, but if you file a bug describing this contradiction and post the bug number here, I’ll make sure that the relevant folks see it. Coming back to your real issue, there’s a lot to unpack there and I don’t have time to dig into it all. However, you seem to have bumped into a pretty fundamental limitation: You want the system to protect your item such that only your program can access it. But you’re not giving it any code-signing credentials to do that. Something has to give. The file-based keychain has a bunch of legacy access control centred around code-signing requirements — see TN3127 Inside Code Signing: Requirements — so that’s one thing you might explore. But that still requires you to have a stable c

I also can't open Xcode Cloud page on appstoreconnect. Any chances It can be fixed?

Well, that’s weird. And it doesn’t gel with my experience. Admittedly, that was all prior to iOS 26, so it’s possible we broke something. I’m gonna try to reproduce this here in my office, but I won’t have time to do that until after the winter break. [quote='869103022, captadoh, /thread/808917?answerId=869103022#869103022, /profile/captadoh'] Are you open to me inviting you to a private Github repo? [/quote] It’s much more convenient to do this with public source code. Keep in mind that you don’t need a full app to test this. Just getting TCP to connect (or the QUIC tunnel) is sufficient to confirm that peer-to-peer Wi-Fi is working. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='869201022, Gong, /thread/765648?answerId=869201022#869201022, /profile/Gong'] Same issue here. [/quote] Are you specifically referring to the com.apple.CommCenter.fine-grained? If so, are you seeing this problem only with Xcode Cloud builds? Or are you seeing it when you build with Xcode locally? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You tagged your thread with “Swift Playground”. Does that mean you’re using the Swift Playground app? Or using Xcode with a playground project? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com