iOS support

[brookman]

Timeline for iOS support

I just wanted to ask if there is a timeline for iOS support. Thanks in advance!

Detailed information

l‘m looking for a unified solution to pass (largeish amounts of) data between Flutter and Unity. On Windows and MacOS those would be separate processes while on iOS they run in the same process. I‘m currently working with ZeroMQ but Iceoryx2 seems to be faster and less error prone to integrate with C# and Dart.

[elfenpiff]

@brookman We plan to support Android first, and then plan to extend it to iOS, which means that iOS will be available in 2026 or later.

However, timelines can be accelerated by contracting us ([email protected]) - this is how we fund our open-source work. Currently, the most requested features from the community are:

1. Request-response support
2. Parity with iceoryx1 features
3. Python and Go language bindings
4. Network communication
5. Gateways

We're actively working on these features in roughly this order.

[elfenpiff]

@brookman I looked at how to deploy Rust code to iOS, and it seems pretty straightforward. Also, iceoryx2 is already ported to mac os, which should make things much simpler. So the work that has to be done is maybe less than we think. However, the apps are usually sandboxed, which means that we do not have direct access to the system's underlying shared memory, which is essential for zero-copy communication. We can handle this by extending the architecture of iceoryx2, something that is already planned independent of iOS or Android.

What we essentially require is that there is a process that owns the service. Every participant uses unix-domain sockets to register at this process, and this process then sends the services corresponding shared memory file-descriptors via unix-domain sockets to the participants.

But when your use-case is:

On Windows and MacOS those would be separate processes while on iOS they run in the same process.

We do not need all of this (the extended architecture) and can work with the process_local service variants that are perfect for sandbox'ed environments. This is maybe already possible without any adjustments in iOS.

Would you then also require a C# language binding or could you then work with the C/C++ language bindings?

[brookman]

Thank you for the quick and detailed feedback!

I could be wrong, but I don't think that it's possible to run multiple processes on iOS. An app only ever consists of one process.

We do not need all of this (the extended architecture) and can work with the process_local service variants that are perfect for sandbox'ed environments. This is maybe already possible without any adjustments in iOS.

So are you saying that the crate might already compile and use process_local on iOS?

When I try to build an example for iOS (--target aarch64-apple-ios) I'm getting an error regarding <libproc.h>.

Would you then also require a C# language binding or could you then work with the C/C++ language bindings?

I have successfully used Rust crates from C#/Unity via csbindgen FFI and NativeArrays. For Flutter the easiest choice would be flutter_rust_bridge. I have used it successfully in production.

[elfenpiff]

@brookman

So are you saying that the crate might already compile and use process_local on iOS?

Not yet but the only thing we need to add is an iceoryx2 "sandbox" mode. This will be a rust feature flag that disables all IPC dependencies and would make it much easier to port iceoryx2 to another OS. When this is introduced the libproc.h problem may vanish completely since it is no longer used.

I have successfully used Rust crates from C#/Unity via csbindgen FFI and NativeArrays.

We already use cbindgen for the C language bindings and build on top a C++ abstraction so that C++ and Rust users have a similar and comfortable API. Would this also be a valid approach for C#? I assume you would just create bindings for the low-level iceoryx2-ffi API which is pretty cumbersome to use.

With the sandbox approach, we should be able to quickly port iceoryx2 to iOS. I would start with the sandbox flag in December, and maybe we can have iOS support in January.
When would you need iOS support?