“xcode github”

Cool. I consider this to be a problem with Xcode’s build system, but it’s an understandable one. Xcode knows that your tool depends on this library — because it adds an import of it — but, being a command-line tool, it doesn’t have anywhere to embed the library. It should embed it in the container app, but it’s clearly not doing that. I think it’s worth filing a bug against Xcode about that. And if you do, please post your bug number, just for the record. As to a workaround, there’s a couple of ways to approach that. The first is the obvious one we’ve been discussing here: Add a dummy use of Subprocess within your app. Xcode will embed libswiftCompatibilitySpan.dylib, because it knows that your app needs it, and your tool can pick it up from there The other option is to embed the library explicitly. This is complicated by the fact that the library exists within a toolchain, so it’s not clear how to reference it [1]. For the moment I recommend that you go with the first opti

[quote='818269021, anonymousdev332299, /thread/818269, /profile/anonymousdev332299'] is both a Developer ID certificate and Apple notarization required on current macOS versions? [/quote] Yes. Developer ID signing has been required for a long time (10.8?). Notarisation for apps has been required since 10.14. [quote='818269021, anonymousdev332299, /thread/818269, /profile/anonymousdev332299'] Is [ditto] necessary to properly preserve the app bundle structure and extended attributes? [/quote] Yes and no. If you compress with the Finder then extended attributes get sequestered, which is not good. See Extended Attributes and Zip Archives. The ditto tool doesn’t do that by default. However, in an ideal world this wouldn’t matter because your code signature should not depend on extended attributes. If you find that it does, that suggests your have a bundle structure problem. We talk about this more in TN3126 Inside Code Signing: Hashes and Placing content in a bundle. As to what’s actually happening here, it’s hard

I have the same problem with Xcode 26.3 and Xcode 26.4 (Beta 3).

Also have problem with git fetch from Xcode, in terminal all work good.

Thanks Ed, this did work. The confusion for me comes from the output & results of the downloadPlatform command above - the export file is automatically named iphonesimulator_26.1_23B86.dmg, and there's no mention in the output that the SDK Platform Support (ver 23B77) component has also been exported. There also wasn't anything in the output when running importPlatform to indicate that this component was being imported, however it did show up correctly in Xcode afterwards when viewing Settings -> Components. Perhaps some indication in the output from both of these commands that the platform support component is included would avoid this confusion?

Xcode Cloud has the Metal toolchain ready for use without any additional installation required. If you remove these commands from your ci_pre_xcodebuild.sh script, does your build succeed? — Ed Ford,  DTS Engineer

Hi! Could you please share your OS versions and Xcode versions so we can track down the source of these errors? Thanks so much!

We started experiencing a similar issue on the day iOS 26.4 Beta 1 was released (2026/02/18). Firebase Analytics is reporting a large number of duplicate in_app_purchase events for some users starting from that day. A few things we've observed: All of the affected transactions are non-consumable items. The duplicated events are triggered right after the process starts. All affected users are on iOS 26.4 So far we haven’t been able to reproduce it locally. It might be because our tests are using the sandbox or because our debug builds are compiled with Xcode 26. So I can't say for sure if it's exactly the same issue as yours, but it looks quite similar.

[quote='878607022, Nickkk, /thread/817724?answerId=878607022#878607022, /profile/Nickkk'] I'm assuming that's what you mean by Mach-O image. [/quote] A Mach-O image is code that can be mapped into memory by the dynamic linker and then run directly, as opposed to something like a .o file that contains code that must be linked before it can be run. I talk more about this in An Apple Library Primer. A Mach-O image is often stored within a universal binary, one image per architecture. So when looking at stuff like this you have to consider the image of the architecture that was running. The other thing to considered is that the dynamic linker may only map in parts of your image. A good way to see what actually gets mapped is to run the app and then run vmmap against it. Consider this: % ls -lh Pages Creator Studio.app/Contents/MacOS/Pages -rwxr-xr-x 1 root wheel 45M 16 Jan 02:44 Pages Creator Studio.app/Contents/MacOS/Pages The Pages executable is 45 MiB. And this: % file Pages Creator