What's the best practice for naming Swift files that add extensions to existing objects?

Question

Most examples I have seen mimic the Objective-C approach. The example extension above would be:

String+UTF8Data.swift

The advantages are that the naming convention makes it easy to understand that it is an extension, and which Class is being extended.

The problem with using Extensions.swift or even StringExtensions.swift is that it's not possible to infer the purpose of the file by its name without looking at its contents.

Using xxxable.swift approach as used by Java works okay for protocols or extensions that only define methods. But again, the example above defines an attribute so that UTF8Dataable.swift doesn't make much grammatical sense.

There is no Swift convention. Keep it simple:

StringExtensions.swift

I create one file for each class I'm extending. If you use a single file for all extensions, it will quickly become a jungle.

I prefer having a + to underline the fact it contains extensions :

String+Extensions.swift

And if the file gets too big, you can then split it for each purpose :

String+UTF8Data.swift

String+Encrypt.swift

I prefer StringExtensions.swift until I added too much things to split the file into something like String+utf8Data.swift and String+Encrypt.swift.

One more thing, to combine similar files into one will make your building more faster. Refer to Optimizing-Swift-Build-Times

Rather than adding my comments all over the place, I'm surfacing them all here in one answer.

Personally, I take a hybrid approach that gives both good usability and clarity, while also not cluttering up the API surface area for the object that I'm extending.

For instance, anything that makes sense to be available to any string would go in StringExtensions.swift such as trimRight() and removeBlankLines().

However, if I had an extension function such as formatAsAccountNumber() it would not go in that file because 'Account Number' is not something that would naturally apply to any/all strings and only makes sense in the context of accounts. In that case, I would create a file called Strings+AccountFormatting.swift or maybe even Strings+CustomFormatting.swift with a formatAsAccountNumber() function if there are several types/ways to actually format it.

Actually, in that last example, I actively dissuade my team from using extensions like that in the first place, and would instead encourage something like AccountNumberFormatter.format(String) instead as that doesn't touch the String API surface area at all, as it shouldn't. The exception would be if you defined that extension in the same file where it's used, but then it wouldn't have it's own filename anyway.