I don't actually think the first example was that bad, modulo some context. Sometimes even knowing the type for this kind of thing isn't super important to understand what the code is doing; ala opaque types.
Apple publishes some very good guidelines for Objective-C and Swift, the latter here: https://swift.org/documentation/api-design-guidelines/
Generally, I'd name this method according to the role of the result, and not it's type. While "xxInteger()" isn't good, "numberOfXX()" returning an integer type does improve readability and would still be understandable assigned into an auto.
Remember, you're not writing code for you, you're writing code for future you. Or worse, for the next guy who comes into the codebase. They should be able to derive your intent without having to figure out what each method signature is, and reading all the API docs due to lack of code readability.
The original function name was named poorly however.
I always want my variable names to be as long and descriptive as possible. We're no longer in the teletype era and our monitors are huge. With autocomplete there is no reason to keep variable names short
> RandomizeArrayPositionUsingFisherYatesShuffle
Since the algorithm detail is something I don't want to think about when I use it and something that the implementer should be able to change without changing the contract.