Swift Code Review: 7 Mistakes That Annoy Senior Developers

Swift Code Review: How to Stop Annoying Colleagues and Write Senior-Level Code

Have you ever submitted a Pull Request, only to receive 15 comments from your team lead an hour later? "Force unwrap? Seriously?", "Where's the error handling?", "This flow controller has been hanging in memory for three days." Sound familiar? Welcome to the world of Swift code review — a place where even experienced developers sometimes feel like interns.

In this article, I've gathered the most common comments that seniors leave on code reviews. We'll analyze real code examples, anti-patterns, and how to fix them. This isn't boring theory — it's the battle-tested experience from hundreds of reviews that will help you write code that doesn't make people want to rewrite everything from scratch. Let's go!

1. Force Unwrap — First Love and Biggest Pain

Let's start with the most basic but eternal issue. Force unwrap (!) is like driving without a seatbelt. It seems convenient, but one sudden stop and you're in the emergency room.

Bad code (typical junior):

func getUserName() -> String {    let name: String? = UserDefaults.standard.string(forKey: "user_name")    return name!}

What a senior will say: "What if there's nothing in UserDefaults? Crash. Always. Add guard let or a defaultValue."

Good code:

func getUserName() -> String {    guard let name = UserDefaults.standard.string(forKey: "user_name") else {        return "Guest"    }    return name}

Exception: Force unwrap is only acceptable in one case — when you are 146% sure the value exists. For example, when working with IBOutlets that are guaranteed to be initialized. But even here, a senior will advise using private var label: UILabel! — this is a convention, not a crutch.

2. Magic Numbers and Strings: Code Shouldn't Be a Puzzle

The second thing that stands out in Swift code reviews is magic constants. "Why exactly 0.75? Oh, it's an animation coefficient... Which one exactly?" If you write numbers and strings directly in the code, you're making your colleagues play detective.

Bad code:

if user.age > 18 {    showAdultContent()}button.layer.cornerRadius = 12let url = "https://api.example.com/v1/users"

What a senior will say: "18 is a magic number. Extract it into a constant. The URL — into an enum. cornerRadius — into a styling constant. Code should read like a book, not like a cipher."

Good code:

private enum Constants {    static let adultAgeLimit = 18    static let defaultCornerRadius: CGFloat = 12    static let baseURL = "https://api.example.com/v1"}

enum APIEndpoint {    case users    var url: String {        switch self {        case .users: return Constants.baseURL + "/users"        }    }}

if user.age > Constants.adultAgeLimit {    showAdultContent()}

3. Memory Leaks: How to Accidentally Hang Your App

Swift code review rarely goes without discussing retain cycles. Seniors love this topic because it shows whether you understand how ARC works. The most popular anti-pattern is capturing self in a closure without a weak reference.

Bad code:

class NetworkManager {    func fetchData(completion: @escaping (Data) -> Void) {        URLSession.shared.dataTask(with: url) { data, _, _ in            self.process(data) // self is captured strongly            completion(data)        }    }}

What a senior will say: "You're holding a strong reference to self inside the closure. As long as the closure is alive, the object won't be deallocated. Add [weak self] and check for nil. Or use [unowned self] if you know for sure that self will outlive the closure."

Good code:

func fetchDa