xcode github

Thank you so much for the detailed, step-by-step instructions. I have now also uploaded a build to the AppStore, with an in-app extension. The key step that I had missed in my previous attempts is number 3 on your list: remove the Info.plist for the Extension that was generated by Xcode (and probably number 4, delete the INFOPLIST_FILE in build Settings). The extension is not yet doing what I want it to, but that's another problem. I can upload, so it's worth pursuing this line of work.

I'm using the current version of XCode from the App Store (Version 26.1.1 (17B100)). I set translatesAutoresizingMaskIntoConstraints to false on everything in sight and it has no effect on this debug pane spam. I appreciate your suggestion to just use Auto Layout, but I have a large project that does a ton of explicit layout that has been working great for many years now. I don't like the idea that I might have to rewrite huge amounts of code because Apple is trying to strong-arm me into using Auto Layout.

Hi everyone, After extensive testing and verification, we have finally resolved the persistent DriverKit archiving and signing errors. The core issue lies in the fact that Xcode enforces distinctly different certificate requirements for DriverKit targets during the Build Phase versus the Distribution Phase. We are sharing our successful experience to help other developers facing the same trap. 💡 Core Conclusion Do not attempt to configure the Distribution Profile directly in Xcode’s Target settings, as this will cause the build to fail. The correct workflow is: Use Development Certificates (Auto) during the Build/Archive phase, and only swap in the Distribution Certificates (Manual) during the Organizer Distribution phase. 🔍 Root Cause Analysis The DriverKit Linker mandates linking against the Development SDK during the build phase. If you force a manual Distribution Profile in Xcode’s Signing & Capabilities tab, Xcode will fail because it cannot find a matching devel

You should probably raise this as a bug in the usual way. It won't really get progressed if it's only posted in these Developer Forums. Raise it at https://feedbackassistant.apple.com/ and provide Xcode version and other relevant info. You should then post the FB number here so Apple devs can link it to this post.

Thanks for the file, the project is missing and the storyboard as well. Any chance to put it on a repository where I can download the zip file? So I can see as well all the project settings? I see you have created the setupViewx() in the code. Xcode 26.2 beta 2 is available for download, have you tried that version? Thanks, Albert Pascual
  Worldwide Developer Relations.

Same problem here, App was compiling and working before Tahoe, Using only the default menu bar, Get many of these error messages, App also not working properly (main window not displaying), App still compiles and works properly on another Mac with same latest Xcode version but with Sequoia, Working App copied over from old Mac to new Mac says The application <...> can't be opened. Really hoping Apple will fix this and magically solve this problem!

i am using xcode 26.0. If i deploy it from there on my phone running 26.1 or 26.2 i get the strange flip. but if i instead deploy it on one running 18.5 (all iphone pros) , the animation is wrong.

We are encountering the same issue since Xcode 16. We run XCTest and Swift Testing. For us it is flaky, sometimes some local Packages (SPM) are missing in the .xcresult file, resulting in a Coverage of 0% for these packages

You were right. We've found out that the issue was that we registered an observer with addObserver using a #selector that pointed to a function marked as @MainActor, but we were calling the NotificationCenter.post method from a background thread. Apparently this caused the main-actor isolation check to fail, which led to a crash. Even though there is no data-race or UI operation in the function, looks like it is enough for the function to be @MainActor to cause a crash when called from outside the main thread. We fixed it by making sure the relevant NotificationCenter.post calls are executed on the main thread. Initially, we thought that marking the function with @MainActor would prevent it from being called from a nonisolated context by producing a compile-time error in Swift 6 mode. But since a Selector instance is not aware of the actor isolation of the target function, Xcode is not able to show a warning and it caused us to not realize the issue at first. I appreciate your guidance @DTS Engineer.