What about a strategy for mobile platforms?

[loes]

Rust has come a great way and it’s great to see the language hit 1.0! Unfortunately, us mobile developers aren’t able to share in this awesomeness as easily as our desktop and server counterparts.

Mobile development today is somewhat of a siloed experience, which makes it harder to share code across platforms. One solution is to use a cross-platform framework. Unfortunately, this can have a lot of downsides, requiring licensing of proprietary tools and poor integration with existing tools, and the extra abstractions can have a bad impact on performance and development overhead. For those of us that want to create quality apps without abstractions getting in the way, these options are a non-starter.

Another option is to share code in C and C++. This is a popular option for games, and some apps (including Dropbox) do this as well. The problems with this approach are already well-known by the group here, hence the demand for new languages like Rust. There’s a lot of demand for a better way! As an example, there’s Silver, an implementation of Swift that seeks to make it possible to write Swift code on other platforms. Developers want to be able to write code for different mobile platforms without necessarily using web technologies or dropping down to C/C++.

From what I can see, Rust does technically support Android and iOS today, but on a second-class level and with a lot of hoops to jump through. When I looked it up, I could only find some scattered information on blog posts here and there, and on a Wiki backup on the Rust site and ultimately I ran into some problems and didn’t get it working at all. It may be possible to get it working right now with enough hacking and poking around, but it’s certainly not easy or fun to use.

Here’s what would make me feel a lot more comfortable as a mobile developer:

1. To start with, it would be really helpful to have some official documentation on the main Rust site on how to setup the Rust compiler for cross-compiling to iOS and Android, with detailed integration steps and instructions on how to integrate things into the build process.

2. Down the road, it would be super-nice to have prebuilt binaries and scripts that can be plugged into an existing build framework. I don’t know how much work this would take as I’m really unfamiliar with the compiler side of things, but as a user I can say that it would be really great to be able to download some compilers and just start using them! I can worry about FFI but having a working compiler to go with is already a big step!

3. Having a story for FFI would be very useful for easier integration into existing codebases. I believe there are already scripts that exist here? They would just need to be adapted to make it easy to generate JNI bindings, C wrappers that can be easily called from Swift, and so on. First-class support for Emscripten would also be a big boost, as it would allow targeting platforms that don’t allow native code, including the web and Firefox OS.

So I really hope I’m not coming across as demanding or complaining here, as that’s not my intention at all. I appreciate all of the effort the team and all of the volunteers have put into this and I would do it myself if I knew anything about working on a compiler. I just want to open the discussion with the hope that Rust can be a strong option for us one day, and I’m curious to see if there are any plans for this now or in the future.

[tomaka]

There are two problems when it comes to using Rust on a different platform.

The first one is that Rust’s stdlib must support the given platform. For the moment if you want to compile for Emscripten for example, you have to make modifications in the stdlib, compile it, and pass the path to it with --sysroot. Obviously it would be better if a platform’s code was directly in the rust repo, as it would avoid breakages. But rust can’t support all platforms, so how do you draw the line between a first-class platform and a second-class platform?

The second problem is that even if you have a Rust and a stdlib for a given platform you still need a linker that targets it (and the basic libraries like the libc), plus sometimes some additional tools. It was already an headache to package Rust with MinGW on Windows, and distributing some binaries with an Android SDK or a prebuilt Emscripten would be worse. Some platforms also require some special steps, and Cargo doesn’t support anything like this for the moment.

[brson]

For what it’s worth, creating a Xamarin-like universal platform around Rust is one of my long-term dream goals, not just for consumer mobile, but much smaller embedded devices. It’s going to take lots of effort and money though to deliver a consistently great experience on diverse platforms.

[brson]

From my perspective the important next steps here are to figure out an ergonomic cross-compilation development and deployment story, extending official distribution to more popular targets. I have vague plans for extending the existing infrastructure in this direction, but nothing on the immediate roadmap, except perhaps what’s necessary to conveniently develop for the upcoming MSVC and musl targets.

