Feel free to critique. Also see: this and this.

Be both brief and clear. Add nouns to contextualize verbs and prepositions. Prefer removeObject(object, atIndex: index) over remove(object, at: index). Clarity should never suffer from an excess of brevity.

Avoid abbreviations. Prefer printError(myError) to printErr(myErr) and setBackgroundImage(myImage) to setBGImage(myImg). Although Apple offers a list of “acceptable” abbreviations, avoid them in Swift outside of gimmes like max and min.

Avoid ambiguity. Consider whether a function or method name has multiple interpretations. For example, in displayName, is the word display a noun or a verb? If it’s unclear, re-work the name to remove that confusion.

Be consistent. Use the same terms throughout your apps and libraries to describe concepts. Avoid using fetchBezierElements() in one method and listPathComponents() in another.

Don’t reference constructs. Avoid struct, enum, class, instance, and object in your names. Prefer buildDeckOfCards() to buildDeckOfCardsStruct().

Use lower-case for method names. Although most developers use lower-case for functions outside a type scope, you can capitalize without committing a moral crime. Uppercase function names immediately differentiate themselves from methods even though they are currently out of fashion. I’ve capitulated for the most part but this may be a battle worth fighting again. This practice was quite common up to and including name-spacing when it suddenly went extinct. It’s like a million capitalized voices cried out and were suddenly silenced

Skip “get”. Functions that retrieve state information should describe the thing they’re returning. Prefer extendedExecutionIsEnabled() or isExtendedExecutionEnabled() to getExtendedExecutionIsEnabled(). Limit get to cases where data is returned through a parameter.

Describe arguments with labels. Encourage reading past the function name to incorporate labels into how the function describes itself. The results create descriptors that incorporate prepositions like with, of, and between. You “construct color with red, green, and blue”, test the “length of string”, or “test equality between x and y”.

A natural fluency relates a function name and its labels to a story about how the function will be used. The result is self-documenting, without relying on memory or look-up to determine which parameters and types are to be provided in each ordered spot. Prefer withTag: to tag:.

Use prepositions, avoid “and”. And is the one word that Apple specifically calls out to avoid. Instead of initializing with view and position, use “view, position” arguments.

If you feel you must use and, reserve it to when there’s a semantic link between a group of arguments, such as constructing colors with “red, green, and blue” floating point values. In such cases, it’s unlikely that future keyword tweaks will interrupt the relationship between these items. Even in such cases, purists will disapprove and treat your use as code smell.

The one case where Apple endorses and use is when a method describes two distinct actions, e.g. openFile(withApplication:, andDeactivate:).

Use the word value after a type-based label. Prefer toIntValue to toInt, or withCGRectValue to withCGRect.

Use American phrases where standard. Prefer initialize to initialise and color to colour as these words are Apple-supplied.

When in doubt, mimic Apple. Search for an Apple API with a similar concept and use that method signature as a guideline. Be prepare to be inspired by Objective-C. As a rule, not all Apple APIs have been reviewed for Swift. Their automatic translation may not offer sufficiently well-considered examples.