9 ms·

Crux: Cross-platform app development in Rust

186 points by homarp 3y ago

lainga 3y ago
Just to clarify, does "cross-platform" in this case mean only {iOS, Android, Web}?
- Aerbil313 3y ago
  Apparently yes. But we have installable PWAs, so…
- deleted 3y ago
  [deleted]
- SushiHippie 3y ago
  I suppose on desktop (windows, linux, macos, ...) you could use the rust component as a normal library without the need of special stuff like on android ios and web
- jeroenhd 3y ago
  Windows can run APK files natively these days: https://learn.microsoft.com/en-us/windows/android/wsa/ https://learn.microsoft.com/en-us/windows/android/wsa/ ChromeOS runs Android apps as well. Apple has Mac Catalyst (https://developer.apple.com/documentation/uikit/mac_catalyst https://developer.apple.com/documentation/uikit/mac_catalyst) which may just work with this wrapper. Linux can run Android through Waydroid (though doesn't work as well as on Windows). PWAs can be installed to desktop on practically any browser that isn't Firefox to make them look like native applications with icons and protocol/share handlers and all. So technically, it's cross-platform as in "mobile apps that will work on desktop if you like a terrible experience"
cmrdporcupine 3y ago
It would be interesting to see, in a real world app developed this way, how much weight is actually being carried by the Rust portion. I feel like it might not be much? The few times in my career that I've ended up doing UI development, the code and complexity was in the presentation layer, not in events or model or business logic. And while can see the advantage of having a crossplatform layer for that stuff.. even as a fulltime Rust developer, I don't really see the advantage of using Rust for it vs, say, TypeScript. But I'm willing to be convinced.
- andrekandre 3y ago
  > The few times in my career that I've ended up doing UI development, the code and complexity was in the presentation layer, not in events or model or business logic. its true, though it doesn't necessarily have to be that way (view models (or even bff) if done properly) speaking from experience, i think the big issue is how will your dev team be structured... will android/ios people be able to write idiomatic rust (or whatever language) or should that core be a completely separate team? now you cant just hire any dev, they need to understand how it's going to be used by multiple client languages specific to that cross-platform system though this framework looks like its pre-baking the architecture which means it probably wont look idiomatic from the client-side, so now your hiring for ui needs to take that into account... and now you have multiple teams that need to communicate adding overhead. using cross-platform sounds simple and easy in the beginning but its a big commitment with multiple facets i'm not sure what the real answer is... my guess is "it depends: what are you actually trying to do?"
- mdgrech23 3y ago
  This is a good point. I remember about 2005 time frame and probably even after everyone thought the front end was easy and the "real" work was on the server. What a joke.
  - scns 3y ago
    Arrogance (trying to hide low self-esteem) has many faces.
- fiedzia 3y ago
  > even as a fulltime Rust developer, I don't really see the advantage of using Rust for it vs, say, TypeScript. UI libraries aside, Rust is better language and has better tooling, which overall contributes to productivity. TS/JS as a language for tooling is brittle and slugish (unless it's rewritten in Rust, where significant amount of tools is already heading), and I am happy for it to be replaced.
  - raincole 3y ago
Klonoar 3y ago
This is your friendly reminder that Spotify went out of their way to write a networking library that wraps platform specific network libraries since iOS will have special-ish behaviors that you lose if you aren’t using their stack. I am the biggest proponent of Rust where possible but I always feel like this is worth mentioning when people bring up moving all shared logic for mobile platforms to Rust. It would be great to see it reqwest/ureq/etc could have a feature flag to use these behind the scenes: https://github.com/nativeformat/NFHTTP https://github.com/nativeformat/NFHTTP Also: if anybody from Spotify is reading I would love to know why it’s discontinued and passed to community maintenance. Alternatively, if someone from e.g Apple would weigh in on how much this still matters it would also be welcome.
- deleted 3y ago
  [deleted]
- jamil7 3y ago
  I think I've seen you mention this before here, and it led me to writing a note about this topic in some documentation at work. So, thanks for the heads-up. Do you have any idea what would be required to write a URLSession backend for ureq/reqwest?
  - Klonoar 3y ago
    To be honest I've not looked into how tricky it would be - if anything I went the opposite route of experimenting with a reqwest-API-compatible wrapper for URLSession but didn't get too far due to other projects taking up my time. It might be the easier path though - one crate that basically uses a `reqwest`, `ureq` or `URLSession` backend since the former two would still work on Android to start. For reqwest specifically I guess it would also depend on how badly you want `async` support or not (i.e just the blocking module API).
    - jamil7 3y ago
      Thanks, sounds like your initial approach would be easier, a blocking API is fine for me. I'll look into it a little further.
