Re: Rust Mobile App
Aminta Brauer
I would like to develop mobile apps for Android/iOS in Rust because Rust is awesome, safe and is the only sane system + application programming language IMO. Sadly, I have no idea where and how I should start. Therefore I researched about frameworks and relatives for that task. I found NativeScript, Phonegap/Cordova, Rubymotion, Xamarin and Djinni.
The approach of Xamarin is the best in my opinion.
They wrote an abstraction layer for the native UI ( ).
For access to sensors, camera etc. they have a system called DependencyService. I think it actually wraps platform-native calls (JNI on Android, something in ObjC on iOS).
To automate generation of binding to call Rust code from Java I created rust_swig,
I plan to use it also to cooperate with Swift, from Rust's structure/trait generate C functions
like foo_new, foo_method, and then generate Swift class, which hide this ugly C functions,
and allow to work with Rust traits like Swift class.
Gtk doesn't do mobile apps AFAIK. While I would love to see that happen, there are going to be folks who scream "'NOOOO'," and for good reason. Gtk is tailored for desktop apps only, and even though Wayland support in EGL/GL ES/whatever-gl-I-missed is here, we don't have a responsive interface ready-to-go. If that were to happen, I'd probably die of a heart attack.
I know some people (like the guy who developed Audacity) say they regretted developing a cross-platform GUI framework, and they say that "certain things feel out of place", but I feel like if you write an agnostic cross-platform app gui framework that binds nearly 1:1 to said platforms' framework, there shouldn't be an issue.
It's a bit more complicated, but you could have 2 (or more) glade files (or UIBuilder files, as I think they are called now), and load one of them based on your constraint (OS, screen size, window size, etc.), like Android does, or simply define the whole interface programmatically.
I think when I said "responsive" I may have meant "converging" at some point. Like watching the same code you wrote respond to three totally different modes of input and you don't have to touch a single LoC.
How is it going with this project? I'm about to write a mobile app and thinking if I should only do iOS since I know the platform, or use Xamarin and do cross platform. The best ever would be if there was a Xamarin equivalent that uses Rust
I'm currently evaluating possible options for technology stack for my mobile app. I would really like to try Rust for the backend, however I have some doubts that there are missing bits and pieces everywhere and I would have to develop a lot of stuff from scratch compared to if I chose a well-established platform like Firebase or Parse. If anyone has an experience of building mobile backends in Rust and difficulties you encountered, I would much appreciate it if you shared them here. Also if you think why Rust is or is not a good choice for building mobile app backends, please let me know too.
Rust is a great language for writing backends, because it makes it a lot harder to make dumb mistakes that affect every user, including security vulnerabilities (memory safety or otherwise) and database misuse.
You're already familiar with Rust and have experienced Rust devs on the team. Network backend will require use of async Rust. On the technical side async is IMHO very good, but it does add a few more things to learn to an already steep Rust's learning curve. Rust can feel high level and be very productive once you know it, but if you're learning as you go, you might get stuck. You can get results faster in a higher-level garbage-collected language.
If you need to work with significant amounts of data and/or low-latency. If you e.g. need to process video streams in real time, generate images, or parse high volume of messages. Rust can be much faster and more memory efficient than server-side scripting languages. OTOH if all you do is fetch things from a database and serve them, you can do it with almost any language.
Or if you work in a domain that requires high level of correctness, where some unexpected null field could cause more trouble than just refresh of a page in an app. Rust generally doesn't allow cutting corners, and its strict type system can catch more problems at compile time than you'd get from a more forgiving language.
In terms of speed, it depends. If your API is just a "CRUD" interface to a database, then Rust won't make it much faster. If you have some data processing involved, or need to have very low latency or low memory usage, then Rust will help.
My exact use for my project is to build a simple social network (with auth, ect) using an ORM. I already did that in rails and it was pretty simple. I want more control over the code so I though of choosing rust.
You definitely can, if you want low level access then Rust is definitely the way to go. It most likely won't be a "lot" faster as the database gives most of the overhead, but will improves some aspects of the API. About the code, it's very likely to take a lot longer to write compared to Rails due to the complexity of most frameworks.
I already built the backend in Rust because I assumed I was going to hook it into WebAssembly, but the front-end, I got no idea where to begin. It doesn't have to be WASM. But I'm not really familiar with my choices.
And now my head is spinning and I need some guidance! Do I build everything (GUI included) as a rust library? Should WASM just draw it all to the HTML canvas? Do I separate front-end and back-end? etc.
As far as I know there is no simple way of creating native apps on ios and android. At least on android you could try going through a java native interface, but I don't think that's a "beautiful" solution.
What I would probably try is taking one of the GUI frameworks (as far as I know they are all still in progress), see here.
At least iced and druid can somehow be compiled to webasembly and used in the browser (there are examples to test in the browser, so its possible), but I don't know how complicated these are to do.
web-view is a crate in Rust, You supply it a string containing HTML code, and then, I believe, it asks the OS to generate a webview from the HTML. It can ask, Linux, Windows, and MacOS for a webview. If this crate had implementations for android and iOS wouldn't this crate at least theoretically be the all-in-one solution? (Asking to make sure even I understand my own problem correctly!)
Disclaimer: I have used jni only very briefly.
That being said jni is mostly used to interact with C code, and should also be usable to interact with rust ffi.
There are crates out there that seem to provide this functionality, but I haven't tried them (searched for jni on crates.io). There are also some android specific results.
I would try going the simplest route, which for me looks like getting some GUI library to output some webpage (which could be tested on your Dev machine) and then get that running on mobile platforms and their respective webview widgets.
This would obviously require wrapper applications for the mobile platforms, but I guess you would need them either way (considering app icons, permissions, etc).
In 2012, a friend and I wrote a mobile game called Panda Doodle. It was a puzzle game in which the player had to draw connections between doodles by matching/mixing the correct colors while looking for the shortest paths that required the least amount of paint. We were two programmers, but we also got help from an artist who contributed with very nice drawings which made the game look great!
The game was originally written in C++ using the Marmalade SDK. Since then this SDK has been discontinued and because of that we lost the ability to compile the game for newer platforms. In consequence of lacking those updates the game got kicked out of both the App Store and Google Play.
Panda Doodle wasn't a big hit or anything, but it was quite well polished and we were kinda proud of it. The fact that we couldn't play the game anymore made me feel a bit sad. It was funny: every time I got a new smartphone or tablet, the first thing I tried was installing Panda Doodle on it and checking how it ran. And now I couldn't find the game in the app stores anymore. My son was about to be born and I thought "Damn, at this pace he probably won't be able to play my game!". Sometimes I can get obsessed with fixing things, and I had to fix this.
Well, in the beginning of 2020 I was starting to get curious about Rust. What's up with all this hype around it? I read the Rust Book which was a nice introduction, but in my experience I usually come to grasp something much better by trying to use it. So I started to look for opportunities to do that.
For those not familiar with Rust, if I had to describe what is unique about it in a few words I would say it's a programming language without garbage collection that can still guarantee memory safety (all other languages that I know that can guarantee memory safety come with garbage collection and its performance drawbacks). To add a few more words, it also provides thread safety.
All of that means Rust is a language in the same league as C/C++ in terms of performance, but also one that takes away a bunch of foot cannons that usually come with that. The thread safety guarantees are also a big deal (very few languages have these), which make it even safer than languages like Java or Go. So fast and safe, a pretty interesting combination.
As part of my initial exploration around Rust, I came across rustwasm and wasm-bindgen which are neat tools that allow building rust-generated WebAssembly and easily interacting with the browser Javascript APIs. I also remember coming across RustyVolley which is a simple game, but looked pretty good and ran super smoothly on my browser.
That was when I first had the idea. Maybe... I could rewrite my game in Rust to run in the browser?
This idea had a few interesting points going for it:
- I get to learn Rust. This is a mid-sized project that will probably push me enough to explore a good part of the language and its features.
- Translating C++ into Rust would probably give me insights on what exactly is different between these languages. By understanding changes forced by Rust, I would probably even become a better C++ programmer by getting a clearer picture of some of its pitfalls.
- I get my game back!
- And by targeting browsers this time the game will last... forever? I bet someone thought this when they were building Flash games back in the day! haha. Still the HTML5 APIs seem pretty solid and in much better shape than Flash ever was, so betting that they're here to stay for a long while seems reasonable.
- I also get to bypass the app stores and don't have to deal with their annoyances. They can't kick me out anymore! ? (to be fair, it wasn't their fault that the SDK I used disappeared)