“Xcode”

And today Xcode's simulators are all unavailable again! I woke up my machine after it went to sleep overnight, and Xcode seemed happy and showed all the simulators. So then I decided to reboot the machine just to make sure, and now Xcode is showing everything as Status unavailable again, and all of the previously downloaded runtimes are gone. And xcrun simctl list just hangs, requiring a Ctrl-C to kill it. To anyone from Apple who is listening ... stop cramming AI slop features into everything and focus on fixing the bugs! This is unacceptable.

Seeing the same issue on mac M1, and only since upgrading to xcode 26.4 (did not experience this with previous releases)

I filed a similar report yesterday... Xcode 26.4 (17E192) Simulators Keep Showing As Unavailable After Successfully Intalling Them FB22346008 ... with sysdiagnose tarball and screen shots. Am also running Tahoe 26.4. I spent the better part of this evening removing the following items: /Applications/Xcode.app /Library/Developer ~/Library/Developer ~/Caches/com.apple.dt.* ~/Preferences/com.apple.dt.* /private/var/tmp/com.apple.CoreSimulator.SimDevice.* rebooting my machine, and then reinstalling Xcode 26.4 (Apple Silicon) and the command line tools. I then used xcrun simctl to flush all of my devices and runtimes. I spent a lot of time fighting Xcode because after removing old simulators, Xcode automatically downloads them all again (SMH!). Once Xcode seemed to stabilize its downloads (using xcrun simctl list to monitor everything), I then added the iOS, watchOS, and tvOS simulators for 26.4. So far, things seem to be behaving. We'll see whether or not I wake up tom

I'm seeing it take 1-5 minutes on launch on Xcode 26.4 (most often around 2m). As suggested, when turning off debug executable, it launches as expected. FB22353872. I've added the requested traces. This also happens when running unit tests via Cmd-U (which is also configured with debug executable).

I would set it to 17.0. Xcode is smart enough to tell you if any of the frameworks that you intend to use is not available for the current deployment version. If I'm right, the Translation framework, which I hardly use, is available from 17.4, though.

I'd like you to try something — go into your scheme, and uncheck Debug Executable from the Run tab. When you click Run, Xcode will run your app with going through the process to attach LLDB. Does the launch performance after this look more like you're expecting? If so, we'd really appreciate getting diagnostics so we can look into the root cause of this slow down. Add the following to your ~/.lldbinit file, and the restart Xcode to ensure this is enabled: log enable gdb-remote packets --timestamp -f /tmp/log_packets.txt Before you launch your app, run the following in Terminal: sample lldb-rpc-server 60 --wait -file /tmp/sample.txt Attach both of those files that those commands placed in /tmp on your bug report, and let me know here when that's done. I also suggest removing the log line from ~/.lldbinit so it's not always logging debugger packets. @Code4Food, it'd be helpful if you could run the same tests and collect the same data, and attach them to your own bug report. Please post the FB

I was able to replicate this issue in a very simple way, within a new project created with the standard Xcode template, to which I added a Swift Package as a library (MyLibrary). This is the Package definition: // swift-tools-version: 6.3 // The swift-tools-version declares the minimum version of Swift required to build this package. import PackageDescription let package = Package( name: MyLibrary, platforms: [.iOS(.v18)], products: [ // Products define the executables and libraries a package produces, making them visible to other packages. .library( name: MyLibrary, targets: [MyLibrary] ), ], targets: [ // Targets are the basic building blocks of a package, defining a module or a test suite. // Targets can depend on other targets in this package and products from dependencies. .target( name: MyLibrary, path: Sources/MyLibrary ), ], swiftLanguageModes: [.v6] ) If the target name is equal to library name (MyLibrary) the preview of SwiftUIView works as expected. If I change the target name (for example

Hi, Sorry to hear you are having problems getting previews working. The issue you are hitting here sounds like one we are actively looking at. If you want us to check for certain then the best next step will be to file a feedback with diagnostics so we can take a look. We will need the diagnostics Xcode Previews generates in order to make sure we understand the error the previews system is encountering. Install the logging profile using instructions available here: https://developer.apple.com/bug-reporting/profiles-and-logs/?name=swift On your mac running Xcode. Install the logging profile using the following instructions on your mac running Xcode: https://developer.apple.com/bug-reporting/profiles-and-logs/?name=swift Then when you reproduce the problem in Xcode: Either (a) an error banner will appear, click the Diagnostics button in that banner; or (b) if you're not seeing an error but you still want to provide diagnostics you can get the same diagnostics window by going

If you pass a string containing slashes where developers intentionally appended multiple components at once (e.g., [baseURL URLByAppendingPathComponent:@Dir/Subdir/file.txt]). Interesting. I did not realize this was intended. I would prefer an explicit -urlByAppendingPathComponents:(NSArray*) method for that use case. What is your concern about the API? I actually find that this API accepting this syntax /../../../ to walk parent directories rather terrifying. As many path components as you want? While that syntax has its uses I think it is extremely rare for developers to use -URLByAppendingPathComponent: intentionally in that way with that purpose in mind. The name of the method implies one I think? And you are most often trying to go forward not backward when you use this API. Tell Xcode where my headers are use of @.. okay fine but most apps don't do that. IMO that should probably be split into a different API that clearly describes the purpose. To walk back parent directories the more sane thing

Zorast's post comes off very angry. I definitely understand why though: Apple steals a LOT of money from its developers and they justify that by saying, It costs money to provide all the tools and frameworks. In that context, there is no excuse for shipping broken, hamstrung tools. Oauth token expiration is a decades-old solved problem. It was solved in Xcode 26.3, even! Allowing that to slip through QA is not excusable. These tools aren't free. They aren't volunteer projects. There is a standard that is expected and Apple is failing to meet it.

@khatum Thanks for providing this into the forums for other users. Is there anything that keep you from moving to the latest Xcode released? Thanks Albert 
  Worldwide Developer Relations.