Aerbil313 3y ago
I’m not convinced that this is a better approach than using Svelte 5 + Tauri. Web is here to stay and I’d rather not learn Swift and Kotlin. I know they say the native UI layer will be as thin as it can get but it still necessitates knowing those 2 langs.
- ComputerGuru 3y ago
  How are you sold on Svelte 5 when it isn’t even released for download as a beta yet?
  - Aerbil313 3y ago
    I saw Runes and that was what I needed to see. Svelte is continuing on its original vision to reach its logical conclusion of easy web application development.
- viraptor 3y ago
  You say that, but there's a lot of pushback against the electron apps for a while now. Tauri improves on that only a little bit. I'm going to go out of my way and lose some features happily is it means I'm using a native app these days, and I know other people do as well.
  - RussianCow 3y ago
    > I'm going to go out of my way and lose some features happily is it means I'm using a native app these days, and I know other people do as well. People say this all the time, but in the real world, whether or not an app is native matters very little compared to everything else about it: features/content, design/UX, etc. And if using web technologies lets you build the app, say, twice as quickly, that means it will have that many more features or be that much more polished than the hypothetical native version, and that could mean the difference between having actual users and not having an app in the first place.
  - bhdlr 3y ago
    How do you feel about react native? As a career mobile developer I honestly can't tell the difference between a well made react native app and a true native app
