“Xcode”

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.

I used the ChatGPT feature in Xcode to suggest change to improve my alpha blending, and it suggested I add the following to my MakePipeline function: func makePipeline() { let library = device.makeDefaultLibrary() let pipelineDesc = MTLRenderPipelineDescriptor() pipelineDesc.vertexFunction = library?.makeFunction(name: vertex_main) pipelineDesc.fragmentFunction = library?.makeFunction(name: fragment_main) pipelineDesc.colorAttachments[0].pixelFormat = .bgra8Unorm // ---- New changes // Enable blending for transparent drawing pipelineDesc.colorAttachments[0].isBlendingEnabled = true pipelineDesc.colorAttachments[0].rgbBlendOperation = .add pipelineDesc.colorAttachments[0].alphaBlendOperation = .add pipelineDesc.colorAttachments[0].sourceRGBBlendFactor = .sourceAlpha pipelineDesc.colorAttachments[0].destinationRGBBlendFactor = .oneMinusSourceAlpha pipelineDesc.colorAttachments[0].sourceAlphaBlendFactor = .sourceAlpha pipelineDesc.colorAttachments[0].destinationAlphaBlendFactor = .oneMinusSourceAlpha //

I can’t help you with the third-party tooling side of this. My advice is that you set up a small Xcode test project to exercise the APIs in question. If you get stuck with that, I’d be happy to help. Once you get that working, you can translate that knowledge to your third-party environment. And if you have problems with that, you can seek help via its support channel. However, I can tell you that this is wrong: [quote='820580021, i12n, /thread/820580, /profile/i12n'] I do have these entries in my Entitlements.plist … com.apple.developer.music-kit [/quote] MusicKit is one of the most commonly hallucinating entitlements. Indeed, I listed it, with a slightly different spelling, in Determining if an entitlement is real. Oh, and if you were using a modern version of Xcode, it would’ve told you about this, which is another good reason to prototype this stuff in Xcode. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Annoyingly, Xcode has a bug that prevents it from exporting Network Extension apps correctly. See Exporting a Developer ID Network Extension for the details. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com