It is the other way around. Using Rust on iOS is pain. Using Swift is not pain because it is supported by Apple. So it is easier to bring my Swift code and knowledge that I use on iOS to other platforms because other platforms (Linux) don't require sophisticated tooling and support. So I can create apps in Swift for iOS but also backend in Swift for Linux and it is the major benefit.
So... what you say is practical, but it creeps me out. This is the same logic behind "just code for windows because that's what everyone runs and treat everything else as a port". We suffered through that for a decade already, let's not repeat the mistake.
Don't tie your ecosystem to a proprietary (yes, Swift is still a 100% proprietary environment!) toolchain. We've done that several times already in this industry and the results have never been good.
Yeah, it bridges to C so you need to build another bridge to have nice Objective-C API. Not mentioning, you will have hard times calling Objective-C API from Rust.
I know that but if I decide to use Rust instead of Swift, why would I be wrapping Rust in Swift through C? And still it doesn't solve a problem how Rust can call anything from Cocoa or my existing code.
Rust can call anything that exposes a C-compatible ABI, and Rust code can expose a C-compatible ABI so any language that can call into C (i.e. all languages) can call into Rust.