AbuAssar 3y ago
what about accessing device's hardware features?
- serial_dev 3y ago
  (just a wild ass guess, I don't have experience with crux) > It splits the application into two distinct parts, a Core built in Rust, (...) and a Shell, built in the platform native language (Swift, Kotlin, TypeScript), which provides all interfaces with the external world. The "external world" includes hardware features, camera, notifications, payment APIs, NFC, gyroscope, etc. The way I imagine it is: as long as the Rust part can talk to the native part, "everything is possible" and you can send commands from the Rust part and send the results back from the native part (or vice versa) or probably even set up streams of data (e.g. live updates to gyroscope). Flutter has platform channels that is a similar idea. I expect it's even easier in Crux because in Flutter almost everything is written in Dart, and Crux leaves more to platform specific stuff https://docs.flutter.dev/platform-integration/platform-channels https://docs.flutter.dev/platform-integration/platform-chann...
airstrike 3y ago
this is pretty neat. I'm building a cross-platform project with yew and this should make things much smoother I am, however, having trouble getting the examples to work. some issue with installing `aarch64-apple-ios` using `stable-aarch64-apple-darwin` error: failed to install component: 'rust-std-aarch64-apple-ios', detected conflict: 'lib/rustlib/aarch64-apple-ios/lib/libaddr2line-8a8c95c7e51dcc3f.rlib' my rust-foo is limited, so I'll keep digging, but if anyone knows of a solution, I'm all ears and deeply grateful
satvikpendem 3y ago
I do this already, but with Flutter and Rust, via the FFI package flutter_rust_bridge. You can write your logic in Rust and transparently call the functions from the Dart side. The benefit is that you get rock solid business logic that can be compiled everywhere as well as a "write once, run everywhere" solution in Flutter. I don't see why you'd need or want to write even the UI layer from scratch every time.
- halostatue 3y ago
  If I can tell that your app is a Flutter app — and unless I’m stuck on an Android phone, I can always tell — your app is being uninstalled. Flutter looks wrong and behaves wrong and is just Google's modern reincarnation of Swing, which at least had its own display shape. I will especially never use your web app if it is based on Flutter. There's a reason that Electron apps get more grief from users of macOS than anything else, and Flutter is at least two steps worse than Electron IMO.
  - satvikpendem 3y ago
    Good for you, but most people can't tell nor do they care, given that I've shipped Flutter apps across thousands of users, both consumer and enterprise, whom we collect feedback from. Not once did anyone complain about the app visuals or performance itself, just about the lack of features that they are looking forward to. For that kind of developer experience to consumer satisfaction ratio, Flutter is unbeatable. At least Flutter compiles to machine code instead of shipping a browser per app.
    - zdragnar 3y ago
      At least in the enterprise space, users are well accustomed to terrible design and UX, because the people with the purchasing power aren't the users, and the users have no purchasing power. Think JIRA, or Epic EHR, or SAP - everyone loves to hate it, but it is the go-to solution because it does what the people paying for it want. The bar is so obnoxiously low in that space that your app literally just needs to work, and people are happy with it. Same goes with a lot of prosumer software. People complain about missing features they need, because having a slick UI is very much a secondary concern, well after "is this actually doing everything I want it to do?" and "does it have all the features I want to accomplish my goals".
rapnie 3y ago
This is an interesting project. The docs mention WebAssembly as a target on the Web side. And I wonder if there are plans to go further on this Wasm track. With Component Model and WASI maturing, polyglot component-oriented development also is within reach. A lot of this is working today. As example look at wasmCloud [0] actor-based application framework which also separates business logic from capabilities / NFR's a la hexagonal architecture. And Cosmonic have built a capability-provider for event sourcing, called Concordance [1]. Everything in this setup is compiled into wasm modules that can be composed into larger components and deployed on any host you spin up. [0] https://wasmcloud.com https://wasmcloud.com [1] https://cosmonic.com/docs/oss/concordance/ https://cosmonic.com/docs/oss/concordance/
blueflow 3y ago
Name collision with https://crux.nu/ https://crux.nu/
- jeroenhd 3y ago
  That's the risk of using simple English (or, I guess Latin) words as your brand name. There shouldn't be too much confusion, though. Crux is either a niche Linux distro or a cross platform build tool, or a business intelligence tool, or a finance provider for green electricity. All of these names can coexist without confusion.
jug 3y ago
Or else you could of course just use https://rocket.rs/ https://rocket.rs/ I mean, honestly. What more do you need than a simple and fun library for the API to the backend? It's 2023 and the cross-platform user interface is the web, the rest has lost, and your devs and cross-platform community is on the web. Even a biased company like Microsoft don't seem to pretend anything else these days as they base their large scale (Office, Teams) apps on... YEP you guessed it, the web.
- robertlagrant 3y ago
  That looks like a backend web framework to me. Did I miss something?
  - rychco 3y ago
    I believe the point of the original comment is that if you’d really like your business logic to be written in rust, you can already do so by building a backend service with a mature rust library & access it via web.
    - Klonoar 3y ago
      Rocket is borderline dead so it’s weird look for OP to suggest it.
- deleted 3y ago
  [deleted]
- bmitc 3y ago
  There are several apps that just do not work on the web inside a browser. If an app is anything beyond a single page app, it effectively requires being a desktop app. It makes no sense to me when people say desktop apps are dead and that web apps are where it's at, when web apps run in a browser which is a desktop app. It's like claiming containers won and operating systems have lost.
- robertlagrant 3y ago
  > I mean, honestly. What more do you need than a simple and fun library for the API to the backend? It's 2023 and the cross-platform user interface is the web, the rest has lost, and your devs and cross-platform community is on the web. Even a biased company like Microsoft don't seem to pretend anything else these days as they base their large scale (Office, Teams) apps on... YEP you guessed it, the web. This makes it make less sense now. Office you can get in a browser, but it's terrible, and Teams is a local client-side app. Or am I mistaken? Could you make the Teams client with rocket.rs?
Zambyte 3y ago
I thought this was going to be related to Crux[0]. [0] https://crux.nu/ https://crux.nu/
mwcampbell 3y ago
This is an interesting architecture, but on at least two of the three target platforms, specifically Android and web, I think it would be better to use Kotlin Multiplatform [1] than Rust. Because Kotlin compiles to JVM bytecode (and ultimately to Dalvik bytecode) on Android and can compile to JS for the web platform, it means that for both of those platforms, the whole application can be compiled and linked together in a single type of object code, leading to lower overhead and a smaller bundle. There's also no need for serialization and deserialization when going between cross-platform and native code, further reducing bundle size; deserialization in particular requires heavy glue code. But I don't yet have any experience with Kotlin Multiplatform, especially Kotlin Native for iOS. Does anyone know whether Rust has any particular advantages over Kotlin for any of the three target platforms? [1]: https://kotlinlang.org/docs/multiplatform.html https://kotlinlang.org/docs/multiplatform.html

186 points by homarp 3y ago

lainga 3y ago

Just to clarify, does "cross-platform" in this case mean only {iOS, Android, Web}?

Aerbil313 3y ago
Apparently yes. But we have installable PWAs, so…
deleted 3y ago
[deleted]
SushiHippie 3y ago
I suppose on desktop (windows, linux, macos, ...) you could use the rust component as a normal library without the need of special stuff like on android ios and web
jeroenhd 3y ago
Windows can run APK files natively these days: https://learn.microsoft.com/en-us/windows/android/wsa/ https://learn.microsoft.com/en-us/windows/android/wsa/ ChromeOS runs Android apps as well. Apple has Mac Catalyst (https://developer.apple.com/documentation/uikit/mac_catalyst https://developer.apple.com/documentation/uikit/mac_catalyst) which may just work with this wrapper. Linux can run Android through Waydroid (though doesn't work as well as on Windows). PWAs can be installed to desktop on practically any browser that isn't Firefox to make them look like native applications with icons and protocol/share handlers and all. So technically, it's cross-platform as in "mobile apps that will work on desktop if you like a terrible experience"

cmrdporcupine 3y ago

It would be interesting to see, in a real world app developed this way, how much weight is actually being carried by the Rust portion. I feel like it might not be much? The few times in my career that I've ended up doing UI development, the code and complexity was in the presentation layer, not in events or model or business logic. And while can see the advantage of having a crossplatform layer for that stuff.. even as a fulltime Rust developer, I don't really see the advantage of using Rust for it vs, say, TypeScript. But I'm willing to be convinced.

andrekandre 3y ago
> The few times in my career that I've ended up doing UI development, the code and complexity was in the presentation layer, not in events or model or business logic. its true, though it doesn't necessarily have to be that way (view models (or even bff) if done properly) speaking from experience, i think the big issue is how will your dev team be structured... will android/ios people be able to write idiomatic rust (or whatever language) or should that core be a completely separate team? now you cant just hire any dev, they need to understand how it's going to be used by multiple client languages specific to that cross-platform system though this framework looks like its pre-baking the architecture which means it probably wont look idiomatic from the client-side, so now your hiring for ui needs to take that into account... and now you have multiple teams that need to communicate adding overhead. using cross-platform sounds simple and easy in the beginning but its a big commitment with multiple facets i'm not sure what the real answer is... my guess is "it depends: what are you actually trying to do?"
mdgrech23 3y ago
This is a good point. I remember about 2005 time frame and probably even after everyone thought the front end was easy and the "real" work was on the server. What a joke.
- scns 3y ago
  Arrogance (trying to hide low self-esteem) has many faces.
fiedzia 3y ago
> even as a fulltime Rust developer, I don't really see the advantage of using Rust for it vs, say, TypeScript. UI libraries aside, Rust is better language and has better tooling, which overall contributes to productivity. TS/JS as a language for tooling is brittle and slugish (unless it's rewritten in Rust, where significant amount of tools is already heading), and I am happy for it to be replaced.
- raincole 3y ago

