Introduction

Sorting an array of custom objects alphabetically in Swift usually means comparing one string property, such as name or title. The mechanics are simple, but the details matter: you need to decide whether to mutate the original array, whether the comparison should be case-sensitive, and how to handle optional or localized text. Good sorting code is less about clever syntax and more about making those rules explicit.

Choose Between sorted() and sort()

Swift gives you two closely related APIs. sorted() returns a new array and leaves the original unchanged. sort() mutates the existing array in place.

1struct Person {
2    let name: String
3}
4
5let people = [
6    Person(name: "Charlie"),
7    Person(name: "Alice"),
8    Person(name: "Bob")
9]
10
11let sortedPeople = people.sorted { $0.name < $1.name }
12print(sortedPeople.map(\.name))
13print(people.map(\.name))

If you no longer need the original order, mutating in place is often cleaner.

var mutablePeople = people
mutablePeople.sort { $0.name < $1.name }
print(mutablePeople.map(\.name))

The rule is simple: use sorted() when you want a new value, and sort() when you want to update the existing array.

Compare the Right Property

Custom objects are not “special” to the sort algorithm. Swift just needs a closure that says which element should come first. For alphabetical sorting, that closure usually compares a string property directly.

1final class Product {
2    let title: String
3
4    init(title: String) {
5        self.title = title
6    }
7}
8
9let products = [
10    Product(title: "Keyboard"),
11    Product(title: "Adapter"),
12    Product(title: "Mouse")
13]
14
15let sortedProducts = products.sorted { $0.title < $1.title }
16print(sortedProducts.map(\.title))

This works for structs and classes alike because the comparison is based on the property value, not on the object type itself.

Use Localized Comparisons for User-Facing Lists

Raw string comparison with < is fine for internal data, but it is not always the best match for what users expect in a visible list. User-facing alphabetical order usually benefits from localized and case-insensitive comparison.

1struct Contact {
2    let displayName: String
3}
4
5let contacts = [
6    Contact(displayName: "zoe"),
7    Contact(displayName: "Alice"),
8    Contact(displayName: "bob")
9]
10
11let sortedContacts = contacts.sorted {
12    $0.displayName.localizedCaseInsensitiveCompare($1.displayName) == .orderedAscending
13}
14
15print(sortedContacts.map(\.displayName))

This produces a more natural order for UI lists because it does not treat uppercase and lowercase as separate alphabets.

If the app is multilingual, localized comparison is usually the better default than a strict binary comparison.

Handle Optional Strings Deliberately

If the property you want to sort by is optional, decide what nil means before you write the comparator. Treating nil as an empty string is common, but it is only correct if missing text should appear first.

1struct User {
2    let displayName: String?
3}
4
5let users = [
6    User(displayName: "Charlie"),
7    User(displayName: nil),
8    User(displayName: "Alice")
9]
10
11let sortedUsers = users.sorted {
12    let left = $0.displayName ?? ""
13    let right = $1.displayName ?? ""
14    return left.localizedCaseInsensitiveCompare(right) == .orderedAscending
15}
16
17print(sortedUsers.map { $0.displayName ?? "(missing)" })

Another reasonable rule is to put nil values last. The important part is to encode the rule directly instead of letting optional handling become an afterthought.

Add Tie-Breakers When Names Are Not Unique

Alphabetical sorting often becomes ambiguous when two objects share the same primary string field. A secondary comparison keeps the result deterministic.

1struct Employee {
2    let firstName: String
3    let lastName: String
4}
5
6let employees = [
7    Employee(firstName: "Jane", lastName: "Adams"),
8    Employee(firstName: "Alex", lastName: "Brown"),
9    Employee(firstName: "Chris", lastName: "Brown")
10]
11
12let sortedEmployees = employees.sorted {
13    if $0.lastName.caseInsensitiveCompare($1.lastName) == .orderedSame {
14        return $0.firstName.localizedCaseInsensitiveCompare($1.firstName) == .orderedAscending
15    }
16    return $0.lastName.localizedCaseInsensitiveCompare($1.lastName) == .orderedAscending
17}
18
19print(sortedEmployees.map { "\($0.lastName), \($0.firstName)" })

That extra rule matters in tests, exported files, and UI lists where unstable ordering creates unnecessary noise.

When Comparable Is Worth It

If the same object type is sorted the same way throughout the app, implementing Comparable can make the call sites cleaner.

1struct City: Comparable {
2    let name: String
3
4    static func < (lhs: City, rhs: City) -> Bool {
5        lhs.name.localizedCaseInsensitiveCompare(rhs.name) == .orderedAscending
6    }
7}
8
9let cities = [City(name: "Tokyo"), City(name: "amsterdam"), City(name: "Berlin")]
10print(cities.sorted().map(\.name))

For a one-off sort, a closure is enough. For a repeated domain rule, Comparable can be a worthwhile improvement.

Common Pitfalls

• Using sort() when you meant to preserve the original array order.
• Comparing raw strings with < for UI data that should use localized or case-insensitive ordering.
• Ignoring nil handling when the sort key is optional.
• Forgetting secondary sort rules when duplicate names are common.
• Creating temporary display strings for sorting when the real model property should be compared directly.

Summary

• 'sorted() returns a new alphabetically ordered array, while sort() mutates in place.'
• Sorting custom objects is just a matter of comparing the correct string property.
• User-facing lists usually benefit from localized, case-insensitive comparison.
• Optional sort keys need an explicit rule for how missing values should be placed.
• Add tie-breakers or Comparable when the sort order is part of the domain model.