fix: add visionOS x64

[okwasniewski]

This PR adds SIMULATOR64_VISIONOS and modifies VISIONOSCOMBINED to also include x86_64 slice for visionOS simulator.

It looks like Apple still requires us to build an x86_64 slice when working with the Release build on the simulator.

[kambala-decapitator]

It looks like Apple still requires us to build an x86_64 slice when working with the Release build on the simulator.

That sounds weird. Iirc developing for vision is possible only on arm Macs.

[okwasniewski]

It looks like Apple still requires us to build an x86_64 slice when working with the Release build on the simulator.

That sounds weird. Iirc developing for vision is possible only on arm Macs.

Totally agree that this is weird and this shouldn't be the case but you can easily check this by running a release build for the simulator, as you can see on the screenshot it builds for both archs (Im on M1 mac):

[kambala-decapitator]

I believe it's a problem in your project file. For example, by default it sets "build active architecture only" only for debug build.

Was this xcode project generated by cmake?

[okwasniewski]

I believe it's a problem in your project file. For example, by default it sets "build active architecture only" only for debug build.

Was this xcode project generated by cmake?

Nope, this project wasn't generated by CMake but it shouldn't matter. I can test out again with build only active arch but the x64 build was also triggered when archiving the app for AppStore release.

If you google this issue you will find similar cases, for example this: https://forums.swift.org/t/archiving-swift-package-that-supports-visionos-requires-x86-64-architecture/71964

[kambala-decapitator]

The Apple Silicon requirement is fake and you can disable it:

now that's funny! :)

will check on a test project to see if it's reproducible

[kambala-decapitator]

indeed, Intel arch is available by default:

You can disable it using either of the two:
1.

2.

Considering that one must take explicit actions to enable vision simulator on Intel, I'd rather adjust this PR to enable Intel support through an option that is off by default.

[okwasniewski]

Considering that one must take explicit actions to enable vision simulator on Intel, I'd rather adjust this PR to enable Intel support through an option that is off by default.

I think support for running visionOS for intel is going to be dropped soon so Im not sure if adding this makes sense for the long term. Have you tried archiving the app? Does the archive process take into account excluded architectures?

[kambala-decapitator]

I think support for running visionOS for intel is going to be dropped soon so Im not sure if adding this makes sense for the long term

fully agree

Have you tried archiving the app? Does the archive process take into account excluded architectures?

archiving from Xcode does build both archs regardless of those settings which is also strange. However, archiving from command line builds only arm64 even without those settings, tried with the following 2 commands:

# 1
xcodebuild archive -scheme vision-test -destination 'platform=visionOS Simulator,name=Any visionOS Simulator Device'

#2
xcodebuild archive -scheme vision-test -destination 'platform=visionOS Simulator,name=Any visionOS Simulator Device,arch=arm64'

(the difference is only in additional arch=arm64 passed to the -destination param)

[okwasniewski]

@kambala-decapitator Thanks for checking this out.

So what's your suggested resolution of this issue?

archiving from Xcode does build both archs regardless of those settings which is also strange

This was my original issue which persists for Xcode 16, maybe we can temporairly support this in ios-cmake until this behaviour isn't removed from Xcode?

I don't think adding Intel support makes sense as we mentioned.

But I think getting .frameworks to build for properly for all archs is necessary. Additionally if someone is using Xcode cloud they are going to run into some issues without x86 slice (at least that's my guess)

[kambala-decapitator]

building for simulator in release mode is a rather rare use case afaik (oh, unless it's a library/framework), and building for visionOS simulator on Intel is even rarer. As you can see, archiving from command line workarounds the issue.

Additionally if someone is using Xcode cloud they are going to run into some issues without x86 slice (at least that's my guess)

not sure why. Pretty sure Xcode cloud builds stuff using command line.

but anyway, I'm not a maintainer, @leetal should decide.

[okwasniewski]

But if you have library/framework that you provide for your users and then they build for the AppStore you need to have the x86 slice for the build to succeed.

In that case building with the CLI won't fix it

[kambala-decapitator]

they build for the AppStore you need to have the x86 slice for the build to succeed

um, what?.. AppStore requires only device archs and Intel is simulator-only.

Also don't understand how CLI wouldn't work it around since you can do the same there as what Xcode GUI does.

[okwasniewski]

As we discussed before, during archiving (for AppStore) Xcode is building x86 architecture of the App. If your .xcframework (built with ios-cmake) doesn't support x86 slice the archive will fail.

You can ask users of your framework to "use the cli" but it is an inconvenience for them

[kambala-decapitator]

you can easily check this by running a release build for the simulator

if I understand correctly, this is your bug report. One doesn't use simulator destination when building/archiving for App Store - instead device destination should be used.

[okwasniewski]

Oh okay sorry I got confused, you are right. This doesn't happen when archiving for the AppStore.

So this happens only if you are building your app for release targeting the simulator.

We've got two use cases:

• Framework maintainer
  • In theory should provide x86 slice
• App Developer
• Can workaround the issue by adding "Build only active Arch"

So this change would be mostly targeted at framework authors/maintainers. I don't think this change would cause any issues but can save some headache from library maintainers

[kambala-decapitator]

I believe that >= 95% of library maintainers already have build scripts to automate things :)

[okwasniewski]

Okay, after thinking about this let's leave this as is.

I'm going to close the PR and just don't ship x86 slice in our framework. Thanks for your help