I'm very torn on this issue.
First of all, I don't think that minor differences in style are a bad thing (TM) and especially for very complex codebases, the idea of everyone's code looking the same (down to the choice of using loops vs. map/reduce) seems utopian to me. That said, sometimes I have ended up working with developers that make very poor (as in, probably objectively poor) formatting choices. Sometimes, this is because the developers are still quite junior and haven't yet developed enough aesthetic sensitivity and/or are somewhat overwhelmed having to grapple both learning the language and the style; sometimes, it's because they're technically brilliant but somewhat disorganised minds; etc.
That's why I think that making it easier to integrate some automated style guide check is very useful, especially for somewhat bigger and more diverse teams; otherwise we have to either live with very weird code being checked in or with style arguments in PRs (which I think is the wrong thing to do, in PRs).
Now, there are already tools that help with this, for example SwiftLint (which we already use). But currently, it seems to be somewhat too limited / not comprehensive enough. Also, there's issues with XCode's auto-formatting—one pet peeve of mine is the indentation of
else in multi-line guards (which, in our codebase, are extremely frequent).
I'm not really sure we need a new tool. I'm also not sure we need a one-size-fits-all code style (others have mentioned how complex the Swift language is as opposed to e.g. Go, and I also think that due to the kind of problem domain you're working on you might use certain features more than in most codebases, like multi-line guards). What I do think we'd need is a better way to get started with things like SwiftLint (e.g. integration into XCode), making SwiftLint more powerful (so it can also check some formatting choices and auto-correct them, etc.). It's fine, IMHO, to have some "starter" code style that can get people (especially newbies) started very quickly, but I would also argue that it should be made configurable.