Klonoar 3y ago

This is your friendly reminder that Spotify went out of their way to write a networking library that wraps platform specific network libraries since iOS will have special-ish behaviors that you lose if you aren’t using their stack. I am the biggest proponent of Rust where possible but I always feel like this is worth mentioning when people bring up moving all shared logic for mobile platforms to Rust. It would be great to see it reqwest/ureq/etc could have a feature flag to use these behind the scenes: https://github.com/nativeformat/NFHTTP https://github.com/nativeformat/NFHTTP Also: if anybody from Spotify is reading I would love to know why it’s discontinued and passed to community maintenance. Alternatively, if someone from e.g Apple would weigh in on how much this still matters it would also be welcome.

deleted 3y ago
[deleted]
jamil7 3y ago
I think I've seen you mention this before here, and it led me to writing a note about this topic in some documentation at work. So, thanks for the heads-up. Do you have any idea what would be required to write a URLSession backend for ureq/reqwest?
- Klonoar 3y ago
  To be honest I've not looked into how tricky it would be - if anything I went the opposite route of experimenting with a reqwest-API-compatible wrapper for URLSession but didn't get too far due to other projects taking up my time. It might be the easier path though - one crate that basically uses a `reqwest`, `ureq` or `URLSession` backend since the former two would still work on Android to start. For reqwest specifically I guess it would also depend on how badly you want `async` support or not (i.e just the blocking module API).
  - jamil7 3y ago
    Thanks, sounds like your initial approach would be easier, a blocking API is fine for me. I'll look into it a little further.

