Rust is not antithetical to iteration-based programming, it just makes you write a lot of heavy boilerplate to explicitly support that kind of style. The flip side of that is once the 'iteration'/'prototyping' phase is over, you can actually refactor the prototype into high-quality production code, instead of either throwing it away altogether and rewriting it from scratch (spoiler alert: this doesn't really happen most of the time, because it's viewed as pointless waste) or just putting it in production as-is (which is what people actually do, even though it's obviously a disaster in the longer run).
No, Rust is pretty antithetical to iteration-based programming. The language basically requires you to plan for the ownership model from the beginning, and it can be quite difficult to retrofit a changed ownership model into an existing program.
I've run into this in a side project I'm working on, where my indecision over which ownership models are actually workable in the API to satisfy the needs I have means almost all of the coding is spent just proving I can get an ownership model working over having a skeleton code that can do something. And still, even as lacking as functionality as this codebase is, swapping to a new ownership model takes several minutes of coding. Trying to do this kind of exploration on a codebase that has real functionality would mean spending hours of change just to move some property from here to there.
If you're genuinely unsure about the ownership model (this is pretty rare in practice though) you can just use Rc<>/Arc<> (which allow for shared ownership via refcounting) and be no worse off than if you were coding in Swift.
Surely there's better choices if the primary desire is iteration speed, and a secondary or maybe even tertiary desire is maintainability/refactorability
Rust gets in the way a lot, as it's supposed to for safety. Maybe it'd be a lot faster to iterate on if some AI could auto fix your code to make the compiler happy.