Cross Compiling VTK for Mobile Architectures

I am interested in consolidating our current functionality for cross-compiling VTK for mobile architectures (iOS, tvOS, Android, etc.). This is likely to have a lot of overlap with the new Apple M1 (arm64) chip support. In addition, we can deprecate support for many previous ARM architectures (armv7, armv7s, etc.).

Previous/Current Development

The last time I visited this topic was six years ago, with the results outlined in this external blog post. The gist is that I created custom toolchain files for device and simulator that could be configured to produce a minimal subset of VTK via a global CMake flag VTK_IOS_BUILD=ON which invokes a configuration path specified in vtkiOS.cmake. This configuration will build the VTK compile tools then build a subset of VTK for each specified mobile architecture. Another CMake script will then consolidate all of the static libraries and headers to make an iOS framework, which can then be included directly in the relevant Xcode project.

The Android path works similar in spirit, albeit with a different toolchain.

The simplest way to build is:

cmake -DVTK_IOS_BUILD=1 -S vtk -B vtk-ios-build

which produces usr/local/frameworks/VTK.framework. Something similar happens with VTK_ANDROID_BUILD=1 to produce a consumable Android library.

One downside of this is that only a small subset of VTK modules are currently available. I am unsure which modules cross-compile correctly for iOS/Android and which do not. In addition, if a developer wants to add another module, they have to edit vtkiOS.cmake directly.

Present/Future Development

Modern CMake has a lot of nice built-in functionality for cross compiling for these architectures now. It would be great if we could simply rely on CMake to handle all of this, and delete the toolchain and iOS- and Android-specific CMake files from the VTK source.

For VTK, this means first building the compile tools:

cmake -S vtk -B vtk-compile-tools \

cmake --build vtk-compile-tools --config Release --target install

Then using modern CMake to cross compile:

cmake -S vtk -B vtk-ios-build -G Xcode \
-DCMAKE_INSTALL_PREFIX=vtk-ios-install \

However, at first pass CMake has an issue with finding a valid threading library. Alexis has a fix for this; I will post again to this thread when I have made progress.

Alexis and Julien have also noted interest around building VTK as an XCFramework, something of which I currently have little knowledge. This seems like the ideal end goal at present.

This is the current state of affairs. Opening up this discussion to track any progress and to list any issues that those working on this run into.


CC: @agirault @brad.king


More information, as I was limited in URLs and user tags as a “new user.” (LOL)

Relevant CMake documentation

For more recent versions of VTK, it seems this merge request is necessary independent of how we’re compiling.

WWDC presentation on XCFrameworks.

Additional CCs: @jjomier, @ben.boeckel

+1 on dumping the custom CMake toolchains in VTK and using the native CMake support instead. Obviously a lot easier to maintain, and more scalable when needing to configure more CMake properties than the ones currently hardcoded. Some useful links:

I don’t know anything about the Android build, but it looks like there was support even before:

Those tickets might help with dependency issues on iOS:

See this comment on the CMake’s issue tracker to follow on that topic:

@ken-martin @ben.boeckel I thought VTK had an iOS job with tests on CDash but I can’t seem to find it. I haven’t done any vtk development for iOS in a while: has it been removed, or am I misremembering?

FYI, looks like multiple people had issues with building VTK for iOS in that thread:

Ken had been in charge of it, but we can add a build to CI once basic macOS is done.

1 Like

Nice. What Xcode version will be used there? You might already be aware, but CMake’s behavior on macOS before and after XCode 12 differs quite a lot. I can follow-up on the GitLab ticket if that’s something you’d like to discuss.

It is using Xcode 12.3 (as can be seen by the tagset and the DEVELOPER_DIR setting). This is to facilitate universal binaries for building once and testing on both architectures to save CI time.