“Xcode”

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

Hello, Additional information: the same subscription works correctly with StoreKit local testing in Xcode (StoreKit configuration file). The product is returned and the purchase flow behaves as expected. The issue only occurs in the App Store sandbox via TestFlight, where the same product ID returns an empty array. This suggests the implementation is correct and the issue may be related to App Store Connect or sandbox availability. Thank you.

Did some more testing. The white screen/delay only happens when the app is provisioned for debugging and started for the first time in the simulator. When i terminate the app and start it on the simulator again (w/o debugging from xcode) all went smooth. No white screen, no delay. So it looks like there is some kind of debugging/first run overhead that causes the delay aka white screen (system launch screen) to be visible for that long time.

Still have the issue in Xcode 26.4 Release Candidate (17E192). Ignore the package.resolved is not a solution because many people works in the project and we need to work under the same versions and, if one package version changes the team only change that package thanks to the cloud, so we cannot play to what versión cloud will download

Same here. Updated xcode & simulator yesterday and out of sudden ios apps when started show a white screen for seconds before the main application screen (i.e. a splashscreen) appears. Added print() to trace but it looks the delay happens not in user code. Looks like loading libs during the startup process takes ages before user code starts running.

I can already tell you, nothing works for me anymore. I updated to macOS 26.4. This morning, it updated Xcode to 26.4 as well. As a result, I had to reinstall Codex, which I did. I logged in, and now nothing works at all. I can submit a request in the chat, sometimes I get a short response, and then it starts thinking about something and never stops. I think it is amazing what kind of unfinished mess Apple is delivering once again. This is absolutely unbelievable. I am furious that such a broken system is being provided to us developers. It would be the easiest thing for Apple to simply test Codex. If they are not even providing us with the latest Codex versions and instead releasing outdated versions with their Xcode, it is outrageous that we are given something so completely unfinished and nonfunctional. With macOS 26.3 and Xcode 26.3, I was at least able to program perfectly fine with Codex and developed several apps. Now I wake up in the morning, want to continue working on my a

OK by this: I tried deleting iOS 18 runtime via Xcode Settings > Components, and even removed iOS 26 runtime then re-downloaded it. But the iOS 18 runtime keeps auto-reappearing right after! I also ran sudo rm -rf against the iOS 18 asset folder, and it just throws a permission error—totally useless. I checked the Info.plist under /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/cc1f035290d244fca4f74d9d243fcd02d2876c27.asset/ and confirmed this folder is exactly the orphaned iOS 18.0 simulator runtime. I’m trying to delete this specific cc1f035290d244fca4f74d9d243fcd02d2876c27.asset folder but hit a wall with system permissions. I found this exact issue is already being discussed in the Apple Developer Forum thread here: Orphaned 9GB Simulator Runtime in /System/Library/AssetsV2 - Cannot Delete (SIP protected). It’s clearly a bug on Apple’s side with MobileAsset lifecycle management—these large orphaned simulator runtime assets get stuck in SIP-protected system directories, and Xcode

So it appears to be the same failure we are talking about here: https://developer.apple.com/forums/thread/814076 I just updated that thread, but the bug described there (FB21805212) was fixed in macOS 26.4. Also, to be clear, the bug was specifically in smb, NOT copyfile itself. However... It has data. I can read the filenames when I view it as 'plain text’. The Resource fork is less than 300 bytes, but that is enough for it to cause copyfile to fail. The total file size is ~12kb. That doesn't sound like the bug above. The bug above was caused by the SMBClient incorrectly accounting for large xattr size, which then caused the copy to fail. I don't think it would have happened with small xattrs (certainly not 300 bytes). FYI, the Finder (and other copy engines) work because they're using the ..namedfork accessor, when it ends up going through a totally different code path in smb. Interestingly, .DS_Store causing problems with copying is infamous enough to have a mention on Wikipedia: Yes, but I think