building via script vs via Xcode

[mesqueeb]

I am trying to build fuego-on-ios in a way I can use it on VisionOS.

For this reason I'm looking into swapping out Boost with a version compatible with VisionOS.

As a first step though, to not rush things and try to understand the current setup, I want to ask this:

When opening the fuego-on-ios Xcode project, and building that static framework for "Any iOS Device (arm64)" as per the screenshot below, would this result in the same thing as using the build.sh script to build fuego-on-ios?

I'm mainly asking because, for me it builds when using Xcode like this. And using Xcode will make it easier for me to debug when trying to swap out Boost for a VisionOS compatible one.

---

PS: Do you have any extra advice for me to make fuego-on-ios buildable for visionOS?

[herzbube]

[...] would this result in the same thing as using the build.sh [...]

Short answer: No. For the long answer, read on...

build.sh does 2 builds: One for the device platform and one for the simulator platform. So if you only build for "Any iOS Device (arm64)" then you do only one of two builds.

On Intel Macs the two platform builds use different architectures (device = ARM, simulator = Intel), but I believe you are on a Silicon Mac, and there both platform builds use the ARM architecture. Nevertheless, I doubt that the two builds are equivalent. So just building for "Any iOS Device (arm64)" is not the same thing as using build.sh.

Furthermore, build.sh also does this:

• It packages the header files and the static library file resulting from each build into a separate .framework bundle. The result are two .framework bundles, one bundle per platform build.
• It packages the two .framework bundles into an .xcframework bundle.

The resulting .xcframework bundle can then be very easily consumed by a downstream project such as Little Go. Thanks to the .xcframework the consumer project does not have to deal with the intricacies of selecting the correct binary to link against.

Why an .xcframework?

• A .framework contains a single binary
• That binary can be a fat binary, i.e. a binary that contains multiple architectures
• The same architecture can appear only once in a fat binary
• On Intel Macs we had two different architectures for the device and the simulator: ARM and Intel. This means that we were able to store both the device and the simulator builds in a single fat binary, hence also only a single .framework was needed.
• On Silicon Mac the architecture for the device and the simulator are the same: ARM. This means that we can no longer store both the device and the simulator builds in a single fat binary, hence we need two .frameworks, and to make those easily consumable we wrap them in an .xcframework.

Do you have any extra advice for me to make fuego-on-ios buildable for visionOS?

I'm not familiar with visionOS, so no profound advice from me, sorry.

If you just replace the iOS build with a visionOS build, then I would assume that not much needs to be changed - probably a different SDK prefix to use for xcrun --sdk <what-to-put-here-for-vision-os> --show-sdk-version? Check out what happens at the top of build.sh and how IPHONEOS_SDKPREFIX is used.

If you want to have a visionOS build in addition to the iOS build, then I guess you will have to build a third .framework and stitch 3 frameworks together into the .xcframework. So the changes to build.sh would be a bit more extensive, but surely not something that a bit of copy&paste cannot solve :-)