For those (1) familiar with Rust and (2) doing iOS dev, do you: (a) use swift or (b) use Rust ?
Swift (compared to ObjC) seems close enough to Rust for most purposes, and I'm not sure if it's worth fighting the iOS dev tool chain just to use Rust.
Nothing could be further from the truth. At this point I'd argue Swift is a lot closer to Java than it is to Rust.
I've been doing iOS development since 2009, first just as a hobby (when jailbreaking was still a thing – oh, the merry days of reverse engineering iOS system components with the almighty tool that is class-dump-z!), then professionally for a couple years. I've been following Swift since its public release in 2014 – but I semi-definitely quit iOS development about a year and a half ago.
My latest project was purely Swift, but I would still have preferred Objective-C, somehow. The problem with Swift that its type system is needlessly bureaucratic. It doesn't save you from nearly as many bugs as Rust does, yet it gets in the way all the time.
Type-level thread safety and ownership is not a thing, pointers are implicit and always-transitively-mutable, but try to do something slightly complex with an associated type, or call a method that throws an exception in a context where this "unlikely" possibility wasn't anticipated well before, and woe betide you!, the compiler will complain. In Objective-C, there's no real type system, but at least you don't run into artificial limitations.
I'd love to do my iOS development in Rust, but knowing Apple's attitude towards supporting any other 3rd-party language, I'm not sure I'd have the courage, the patience, and the intricate knowledge of Xcode's mental health issues to ever try it out.
2 Likes
You can expect Rust to be significantly faster than Swift. Although Swift is natively compiled, it trades off speed for not being annoying about borrow checking, so it will box and refcount left and right. In some cases Swift is as slow as JavaScript. Parallelism in Swift is unsafe, and there's not much beyond GCD queues. So if you have something computation-heavy, Rust is a solid choice.
Rust by itself works fine on iOS, but:
- Access to Cocoa directly from Rust is unergonomic (foreign wrapped objects, bare
msg_send), - Communication between Rust and Swift is tedious, as it requires going through both languages' C FFI.
So for the UI I recommend Swift, just because Cocoa is so closely tied to ObjC/Swift that anything else is painful (even Python with PyObjC was awkward and barely usable).
Swift's FFI is not as nice as Rust's. With unsafe pointers and no borrow checker you get… unsafety. If you want a hybrid Rust+Swift app I recommend keeping the interface between them to minimum.
6 Likes
Hmm. Does iOS support multi processing?
If Rust/Swift doesn't play too nicely together and it is important to minimize communication -- would it make sense to just go one step further, have Rust in one process, Swift in another, and the two to communicate only via json?
In iOS you don't even control your own process 
Rust and Swift don't have an issue running both in the same process. Still, you could make them communicate via serialized messages if you wanted to. Protobuf/Msgpack may be better for this than JSON though (faster, support binary data).
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.