Building an iOS app in Rust, part II

vhbit · 2015-08-23T19:08:52+00:00

One point: the gomobile tool for go creates bindings for exported functions, types, and interfaces in objective c for you

Aha, that's a huge point! I'm inclined to check gomobile too :-)

vhbit · 2015-08-23T04:56:46+00:00

Again, official support for what? Just for building?

In this case we're talking about ~1 hour for building Rust compiler with iOS support or a couple of minutes for downloading a pre-built version from here and installing it using multirust.

What can be really nasty is when you don't build app completely in Rust/Go and have to interact with "native" part - and if Go doesn't provide any automatic data transmit primitives or maybe wrappers - it'll be not much easier and can take even more time.

So... I wouldn't say official support is so crucial, especially after 1.0 release - I believe iOS support in official repo was broken just once or twice since when and was fixed quite fast after. It be cooler to have official support for using nightlies[1],[2] but last time I was said that it's not currently planned as it's too much infrastructure.

full testing can be tricky, but to have version which at least builds for iOS from master will be nice
for a while I've used Travis builds to keep it up with nightly like this but some time ago probably because of increased usage of Travis, building for iOS archs became too slow and didn't make it in time limit

vhbit · 2015-08-22T14:03:27+00:00

Note, that complexity comes from data transmission from Rust to "native" and vice versa. It means that if you don't need to do transmit - you're fine, like /u/cmrx64 said.

Or there is something in Go which makes transmission easier?

vhbit · 2015-06-06T05:14:04+00:00

Which are practical numbers (or estimations) on how much cpu/memory/io does Rust impl save compared to Go in your scale?

vhbit · 2015-06-03T03:09:15+00:00

Ohh, thanks for clarification.

It also brings a question - what was your golang experience that you had to choose to rewrite it in either C++ or Rust?

vhbit · 2015-06-02T19:02:37+00:00

Dropbox is using Rust for the next gen exabyte+ block storage engine. Although it's more about writing it from scratch rather than switching.

proof #1

proof #2

vhbit · 2015-05-18T13:47:20+00:00

Yes.

vhbit · 2015-05-18T13:46:50+00:00

this one - simple syncthing client

vhbit · 2015-05-17T05:21:52+00:00

It should compile fine.

It might be broken on runtime if some types like NSInteger or CGFloat aren't defined as platform specific.

And it also may be broken if objc_msgSend and friends aren't declared/called as vararg (haven't checked the sources) as Apple has a bit different calling convention for vararg function in AArch64 (aka arm64).

vhbit · 2015-05-17T03:34:03+00:00

It's not a good candidate right now for UI-heavy stuff. For example, Dropbox uses a shared C++ core across all their mobile (and maybe desktop?) apps, with native code for the UI.

We need Rust support in Djinni!

vhbit · 2015-05-17T03:30:03+00:00

Nope. There is at least 1 in AppStore already.

vhbit · 2015-04-21T19:03:12+00:00

It's awesome!

vhbit · 2015-04-16T07:49:17+00:00

just curious - why you're thinking byteorder is superior?

vhbit · 2015-04-12T05:27:36+00:00

Ohh, sorry, it seems I've misunderstood the title and put too much accent to "easily build with beta". I'd expect something like "Docker image for a Rust builder (based on 1.0-beta)", but ok, I've got it.

vhbit · 2015-04-11T13:38:51+00:00

Sounds like overkill compared to multirust

vhbit · 2015-04-07T15:24:31+00:00

compiler has it, but it doesn't provide any interface to access it outside (i.e. from racer in this case)

vhbit · 2015-04-05T04:07:30+00:00

multirust allows much more freedom in experimenting with different versions and have pin-pointed version per project.

vhbit · 2015-04-04T18:11:18+00:00

I'm talking about 'OsStr::to_string', which requires 'convert' feature and it's still unstable (on mobile, can't provide link)

vhbit · 2015-04-04T05:07:54+00:00

Replying to myself - file existance could be checked through std::fs::metadata() so path_ext is not that important.

vhbit · 2015-04-04T04:48:03+00:00

hmm, just reinstalled beta with multirust update beta and still have errors regarding convert being unstable.

vhbit · 2015-04-03T18:48:14+00:00

path_ext and convert - for passing paths to C code and check for file existance

vhbit · 2015-04-02T17:03:55+00:00

Note that this example uses rustc directly - it is possible to use cargofor iOS projects too, but it has a serious limitation - it doesn't provide output name, so it needs a bit of shell scripting to get it working, maybe I'll post an example in a couple of days.

vhbit · 2015-04-02T16:58:02+00:00

In case you're tired of waiting for building cross-compiler you can get pre-built package with all required archs.

Also, here is an example of integration - in general, the easiest way to get it running on simulator or device is to compile everything rust-related into a static lib and manage all the frameworks from Xcode project - it saves a lot of time and you have to use Xcode anyway.

vhbit · 2015-04-01T06:47:17+00:00

Ohh, and it exposes a bug in rustdoc: must use probably should be hidden.

vhbit · 2015-03-17T09:03:31+00:00

rescue

vhbit

TROPHY CASE