Aerbil313 3y ago

I’m not convinced that this is a better approach than using Svelte 5 + Tauri. Web is here to stay and I’d rather not learn Swift and Kotlin. I know they say the native UI layer will be as thin as it can get but it still necessitates knowing those 2 langs.

ComputerGuru 3y ago
How are you sold on Svelte 5 when it isn’t even released for download as a beta yet?
- Aerbil313 3y ago
  I saw Runes and that was what I needed to see. Svelte is continuing on its original vision to reach its logical conclusion of easy web application development.
viraptor 3y ago
You say that, but there's a lot of pushback against the electron apps for a while now. Tauri improves on that only a little bit. I'm going to go out of my way and lose some features happily is it means I'm using a native app these days, and I know other people do as well.
- RussianCow 3y ago
  > I'm going to go out of my way and lose some features happily is it means I'm using a native app these days, and I know other people do as well. People say this all the time, but in the real world, whether or not an app is native matters very little compared to everything else about it: features/content, design/UX, etc. And if using web technologies lets you build the app, say, twice as quickly, that means it will have that many more features or be that much more polished than the hypothetical native version, and that could mean the difference between having actual users and not having an app in the first place.
- bhdlr 3y ago
  How do you feel about react native? As a career mobile developer I honestly can't tell the difference between a well made react native app and a true native app

AbuAssar 3y ago

what about accessing device's hardware features?

