Change:
pub fn target() -> Target { Target { <del> llvm_target: "armv7-apple-ios".to_string(), </del> <ins> llvm_target: super::apple_base::ios_llvm_target("armv7"), </ins> pointer_width: 32, data_layout: "e-m:o-p:32:32-Fi8-f64:32:64-v64:32:64-v128:32:128-a:0:32-n32-S32".to_string(), arch: "arm".to_string(),

Discussion:
Hi We are currently trying to build a xcframework, which includes a rust static library as a binary target. When we build the xcframework with we get . To reproduce the failure just build a static lib with a function in it e.g.: Interestingly enough, the binary works when statically linked during the usual build process in XCode (so the code itself seems to be correct). Further, for the darwin binary (target macos) the xcframework creation process succeeds. I think with rustc 1.43 the xcframework also worked for the ios platform, but other than that we have no idea what is wrong. It is though certainly somehow linked to rust, as C/C++ libraries work (e.g. libsodium) with exact the same command/folder-structure. [EDIT] We found that LCVERSIONMIN is emitted instead of LCBUILDVERSION in the load commands of the MachO binary. Apparently this is the newly used command to specify the platform. As a comparison: XCODE: cmd LCBUILDVERSION cmdsize 24 platform ios sdk 14.2 minos 14.2 ntools 0 RUST: cmd LCVERSIONMIN_IPHONEOS cmdsize 16 version 7.0 sdk 13.7 [EDIT 2] Getting closer found and made a new target, where I set the llvm-target to the one with the correct version like this: Now I can create an xcframework again!
Does that mean that this issue can be closed?
Well not really, since the ios and mac targets have two issues that I seen so far: With catalyst and simulator builds, we have two platforms than match x8664-apple-ios, and rustc's llvm will create a "fat" binary containing both, catalyst and simulator (the actual llvmtarget should be x86_64-apple-ios-simulator)There is no way of setting a OS target, which let's llvm choose the lowest available (7.0). This breaks support with various novel Apple/Mac tools (as e.g. explained with xcframework). Since the plattform is deprecated, it is not clear for how long the fallbacks which are currently in place for older toolchains will work (e.g. normal xcode builds). So to summarize: The llvm targets for ios/darwin need to specify the version (as in e.g.

aarch64-apple-ios13.0) (which should probably best be set via a cargo option or env var). Further, since maccatalyst is supported, the simulator target should set its environment to simulator to prevent llvm from generating a "fat" binary.
I also encountered this issue when trying to put together an . I don't quite understand your workaround. Is there an example of how to pass that config during the build step? When I put that config in a json file and pass it as the during or , cargo simply tells me the target may not be installed.
You have to [rebuild the standard library][build-std] in order to use a custom target as mentioned in: Write the above target-spec into a file named . Modify the line to indicate 11.0 (or your desired version) and then invoke your build like: I should note, however, that my resulting static library does not include the load command. It simply includes: Nonetheless, it can be inserted into an using: [build-std]:
If you set the version high enough, it appears you do get the newer load command:
Ah yes, sorry my answer was edited multiple times, so this probably did not come across. Those load commands are emitted for the newer llvm-targets automatically (XCode itself is using the same LLVM-Targets).
have you been able to archive an iOS app that includes an xcframework built this way? I'm getting:
For our CI we use the following script (note we also had problems with the new aarch64-simulator target, so we excluded that in the build process). The script essentially checks for a valid rust installation on the CI, then builds the standard library for the new ios target, generates C-Bindings with cbindgen, and finally combines headers and static lib to a xcframework. Hopefully this helps you :)
thanks for the script, it helped me debug. I am actually doing something pretty similar to you however I'm building fat binaries with both and slices and building for , , , and . After ruling out most of the differences between our two approaches, I narrowed the issue down to build profile. Trying to archive an iOS app with a debug/dev build of a rust library packaged as an xcframework results in the error.

But, switching to the release profile yields: Which seems to indicate (1.52-nightly) Rust's llvm includes attributes that Xcode's version doesn't know about yet. Using the nightly resolves the issue. For posterity, my script looks like: <SUPThe reason I don't have a module map is because I'm packaging this xcframework using the swift package manage, which will automatically generate one for you for binary xcframework targets (:</SUP
I have a similar thing working with current nightlies. You just need to use to modify the target's json to have the correct llvm target, which your script forgets to do if I'm reading it right. My code for this lives over at in the Scripts directory. Bit messy but it works. Irrelevant to rust-lang/rust, but I did things a bit differently: If you are relying on Xcode you can also just compose the env variables to create such a triple that works correctly even for the simulator. You can also get the list of archs from $ARCHS etc, as Carthage will build one PLATFORMNAME at a time with all the ARCHS at once. never builds an xcframework of only the rust code, it just makes binaries for linking into a Swift wrapper which carthage will build into an xcframework, but in theory the thing is enough for your script. Side note why this way? If you're working on the rust ffi lib at the same time, Xcode can get to a debug-my mac build much faster for running the attached test suite, doesn't need to wait for a full multi-platform multi-arch build to finish The only way to get an xcframework into SPM is through a .binaryTarget and I didn't want releases + CI in the way at the moment It also turns out that Xcode will thin out anything you lipo before linking to swift anyway and then sum all the swift+rust objects at the end, so I just copy the resulting archs to a Cargo/Build/CONFIGURATION/CURRENTARCH to the library search paths. Read the Link-citeproc-rs.xcconfig file thoroughly if you want to know how the linking works.
I just have different target JSON files rather than modifying a single one with . I'm able to run on the simulator using the script I posted above, that all works fine.

After running , my project looks like: We're not using Carthage, just pure SwiftPM. I have a swift package project that includes Swift code to interface with the FFI. I build the binary xcframework using the artifacts from the crate where I've my FFI. In the swift package I have a directory where I copy the xcframework and use it as a binary target. There is a swift target containing code to interface with the rust crate via the published FFI, which depends on the binary target. I guess my goal was to have this working in swift package manager and building via the command rather than relying on xcode to do the heavy lifting. The swift package looks like: We do use xcode, of course, and I may try to get what you have working over in CiteprocRSKit setup for us, so thanks for the leads. I do get the impression Apple is leaning into xcframeworks for integrating binary artifacts into the swift ecosystem although I absolutely respect the aesthetic beauty of getting the build working by passing everything through via Xcode. Building for all platforms is an annoying kink in the workflow but not a showstopper for our use case and not without it's own advantages/tradeoffs. It would be cool if you could create a dynamic "script" target using swiftpm that would have access to all the appropriate env vars and just call out to cargo. The artifacts of such could be specified in the build script and then included normally in the appropriate search paths. Just wanted to provide a little rationale in response to your "why do it this way" and "never build pure rust xcframework" questions/comments. Back to rust stuff: I tested 1.55 nightly with the new Xcode 13 beta (which uses llvm 12+). I no longer have an issue building or archiving. I think that confirms the llvm version mismatch hypothesis. It's possible this scenario could happen again in the future though, so it may always be something to watch out for. And it wouldn't happen if we didn't have to use rust nightly to build xcframeworks. So the original issue still stands: building an xcframework requires rust nightly because it requires a custom target because the main rust does not use a sufficiently specified llvm target.

During this whole debugging process, I stumbled upon , allowing to build rust with a specific Apple llvm-backend, to allow the usage of bitcode. Since I had the compiler checked out anyways, I tested it and it seems to work with current upstream rust.
Update from me, which is of course still off-topic for the Rust repo, but hopefully useful. Doing it the fully Xcode way finally hit a snag. My Swift code needs to re-export items from the FFI headers. Swift is generally bad at this, and if you do, it gets in the way of using module stability to make the final product work across different swift compilers than it was compiled with. There isn't an obvious way (using custom modulemaps) to bring the ffi module into scope in the .swiftinterface file. So it just says "no such module YourRustFFIModule". Works fine when the swift compiler versions match. Works fine if you don't re-export anything. Use a different Xcode with re-exports and you're in trouble. So if solution can do this, it would have the advantage. I suspect it can, because it seems like consumers would be able to compile your package from source and so the swiftc version mismatch is irrelevant. However I am guessing that it requires providing a download URL for the Rust xcframework to pop in the , to avoid placing many versions of multiple large binary blobs in git. I will maybe give this a go.
Rust 1.55 works fine with XCode 13 (13.1), however for 1.56 fails with some unknown attribute, which is seems to be related to the (llvm 13 for 1.56, llvm 12 for XCode 12) Without bitcode builds fine.