Elixir Desktop - Can it be used to write SDKs for Android and iOS?

Ping to @dominicletz (the author).

For example the Mozilla foundation uses UniFFI to help with the generation of the bindings to include Rust in their SDKs for Android, iOS and others:

UniFFI is a tool that automatically generates foreign-language bindings targeting Rust libraries.
It fits in the practice of consolidating business logic in a single Rust library while targeting multiple platforms, making it simpler to develop and maintain a cross-platform codebase.
Note that this tool will not help you ship a Rust library to these platforms, but simply not have to write bindings code by hand

I still need to find resources on how to compile to iOS and Android.

It’s definitely possible, whether it’s advisable in your case I don’t know. You will have to ship the iOS and Android runtimes with your SDK and adjust the Bridge.swift / Bridge.kotlin files to expose your API.

You would not in fact be using the Elixir-desktop library but just the runtimes and your own code to respond to the API calls. The bridge in the mobile sample apps is using socket communication to send and receive messages between native and Elixir. There is no API generation tool and creating one would be a pretty creative task as you need real type information for Kotlin/Swift API that you don’t have in Elixir. So maybe generation from the typespec meta-data?

I recommend you get started by trying to run the android or iOS sample app on your machine. Feel free to PM me on any issues your running into.

To add to that this is the Elixir-desktop bridge library bridge/lib/bridge.ex at main · elixir-desktop/bridge · GitHub

It’s a simple socket server using JSON for data exchange between native and Elixir. This one is specific to Elixir-desktop and mocks the wxWidgets APIs that are not existing on iOS and Android. For your SDK case you would be able to use the same approach but implement your own Bridge that wraps your APIs.

My use case is to build an SDK that will be used to talk with the backend (with added security) and to manage some functionality that will be common to both Android and iOS. To be clear I will not need to do UI stuff.

If you are not going to do any UI stuff in elixir, then you can just make a headless binary that is controlled by stdin/stdout from the outside. The binary can be distributed inside your mobile app.

You mean I can write the code in Elixir and compile it to native Android and iOS?

Being controlled from the outside, means to maintain complexity in both Swift and Kotlin wrappers, or am I misunderstanding something?

Bear in mind that I am a newbie in terms of mobile app development.

This is not something I have done either. But to use elixir in any way on the mobile platform, binary generation must be a prerequisite?

On the elixir side it is just port, possibly with a json interface. On the other side, you would need to wrap the port interface in the native language. Some part of it could be automatic code generation based on a spec or something.

I think so.

Wouldn’t be the use of Android and iOS FFI a better option?

Maybe; however, then you need to link them together; which can be tricky. Whereas with port, it would be quite mechanic to implement and easier to test. True, you pay the cost of serialization and head of line blocking, but if absolute speed is the goal you wouldn’t want to do it in elixir anyway.

This option is tricky but possible on Android, but it’s impossible on iOS. There is no such thing as stdin/stdout communication on iOS. You can’t in fact ship more than one executable. Everything has to be one big statically linked object file. You can checkout the port of the beam, but in short the system() and spawn_port() commands are not supported on iOS. This is an iOS limitation and intended by apple.

For that reason I went with JSON communication via sockets. But it’s all running in the same iOS process. With some more native plumbing the socket could be replaced with in-process communication with memory buffers which would be more efficient, but I didn’t have enough time for that.