Style Guide: Swift Naming Conventions


Descriptive and consistent naming makes software easier to read and understand. We use the Swift naming conventions described in the API Design Guidelines. We find Ray Wenderlich swift style guidelines valuable, below are some of his main takeaways that we incorporate into our work.

  • Striving for clarity at the call site
  • Prioritizing clarity over brevity
  • Using camel case (not snake case)
  • Using uppercase for types (and protocols), lowercase for everything else
  • Including all needed words while omitting needless words
  • Using names based on roles, not types
  • Sometimes compensating for weak type information
  • Striving for fluent usage
  • Beginning factory methods with make
  • Naming methods for their side effects
    • Verb methods follow the -ed, -ing rule for the non-mutating version
    • Noun methods follow the formX rule for the non-mutating version
    • Boolean types should read like assertions
    • Protocols that describe what something is should read as nouns
    • Protocols that describe a capability should end in -able or -ible
  • Using terms that don’t surprise experts or confuse beginners
  • Generally avoiding abbreviations
  • Using precedent for names
  • Preferring methods and properties to free functions
  • Casing acronyms and initialisms uniformly up or down
  • Giving the same base name to methods that share the same meaning
  • Avoiding overloads on return type
  • Choosing good parameter names that serve as documentation
  • Labeling closure and tuple parameters
  • Taking advantage of default parameters


When referring to methods in prose, being unambiguous is critical. To refer to a method name, use the simplest form possible.

  1. Write the method name with no parameters. Example: Next, you need to call the method addTarget.
  2. Write the method name with argument labels. Example: Next, you need to call the method addTarget(_:action:).
  3. Write the full method name with argument labels and types. Example: Next, you need to call the method addTarget(_: Any?, action: Selector?).

For the above example using UIGestureRecognizer, 1 is unambiguous and preferred.

Pro Tip: You can use Xcode’s jump bar to lookup methods with argument labels.


Class Prefixes

Swift types are automatically name spaced by the module that contains them and you should not add a class prefix such as RW. If two names from different modules collide you can disambiguate by prefixing the type name with the module name. However, only specify the module name when there is possibility for confusion which should be rare.

import SomeModule

let myClass = MyModule.UsefulClass()


When creating custom delegate methods, an unnamed first parameter should be the delegate source. (UIKit contains numerous examples of this.)


func namePickerView(_ namePickerView: NamePickerView, didSelectName name: String)
func namePickerViewShouldReload(_ namePickerView: NamePickerView) -> Bool

Not Preferred:

func didSelectName(namePicker: NamePickerViewController, name: String)
func namePickerShouldReload() -> Bool

Use Type Inferred Context

Use compiler inferred context to write shorter, clear code. (Also see Type Inference.)


let selector = #selector(viewDidLoad)
view.backgroundColor = .red
let toView = context.view(forKey: .to)
let view = UIView(frame: .zero)

Not Preferred:

let selector = #selector(ViewController.viewDidLoad)
view.backgroundColor =
let toView = context.view(forKey:
let view = UIView(frame:


Generic type parameters should be descriptive, upper camel case names. When a type name doesn’t have a meaningful relationship or role, use a traditional single uppercase letter such as T, U, or V.


struct Stack<Element> { }
func write<Target: OutputStream>(to target: inout Target)
func swap<T>(_ a: inout T, _ b: inout T)

Not Preferred:

struct Stack<T> { }
func write<target: OutputStream>(to target: inout target)
func swap<Thing>(_ a: inout Thing, _ b: inout Thing)


Use US English spelling to match Apple’s API.


let color = “red”

Not Preferred:

let colour = “red”