Airbnb Swift Style Guide

Avoid using try! in tests, as it will crash the entire test suite. Instead, mark your test methods as throws and use try to allow the testing framework to handle errors gracefully.

import Testing

struct SomeTests {
  // WRONG
  @Test
  func something() {
    try! Something().doSomething()
  }

  // RIGHT
  @Test
  func something() throws {
    try Something().doSomething()
  }
}

Avoid unowned captures because they cause crashes if the referenced object is deallocated. Instead, use weak captures (and handle the nil case) or capture the specific variables needed directly.

// RIGHT: Use weak self and handle nil
spaceship.travel(to: planet, onArrival: { [weak self] in
  guard let self else { return }
  planet.colonize()
})

// RIGHT: Capture the variable directly to avoid self
spaceship.travel(to: planet, onArrival: { [planet] in
  planet.colonize()
})

When using the #expect macro in Swift Testing, avoid providing a message string that simply restates the condition. The macro automatically generates detailed failure messages. If you need to add context, use a more descriptive string or a code comment.

// RIGHT: Omits the message string, or adds valuable context
@Test
func `engage warp drive`() {
  spaceship.engageWarpDrive()
  #expect(spaceship.isWarpDriveActive)
  #expect(spaceship.speed > lightSpeed, "Spaceship must reach light speed before the warp bubble can form")
}

To use the Airbnb Swift Style Guide's automated formatting and linting, add this repository as a dependency in your Package.swift file.

dependencies: [
  .package(url: "https://github.com/airbnb/swift", from: "1.0.0"),
]

Follow these spacing and syntax rules:

• Return Arrows: Place a space on both sides of a return arrow (->) for readability.
• Unnecessary Parentheses: Omit parentheses in if and switch statements, and in closure parameter lists where they aren't required.

// RIGHT: Spacing around return arrows
func doSomething() -> String { ... }
func doSomething(completion: () -> Void) { ... }

// RIGHT: Omitting unnecessary parentheses
if userCount > 0 { ... }
switch someValue { ... }
let evens = userCounts.filter { number in number.isMultiple(of: 2) }
let squares = userCounts.map { $0 * $0 }

For long function declarations, use line breaks before each argument label and before the closing parenthesis ). This prevents visual blending with the function body and ensures compatibility with Xcode's indentation.

// RIGHT
func generateStars(
  at location: Point,
  count: Int,
  color: StarColor,
  withAverageDistance averageDistance: Float
) -> String {
  populateUniverse()
}

// ALSO RIGHT (with async/throws)
func generateStars(
  at location: Point,
  count: Int,
  color: StarColor,
  withAverageDistance averageDistance: Float
) async throws -> String {
  populateUniverse()
}

When working with Swift 6.0+, prefer using the count(where:) method instead of filtering a collection and then calling .count. This is more direct and efficient.

// WRONG
let planetsWithMoons = planets.filter { !$0.moons.isEmpty }.count

// RIGHT
let planetsWithMoons = planets.count(where: { !$0.moons.isEmpty })

Do not explicitly use @ViewBuilder when it is not required. It is implicitly applied to View.body properties and ViewModifier.body(content:) functions. It is also unnecessary for single-expression properties or functions. Use @ViewBuilder only when necessary, such as for properties containing conditional logic (e.g., if statements).

// RIGHT: @ViewBuilder is implicit on body
struct PlanetView: View {
  var body: some View {
    Text("Hello, World!")
  }

  // ALSO RIGHT: @ViewBuilder is necessary for conditionals
  @ViewBuilder
  var title: some View {
    if showDetails {
      Text("Details")
    } else {
      Text("Summary")
    }
  }
}

Do not use redundant typed throws annotations. throws(Never) is equivalent to a non-throwing function, and throws(Error) is equivalent to a standard non-typed throws.

// RIGHT
func doSomething() -> Int {
  return 0
}

func doSomethingElse() throws -> Int {
  throw MyError.failed
}

Wrap function and property bodies onto multiple lines rather than using single-line declarations. Note that this rule does not apply to protocol definitions.

// RIGHT
var galaxy: String {
  "Milky Way"
}

func launchRocket() {
    print("Launching")
}

init() {
    self.value = 0
}

subscript(index: Int) -> Int {
    array[index]
}

// Protocol definitions remain single-line
protocol SpaceshipEngine {
  func engage() -> Bool
  var fuelLevel: Double { get }
}

Avoid using Group wrappers that wrap the entire content of a @ViewBuilder context (like View.body) without applying any modifiers. Inside a @ViewBuilder property, using @ViewBuilder is more idiomatic and reduces nesting compared to Group.

Note: Group is still useful when you need to apply a modifier to a collection of views at once.

// RIGHT: Using @ViewBuilder instead of Group to reduce nesting
struct SpacecraftView: View {
  var body: some View {
    Text("Voyager")
    instruments
  }

  @ViewBuilder
  var instruments: some View {
    Text("Altimeter")
    Text("Gyroscope")
  }
}

// ALSO RIGHT: Group is not redundant when a modifier is applied to it
struct SpacecraftView: View {
  var body: some View {
    Group {
      Text("Voyager")
      instruments
    }
    .padding()
  }
}