Availability of VTK Modules for iOS

Development
1

Hello,
I have a an application for macOS that utilizes quite a few modules, and almost none of them are available for iOS. Here’s the list of dylib modules I’m using so far:

libvtkCommonCore
libvtkCommonMisc
libvtkCommonDataModel
libvtkCommonExecutionModel
libvtkFiltersCore
libvtkFiltersGeneral
libvtkFiltersTexture
libvtkImagingMorphological
libvtkImagingStencil
libvtkImagingCore
libvtkImagingStatistics
libvtksys

Is there a limitation preventing other modules from working?
I’m not interested in OpenGL or otherwise any rendering modules as I’m doing my own rendering.

Looking forward to hearing from devs about this as there seems to have been radio silence on the topic for the past couple years.

2

Hello,

What issues are you experiencing?

best,

PC

3

I just want the aforementioned modules to be available on iOS, since they’re not. in vtkiOS.cmake there’s only a few modules listed, mostly around loading models and rendering with OpenGL, and that’s not functionality I’m interested in.
Also ideally it’d be great if there would be a way to work with VTK with Swift Package Manager.
Currently VTK doesn’t appear to ship with pkg-config files (at least when installed with Homebrew) so there’s no way to load VTK as a .systemLibrary target.
I could go on about how the integration experience could be improved, but the main issue is that I just need modules to be available for building at all.

4

Well, you can build VTK provided you have a C++ compiler. By doing so, you can have any VTK library you need.

5

The VTK iOS integration may have bit rotted over the years. Unfortunately, Kitware doesn’t build and test VTK for the iOS/Android platforms. I guess there hasn’t been much demand to justify spending resources. On the bright side, contributions are always welcome. Members of the community (like you) who understand what’s required to make it easier for iOS developers, could help us improve the docs and package integration to current standards for the iOS platform.

I have a an application for macOS that utilizes quite a few modules, and almost none of them are available for iOS. Here’s the list of dylib modules I’m using so far:

Could you extend the existing vtkIOS.cmake with the modules you’re interested in?

6

I would love to help, but the time I can afford to spend on this is unfortunately quite limited at this point.
I can try to add more modules and see if it works, but this post here made me think this might be a somewhat of a dead-end approach.

There’s talk of “modern CMake”. I never worked with CMake and so I have no clue how to pick this up, my focus is on Swift and I have some interoperability code to be able to use VTK through C++.

In the thread I linked there was talk of XCFrameworks. These are a sort of container that packages a binary library for multiple architectures, and their associated headers.
So potentially you could have an XCFramework for each module, and have all architectures in there. That’s a very versatile solution for the Apple ecosystem, much nicer to work with than VTK installed through Homebrew or otherwise.

I tried buildling XCFrameworks, but the issue I encountered was that I’d have to partition the headers according to their modules (otherwise I get errors of duplicate headers), and that didn’t seem to be feasible.

Somewhat of a tangent but for macOS there’s a Homebrew installation of VTK. It’s common for Homebrew installations to include a pkg-config file. The Swift Package Manager uses these files to locate “system libraries”. That’s really the only way other than XCFrameworks to include a C++ library in a Swift project that has C++ interoperability enabled. I tried writing one on my own and saw some success but I got stuck on something else that I don’t recall now.
The alternative to using Swift Package Manager is the way the macOS example project is set up, more or less. It’s really hardly ideal to mix these approaches, but that’s the only way I could things working for macOS.

But really I’d like to first understand what “modern CMake” means in this cross-compile context. If we could just get all or most of the modules built for more Apple platforms, the way we’d package them to make it easier on Apple platforms would be the icing on the cake.