Dynamic linking isn't a problem. Rust's checking is local, and doesn't require checking things in other functions, just their signatures. Swift is the same.
There are some cases were dynamic checks are required (e.g. with reference counting/shared ownership: class in Swift, Rc/Arc in Rust). Swift will automatically insert checks in these cases, whereas they have to be manually written into Rust code (via tools like RefCell). Swift and the APIs inherited from Obj-C use a lot more reference counting that Rust does by default, plus it's more difficult for the programmer to reason about the checks (e.g. to be able to write code that avoids them, to optimise) when they're implicit.
In summary, Rust and Swift have essentially the same rules, but Rust requires manual code to break the default rules, whereas the Swift compiler will implicitly insert those necessary checks (in some cases).
That's the point: with dynamic linking the static signature encodes too much.
In Rust sometimes you need to switch from FnOnce to Fn, or from Rc to Arc. These changes are binary incompatible. You have to recompile every client.
Swift can't tolerate that restriction. UIKit doesn't want to have to pick from among Fn/FnOnce/etc for every function parameter, and commit to it forever.
Swift types and functions need to evolve independently from their clients, so static checks are insufficient. That's why you see more dynamic checks. If Rust had the same dynamic linking aspirations it would insert more dynamic checks as well.
No, Swift needs the static signature of the library for dynamic linking too, by default.
You are correct that Swift wants to be able to change signatures without recompiling clients ("resilience"), but this is very limited, especially for changes that would affect the `inout` checking (e.g. one cannot change an argument to be inout): https://github.com/apple/swift/blob/master/docs/LibraryEvolu... (note the list of non-permitted changes includes changing types).
This doesn't sound like a very good example. Fn inherits FnMut inherits FnOnce, so a library should just ask for the freest one it can support. Usually that just falls out of the meaning of the function. For example, a callback should only be called once, so you ask for an FnOnce, or maybe some function will be called in parallel, so you ask for an Fn. And with Rc, RefCell, Arc, etc. a dynamic approach is also pretty well-supported.
Apple's APIs last for years, in some cases decades. In this world, properties like "this object can only have one reference" and "this function can only be called once" become arbitrary constraints on the future.
Think about instances where you've refactored a RefCell to an Rc or a FnOnce to a FnMut, and consider what it would be like if you were unable to make that change because it would break the interface. It would be profoundly limiting.
Rust does not have a stable ABI at present, so practical use of dynamic linking would require falling back to some baseline ABI/FFI for everything that crosses shared-object boundaries (such as the C FFI), or lead to a requirement that a shared object must be compiled with the same compiler version and compile options as all of its users. This seems like it would be a severe pitfall.
I'm referring only to the thing being discussed in this post. To expand for precision: dynamic linking doesn't force the Swift compiler to insert more dynamic checks for exclusivity enforcement.
There are some cases were dynamic checks are required (e.g. with reference counting/shared ownership: class in Swift, Rc/Arc in Rust). Swift will automatically insert checks in these cases, whereas they have to be manually written into Rust code (via tools like RefCell). Swift and the APIs inherited from Obj-C use a lot more reference counting that Rust does by default, plus it's more difficult for the programmer to reason about the checks (e.g. to be able to write code that avoids them, to optimise) when they're implicit.
In summary, Rust and Swift have essentially the same rules, but Rust requires manual code to break the default rules, whereas the Swift compiler will implicitly insert those necessary checks (in some cases).