serial_dev 3y ago
(just a wild ass guess, I don't have experience with crux) > It splits the application into two distinct parts, a Core built in Rust, (...) and a Shell, built in the platform native language (Swift, Kotlin, TypeScript), which provides all interfaces with the external world. The "external world" includes hardware features, camera, notifications, payment APIs, NFC, gyroscope, etc. The way I imagine it is: as long as the Rust part can talk to the native part, "everything is possible" and you can send commands from the Rust part and send the results back from the native part (or vice versa) or probably even set up streams of data (e.g. live updates to gyroscope). Flutter has platform channels that is a similar idea. I expect it's even easier in Crux because in Flutter almost everything is written in Dart, and Crux leaves more to platform specific stuff https://docs.flutter.dev/platform-integration/platform-channels https://docs.flutter.dev/platform-integration/platform-chann...

airstrike 3y ago

this is pretty neat. I'm building a cross-platform project with yew and this should make things much smoother I am, however, having trouble getting the examples to work. some issue with installing `aarch64-apple-ios` using `stable-aarch64-apple-darwin` error: failed to install component: 'rust-std-aarch64-apple-ios', detected conflict: 'lib/rustlib/aarch64-apple-ios/lib/libaddr2line-8a8c95c7e51dcc3f.rlib' my rust-foo is limited, so I'll keep digging, but if anyone knows of a solution, I'm all ears and deeply grateful

satvikpendem 3y ago

I do this already, but with Flutter and Rust, via the FFI package flutter_rust_bridge. You can write your logic in Rust and transparently call the functions from the Dart side. The benefit is that you get rock solid business logic that can be compiled everywhere as well as a "write once, run everywhere" solution in Flutter. I don't see why you'd need or want to write even the UI layer from scratch every time.

halostatue 3y ago
If I can tell that your app is a Flutter app — and unless I’m stuck on an Android phone, I can always tell — your app is being uninstalled. Flutter looks wrong and behaves wrong and is just Google's modern reincarnation of Swing, which at least had its own display shape. I will especially never use your web app if it is based on Flutter. There's a reason that Electron apps get more grief from users of macOS than anything else, and Flutter is at least two steps worse than Electron IMO.
- satvikpendem 3y ago
  Good for you, but most people can't tell nor do they care, given that I've shipped Flutter apps across thousands of users, both consumer and enterprise, whom we collect feedback from. Not once did anyone complain about the app visuals or performance itself, just about the lack of features that they are looking forward to. For that kind of developer experience to consumer satisfaction ratio, Flutter is unbeatable. At least Flutter compiles to machine code instead of shipping a browser per app.
  - zdragnar 3y ago
    At least in the enterprise space, users are well accustomed to terrible design and UX, because the people with the purchasing power aren't the users, and the users have no purchasing power. Think JIRA, or Epic EHR, or SAP - everyone loves to hate it, but it is the go-to solution because it does what the people paying for it want. The bar is so obnoxiously low in that space that your app literally just needs to work, and people are happy with it. Same goes with a lot of prosumer software. People complain about missing features they need, because having a slick UI is very much a secondary concern, well after "is this actually doing everything I want it to do?" and "does it have all the features I want to accomplish my goals".

rapnie 3y ago

This is an interesting project. The docs mention WebAssembly as a target on the Web side. And I wonder if there are plans to go further on this Wasm track. With Component Model and WASI maturing, polyglot component-oriented development also is within reach. A lot of this is working today. As example look at wasmCloud [0] actor-based application framework which also separates business logic from capabilities / NFR's a la hexagonal architecture. And Cosmonic have built a capability-provider for event sourcing, called Concordance [1]. Everything in this setup is compiled into wasm modules that can be composed into larger components and deployed on any host you spin up. [0] https://wasmcloud.com https://wasmcloud.com [1] https://cosmonic.com/docs/oss/concordance/ https://cosmonic.com/docs/oss/concordance/

blueflow 3y ago

Name collision with https://crux.nu/ https://crux.nu/

jeroenhd 3y ago
That's the risk of using simple English (or, I guess Latin) words as your brand name. There shouldn't be too much confusion, though. Crux is either a niche Linux distro or a cross platform build tool, or a business intelligence tool, or a finance provider for green electricity. All of these names can coexist without confusion.

jug 3y ago

Or else you could of course just use https://rocket.rs/ https://rocket.rs/ I mean, honestly. What more do you need than a simple and fun library for the API to the backend? It's 2023 and the cross-platform user interface is the web, the rest has lost, and your devs and cross-platform community is on the web. Even a biased company like Microsoft don't seem to pretend anything else these days as they base their large scale (Office, Teams) apps on... YEP you guessed it, the web.

robertlagrant 3y ago
That looks like a backend web framework to me. Did I miss something?
- rychco 3y ago
  I believe the point of the original comment is that if you’d really like your business logic to be written in rust, you can already do so by building a backend service with a mature rust library & access it via web.
  - Klonoar 3y ago
    Rocket is borderline dead so it’s weird look for OP to suggest it.
deleted 3y ago
[deleted]
bmitc 3y ago
There are several apps that just do not work on the web inside a browser. If an app is anything beyond a single page app, it effectively requires being a desktop app. It makes no sense to me when people say desktop apps are dead and that web apps are where it's at, when web apps run in a browser which is a desktop app. It's like claiming containers won and operating systems have lost.
robertlagrant 3y ago
> I mean, honestly. What more do you need than a simple and fun library for the API to the backend? It's 2023 and the cross-platform user interface is the web, the rest has lost, and your devs and cross-platform community is on the web. Even a biased company like Microsoft don't seem to pretend anything else these days as they base their large scale (Office, Teams) apps on... YEP you guessed it, the web. This makes it make less sense now. Office you can get in a browser, but it's terrible, and Teams is a local client-side app. Or am I mistaken? Could you make the Teams client with rocket.rs?

Zambyte 3y ago

I thought this was going to be related to Crux[0]. [0] https://crux.nu/ https://crux.nu/

mwcampbell 3y ago

This is an interesting architecture, but on at least two of the three target platforms, specifically Android and web, I think it would be better to use Kotlin Multiplatform [1] than Rust. Because Kotlin compiles to JVM bytecode (and ultimately to Dalvik bytecode) on Android and can compile to JS for the web platform, it means that for both of those platforms, the whole application can be compiled and linked together in a single type of object code, leading to lower overhead and a smaller bundle. There's also no need for serialization and deserialization when going between cross-platform and native code, further reducing bundle size; deserialization in particular requires heavy glue code. But I don't yet have any experience with Kotlin Multiplatform, especially Kotlin Native for iOS. Does anyone know whether Rust has any particular advantages over Kotlin for any of the three target platforms? [1]: https://kotlinlang.org/docs/multiplatform.html https://kotlinlang.org/docs/multiplatform.html