search

eclipse-iceoryx / iceoryx2

Eclipse iceoryx2™ - true zero-copy inter-process-communication in pure Rust
https://iceoryx.io
Apache License 2.0
1.02k stars 40 forks source link

iOS support #510

Open brookman opened 1 week ago

brookman commented 1 week ago

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 commented 1 week ago

@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 (info@ekxide.io) - 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 commented 6 days ago

@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 commented 6 days ago

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 .

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.