I think you're spot on, in that a lot of iOS/macOS is gluing together existing components, very much like a scripted-components/Software-IC[1] pattern. For most of this, a scripting/coordination language would be great.
However, it needs to be interactive, not require the same (if slightly faster) Xcode build cycles. Also, most of those languages interoperate only partially.
My crack at this is Objective-Smalltalk[2]. It can script interactively [3][4] and is a full-fledged programming language.
Swift's type system was designed to make developers happy, Rust's to make the borrow checker happy.
As it turns out, some people think like a borrow checker and don't have any issue with Rust's choice. But most don't and we should not make them miserable.
What do you think is nicer about Rust's type system?
IMO Rust's type system is more principled but does much less for you, and so is more annoying to use. As a simple example, incrementing a reference count in Rust requires a clone() call; in Swift this happens automatically.
Last time I checked out Swift, I ran into some annoying issues with type erasure and generic protocols (similar to the issues Java has, where one class can't be both Iterable<Integer> and Iterable<String>).
I also find Swift's "inout" params deeply confusing (especially when aliasing is involved), and I wish it made dynamic dispatch more explicit (like Rust).
What would e.g. `view.superview` look like in Rust though? That seems to be the main sticking point. In UI programming it is common to walk up, down, and around the view hierarchy.