[cmr]

It took me about an hour to go from 0 knowledge of iOS development to a working Xcode project building a Rust application with SDL2, and similar effort for Android. I don’t think the situation is that dire, you just need to build Rust. I’ll write a blog post about it soon.

[aturon]

t took me about an hour to go from 0 knowledge of iOS development to a working Xcode project building a Rust application with SDL2, and similar effort for Android. I don’t think the situation is that dire, you just need to build Rust. I’ll write a blog post about it soon.

Keep in mind, though, that you’ve been working with Rust for a long time now, and know your way around The OP suggests that a major factor here is just lack of centralized docs and guides – a blog post sounds great!

[cmr]

Keep in mind, though, that you’ve been working with Rust for a long time now, and know your way around The OP suggests that a major factor here is just lack of centralized docs and guides – a blog post sounds great!

Right, I recognize that, which is why it’s my duty to write some docs!

[steveklabnik]

Right, I recognize that, which is why it’s my duty to write some docs!

[loes]

A new blog post would definitely help out! I could probably get it working if I hacked on it long enough, but as someone who makes a living doing mobile development, I’d feel a lot more comfortable if I knew that it was on the same level as the desktop platforms and getting the same love and attention from the core developers. Mobile is now the computing platform with the most users1, and it’s a market that’s being left on the table by some of the other languages because they don’t have a compelling story here. For many people, their mobile device is their computer.

A Xamarin-like universal platform is definitely an ambitious goal, and I believe that Rust can provide a massive benefit even far short of that goal; if there was a good story for integrating the Rust compilers into existing mobile build workflows and for linking to that code with easy-to-create wrappers, and this was put on equal footing with the desktop platforms, I think that would go a very long way.

I’m really happy to see so many positive responses, and so quickly. I’m sure there are other OSS communities where I would have been roasted off of the board by now. Thanks for having an open ear.

[cmr]

Mobile is really important to me as a platform to ship on as well, but I’m definitely not a mobile developer so I’m hoping that if I put down some foundations other people can build the castle

[tomaka]

I’m not familiar with Xamarin.

Does that mean that you’d “extract” the std::sys and std::rt modules from the stdlib, and allow third-parties to write counter-parts for a specific platform?

[vhbit]

Feel free to ask any questions regarding iOS.

I believe I’m in the same boat as @cmr - I’ve been doing it for a long time and from my perspective info in Wiki is more than enough to start (otherwise I’d put much more there). But… based on questions, I can provide much more detailed write up.

[sgrif]

@cmr Did you ever get around to writing anything? I can’t seem to find resources or get anything to work for Android in particular when I’m not using NativeActivity. It seemed like it’d just be as simple as building with the right target and including the .a file as a static library, but no dice. Would be interested to hear your stories on getting things to build.

[cmr]

Not yet, sorry. We decided to put off the mobile port for a bit and focus on the MVP.

See https://github.com/tomaka/android-rs-glue though.

[sgrif]

Yup, I’ve looked pretty deeply into it. Seems to only be helpful for apps using NativeActivity though.

[kkrishnan90]

Any update on the ffi integration part with Android ?? I’m finding it very difficult to actually even cross compile a shared library using rust code. Also , I’m planning to shunt away from JNI and use JNR FFI formula to use Rust in my app. However the most hardest shell to crack here is the cross compilation part. Any idea thrown at this would make my life much easier than running through 500 snippets of code from stackoverflow and finally nothing works…

[malbarbo]

Have you tried cross?

[kkrishnan90]

That one looks promising man ! I’ll give it a shot tonight and share my views. If so that works great with JNR FFI (as JNR seems to be upset not even loading the .so file) I’m just suspecting if that can be a problem with .so file generated. However, the same .so file used over JNI wrappers works seamlessly. Any light thrown over JNR would also be much helpful as JNI only increases effort by writing wrappers over the compiled .so file again ! JNR seems to do a great job on Desktop Java Apps but fails blatantly over mobile platforms.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.