Scott Berrevoets - blog

Review your own AI-generated code

2026-03-20T00:00:00-07:00

Years ago, when we started to have 5+ contributors to our codebase at Lyft, we had to establish a code review process with high enough value to justify the friction it caused. However, "value" is very subjective, as not everyone cares about the same qualities of a pull request:

Catching runtime problems like bugs, security vulnerabilities, or performance issues
Knowledge and context sharing, mentoring, or general collaboration
Code quality and maintainability
Upholding code consistency, conventions, style, naming, grammar, etc.

Over the last 10-15 years, the industry has seen its engineering foundations greatly improved: programming languages, CI systems, build tools, internal architectures and processes, and engineering principles have improved so much that human review of many of these potential issues has lost a lot of their value. Linters keep code consistent as much as possible, standardized architectures should enable reliability and testability, modern programming languages and paradigms enable low code complexity, and CI validates all these conditions before deploying.

With these advancements over the years, I find myself leaving significantly fewer comments on PRs than before. Any comments I do leave are usually about local, low-severity code quality improvements, avoiding suppressing linter violations, asking for specs/context, double-checking intention, etc. Whenever possible, I try to instead invest in some of these foundations: an additional linter rule, updating CI, providing better architectural patterns. That time investment scales much better than me leaving comments on individual PRs.

And that brings us to 2026, where we get to re-evaluate the "value" of code review because of AI agents. The impact of AI on code review is threefold:

Output quality: a year ago we called it vibe-coding, today it's much more difficult to tell apart agent code from human code if the human(s) behind the agent code put real effort into getting high-quality output from the agent
Agentic review: many teams have agents review other agents' code. Codex has /review, Claude Code has Code Review, and Cursor, Copilot, and various observability and SRE tools all have code review agents as well.

I've made code review part of my own workflow as well: write a plan, have an agent refactor a bunch of code, and have other agents review it for issues. OpenAI is, unsurprisingly, pushing the boundaries with an internal project where all code is reviewed by agents and mostly not by humans at all.
Code volume: engineers are "writing" a lot more code than before and, if we stick to our old practices, the burden of code review increases more too

We have gotten faster at producing high-quality code, but if it can't be reviewed at higher speed as well, we've just found ourselves a new bottleneck.

The status quo is that engineers review each other's code to avoid author bias, which could lead to overestimating the quality, performance, and clarity of the code written by the author. But in a world where the entire development workflow is changing and code is increasingly written by agents, we're no longer actually reviewing each other's code, we're reviewing agents' code. The bias no longer exists at the code level; it moves to the plan level.

Human accountability and oversight are still important, but the primary responsibility of code review can shift to the engineer that drove the agent in the first place. That engineer is coming in with all the context and can review the code much faster than other engineers. For bigger changes, their author bias could still apply to the plan, so it's good to have other engineers review that, but the code itself is just execution.

With the right plan and LLM guidance in place, agents have gotten excellent at implementing exactly according to spec. When an agent introduces a bug, it's less likely to be an implementation issue and more likely an underspecification of the plan, guidance, or documentation. The correctness of these documents is still a shared team responsibility.

The outcome is more than just removing the new bottleneck in writing code. Engineers are more autonomous in shipping because they don't have to wait for others, possibly in different time zones, and can fully unblock themselves in all the work they are doing. With strong PR checks, such as linters and code quality gates, in place to prevent old-fashioned vibe-coding, the bar remains high while increasing velocity.

There is one notable downside to this approach: the reduced context sharing and mentoring. It's a real benefit of "traditional" code review, but not the most effective time to break knowledge silos. As I mentioned earlier, plans still warrant review by others, and plans are usually derivatives of tech specs or PRDs. A well-written document provides the necessary context, the whys, the thought process, and the alternatives considered. It's also easier to ask questions and act on feedback in this stage because it's much earlier in the development lifecycle.

In a world where agentic engineering is the norm, teams review plans, specs, and agent guidance together so they capture the intended design and behavior; the code becomes an implementation detail of the plan that can be self-reviewed by the driver of the agent.

All in on Interface Builder: 10 years later

2026-03-02T00:00:00-08:00

Back in 2017, I wrote about how we used Interface Builder as our primary way of building UI at Lyft. Interestingly, Speak chose to use Interface Builder to build UI too before SwiftUI came along, though without the same tooling we had at Lyft. With Interface Builder mostly forgotten, including by Apple itself, I think it's worth sharing some lessons learned after all this time.

I didn't explicitly share this in the original post, but we didn't take the decision to use Interface Builder lightly. The main benefits we saw:

The Swift toolchain was very young and not fully developed yet. The compiler was slow and autocomplete was much less advanced, so the more code we could shove in Interface Builder the less code that had to be compiled. This had a significant impact on build times and build failures for us.
We were hoping for what Swift Previews eventually got much closer to: a quick way to understand what a view looks like at runtime without spinning up a simulator
It saved developers a lot of typing manual, tedious Auto Layout code. Interface Builder provide immediate feedback about whether your constraints resolved cleanly

We were also aware of the pain points of Interface Builder and built good tooling around managing those. We got to meet with Apple engineers to voice IB's weaknesses that we couldn't tool our way out of, and were generally happy to not be writing super verbose Auto Layout code. Merge conflicts still never were a problem because we distributed the UI over many individual storyboards and xibs.

We felt we'd found a way to make Interface Builder scale pretty well, and it did for a long time. But cracks started to form in the strategy:

We had primarily invested in storyboards, but a stronger focus on code testability was directly in conflict with that investment
New team members never fully got the hang of some of these more nuanced and advanced ways of using Interface Builder
@IBDesignable never really lived up to its expectations, being buggy, slow, and unreliable
Routing complexity changed our strategy over time to not use segues anymore, losing some of the benefits of using IB
UIs became a lot more complicated and constraint management became difficult in Interface Builder (this likely would've also been hard in programmatic UI)
Building Lyft's internal design system was more difficult while supporting Interface Builder

All these problems came with scale none of us had really seen before. At the same time, the original problem of writing programmatic Auto Layout also still was a concern, so a potential migration was costly with unclear benefits.

Until SwiftUI came along. With SwiftUI, we finally felt like the cons started to outweigh the pros. We embarked on what ended up being a five year migration journey away from Interface Builder, finally completing the effort mid-2024. This multi-step migration was the largest we had undertaken on iOS (on Android the Dagger 1 to Dagger 2 migration was of similar scale), and immediately justified the investment into DeclarativeUI as a prelude to SwiftUI adoption.

Joining Speak also exposed me to the newcomer perspective of having so much UI defined in Interface Builder. It's hard to understand the scope, complexity, and context of a screen when all its configuration is tucked away in the right sidebar, with many implicit behaviors from checkboxes, dropdowns, and long lists of constraints and their properties.

We're also dealing with the same testability problem (even though dependency injection with storyboards is a little easier nowadays), and the storyboards in the Speak codebase are more like wireframes than actual designs, so navigating them isn't any easier than code. Refactoring is harder because the UI definition is split into two (some in code, some in Interface Builder), and the weakly typed IB/code connections between @IBOutlets and @IBActions make it hard and risky to understand which code is still used and which isn't.

A more modern problem is that because Interface Builder was not the popular choice in an ecosystem where open source was already much less valued than in other development domains, there is very little Interface Builder XML that AI agents are trained on. This means their effectiveness is also much less compared to plain Swift, which is doubly annoying when AI agents would otherwise reduce the migration cost tremendously.

Let it be clear that I wouldn't recommend Interface Builder as a tool for building UI anymore, but despite my change of heart, I can't say I regret the choice of introducing it at the time we did. There were no signs a replacement UI framework would come along, teams were reasonably productive with it, and we benefited from its use for a good 4-5 years. Some of the tools and implementations were arguably too clever for their own good, and that's a valuable lesson learned.

But I think the bigger lesson is that there's a cost to architectural decisions like these, and in an industry that's always changing, the pros and cons need constant weighing. It's easy to adopt a sunk cost mentality and keep investing more time and resources because the migration cost is high, but like other tech debt it just increases the cost of migration at a later stage.

Relating this to my own post about human factors in choosing technologies, the adoption, ramp-up, and support factors were all pretty favorable. However, in retrospect, IB scored low on the ability to undo (as many architectures would), and after declarative UIs came along there was a downward trend in whether engineers liked using IB. Once that trend started, Interface Builder's days were numbered, even if the path to obsolescence was long and painful.

Scaling my git/tmux workflows for AI agents

2026-02-17T00:00:00-08:00

After I started to ramp up on agentic coding, I found my workflow lagging behind how I ended up working. Previously I would clone my project's repo twice and switch back and forth between the clones. I used stack-based git workflow git-pile, which eliminated the overhead of switching branches and stashing changes.

When I was occasionally in the middle of something and needed to context switch and have a clean repo, I would have the other clone and that was about as much as I could handle at a time. I knew of git worktrees but never needed it so didn't bother upgrading my workflow.

In the age of AI I found myself needing a lot more. Understanding various parts of the codebase is one prompt away and making changes requires a much smaller context switch than before so I do it much more frequently. However, the two clones weren't really sufficient for this anymore, as it became more painful to sync changes back and forth before they landed on main.

So I had Claude design me a new workflow that scaled better and allowed more parallelization. I wanted:

one repo with n worktrees with no prior set up required
tmux integration so each worktree gets its own tmux window
no dangling worktrees and branches if I abandon work
compatibility with git-pile, but no direct integration
packaged in an easy to use CLI with powerful commands that capture a lot of complexity

I wanted to use worktrees under the hood, but also have that be an implementation detail as I'd prefer to not deal with them directly.

The end result is a Python script I called agents that has 6 commands:

new [name] - create a new worktree
list - lists all existing tasks/worktrees
merge - merge the current changes into the parent repo on main
rm - delete this worktree and close its tmux window
open - create a tmux window with the specified worktree (in case it was closed)
clean - delete all stale worktrees and branches, and closes their tmux windows

This provides a very simple workflow:

# Initialize worktree
# No subcommand is shorthand for `new`
agents find-bug

# Run some agents
codex exec "fix the race condition in DataManager"

# ...
# switch to another agent/tmux window, do some work there, then return
# ...

# Codex output looks good - let's upstream (or have the agent do it)
git add . && git commit -m "Fix race condition"

# Merge commit back to main repo
agents merge

# Delete worktree and close tmux window
agents rm

The main branch on my repo clone now has this commit, and I can use git-pile to submit a pull request with this change. This workflow works in any git repo out of the box, no special setup required.

While Codex is running, I can switch back to the previous tmux window and start another agent, or I can even branch off that particular worktree into a new one. I'm not sure I want that from the workflow since I prefer working on the repo's main branch in the first place, so time will tell if I end up using that branching behavior.

Ideally these worktrees are shortlived and will just get their work merged in. However, there are situations where there's longer running work or work I end up not moving forward with, and for that I had Claude implement an agents clean command. It deletes all stale worktrees, with some protections for unmerged work to avoid losing uncommitted changes.

To understand what work is in progress, agents list gives a nicely-formatted output that's piped to fzf for easy selection:

The arrows indicate commit status, which is helpful to understand if any worktrees may need rebasing.

After building and working this tool a bit I realized the workflow works even when not using an agentic programming workflow, so agents is probably not the best name, but since I developed it with that use case in mind I'll probably continue to use that for now.

The full script is in my dotfiles' ./bin folder, which is automatically accessible anywhere from my Terminal. I've also written a Claude/Codex skill to run this automatically for me in case I forget to do so myself, and I'll probably keep tweaking the workflow to my liking as I work with it more.

Localization troubles with Swift PM

2025-09-19T00:00:00-07:00

A few weeks ago we got bit by a piece of Apple magic in its localization workflow when combined with Swift PM. The problem we ran into was that as soon as we moved all our Localizable.strings files to an SPM package, none of the localizations would be picked up anymore and the app would display in English—but only for first-time installations. We followed the documentation guidelines for how to localize an app in an Swift PM environment and have no custom tooling in place, so it was a bit of a headscratcher.

The modern way of adding support for another language/region in Xcode is through the project's Info tab. Simply click the + and add a language and the app now supports localizing in that language.

Adding localizations for any resource is done by clicking the Localize... button in the Attributes inspector. After confirming the language, Xcode creates a new .lproj folder for the selected language and moves the resource into that folder. The end result is the project will have a .lproj folder for each localization as well as the Base.lproj.

This just works. The .lproj folders get copied over to the .app and at runtime the SDK knows how to read and use these folders. Xcode also gives visual confirmation in the Info tab by indicating for how many files it has picked up a localized version per language/region.

Getting started with adding some SPM packages in our app, we moved the .lproj folders into our Localization package at Localization/Sources/Localization/Resources/, which follows the process outlined in the documentation. Locally this seemed to work and we shipped the change, only for QA to report localizations were broken throughout the app.

As it turns out, any .lproj folders in SPM packages aren't considered when determining what localizations are available. At first this was a bit confusing, but it makes sense for two reasons:

Through various layers of abstraction, the system looks up the available localizations using methods on Bundle. Bundle.localizations simply finds all .lproj folders in that bundle. SPM package bundles aren't included in Bundle.main, which is the bundle that's used to determine app-wide localizations.
An SPM package can be localized in different languages than the app that integrates the package, especially if the package is from an external vendor. It could be weird behavior to have the app's selected localization be determined by some SPM package.

Note

There is an Info.plist key that would allow SPM packages to use a different localization than the main app: CFBundleAllowMixedLocalizations. I haven't tried for myself, but setting this to YES allows different localizations for the app and for every package.

When moving all .lproj folders into the SPM package, the app didn't have any localized files left and Xcode indicated as much.

As a result, the app would always default to English. This explained why things were broken but there were still a few questions left.

How come the correct localization was used for returning users?

This issue only happened to users that freshly installed the app. Upon first launch, we store the user's locale in UserDefaults (later giving users the ability to override this manually). Instead of reading strings from Bundle.main we read them from a new Bundle instance specifically scoped to that locale:

let defaultLocale = Bundle.main.preferredLocalizations[0]
let userLanguage = UserDefaults.shared.language // e.g. "nl" for Dutch
let path = Bundle.main.pathForResource(language ?? defaultLocale , ofType: "lproj")
let customBundle = Bundle(path: path)

let localized = customBundle.localizedString(forKey: key, value: nil, table: nil)

This setup has some interesting results:

❌ Bundle.main.preferredLocalizations only contains the development default locale en as the main bundle doesn't have any localizations
❌ customBundle.preferredLocalizations only contains the localization it was scoped to
✅ customBundle.localizedString(forKey:value:table:) works as the SPM package's resources still get copied into the main app as a separate bundle
✅ Bundle.module.preferredLocalizations correctly returns all the supported localizations since they're defined in the SPM package
✅ Bundle.module.localizedString(forKey:value:table:) works for the same reason
❌ Bundle.main.localizedString(forKey:value:table:) does not work as the main bundle doesn't have any localizations

For first-time users we would read en as their preferred language through Bundle.main.preferredLocalizations, but for returning users we'd read what language they were using before from UserDefaults.

Conclusion: we should be using Bundle.module.preferredLocalizations instead.

Why was it so difficult to figure this out?

The build cache in Xcode messed with our ability to reproduce the issue. In understanding what commit introduced the problem, we would often switch branches but that didn't invalidate the build cache.

So building any commit before the offending change would copy the .lproj folders into the main app's build cache, and those folders would stay there after checking out and building the offending commit.

At first we thought the issue was only intermittently reproducible, but once we realized the build cache was "polluted" we started to clean it every time. This made it much easier to reproduce but much slower to test due to constantly doing full builds.

What am I supposed to do in a fully modularized app where there are no files to localize in the main app?

In theory, using Bundle.module everywhere would work as highlighted above. However, that's pretty cumbersome and there's a nicer way: CFBundleLocalizations. This is another Info.plist key that lets you explicitly define what localizations the app handles, instead of looking for .lproj folders and implicitly supporting the localizations for the folders Xcode finds. With that key set, Xcode still does look for these folders but now it also considers SPM bundles, fixing the issue.

Finally, there's another way to be explicit about the localizations a project supports: by adding a localization through Xcode's Info tab. This sets the knownRegions value in the Xcode project file, which is not only considered for determining what localizations to consider at build time, but is also used to export and import xliff files.

That would have fixed our issue as well, but I personally prefer to not touch the project file as much as possible and be explicit about what localizations are supported through CFBundleLocalizations.

Managing code deprecations on iOS

2025-08-20T00:00:00-07:00

A great manager I once worked with had been at Google for a while and poked fun at an aspect of its engineering culture: any given service was either deprecated or not yet ready for adoption. I spend a lot of my time working on mobile platform development and over the years have been exposed to both sides of this: needing to get rid of code that's deprecated in new OS versions, and deprecating technologies many internal teams depend on.

Vendor deprecations usually involve the platform vendor releasing new APIs or technologies that replace older ones and they want their developer base to put in the work to use this new tech
Internal deprecations come with a lot of non-technical work and a long migration path, often in the order of quarters or years, on top of the technical challenge and often ugly tradeoffs in making the old and systems compatible during the transition period

Both types of deprecations are a way of life for platform engineering, and yet on Apple platforms we have very little tooling available to make these easier. In fact, the only real tool we have is @available() to mark a type as having been deprecated:

@available(*, deprecated, renamed: "myNewFunction()")
func myFunction() {} // deprecated and renamed to myNewFunction

@available(iOS, deprecated: 26.0)
func myFunction() {} // deprecated starting in iOS 26

@available(*, deprecated, message: "Please use myOtherNewFunction instead")
func myOtherFunction() {} // deprecated with a custom warning message

Apple uses this pattern extensively throughout their frameworks and every new OS version introduces more deprecation annotations exactly like the examples above. This makes raising the deployment target in a sufficiently large project a much bigger initiative than it might seem at first, because suddenly you're facing a large number of deprecation warnings.

Handling the deprecation of a single class can in extreme cases be a project on its own. If you're looking to raise the deployment target to use the latest SwiftUI APIs, it can be a bummer to first have to spend a bunch of time resolving deprecation warnings, especially when warnings-as-errors is on and the app doesn't even build.

Since @available's only real logic is gating on OS and Swift versions, it isn't helpful for internal deprecations. If I write a new database class that replaces an old one that's used in 50+ places, I don't know what OS version to specify because it's not related to OS-specific system APIs. It's more important to think about how to manage the existing call sites, which in most cases means accepting the 50+ instances, ensuring it doesn't grow any further, and working with the team to migrate them over time.

Annotating the old class with @available(*, deprecated) would immediately cause build errors, so that's not an option. At Lyft we often resorted to the ugly workaround of renaming the old class to DeprecatedDatabase or even DEPRECATEDDatabase. This worked surprisingly well, but it also very clearly highlights a gap in tooling.

SE-0443: Precise Control Flags over Compiler Warnings gives developers more granular control over compiler warnings, even mentioning the deprecation use case specifically. In short, there are now build settings that enable upgrading and downgrading warnings of a specific type to and from errors. The proposal gives this example to turn warnings-as-errors on except for deprecations: -warnings-as-errors -Wwarning Deprecated. This leaves warnings-as-errors on for everything except deprecations.

It's an OK first step, but not really sufficient:

There might be multiple deprecations happening at once, but you can only specify whether to enable or disable deprecation warnings as a whole, not per type
Even if per-type warning disables were available, that still means it's too easy to accidentally or unknowingly introduce new call sites of a deprecated type

The most ideal solution is bringing back a relic from the Objective-C past: C compiler directives. In C-based languages, #pragma blocks could be used to ignore specific instances of a warning:

#pragma GCC diagnostic ignored "-Wdeprecated-declarations"

myDeprecatedFunction() // no warning

#pragma GCC diagnostic pop

myDeprecatedFunction() // warning: myDeprecatedFunction is deprecated

Although the syntax is clearly not very "2025", the idea is still good and exactly what should happen to improve this bit of API tooling. The deprecation warning on the call site that's "wrapped" in the diagnostic directive would be ignored, and introducing a new caller of myDeprecatedFunction generates a warning (or more ideally, a build error). You can choose to wrap that new call in the same #pragma block, but then it's an explicit choice and not something the developer was just unaware of.

Incidentally, having multiple levels of granularity is also exactly how e.g. SwiftLint and linters on other platforms work: you can disable rules entirely, per-file, per code-section, per-line, etc. It's too bad SE-443 didn't go that far, but discussions in the developer forums have pointed out these same problems so hopefully those will be considered in future improvements.

Flywheel of tech debt

2025-07-02T00:00:00-07:00

Tech debt is often compared to financial debt, in that you're borrowing development time now to pay it off with more development time later. When "later" comes around, the development time needed to fix the issues introduced earlier is too high so the new thing is also not built "correctly", and the pattern repeats itself: tech debt begets tech debt.

A few years ago I came across an article about the Taxonomy of Tech Debt, which talks about the contagion of tech debt: the easier a piece of tech debt spreads, the higher its impact because fixing that fragile code means preemptively fixing it in future cases as well.

A more extreme version of this is a flywheel of tech debt™: tech debt that doesn't just expand linearly because of a high contagion factor, but that multiplies at an excessive rate. This tends to happen in one specific part of the codebase: the infrastructure. Any libraries, frameworks, architectures, foundational patterns, etc. with tech debt have this flywheel and once it's rotating it's very difficult to stop.

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviours of your system will be depended on by somebody.

Hyrum's Law

Hyrum's Law is the primary reason why it's so hard to remove any tech debt from infrastructure code: even if the tech debt is internal to the architecture to account for one edge case, the behavior is there and will be depended on by somebody. If the tech debt is more severe and affects the API, the flywheel goes brrr and now requires all consumers of that API to incur the tech debt as well, unless they specifically understand (how) to avoid it.

What's worse is that after some time passes and people are using these APIs, it's much more difficult to remove because it also requires removing it at all the call sites that API. For a large team/codebase, this requires a lot of coordination between teams and can take years of time and effort. One team that doesn't pull its weight impacts everyone else.

This is ironic because in many situations that foundational layer with good abstractions and nice developer ergonomics is specifically created to avoid tech debt. The more this happens, the more brittle the foundations get until we get to the other xkcd. As such, I tend to advocate for moving the fragile code downstream, to the feature code as much as possible. This reduces chances of it impacting other features, even if that means the fragile code is worse or more risky.

The cost of fragile infrastructure code is so high because that code is generally long-lived, where the feature may be scrapped before it even launches. The team that introduces this code is now also directly responsible for it without impacting everybody else in the process. And, if the tech debt finally becomes too painful to deal with, fixing it is much simpler and easier to roll out than a fundamental change in the foundational layer of an app.

In the past I reluctantly accepted a hack here and there in some foundational libraries, but I intend to push back harder going forward. Spending years working out a single parameter from a public method in some part of our architecture is a valuable lesson learned...

Art of the state

2025-06-02T00:00:00-07:00

@State plays a prominent role in any SwiftUI app, and for good reason: app state is what ultimately drives the UI and how the user interacts with your app. This has always been true, but SwiftUI embraces this reality with specific APIs and a unidirectional data flow. UIKit-based apps or features were also driven by state, but this state would often live in the UI layer and was much more hidden as a result.

Note

This is actually true for frontend/web apps as well, as React works in a very similar way as SwiftUI and also uses a unidirectional data flow. In fact, I suspect SwiftUI drew some inspiration from React in terms of API design, but we probably won't ever get that confirmed :)

SwiftUI improves the data flow in applications, but there is much less discussion on best practices for defining what that data looks like. This is too bad, because thoughtful data and state modeling has cascading effects in API design and testability of code. Suboptimal definitions of state in the the model layer means that view models, view controllers, views, etc. all also suffer from that suboptimal design.

No matter the app, state plays a critical role (even if that state largely comes from the server) and I wanted to write down best practices and common pitfalls I've seen when writing state models.

Prefer value types

State is often passed down or otherwise accessed by different parts of the app. In some cases you might want to mutate it or operate on a separate copy of that state, without immediately affecting every other part of the app that relies on that same state. Using value types provides the necessary guard rails to make sure those changes don't unintentionally also impact other parts of the app, while still making it possible, to also globally mutate state.

Making the main state type a struct or an enum is a good start but not always sufficient: all state in a tree is ideally using value types. This avoids misusing a state type to be more than just the basic values that represent the current condition of the app.

It also inherently means that almost all state should be a collection of "primitives" like String, Int, Float/Double, and Bool that are used either directly or wrapped in other types (e.g. CGRect, NumberFormatter.Style, a custom type, etc.).

Basically any other type is out. No classes, closures, actors, or other more complex types as they typically aren't good candidates to represent state. Unfortunately, tuples are also not an option for now, but using a named struct is usually worth that hassle.

I've found that a good way to validate this is by making all state types conform to Equatable (or possibly Sendable). Types whose implementation of those Equatable don't require a custom implementation of == are good to go, and if the compiler complains about non-conformance there's some critical thinking to do.

Avoid singletons

If you needed more reasons to dislike singletons, here is another one: it makes data modeling more difficult. Take this UserManager example:

struct User {
    let id: UUID
    let name: String
}

final class UserManager {
    static let shared = UserManager()

    var user: User?
}

Ignoring all other singleton-related issues, the problem here is that since UserManager can be accessed even if the user isn't logged in, it gets hard to model the user property:

Make it optional and you're dealing with optionality everywhere, which is also not ideal (more on that below)
Make it "empty" (e.g. var user = User(id: UUID(), name: ""), and it doesn't properly reflect the state the app could actually be in since a user isn't required for the app to function

It's better to architect this in a different way such that you can guarantee the user and its properties are valid (i.e. non-nil and not just some default value) when asking for it.

Separate DTOs from domain models

Data Transfer Objects are the objects you get back directly from, typically, an API. DTOs are directly bound to the data the API sends, which could have all kinds of problems: missing or unused fields, wrong data types, optionality in some cases but not in others, unexpected or inconsistent formats, different versions, etc.

It's tempting to use these DTOs directly, especially when using mechanisms like Codable to create them easily and to cover some of those flaws. However, it might also be tempting to not optimize the domain model for your app because Codable isn't always the easiest to work it. This could handicap your data models as they now have to follow the API design and all its flaws everywhere in your app.

Admittedly, it is a bit annoying to write the data model "twice", but the work often pays off and the decoupling is worth it. Perhaps AI or other tools can help with this as well.

Avoid state impossibilities

Imagine a User object that captures the user's email and its verification status:

struct User {
    let email: String?
    let emailVerified: Bool
}

The verified status is required regardless of whether there is an email address. But the combination email = nil and emailVerified = true means nothing, so the state is modeling an impossible scenario. It's better to model this as a tuple or a struct:

struct User {
    struct Email {
        let value: String
        let verified: Bool
    }

    let email: Email?
    // or
    let email: (value: String, verified: Bool)?

    // with optional conveniences:
    var emailAddress: String? { email?.address }
    var emailVerified: Bool { email?.verified == true }
}

Now either both fields are set, or neither are and the app doesn't have to handle that "impossible" state.

Minimize redundant state

Try to use the minimum amount of state possible to represent a scenario. For example, you might start out with a simple flag to choose whether an account has been selected, but the app's requirements later change to also capture which account:

struct AccountSelection {
    let hasSelectedAccount: Bool
    let selectedAccount: Account?
}

Not only does this lead to another impossible state (hasSelectedAccount = true and selectedAccount = nil), but hasSelectedAccount can also be inferred from selectedAccount: if it's nil, no account has been selected.

Don't be lazy and let these redundancies build up in your app because the core business logic and UI layers (and tests!) will have to deal with this unnecessary complexity.

Reduce optionals when possible

The power of optionals is not using them

- Someone, at some point

In languages that have an Optional type, use them as little as possible. An optional immediately forks a type into two possible values (some or none), which incurs an additional code branch to test.

Note that "as little as possible" doesn't mean "never", so here are a few common pitfalls I've encountered when an optional is the best tool available:

Handle optionality as early as possible

If you're calling an API that returns an optional value that you expect to always be there anyway, try to eliminate it as early as possible instead of letting that optional permeate your entire tech stack. Define your model with the value as a non-optional and assert on its existence in your model (or even networking) layer.

In line with the DTO use above, that could look like this:

struct User {
    let name: String

    init(dto: UserDTO) throws {
        // UserDTO might not have a user's name for some reason
        guard let name = dto.name else {
            throw ParsingError.missingField("name")
        }

        self.name = dto.name
    }
}

This eliminates the need to test for what happens at every other layer (UI, business logic, etc.) if that value were to be nil.

Optional vs. empty arrays

A pattern I see a lot, unfortunately also in Apple's code, is an array defined like this:

let myStrings: [String]?

The optional here makes the code more difficult to deal with, since now you have to account for the nil case everywhere, in addition to the array being empty.

Hot take: in the vast majority of cases, code doesn't handle a nil array differently from an empty array (search your codebase for ?? [] and you'll see what I mean), so you might as well model it like that too.

In the situations where that difference is meaningful, making the property optional is fine:

struct User {
    let friends: [User]?
}

In this case, nil could mean we don't know who the user's friends are, and an empty array could mean the user has no friends ☹️

Consider enums instead of optionals

The Result type was introduced in Swift's standard library to eliminate the awkward situation where both the value and the error are optional types yet one of them will always be set. (Another example of state impossibility: what does it mean if both the value and the error are set? Or neither?)

I've often seen this awkwardness in state as well, and similar to Result, the solution is often to model that state as an enum with associated values. As a simplified example, instead of a bunch of optionals in an onboarding flow where data is collected step by step, that state could be modeled as:

struct OnboardingState {
    case askForName
    case askForBirthday(name: String)
    case askForEmail(name: String, birthday: Date)
    case askForPhone(name: String, birthday: Date, email: String)
}

Closing

Not all of the techniques above will be useful all the time, but I've often found myself adjusting the data model when something was annoying to deal with in layers that consumed it, and over time realized the importance of getting the details there right to make the rest of the application easier to deal with too.

Composing a resume in markdown

2025-03-15T00:00:00-07:00

I recently updated my resume, and after a few iterations of tweaking the same Pages file I started more than a decade ago, I decided that I really wanted source control to make it easier to keep track of changes and to have different versions of the same resume. Additionally, the very consistent structure and simplicity of a resume makes it a perfect candidate to be written in markdown, which is a text-based format and easy to have in source control.

Some quick searching confirmed my suspicion that many people were already doing this and that there are various tools available to make this easier. The primary tool is pandoc, which is a universal document converter. It can convert between many different formats, including markdown and PDF.

Note

The other tool that makes for a very structured resume is JSON Resume. It's a JSON schema with standard fields for common resume sections like 'experience' and 'education' that can then easily be themed. I found this a little too limiting and not as readable in plain text as markdown.

In my case, I'm converting from markdown to HTML, injecting some CSS to make it look the way I want it to, and then converting that to PDF. LaTeX was another option but I wasn't familiar with either LaTeX or ConTeXt and didn't want to bother learning it just for this exercise.

Converting to HTML was generally easy.

pandoc --standalone --include-in-header resume.css --output resume.html resume.md

This gives a pretty good starting point even with no CSS at all. pandoc uses a custom markdown dialect with some extensions and other features, which makes it easy to add ids and classes to <h1>-<h6> elements. This is useful as it makes applying the right style to the right element easy. The resume itself is simple and so is the resulting HTML. pandoc does inject its own CSS as well, which is easy to override in the custom CSS file.

After tweaking the CSS to my liking, the next step was to convert the HTML to PDF format. This was a bit more complicated as there were multiple ways to do that:

Safari (or another browser): There is an export as PDF option or the option to print and then save as PDF. This worked but required manual steps I wanted to automate.
wkhtmltopdf: a command line tool that converts HTML to PDF using a WebKit engine
pandoc: can convert to PDF directly with some options that, supposedly, affect the final PDF output. I tried using it with wkhtmltopdf as its engine, and it can also use LaTeX or ConTeXt as an intermediate format that bypasses HTML generation altogether.

I struggled a bit with which to choose, as the format for all of them wasn't quite right except for the print to PDF option in Safari. I ultimately settled on using wkhtmltopdf directly (without using pandoc for this step), after experimenting with these options and seeing which output I liked best. Converting the HTML to PDF was as simple as:

wkhtmltopdf -s letter resume.html resume.pdf

The -s letter option sets the paper size to US Letter since the default is A4. Nowadays it doesn't really matter as resumes are only ever used in digital format so the size of the PDF doesn't really matter anyway.

I then wrapped both commands in a simple shell script to make it easier to run:

pandoc \
    --standalone \
    --include-in-header resume.css \
    --output resume.html \
    resume.md

wkhtmltopdf -s letter resume.html resume.pdf

open resume.pdf && open resume.html

After some modifications to the markdown, running this script will quickly generate the HTML and PDF files and open them both so I can validate the result.

This setup ends up working pretty well for me for 3 reasons:

With everything in a git repo I can make changes as I like, undo them easily, and use all of git's features on my resume. I push the markdown, HTML, and PDF versions to GitHub so I always have the latest version handy in a few different formats.
The format and the content are for the most part separate, making it easier to focus on one or the other.
Since everything is now text-based and not in proprietary binary formats, it's also easy to overengineer this in the future by including certain sections when applying to different jobs, including certain information only when certain flags are set, differentiating between a CV and a resume, etc.

Incremental complexity in iOS development

2025-02-03T00:00:00-08:00

I wrote my first app, a map to navigate my college campus, in the winter of 2011, on iOS 4.x and with Xcode 4.x. There were 25 frameworks, iOS 7 hadn't been invented yet, there was only 1 phone size, and we wrote apps with Objective-C.

But things have gotten much more complex over the years: within iOS you can specialize in build engineering, architecture, performance & observability, UIKit or SwiftUI, game development, security and privacy, Core Data or SwiftData, iCloud, cross-platform apps with Catalyst, machine learning... The list goes on and on, and that's on top of the already powerful frameworks from the early days.

There are frameworks that enable entire categories of apps that weren't possible in the early days, or if they were with much less OS integration than today. HealthKit, WalletKit, StoreKit, RealityKit, ARKit all enable apps that were pretty much unimaginable 15 years ago. And that's just iOS without even thinking about watchOS, visionOS, or Apple's other platforms.

Swift went through a similar evolution. It started with a more functional programming language compared to Objective-C, but quickly added new features: protocol-oriented programming, property wrappers, function builders, concurrency, macros, and a billion new keywords.

In my first few years, I was eager to learn everything there was to learn about iOS. This was in the days when there was still an NDA anything related to iOS APIs and the developer forums required a paid membership, so only anything published by Apple was readily available. One of the first things I checked with new platform versions was the API changes in UIKit and Foundation, and the iOS and Xcode release notes were next. WWDC keynote days were overwhelming because a year's worth of changes just shipped and I felt like I needed to learn all of it in a few hours' time.

There are so many more sources to learn some part of the platform now that's impossible to keep up with it all. You can easily be an iOS developer without knowing 90% of its technologies. A "generalist" iOS developer will know many of the UIKit/SwiftUI and Foundation APIs, as well as commonly used Swift features. But if you're building an iOS app for an audio company that requires deep knowledge of AVFoundation, you won't care or be able to keep up with advancements in Core Location simply because they're irrelevant.

This feels like a pretty big difference from the first few years of the App Store, when experienced developers went "broad" because "deep" didn't really exist yet. There were no UI experts, iOS game developers, Swift enthusiasts, or multiplatform lobbyists, so it was fun to learn more about all the frameworks even if you weren't going to use them.

For beginning developers that increase in complexity isn't super obvious, as everyone is "expected" to know basic UI and Swift knowledge and it takes some time to learn that. But more senior developers looking for a new job where experience with specific frameworks (sometimes not even Apple's own, like React Native, RxSwift, or The Composable Architecture) is desired may feel like they are not experienced enough. In reality they have plenty of great experience, just in other parts of iOS.

Most companies that hire for a niche iOS specialty realize this and are generally OK with someone who's willing to learn the technologies that specific job requires. But how do those companies interview for that? For hands-on coding exercises, there are a few options:

Ask more basic questions that all people should know at least to some extent. This works OK but doesn't really distinguish senior from junior engineers.
Ask deeper questions but run the risk the candidate happens to not have deep knowledge on the topic they're being asked about.
Let candidates choose the topic they have deep knowledge of and talk about that, but run the risk of the interviewer knowing nothing about topic.

Having been deeply involved in designing an interview process, I'm growing more convinced that evaluating candidates based on 60 minutes of hands-on coding isn't going to get you the best developers and will primarily weed out the below average ones. What I find more interesting for these positions is if candidates have enough transferable knowledge in one framework to quickly ramp up with another. You can learn a ton about someone's experience through questions like:

How does Apple approach privacy and how is that reflected in its APIs? What is generally involved in requiring user permission to use sensitive user data and what is the best way to handle that data?
What hardware and environmental constraints do iPhones have? How does the system deal with those limitations and in what ways are developers affected by that? What precautions can you take and how can you know if your app performs well?
How would you do the research for a lightning talk about an iOS technology you currently know nothing about (e.g. data persistence)? What sources of information are there, how reliable are they, and which do you prefer?
Think of an API, language feature, or pattern you've used recently that can be improved. What did you not like about it, how would you improve it, and why do you think Apple might have designed it this way?
Apple introduces a new technology at WWDC and your boss hears about it and wants you to implement it in the company's app. What problems do you foresee?
What App Store Review guideline would you get rid of and why? Which one would you introduce?

These questions feel decidedly more involved than typical questions like "how does memory management work" and "what's the difference between a class and a struct", and they give a lot more insight into someone's (lack of) experience with the platform.

Being a senior iOS developer went from breadth of knowledge to depth of knowledge, and I expect more defined specialties, perhaps iOS Security Engineer or iOS Camera Engineer, to crystallize in the future. It's no longer about watching every WWDC video and learning the latest UIKit tricks, knowing exactly what APIs became available in what iOS version, and finding ways to use the latest Swift features in your own code.

Instead, more experienced developers understand how Apple designs their platforms and technologies, have surface-level knowledge of what is available to them, and are able to take their existing knowledge and apply it to something new to ramp up quickly and effectively. The rest they know they can learn on the fly. Hopefully companies realize this too in their interviewing and onboarding processes, because you might be onboarding an iOS developer who doesn't know a single thing about the tech stack your app is running on.

Update (February 2026)

This post is only a year old but many shifts have already happened. AI impacts the profession in a profound way and I no longer think more specialized jobs will exist. Instead, companies will have their engineers leverage AI to ramp up on new technologies quickly instead of trying to find their unicorn engineer that happens to be an expert on Bluetooth audio.

Senior engineers with a baseline knowledge will need to upskill to learn how to use AI tools but will be fine in the end. Junior engineers will have a harder time as companies seem to be unwilling to train them, a bad trend in my opinion because the junior engineers are the senior engineers of the future.

Looking up words in a dictionary with Neovim

2024-12-08T00:00:00-08:00

When writing code in neovim, I frequently use K to look up documentation, function signatures, variable definitions, etc. In markdown files that doesn't make too much sense, but I wanted to use it to look up words in the dictionary instead. This didn't appear to be possible out of the box but the power of (neo)vim is its extensibility so I decided to build it myself.

The steps to build this roughly were:

Write a dictionary lookup tool
Parse this tool's output and show it in neovim
Configure neovim's K functionality

`dict`

dict seemed like an appropriate, easy name to look up a word in the dictionary. As I'm a macOS user I first wanted to use the built-in dictionary through pyobjc-framework-CoreServices but DCSCopyTextDefinition doesn't return dictionary entries in a well-structured or consistent way, so I ultimately decided to write a quick lookup using dictionaryapi.dev. I also added some other formatting and ANSI coloring to improve the CLI output:

#!/usr/bin/env python3

import requests
import argparse

_TERMINAL_RESET = "\033[0m"
_TERMINAL_BOLD = "\033[1m"
_TERMINAL_DIM = "\033[2m"
_TERMINAL_RED = "\033[91m"
_TERMINAL_GREEN = "\033[92m"
_TERMINAL_BLUE = "\033[94m"


def _fetch_word_definition(word):
    url = f"https://api.dictionaryapi.dev/api/v2/entries/en/{word}"
    response = requests.get(url)

    # Handle API errors
    if response.status_code != 200:
        return None

    return response.json()


def _format_definition_output(word_data):
    if not word_data:
        return f"{_TERMINAL_RED}error: word not found{_TERMINAL_RESET}"

    word = word_data[0]["word"]
    meanings = word_data[0].get("meanings", [])

    output = f"{_TERMINAL_GREEN}{_TERMINAL_BOLD}{word}{_TERMINAL_RESET}\n"

    for part_of_speech in meanings:
        pos = part_of_speech["partOfSpeech"]
        output += f"\n{_TERMINAL_BLUE}{pos}{_TERMINAL_RESET}"

        synonyms = ", ".join(part_of_speech["synonyms"])
        output += (
            f"  {_TERMINAL_DIM}({synonyms}){_TERMINAL_RESET}"
            if synonyms
            else ""
        )
        output += "\n"

        for i, definition in enumerate(part_of_speech["definitions"], 1):
            definition_text = definition.get("definition", "N/A")
            example = definition.get("example", "")
            output += f"  {i}. {definition_text}"
            if example:
                output += f" (e.g., {example})"
            output += "\n"

    return output


def _get_word_definition(word):
    word_data = _fetch_word_definition(word)
    return _format_definition_output(word_data)


def main():
    parser = argparse.ArgumentParser(
        description="Fetch word definitions from API dictionary.dev."
    )
    parser.add_argument("word", help="Word to look up")
    args = parser.parse_args()

    word = args.word
    print(_get_word_definition(word))


if __name__ == "__main__":
    main()

This file needs to be in the PATH which I did by putting it in ~/.bin/dict.py and setting export PATH="$HOME/.bin:$PATH".

dict ambiguous now gives a nicely formatted definition:

Neovim integration

I wanted to invoke dict using K passing in the word under the cursor as the trigger and showing the output in a popup window. Other than the plain vim configuration this required some text manipulation so I put all that in ~/.vim/plugin/dictionary.lua:

-- Create a new buffer with the given message and apply ANSI highlighting
local function create_buf(message)
  local buf = vim.api.nvim_create_buf(false, true)

  local lines = vim.split(message, "\n", { plain = true })
  for i, line in ipairs(lines) do
    local stripped = line:gsub("\27%[[0-9;]+m", "")
    vim.api.nvim_buf_set_lines(buf, i - 1, i, false, { stripped })
    apply_ansi_highlighting(buf, i - 1, line)
  end

  return buf
end

-- Show a popup window with the given buffer
local function show_popup(buf)
  vim.g.popup_window = vim.api.nvim_open_win(buf, false, {
    relative = "cursor",
    width = 100,
    height = 15,
    row = 1,
    col = 0,
    anchor = "NW",
    style = "minimal",
    border = "single",
  })
end

-- Close the popup window
function ClosePopup()
  local window = vim.g.popup_window
  if vim.g.popup_window and vim.api.nvim_win_is_valid(window) then
    vim.api.nvim_win_close(window, true)
    vim.g.popup_window = nil
  end
end

-- Look up the definition of the word under the cursor
function DictionaryLookup()
  local word = vim.fn.expand("<cword>")
  local file = assert(io.popen("dict " .. word, "r"))
  local definition = assert(file:read("*a"))
  file:close()
  show_popup(create_buf(definition))
end

This creates 2 functions, DictionaryLookup() and ClosePopup() that show and dismiss the popup, stripping the ANSI codes from the output as they were rendered raw in the popup.

However, note the call to apply_ansi_highlighting(buf, i - 1, line) near the end of create_buf(), which replaces the ANSI codes with neovim specific highlight groups. This turned out to be quite involved but I wanted the formatted output and used this as an opportunity to learn lua a bit more.

vim.api.nvim_set_hl(0, "Normal", { fg = "fg", bold = false, underline = false, italic = false })
vim.api.nvim_set_hl(0, "Bold", { bold = true, underline = true })
vim.api.nvim_set_hl(0, "Dim", { fg = "gray", italic = true })
vim.api.nvim_set_hl(0, "Red", { fg = "red" })
vim.api.nvim_set_hl(0, "Green", { fg = "green" })
vim.api.nvim_set_hl(0, "Blue", { fg = "blue" })

local ansi_patterns = {
  { pattern = "\27%[0m", highlight = "Normal" },
  { pattern = "\27%[1m", highlight = "Bold" },
  { pattern = "\27%[2m", highlight = "Dim" },
  { pattern = "\27%[91m", highlight = "Red" },
  { pattern = "\27%[92m", highlight = "Green" },
  { pattern = "\27%[94m", highlight = "Blue" },
}

-- Find the highlight group for a given ANSI escape code
local function find_ansi_pattern(text)
  for _, entry in pairs(ansi_patterns) do
    if text:find(entry.pattern) then
      return entry.highlight
    end
  end
  return nil
end

-- Apply ANSI highlighting to a line of text in the given buffer
local function apply_ansi_highlighting(buf, line_num, text)
  text = text:gsub("\27%[0m$", "")
  local pattern = "\27%[[0-9]+m"

  local start_pos, end_pos, match = text:find("(" .. pattern .. ")")
  local cursor = 1
  local pos_in_stripped = 0

  local next = text
  while start_pos do
    if next:find("^" .. pattern) then
      start_pos, end_pos, match = next:find("(" .. pattern .. ")")
      cursor = end_pos + 1
      vim.api.nvim_buf_add_highlight(
        buf,
        -1,
        find_ansi_pattern(match) or "Normal",
        line_num,
        pos_in_stripped,
        -1
      )
    else
      start_pos = next:find(pattern)
      if start_pos then
        pos_in_stripped = pos_in_stripped + start_pos - 1
        cursor = start_pos
      end
    end

    next = next:sub(cursor, -1)
  end
end

Configuring `K`

Opening any file and calling :lua DictionaryLookup() already works (and :lua ClosePopup() to dismiss it) but that's a lot of typing and it better fits K in markdown files since that's otherwise unused anyway.

I mapped the first to a vim command :Dict and wanted to hide the window with any cursor movement, similar to how this works for other documentation lookups. keywordprg is the command that gets invoked through K (and can also be set through set keywordprg).

I put this in ~/.vim/ftplugin/markdown.lua so that it automatically is applied to markdown files:

vim.api.nvim_create_user_command("Dict", DictionaryLookup, { nargs = 1 })
vim.opt["keywordprg"] = ":Dict"

vim.api.nvim_create_autocmd("CursorMoved", {
  pattern = "*",
  callback = ClosePopup,
})

With the end result being:

Dictionary lookup also still works in non-markdown files by directly invoking :Dict, which is a bit more typing but also much less common. That's all that was needed, now K performs a dictionary lookup and shows it nicely formatted in-line and is automatically hidden when needed. This may be nice as a generic plugin as well so I might do that at some point in the future as well.

Shifting the testing culture: Code coverage

2024-11-20T00:00:00-08:00

Note

This is the third post in a series on shifting our testing culture.

Motivation
Infrastructure
Code coverage

Most people will say that code coverage is a measure of how well-tested your code is. I prefer to say it's a measure of how untested a codebase is. Take this example:

func myFunction(input: Int) -> String {
    if input == 0 {
        return "zero"
    } else if input == 1 {
        return "one"
    } else {
        return "other"
    }
}

func testMyunction() {
    _ = myFunction(input: 1)
    _ = myFunction(input: 2)
}

This yields 66.7% code coverage, but although the test passes, it doesn't validate any business logic because the test has no assertion. The example is a bit derived, but in a more realistic scenario where tools report you have 66.7% code coverage, you don't actually know if that code is actively tested or just happens to be executed while running tests. What you do know is that the other 33.3% is definitely not tested.

`llvm-cov`

Pedantries aside, code coverage is still important even if the coverage level is already high and there isn't much untested code. That's because code coverage isn't just a number, it also comes with a detailed source overlay: the source code with highlights that indicate which lines, functions, and code branches were invoked while running tests, and how often:

It's clear that although this method has a test, the input == 0 branch wasn't executed while running them. The return "one" and return "other" lines are executed once, and the rest of the method is executed twice. Getting full coverage of this function requires adding a test that calls it with input == 0.

On iOS, Xcode has built-in support for reporting code coverage. It presumably uses llvm-cov for user friendliness, but invoking llvm-cov directly gives a ton of extra options, including exporting in different formats like JSON and HTML.

Since llvm-cov operates on a test bundle and we have a test bundle for each of our modules, we can get detailed information about a module's code coverage: which file and which lines within a file, how many total lines are testable and how many are covered, etc.

In the past we used the various output formats to integrate with codecov, but eventually moved to an in-house web portal where this data is stored and easily accessible. We've also built tooling integration so developers can run a simple command on their own machine to get llvm-cov's output generated for their modules, though viewing it in Xcode is often the better choice for local development. The only part that's missing is seeing the source overlays in GitHub so you can immediately tell which code changes require more tests.

Tracking coverage

Every time a module's source code or tests change, we capture the new coverage metrics in a database to keep track of a full history of each module's code coverage. We aggregate the data by team and for the codebase as a whole, and display it on the web portal. This gives anyone immediate access to answer common questions about their team's testing progress.

Developers are often interested in more than just the raw code coverage numbers - they also want to understand what code isn't tested so they can add more coverage. To make this easier, the web portal also displays the source overlays for all source files in a module for easy viewing without having to open Xcode for it.

Minimum coverage

When a measure becomes a target, it ceases to be a good measure

- Goodhart's law

Many companies enforce a minimum coverage level all code has to hit. Although it sounds enticing, it could also turn into exactly what Goodhart's law warns about. Developers will likely work around it if they feel they need to, or write low-quality tests just to hit the minimum. It's also not clear what number to pick and what to base that on.

So instead we took a slightly different approach: each module gets to set its own minimum coverage percentage in the BUILD file, and that percentage is then enforced by our CI system. It's a good balance between establishing a minimum while giving developers enough control to not make it feel overbearing.

Developers are free to set that minimum to any percentage they want through a pull request, but lowering it too drastically requires a good justification and comes with social friction. Increases are often celebrated as a job well done.

We also bump the minimum for a given module automatically if it's too low compared to its actual coverage. A module whose minimum coverage is set to 10% but actually has 50% coverage, would get its minimum increased to 45%. This makes it harder to accidentally drop coverage.

Other ideas we've played around with but haven't implemented:

not allowing decreases in minimum coverage below a certain threshold
enabling a global minimum but setting it very low (e.g. 20%), in hopes of having to write some tests will lead to writing more
higher minimum coverage for code that uses highly testable architectural components (as opposed to legacy code that's harder to test)
tech lead approval for dropping a module's minimum coverage
requiring adding/updating tests on PRs (changing code without needing to change tests generally means the code is not tested)

Raising the bar

Having a long history of coverage data available has been a big factor in raising the quality bar. During biannual planning, teams get a clear overview of their average coverage and can quickly see which of their modules have the most room for improvement, and attach a measurable goal to it.

We look at overall trends and average coverage levels per module type, and set goals for them for as guidance for other teams. Nothing big, just a couple percent points per quarter, but it makes testing a talking point. When we introduce a new tool, e.g. snapshot tests, we can see how that affects the trend (spoiler alert: our developers strongly prefer snapshot tests) and whether to invest more time/effort.

Developers ask for more or better tests during code review. There has been a noticeable uptick in code changes that just introduce a bunch more tests for existing code. More refactors start out with ensuring code coverage is solid or by closing any testing gaps. If an incident happens, the fix is asked to include a test, and the post-mortem documents the code coverage of the code that was at fault, with an action item to increase coverage if it's too low.

Just like a more testable architecture and better tooling, having insightful code coverage data played a big role in the gradual shift of our iOS testing culture. We started with near 0% coverage, and all the improvements over the years have gotten us to an overall code coverage of 60% and climbing.

To me it's one of the most fascinating leaps in maturity I've seen in my time at Lyft with a ton of learnings along the way.

Shifting the testing culture: Infrastructure

2024-11-19T00:00:00-08:00

Note

This is the second post in a series on shifting our testing culture.

Motivation
Infrastructure
Code coverage

This second article goes a bit deeper into the testing infrastructure we built over the years to optimize the ergonomics and developer experience as much as possible.

Our initial test suites only had basic tests for some foundational code in shared modules. Initially these were written in Quick and Nimble, but we moved to the default XCTest to reduce the learning curve. When we started writing UI tests, we immediately used XCUITest and still use that today.

(swift-testing looks very nice and we're exploring how we can start using this in our own codebase.)

Modules

When we modularized the codebase (which I wrote a little bit about before), we did so specifically with testing in mind. All modules got their own test bundle to test that module's code.

Later on, we also specialized each module to the type of code it contained. A module with primarily UI code in it is a UI module, and a module with core business logic is a logic module. This approach has three (testing) benefits:

It separates business logic from UI logic at a higher level
You can now establish the level of testing that's expected per module type (e.g. higher for logic modules than for UI modules)
The module type defines what type of tests should be written for that module (e.g. snapshot tests for UI modules, unit tests for logic modules)

Since each module is owned and maintained by a specific team, that team is now fully in control over the tests they want to write for their own features. For example, a UI-heavy feature is more likely to have snapshot tests than unit tests. Complicated flows might have both or use UI tests for integration-like tests.

Avoiding flakiness

Test flakiness, tests that sometimes pass and sometimes fail, became more common as we grew the number tests. This is a problem for multiple reasons:

people lose confidence in the system if tests fail when they shouldn't
it slows engineers down
it's disruptive when tests that have been around for months suddenly start failing

The source of flakiness was generally an infrastructure problem, a test problem, or a code problem. Infrastructure problems were usually not actionable by product engineers and was something related to CI, Xcode, the test runner, the simulator, or the intersection between any of these.

If the code was flaky that may have actually been a bug (yay tests!). Often this meant some globally mutable state was involved, and was different than what the tests expected for some reason.

If the test itself was flaky, it wasn't always obvious why and how that could be avoided. The code is hard to debug because the issue doesn't always reproduce (sometimes only on CI) and if there didn't seem to be any bugs people would understandably give up on that test if tracking the issue down took too long.

On the infrastructure side we've made many improvements over the years to reduce flakiness to a minimum:

retry a failing test to reduce the impact of infrastructure failures
disable a test that failed multiple times in a row and report it to the maintainer of the module that has the failing test
increase the timeouts for test suites to run to avoid timing out slow-running, but passing, tests
keep track of common errors out of our control (e.g. bugs in Xcode) and explicitly ignore them, try again, or work around them
ensure tests always ran in the same environment: iOS version, device simulator, locale, etc.

Infrastructure flakiness still happens on rare occasion, but the sytems are much more robust and forgiving of intermittent issues than when we first started.

Making simple things simple

Simple things should be simple, complex things should be possible.

- Alan Kay

Further architecture improvements led us to standardize on a Unidirectional Data Flow using RxSwift. These patterns are very testable, but required quite a bit of boilerplate and significant knowledge of best testing practices within those systems.

With a more RxSwift-centric architecture, more asynchronousness code patterns emerged as well. Initially we used XCTestExpectations to deal with that since that's what Apple recommended, but regularly having to increase the timeout on these expectations felt bad and we figured there had to be better ways.

We first adopted RxBlocking, but later realized RxTest was where the real money was for us. Having two extra libraries just for testing felt heavy-handed at the time, but have become invaluable for us.

Because the new standard for features was that they were all written using in-house architectural components without too much deviation, we could also standardize the test-writing part through a thin glaze of syntax sugar. Testing a single action's outcome in a reducer now looks like this:

func testAcknowledgingError() {
    self.reducer.assert(
        state: .init(error: .mock()), // easy error state setup with mock data
        action: .acknowledgeError, // acknowledge the error
        result: { $0.activeError = nil } // error has been acknowledged
    )
}

With many conveniences like these in place, many tests are easy to read and take just a few lines of code. I'm optimistic that once we adopt swift-testing's parameterized testing we can probably reduce this even more.

Mocking

Our dependency injection system enables mocking with protocols which carries a bit more boilerplate than I'd prefer but isn't too bad overall. We've also built "automock" tooling: a pre-compile tool that generates mock classes for all protocols it found in a module. That looks something like this:

// handwritten by a developer:

protocol MyAPI {
    func getDataFromServer() -> [String: Any] // json
    func postDataToServer(param: Bool)
}

// autogenerated by automock:

open class MyAPIMock: MyAPI {
    public var getDataFromServerReturn: [String: Any] = [:]

    public getDataFromServerCalls: [Int] = []
    public get postDataToServerParams: [Bool] = []

    func getDataFromServer() -> [String: Any] {
        getDataFromServerCalls += 1
        return getDataFromServerReturn
    }

    func postDataToServer(param: Bool) {
        postDataToServerParams.append(param)
    }
}

MyAPIMock can be used in tests to verify that the right methods are called at the right time, and with the right parameters.

Automock supports more complicated use cases like closures, and more complex parameter and return types as well. This saves developer time writing mock classes and promotes consistency in naming and mocking usage.

It even works for model data, but it's less used and I'm more interested in a macro approach that looks something like this:

@Mock
struct User {
    let name: String
    let age: Int?
    let active: Bool
}

// @Mock expands to:

extension User {
    static func mock(name: String = "", age: Int? = nil, active: Bool = true) {
        User(name: name, age: age, active: active)
    }
}

Generating mock data is now as simple as User.mock() (or even .mock() if the type can be inferred) while still having the ability to set parameters manually if needed.

Other improvements

We've made a plethora of other improvements as well: sharding to parallelize tests, only running test bundles for changed modules, a TestKit module to remove common setUp() boilerplate, and a bunch of small things I'm probably forgetting right now.

But the most meaningful and impactful improvements have been related to how we handle code coverage. So much so that I thought it deserved a whole separate post.

Shifting the testing culture: Motivation

2024-11-18T00:00:00-08:00

Five years ago I began promoting automated testing heavily within Lyft even though I didn't have any real experience in writing big test suites myself. Many hands make light work, so I found a few people who shared this thinking and we started on what turned out a multi-year testing journey. What did we do?

We optimized the architecture in a much more profound way than just "you can write tests more easily"
We built a ton of tooling to improve the developer experience and to hold ourselves more accountable
We started measuring and reporting progress on our efforts regularly
We included testing in company-wide processes like incident review and biannual planning

The end result of all the major efforts, minor quality-of-life improvements, and fixing tiny paper cuts has led to test-writing now being a huge part of our engineering culture. That's not to say we're there—there is definitely still more work to be done. But the progress is pretty remarkable and I wanted to share more about it.

I'll do this in a series of blog posts, this being the first one:

Motivation: why we thought this was an important area to invest in
Infrastructure: how we upgraded our infrastructure to optimize for testability
Code coverage: how we measure, report, and act on our code coverage

Motivation

After experiencing the hypergrowth of both our team and codebase in 2017-2019, it became clear that the only way to maintain code and product quality was through automated testing. Prior to that, a lot of testing would happen through knowledgeable developers, QA processes, and dogfooding, but that wasn't going to hold up indefinitely for a few reasons:

QA time is costly because a human hour is much more expensive than a computer hour. Writing a unit test means you can now validate any code change with that test in a fraction of a second, but a QA engineer needs to spend that time again and again.
QA processes themselves are expensive: test plan management and maintenance costs time and money and the process itself needs to be developed, documented, and updated
People leave, and with them institutional knowledge leaves as well. It takes a long time for new people to build that knowledge, if they ever get there.

In short, computers can handle 80-90% of this work faster and more accurately than developers can. As with all infrastructure, it takes some time to set it up in an effective way, but since that's a one-time effort it should pay itself off over time.

Testing methodologies

Unit testing, acceptance testing, integration testing, system testing, regression testing, UI testing... fanatics will tell you they're all important. I don't necessarily disagree, but how hard you go also depends on how you need to balance quality and velocity. Aviation software leans much more toward quality, a rideshare app comparably more toward velocity.

So we initially focused on two types of testing: unit testing and UI testing. After snapshot testing became popular on both iOS and Android we added that to our arsenal as well.

Unit and snapshot tests are written by mobile developers for their own code, UI tests cover larger flows and are written by SETs. (In my opinion UI tests, if you choose to invest in them, should also be written by the developers that wrote the original code, but that is not the setup we have today.)

Benefits

It feels a bit weird to be writing these articles pretending it's some novel idea that writing tests benefits an engineering organization like that isn't already common knowledge. However, testing culture in the iOS community, and I suspect all "frontend" disciplines (web, mobile, TVs, etc.), is weak compared to that in other communities. For one because UI is hard to test, but also because Apple itself doesn't promote it much as a best practice.

To not just speak in hypotheticals, the benefits we've experienced firsthand are:

Behavior validation: The most obvious benefit is that tests validate how code behaves. Bug fixes will see fewer regressions, refactors are safer, and the app is generally of higher quality because every bug happens only once (in theory) and many are prevented from happening at all.
Behavior documentation: Code becomes more self-documenting as a lot of the behavior is prescribed in tests. You can skim test names/descriptions to understand how a class is supposed to behave, with little risk of the documentation becoming outdated because the tests will fail if they don't match the actual behavior.
Code readability: in order to write reasonable tests, code has to be structured reasonably well too. Test setup is hard with spaghetti code, so there's an incentive to write cleaner code. (Unfortunately, the opposite is true too: poorly written code can often lead to poorly written or no tests.)
Engineering satisfaction: a well-tested codebase is more satisfying to work in because developers have higher confidence in the correctness of their code. It "feels" easier to make changes because you can rely on the tests to catch any mistakes.

Drawbacks

I don't really like writing these articles without also mentioning the drawbacks. The main ones we've experienced are:

Time cost: it simply takes time to write tests, and there's strong correlation between a codebase that desperately needs tests and the time it takes to write those tests
False sense of security: it's easy to become overly confident in the test suite and assume a passing test suite means there are no bugs, when in reality the test suite might be incomplete or of low quality
Learning curve: there's a learning curve involved, especially in a large codebase, and not everyone is interested in learning this
More code to maintain: code requires maintenance and test code is no different

Over time we've tried to minimize these drawbacks as best as we could, but most of them will likely always be a factor. In the next articles I'll go in a bit more depth on the mitigation strategies we've used and how effective they've been.

Migration strategies in large codebases

2022-11-15T00:00:00-08:00

Code migrations are a fact of life for large codebases. New technologies pop up, platforms see improvements, and programming languages get new features you might want to adopt. Not performing these migrations and keeping up with the times is simply not an option in most cases. While some migrations are easy 1 for 1 replacements that can/should be scripted, that’s not true for the more “semantic” migrations—the new code accomplishes the same but in an entirely different manner.

We’ve done a number of these semantic migrations in Lyft’s mobile codebases and while we’ve learned something from every one of them (and applied the learnings the next time), they only get harder as time goes on.

What makes migrations so difficult? This generally comes down to how development works in large codebases: there is no 1 mobile team, but rather a lot of vertical teams (e.g. payments, new user experience, etc.) that all build their own features, using shared foundational code and architectural patterns. The coordination of dozens of teams on the progress of a migration is what makes this difficult:

Codebases tend to grow ad infinitum, so there is simply more code to migrate each time and there are more “weird” cases that make automating a migration difficult.
Getting (and keeping) buy-in and commitment. Teams all have their own plans and priorities, and migrating code from pattern A to pattern B is often not high on the priority list. If it is, that could change before the migration is completed.
Senior engineers on those teams tend to have good judgment on the importance of reducing tech debt and can weigh it against other priorities coming from product managers and designers. Junior engineers that get pulled in 4 different directions are less likely to push back against their direct teammates, so tech debt tickets are moved to an ever-expanding Jira backlog.
Teams are not static. You might inherit code written years ago that still works and is in use, but you didn’t even know it existed until last week. And now it needs to be migrated? Or it’s that one feature that is somehow mission critical but no one knows how to even get in the state to show it, let alone test new code in it.

So how do we get these migrations done anyway? There is no silver bullet, but we have started using a number of strategies to make these migrations less painful—and almost all of them have to do with improving the communication and expectations everyone involved has.

Migration tracker

The biggest leap forward for us was the rollout of an in-house web dashboard that shows progress on all ongoing migrations in our iOS and Android codebases. It shows all the important information anyone could want to know: the start date, (projected) completion date, links to documentation and support channels, relative priority (more on that below), etc.

But the real win is automatic progress tracking. Every migration is defined as the presence of a certain pattern in the codebase we want to get rid of. A cron job records all instances of that pattern on the main branch once a day, so we know exactly how much code has been migrated and how much is left.

Furthermore, our codebase is heavily modularized, and through CODEOWNERS every module is required to define what team owns it. This data is shared with the Migration Tracker, so it can give a detailed breakdown by module and by team of how much unmigrated code is left. This is extremely helpful in understanding which teams might need extra time, help, or nudging in getting everything done.

Timeline

The “deadline” of a migration needs to be carefully chosen. Not giving people enough time makes them not do the work at all, giving them too much time means people will procrastinate and needlessly extend the migration time. If it looks like teams are not going to make the deadline (as projected by the Migration Tracker), we ask them when they can get it done. We usually accept whatever answer the team gives, but hold them accountable to that since they themselves picked that timeframe.

Priorities

Teams that are far behind in code modernization might have to migrate their code in multiple ways. We give each migration a priority (P0/P1/P2/P3) to give teams a sense of where to focus their tech debt energy first.

A P0 migration is a “must-do-or-else” (externally mandated changes, tight deadlines, extremely high impact on overall trajectory of the codebase or product, etc.), a P1 is high impact but not as urgent, P2 is a nice to have, and P3 is almost more of an FYI.

This helps everyone understand where they should focus their energy, instead of seeing a potentially long list of items that are all seemingly equally important migrations.

Incremental value

Where possible (which is most cases), we try to bring incremental value as a migration is being performed. For example, if we set out to replace all uses of class A with class B because class B performs better, the places where class B is used should see that performance increase before the rest of the code has been migrated. This has a few benefits:

It rewards teams that have done their part of the overall migration
It’s easier to convince people doing their part has value since they themselves immediately see that value
It de-risks long-running migrations—if it gets to 95% completion we realize 95% of the benefits and not 0%

Only invest in the new

The initial value (like performance improvements in the example above) teams get from migrating their own code might not be enough to convince them to do it. But as more and more improvements are made to “class B” (e.g. API ergonomics, integrated analytics, compatibility with other systems) that “class A” doesn’t have, the value proposition for the migration changes with time. We no longer update A, which means there's some amount of bit rot and it becomes more cumbersome to use.

In extreme cases we could even remove features of class A that would necessitate a migration, but we haven’t done that so far and would like to avoid it to avoid losing goodwill with teams.

Develop great partnerships

Getting adoption of a new pattern or tool is difficult even if it doesn’t involve a new migration, because there is no precedent. Early adopters will hit all the rough edges and have often incomplete documentation and no sample code. The developer experience isn’t great (yet), so we make ourselves very available to their needs. We take their feedback seriously and address it promptly, sit down with them to help solve their issues, and generally spend a lot of time with them working out the kinks. We do this 1) to build more confidence that what we built is production-ready and 2) to recognize/reward people that want to try new things by reducing as much of the growing pains as possible.

Of course, good developer experience is important for all teams and not just early adopters, but piloting teams can help us get the ball rolling with other teams as well. Positive reviews from users of Great New Thing is different than hearing it from the developers of Great New Thing.

Avoid new uses

To avoid creating a moving target, as soon as we start a new migration we lock down the uses of that pattern to only the current ones and no longer accept new uses of this pattern. Depending on the situation we have a few different ways of accomplishing this:

We add a linter rule or sometimes entirely new type of (custom) linter and introduce exceptions to all existing use cases
We rename a class or method by prepending the current name with DEPRECATED. This isn’t particularly elegant, but it alerts the author and PR reviewers that new legacy code is being introduced, which usually has them dig deeper and figure out what to do instead.
If an entire module is being deprecated, we don’t easily let new modules depend on it. Exceptions are always possible, but engineers have to talk to us first so we can guide them in the right direction.

These measures are just to generate awareness that a pattern is outdated, it doesn’t always communicate why it’s being deprecated and what’s replacing it. But if people come to us asking for an exception we can explain it or link to docs, an opportunity we wouldn’t have had if we didn’t do any of the things above.

Support, support, support

And that brings me to the most critical and time-consuming piece: support. This means helping people with questions, plugging gaps new patterns have compared to the old ones, checking in with people on progress, celebrating the completion of major (or all!) migrations with everyone that helped contribute, assisting teams that are having difficulty prioritizing the work, and anything else that gets the work done.

Migrations are a very specific type of codebase maintenance due to the large footprint they often have in a lot of the codebase. It’s an all-hands on deck situation and requires proper coordination and communication, sometimes for years on end. It’s hard to get them right and we’re still fine-tuning our strategies but applying the learnings I described here have made us become better at them. I can only hope one day refactoring tools become smart enough to automate the work for us.

Human factors in choosing technologies

2022-09-28T00:00:00-07:00

I recently saw a thread where someone wanted to introduce a more capable architecture pattern than what most apps start out with in a small team, but received some pushback from teammates and was looking for help in countering their arguments.

The thread for the most part focused on the technical benefits of the proposed pattern, such as testability, separation of concerns, modularity, etc. These are all valid trade-offs to consider: we’ve done the same at Lyft when figuring out what architectures would suit us best. This is also not unique to architectures, any big technology that influences the overall direction of the codebase: SwiftUI vs. UIKit, RxSwift vs. Combine vs. async/await, etc.

But over time I’ve realized that even with a technically “perfect” solution (a real oxymoron!), there is an entirely different yet equally important factor to consider: who are the people using it—now and in the future? The success of a particular technology is highly dependent on the answer to that question, and it plays a huge role at different stages of the development of that technology.

In the thread I mentioned above there was very little focus on the human aspect of the proposal, so I wanted to list a number of things that I personally ask myself and our teams before considering moving forward:

How much is the onboarding/ramp-up cost? While I generally think short-term pain is worth long-term gain, onboarding is often a continuous cost. New people join, you might have interns, non-mobile engineers wanting to make quick contributions, etc. If those people first need a lot of time to ramp up, it’s worth wondering if the benefits are worth it, or how to reduce that burden. For example, while we currently aren't using any SwiftUI at Lyft, we have a layer of sugar syntax on top of UIKit that enables us to use SwiftUI-like syntax anyway. This makes it easier for both new people that join and already know SwiftUI and for everybody to move over to SwiftUI if/when we're ready for that.

How easy is it to undo? Or: what is the cost of mistakes? If things don’t pan out the way we want them to, how easily could we switch to something else? The more difficult switching back is, the higher the commitment level and the more we need to be sure it’s worth it. This applies both to the internals of the framework and how the code that uses the framework is structured.

Is it easy to do the right thing? This one is straightforward: if it’s easy to do the right thing it’s more likely people will do the right thing and achieve the architecture’s potential more. Conversely, if it’s easy to do the wrong thing, the benefits aren’t realized as much. Especially considering my previous point, if it’s hard to undo bad usage it’s maybe worth going back to the drawing board.

How much support is available? Popular technologies have a lot of online material available for support in the form of Stack Overflow questions and answers, blog posts, videos, open source code + discussions on GitHub, etc. A home-built solution means this knowledge only lives in-house which increases the bus factor. The same is true for very opinionated third-party libraries like RxSwift or The Composable Architecture. I’m a fan of both, but without fully understanding how they’re implemented you’re at the mercy of the developers and contributors of these libraries for years to come.

How much institutional knowledge does it require? Good architectures hide domain complexity for its consumers, and incur the complexity internally. To some extent that’s fine, but if the internals become so complicated that few people know how it works there is again a high bus factor. It can absolutely be worth putting some complexity/boilerplate burden onto feature owners to avoid making complex abstractions that are hard to change in the future once it’s used everywhere and the original developers have left.

How much effort does it take to see 100% adoption? Depending on the size of the existing code base, it could take a long time to get 100% adoption. That can be OK if this is the codebase’s first serious architecture, but if it’s version 5 and some parts of the codebase still use version 1 through 3, it’s probably worth removing those first and reducing lava layers. Even if the change from version 10 to 11 is small and easy, the fragmentation of the codebase inhibits developer productivity. The quicker the migration the better, and if the codebase can safely be migrated through automation that’s the best case outcome.

But the most important one of all: do people actually like the architecture? No one likes working in a codebase where everything is a hassle, the underlying concepts never seem to make sense, abstractions are leaky, and you seem to always have to do work for it instead of it working for you. Those codebases diminish the team’s motivation levels and will affect many of the other points from above.

On the flip side, if people like the proposed patterns, they will put in a lot more work in to use them correctly, try harder to do the right thing, are willing to help others, etc. If not, forcing patterns people don’t like could lead to developer unhappiness and attrition. We have more than a few examples of this at Lyft, where a slightly inferior technical solution is overall much more beneficial because the pattern is a bit simpler to use than the alternative.

Going back to why I started writing this in the first place: in my opinion the question “what counterarguments can I use” is not a great first question to ask when it comes to convincing people your solution is the best one out there. Understanding why people are resistant is key. Sure, some people just don’t like change, but papering over any of the concerns above with a technically superior solution is a recipe for a bunch of barely-adopted technologies in a codebase that’s often worse off than if nothing had been done in the first place.

Third-party libraries are no party at all

2022-07-15T00:00:00-07:00

What better way to end the week than with a hot take?

In my 8 years at Lyft, product managers or engineers have often wanted to add third-party libraries to one of our apps. Sometimes it’s necessary to integrate with a specific vendor (like PayPal), sometimes it’s to avoid having to build something complicated, and sometimes it’s simply to not reinvent the wheel.

While these are generally reasonable considerations, the risks and associated costs of using a third-party library are often overlooked or misunderstood. In some cases the risk is worth it, but to be able to determine that you first need to be able to define that risk accurately. To make that risk assessment more transparent and consistent, we defined a process of things we look at to determine how much risk we're incurring by integrating it and shipping it in one or more production apps.

Risks

Most larger organizations, including ours, have some form of code review as part of their development practices. For those teams, adding a third-party library is equivalent to adding a bunch of unreviewed code written by someone who doesn't work on the team, subverting the standards upheld during code review and shipping code of unknown quality. This introduces risk in how the app runs, long-term development of the app, and, for larger teams, overall business risk.

Runtime risks

Library code generally has the same level of access to system resources as general app code, but they don't necessarily apply the best practices the team put in place for managing these resources. This means they have access to the disk, network, memory, CPU, etc. without any restrictions or limitations, so they can (over)write files to disk, be memory or CPU hogs with unoptimized code, cause dead locks or main thread delays, download (and upload!) tons of data, etc. Worse, they can cause crashes or even crash loops. Twice.

Many of these situations aren't discovered until the app is already available to customers, at which point fixing it requires creating a new build and going through the review process which is often time intensive and costly. The risk can be somewhat mitigated by invoking the library behind a feature flag, but that isn't a silver bullet either (see below).

Development risks

To quote a coworker: "every line of code is a liability", and this is even more true for code you didn't write yourself. Libraries could be slow in adopting new technologies or APIs holding the codebase back, or too fast causing a deployment target that's too high. When Apple and Google introduce new OS versions each year, they often require developers update their code based on changes in their SDKs, and library developers have to follow suit. This requires coordinated efforts, alignment in priorities, and the ability to get the work done in a timely manner.

As the mobile platforms are ever-changing this becomes a continuous, ongoing risk, compounded by the problem that teams and organizations aren't static either. When a library that was integrated by a team that no longer exists needs to be updated, it takes a long time to figure out who should do so. It has proven extremely rare and extremely difficult to remove a library once it's there, so we treat it as a long-term maintenance cost.

Business risks

As I mentioned above, modern OSes make no distinction between app code and library code, so in addition to system resources they also have access to user information. As app developers we're responsible for using that information properly, and any libraries are part of that responsibility.

If the user grants location access to the Lyft app, any third-party library automatically gets access too. They could then upload that data to their own servers, competitors' servers, or who knows where else. This is even more problematic when a library needs a new permission we didn't already have.

Similarly, a system is as secure as its weakest link but if you include unreviewed, unknown code you have no idea how secure it really is. Your well-designed secure coding practices could all be undone by one misbehaving library. The same goes for any policies Apple and Google put in place like "you are not allowed to fingerprint the user".

Mitigating the risk

When evaluating a library for production usage, we ask a few questions to understand the need for the library in the first place.

Can we build this functionality in-house?

In some cases we were able to simply copy/paste the parts of a library we really needed. In more complex scenarios, where a library talked to a custom backend we reverse-engineered that API and built a mini-SDK ourselves (again, only the parts we needed). This is the preferred option 90% of the time, but isn't always feasible when integrating with very specific vendors or requirements.

How many customers benefit from this library?

In one scenario, we were considering adding a very risky library (according to the criteria below) intended for a tiny subset of users while still exposing all of our users to the library. We ran the risk of something going wrong for all our customers in all our markets for a small group of customers we thought would benefit from it.

What transitive dependencies does this library have?

We'll want to evaluate the criteria below for all dependencies of the library as well.

What are the exit criteria?

If integration is successful, is there a path to moving it in-house? If it isn't successful, is there a path to removal?

Evaluation criteria

If at this point the team still wants to integrate the library, we ask them to “score” the library according to a standard set of criteria. The list below is not comprehensive but should give a good indication of the things we look at.

Blocking criteria

These criteria will prevent us from including the library altogether, either technically or by company policy, and need to be resolved before we can move forward:

Too high deployment target/target SDKs. We support major OSes going back at least 4 years so third-party libraries have to support at least that many too.
Improper/missing LICENSE. We bundle license files with the apps to make sure we can legally use the code and attribute it to the license holders.
No conflicting transitive dependencies. A library can't have a transitive dependency we already include but at a different version.
Does not display its own UI. We put great care in making our products look as uniform as possible, custom UIs are a detriment to that.
Does not use private APIs. We are not willing to risk app rejection over the use of private APIs.

Major concerns

Closed source. Access to the source means we can pick and choose which parts of a library we want to include and how to bundle that source with the rest of the app. A closed source, binary distribution is much more difficult for us to integrate.
Builds with warnings. We have "warnings as errors" enabled, and a library with build warnings is a decent indication of the overall quality of the library.
Poor documentation. We look for high quality inline docstrings, external "how to use" documentation, and meaningful change logs.
Binary size impact. How big is this library? Some libraries provide a lot of functionality of which we only need a fraction. Especially without source access it's often an all-or-nothing situation.
External network traffic. A library that communicates with upstream servers/endpoints we have no control over could take the entire app down when the server is down, bad data is sent back, etc. This also has the same privacy implications I mentioned above.
Technical support. When things don't work as they should we need to be able to report/escalate issues and get them fixed in a reasonable amount of time. Open source projects are often run by volunteers and usually can't commit to timelines, but at least we could make changes ourselves. This is impossible without source access.
Inability to disable. While most libraries specifically require us to initialize it, some are more "proactive" in their instantiation and will perform work themselves without us ever calling into it. This means when the library causes issues we have no option to turn it off through feature flags or other mechanisms.

We assign point values to all these (and a few others) criteria and ask engineers to tally those up for the library they want to include. While low scores aren't hard-rejected by default, we often ask for more justification to move forward.

Final notes

While this process may seem very strict and the potential risk hypothetical in many cases, we have actual, real examples of every scenario I described in this blog post. Having the evaluations written down and publicly available also helps in conveying relative risk to people unfamiliar with how mobile platforms works and demonstrating we're not arbitrarily evaluating the risks.

Also, I don't want to claim every third-party library is inherently bad. We actually use quite a few at Lyft: RxSwift and RxJava, Bugsnag's SDK, Google Maps, Tensorflow, and a few smaller ones for very specific use cases. But all of these are either well-vetted, or we've decided the risk is worth the benefit while actually having a clear idea of what those risks and benefits really are.

Lastly, as a developer pro-tip: always create your own abstractions on top of the library's APIs and never call their APIs directly. This makes it much easier to swap (or remove) underlying libraries in the future, again mitigating some risk associated with long-term development.

Update (February 2026)

The industry has changed a ton over the years but this topic is still very much relevant. Many vendors have decided to write their own SDKs which are difficult to avoid, and I don't think writing an in-house SDK for a third-party vendor really caught on. The growth of Apple's platforms (hardware capabilities, OSes, Swift and Xcode versions, etc.) and associated complexity make some of these SDKs also inherently more complex and buggier.

Fortunately, LLMs have shifted the buy vs build decision more in the direction of build, and Apple's investment in modern/capable APIs and privacy manifests made it easier to opt for them than introducing another dependency. More tooling is available to monitor dependencies and keeping them up to date.

I don't think companies have become more thoughtful about the risks they take on with third-party dependencies, but platform, tooling, and workflow improvements at least make it a little bit easier to choose which vendor (be it first, second, or third-party) suits them best.

iOS Architecture at Lyft

2021-10-14T00:00:00-07:00

June 30, 2014 was my first day at Lyft as the first iOS hire on the ~3 person team. The app was written in Objective-C, and the architecture was a 5000-line nested switch statement.

Since then, the team has grown to about 70 people and the codebase to 1.5M lines of code. This required some major changes to how we architect our code, and since it had been a while since we've given an update like this, now seems as good a time as any.

Requirements

The effort to overhaul and modernize the architecture began around mid-2017. We started to reach the limits of the patterns we established in the 2015 rewrite of the app, and it was clear the codebase and the team would continue to grow and probably more rapidly than it had in the past.

The primary problems that the lack of a more mature architecture presented and that we wanted to solve were:

Isolation: Features were heavily intertwined, which made it difficult to safely make changes
Testability: We were still mostly following MVC with view controllers being the main source of business logic which made it difficult to test that logic
State management: The navigation in most of our app relied on local + server state, which grew with the number of features. How and when state changed then became too difficult to manage.

There was not going to be one solution that would solve all of this inherently, but over the course of a few years we developed a number of processes and technical solutions to reduce these problems.

Modules

First, to provide better feature separation, we introduced modules. Every feature had its own module, with its own test suite, that could be developed in isolation from other modules. This forced us to think more about public APIs and hiding implementation details behind them. Compile times improved, and it required much less collaboration with other teams to make changes.

We also introduced an ownership model that ensured each module has at least one team that's responsible for that module's tech debt, documentation, etc.

Module types

After fully modularizing the app and having 700 modules worth of code, we took this a step further and introduced a number of module types that each module would follow.

UI modules only contain UI elements (views, view controllers)
Flow modules contain routing infrastructure
Service modules contain code to interact with endpoints related to the feature's functionality
Logic modules contain pure business logic, data transformations, etc.

Breaking modules down this way enabled us to implement dependency validators: we can validate that certain modules can't depend on others. For example, a logic module can't depend on a UI module, and a Service module can't import UIKit.

This module structure also prevents complicated circular dependencies, e.g. a Coupons module depending on Payments and vice versa. Instead, the Payments module can now import CouponsUI without needing to import the full Coupons feature. It's led to micromodules in some areas, but we've generally been able to provide good tooling to make this easier to deal with.

All in all we now have almost 2000 modules total for all Lyft apps.

Dependency Injection

Module types solved many of our dependency tree problems at the module level, but we also needed something more scalable than singletons at the code level.

For that we've built a lightweight dependency injection framework which we detailed in a SLUG talk. It resembles a service locator pattern, with a basic dictionary mapping protocols to instantiations:

let getNetworkCommunicator: NetworkCommunicating =
    bind(NetworkCommunicating.self, to: { NetworkCommunicator() })

The implementation of bind() doesn't immediately return NetworkCommunicator, but requires the object be mocked if we're in a testing environment:

let productionInstantiators: [ObjectIdentifier: () -> Any] = [:]
let mockedInstantiators: [ObjectIdentifier: () -> Any] = [:]

func bind<T>(protocol: T.Type, instantiator: () -> T) -> T {
    let identifier = ObjectIdentifier(T.self)

    if NSClassFromString("XCTestCase") == nil {
        return productionInstantiators[identifier] ?? instantiator()
    } else {
        return mockedInstantiators[identifier]!
    }
}

In tests, the mock is required or the test will crash:

final class NetworkingTests: XCTestCase {
    private var communicator = MockNetworkCommunicator()

    func testNetworkCommunications() {
        mock(NetworkCommunicating.self) { self.communicator }

        // ...
    }
}

This brings two benefits:

It forces developers to mock objects in tests, avoiding production side effects like making network requests
It provided a gradual adoption path rather than updating the entire app at once through some more advanced system

Although this framework has some of the same problems as other Service Locator implementations, it works well enough for us and the limitations are generally acceptable.

Flows

Flows, inspired by Square's Workflow, are the backbone of all Lyft apps. Flows define the navigation rules around a number of related screens the user can navigate to. The term flow was already common in everyday communications ("after finishing the in-ride flow we present the user with the payments flow") so this terminology mapped nicely to familiar terminology.

Flows rely on state-driven routers that can either show a screen, or route to other routers that driven by different state. This makes them easy to compose, which promoted the goal of feature isolation.

At the core of flows lies the Routable protocol:

protocol Routable {
    let viewController: UIViewController
}

It just has to be able to produce a view controller. The (simplified) router part of a flow is implemented like this:

final class Router<State> {
    private let routes: [(condition: (State) -> Bool, routable: Routable?)]

    func addRoute(routable: Routable?, _ condition: @escaping (State) -> Bool) {
        self.routes.append((condition, routable))
    }

    func route(for state: State) -> Routable? {
        self.routes.first { $0.condition(state) }
    }
}

In other words: it takes a bunch of rules where if the condition is true (accepting the flow's state as input) it provides a Routable. Each flow defines its own possible routes and matches those to a Routable:

struct OnboardingState {
    let phoneNumber: String?
    let verificationCode: String?
    let email: String?
}

final class OnboardingFlow {
    private let router = Router<OnboardingState>
    private let state = OnboardingState()

    init() {
        self.router.addRoute({ $0.phoneNumber == nil }, EnterPhoneNumberViewController())
        self.router.addRoute({ $0.verificationCode == nil }, VerifyPhoneViewController())
        self.router.addRoute({ $0.email == nil }, EnterEmailViewController())

        // If all login details are provided, return  `nil` to indicate this flow has
        // no (other) Routable to provide and should be exited
        self.router.addRoute({ _ in }, nil)
    }

    func currentRoutable() -> Routable {
        return self.router.route(for: state)
    }
}

We're then composing flows by adding Routable conformance to each flow and have it provide a view controller, adding its current Routables view controller as a child:

extension Flow: Routable {
    var rootViewController: UIViewController {
        let parent = UIViewController()
        parent.addChild(self.currentRoutable().viewController)
        return parent
    }
}

Now a flow can also route to another flow by adding an entry to its router:

self.router.addRoute({ $0.needsOnboarding }, OnboardingFlow())

This pattern could let you build entire trees of flows:

When we first conceptualized flows we imagined having a tree of about 20 flows total; today we have more than 80. Flows have become the "unit of development" of our apps: developers no longer need to care about the full application or a single module, but can build an ad-hoc app with just the flow they're working on.

Plugins

Although flows simplify state management and navigation, the logic of the individual screens within a flow could still be very intertwined. To mitigate that problem, we've introduced plugins. Plugins allow for attaching functionality to a flow without the flow even knowing that the plugin exists.

For example, to add more screens to the OnboardingFlow from above, we can expose a method on it that would call into its router:

extension OnboardingFlow {
    public func addRoutingPlugin(
        routable: Routable?,
        _ condition: @escaping (OnboardingState) -> Bool)
    {
        self.router.addRoute((condition, routable))
    }
}

Since this method is public, any plugin that imports it can add a new screen. The flow doesn't know anything about this plugin, so the entire dependency tree is inverted with plugins. Instead of a flow depending on all the functionalities of all of its plugins, it provides a simple interface that lets plugins extend this functionality in isolation by having them depend on the flow.

Since all Lyft apps operate on a tree of flows, the overall dependency graph changes from a tree shape to a "bubble" shape:

This setup provides feature isolation at the compiler level which makes it much harder to accidentally intertwine features. Each plugin also has its own feature flag, making it very easy to disable a feature if necessary.

In addition to routing plugins, we also provide interfaces to add additional views to any view controller, deep link plugins to deep link to any arbitrary part of the app, list plugins to build lists with custom content, and a few others very unique to Lyft's use cases.

Unidirectional Data Flow

More recently we introduced a redux-like unidirectional data flow (UDF) for screens and views within flows. Flows were optimized for state management within a collection of screens, the UDF brings the same benefits we saw there to individual screens.

A typical redux implementation has state flowing into the UI and actions that modify state coming out of the UI. Influenced by The Composable Architecture, our implementation of redux actions also includes executing side effects to interact with the environment (network, disk, notifications, etc.).

Declarative UI

In 2018, we began building out our Design System. At the time, it was a layer on top of UIKit, often with a slightly modernized API, that would provide UI elements with common defaults like fonts, colors, icons, dimensions, etc.

When Apple introduced SwiftUI in mid-2019, it required a deployment target of iOS 13. At the time, we still supported iOS 10 and even today we still support iOS 12 so we still can't use it.

However, we did write an internal library called DeclarativeUI, which provides the same declarative APIs that SwiftUI brings but leveraging the Design System we had already built. Even better, we've built binding conveniences into both DeclarativeUI and our UDF Store types to make them work together seamlessly:

import DeclarativeUI
import Unidirectional

final class QuestionView: DeclarativeUI.View {
    private let viewStore: Store<QuestionState>

    init(store: Store<QuestionState>) {
        self.viewStore = store
    }

    var body: DeclarativeUI.View {
        return VStackView(spacing: .three) {
            HeaderView(store: self.store)
            Label(text: viewStore.bind(\.header))
                .textStyle(.titleF1)
                .textAlignment(.center)
                .lineLimit(nil)
                .accessibility(postScreenChanged: viewStore.bind(\.header))
            VStackView(viewStore.bind(\.choices), spacing: .two) { choice in
                TwoChoiceButton(choice: choice).onEvent(
                    .touchUpInside,
                    action: viewStore.send(.choiseSelected(index: choice.index)))
            }
            .hidden(viewStore.bind(\.choices.isEmpty))

            if viewStore.currentState.model.usesButtonToIncrementQuestion {
                NextQuestionButton(store: self.store)
                    .hidden(viewStore.bind(\.choices.isEmpty))
            }
        }
    }
}

Putting it all together

All these technologies combined make for a completely different developer experience now than five years ago. Doing the right thing is easy, doing the wrong thing is difficult. Features are isolated from each other, and even feature components are separated from each other in different modules.

Testing was never easier: unit tests for modules with pure business logic, snapshot tests for UI modules, and for integration tests it takes little effort to sping up a standalone app with just the flow you're interested in.

State is easy to track with debug conveniences built into the architectures, building UI is more enjoyable than it was with plain UIKit, and adding a feature from 1 app into another is often just a matter of attaching the plugin to a second flow without detangling it from all other features on that screen.

It's amazing to look back at where the codebase started some 6 years ago, and where it is now. Who knows where it will be in another 6 years!

Note: If you're interested in hearing more, I also talked about many of these technologies on the Lyft Mobile Podcast!

Re-binding self: the debugger's break(ing) point

2018-08-08T00:00:00-07:00

Update 07-29-2019: The bug described below is fixed in Xcode 11 so this blog post has become irrelevant. I'm leaving it up for historical purposes.

For the Objective-C veterans in the audience, the strong-self-weak-self dance is a practice mastered early on and one that is used very frequently. There are a lot of different incantations, but the most basic one goes something like this:

__weak typeof(self) weakSelf = self;
dispatch_group_async(dispatch_get_main_queue(), ^{
    [weakSelf doSomething];
});

Then, if you needed a strong reference to self again inside the block, you'd change it to this:

__weak typeof(self) weakSelf = self;
dispatch_group_async(dispatch_get_main_queue(), ^{
    typeof(weakSelf) strongSelf = weakSelf;
    [strongSelf.someOtherObject doSomethingWith:strongSelf];
});

Fortunately, this was much easier on day 1 of Swift when using the [weak self] directive:

DispatchQueue.main.async { [weak self] in
    if let strongSelf = self {
        strongSelf.someOtherObject.doSomething(with: strongSelf)
    }
}

self is now weak inside the closure, making it an optional. Unwrapping it into strongSelf makes it a non-optional while still avoiding a retain cycle. It doesn't feel very Swifty, but it's not terrible.

More recently, it's become known that Swift supports re-binding self if you wrap it in backticks. That makes for an arguably much nicer syntax:

DispatchQueue.main.async { [weak self] in
    guard let `self` = self else { return }
    self.someOtherObject.doSomething(with: self)
}

This was long considered, and confirmed to be, a hack that worked due to a bug in the compiler, but since it worked and there weren't plans to remove it, people (including us at Lyft) started treating it as a feature.

However, there is one big caveat: the debugger is entirely hosed for anything you do in that closure. Ever seen an error like this in your Xcode console?

error: warning: <EXPR>:12:9: warning: initialization of variable '$__lldb_error_result' was never used; consider replacing with assignment to '_' or removing it
    var $__lldb_error_result = __lldb_tmp_error
        ~~~~^~~~~~~~~~~~~~~~~~~~

That's because self was re-bound. This is easy to reproduce: create a new Xcode project and add the following snippet to viewDidLoad():

DispatchQueue.main.async { [weak self] in
    guard let `self` = self else { return }

    let description = self.description
    print(description) // set a breakpoint here
}

When the breakpoint hits, execute (lldb) po description and you'll see the error from above. Note that you're not even using self - merely re-binding it makes the debugger entirely useless inside that scope.

People with way more knowledge of LLDB than I do can explain this in more detail (and have), but the gist is that the debugger doesn't like self's type changing. At the beginning of the closure scope, the debugging context assumes that self's type is Optional, but it is then re-bound to a non-optional, which the debugger doesn't know how to handle. It's actually pretty surprising the compiler supports changing a variable's type at all.

Because of this problem, at Lyft we have decided to eliminate this pattern entirely in our codebases, and instead re-bind self to a variable named this.

If you do continue to use this pattern, note that in a discussion on the Swift forums many people agreed that re-binding self should be supported by the language without the need for backticks. The pull request was merged shortly after and with the release of Swift 4.2 in the fall, you'll be able to use guard let self = self else { return } (at the cost of losing debugging capabilities!)

Using Interface Builder at Lyft

2017-03-06T00:00:00-08:00

Last week people realized that Xcode 8.3 by default uses storyboards in new projects without a checkbox to turn this off. This of course sparked the Interface Builder vs. programmatic UI discussion again, so I wanted to give some insight in our experience using Interface Builder in building the Lyft app. This is not intended as hard "you should also use Interface Builder" advice, but rather to show that IB can work at a larger scale.

First, some stats about the Lyft app:

40 storyboards
100 XIB files
150 view controllers
20 people on the iOS team with occasional outside contributors

With the rewrite of our app we moved to using IB for about 95% of our UI.

The #1 complaint about using Interface Builder for a project with more than 1 developer is that it's impossible to resolve merge conflicts. We never have this problem. Everybody on the team can attest that they have never run into major conflicts they couldn't reasonably resolve.

With that concern out of the way, what about some of the other common criticisms Interface Builder regularly gets?

Improving the workflow

Out of the box, IB has a number of shortcomings that could make working with it more painful than it needs to be. For example, referencing IB objects from code still can only be done with string identifiers. There is also no easy way to embed custom views (designed in IB) in other custom views.

Over time we have improved the workflow for our developers to mitigate some of these shortcomings, either by writing some tools or by writing a little bit of code that can be used project-wide.

storyboarder script

To solve the issue of stringly-typed view controller identifiers, we wrote a script that, just before compiling the app, generates a struct with static properties that exposes all view controllers from the app in a strongly-typed manner. This means that now we can instantiate a view controller in code like this:

let viewController = Onboarding.SignUp.instantiate()

Not only is viewController now guaranteed to be there at runtime (if something is wrong in the setup of IB the code won't even compile), but it's also recognized as a SignUpViewController and not a generic UIViewController.

Strongly-typed segues

All our view controllers have a base view controller named ViewController. This base controller implements prepare(for:sender:) like this:

open override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
    guard let identifier = segue.identifier else {
        return
    }

    let segueName = identifier.firstLetterUpperString()
    let selector = Selector("prepareFor\(segueName):sender:")
    if self.responds(to: selector) {
        self.perform(selector, with: segue.destination, with: sender)
    }
}

This means that a view controller that has a segue to TermsOfServiceViewController can now do this:

@objc
private func prepareForTermsOfService(_ viewController: TermsOfServiceViewController, sender: Any?) {
    viewController.onTermsAccepted = { [weak self] self?.proceed() }
}

We no longer have to implement prepareForSegue and then switch on the segue's identifier or destination controller, but we can implement a separate method for every segue from this view controller instead which makes the code much more readable.

`NibView`

We wrote a NibView class to make it more convenient to embed custom views in other views from IB. We marked this class with @IBDesignable so that it knows to render itself in IB. All we have to do is drag out a regular UIView from the object library and change its class. If there is a XIB with the same name as the class, NibView will automatically instantiate it and render it in the canvas at design time and on screen at runtime.

Every standalone view we design in IB (which effectively means every view in our app) inherits from NibView so we can have an "unlimited" number of nested views show up and see the final result.

Basic `@IBDesignable`s

Since a lot of our views have corner radii and borders, we have created this UIView extension:

public extension UIView {
    @IBInspectable public var cornerRadius: CGFloat {
        get { return self.layer.cornerRadius }
        set { self.layer.cornerRadius = newValue }
    }

    @IBInspectable public var borderWidth: CGFloat {
        get { return self.layer.borderWidth }
        set { self.layer.borderWidth = newValue }
    }

    @IBInspectable public var borderColor: UIColor {
        get { return UIColor(cgColor: self.layer.borderColor!) }
        set { self.layer.borderColor = newValue.cgColor }
    }
}

This lets us easily set these properties on any view (including the ones from UIKit) from Interface Builder.

Linter

We wrote a linter to make sure views are not misplaced, have accessibility labels, trait variations are disabled (since we only officially support portrait mode on iPhone), etc.

ibunfuck

A bug impacting developers that use Interface Builder on both Retina and non-Retina screens (which at Lyft is every developer) has caused us enough grief to write ibunfuck - a tool to remove unwanted changes from IB files.

Color palette

We created a custom color palette with the commonly used colors in our app so it's easy to select these colors when building a new UI. The color names in the palette follow the same names designers use when they give us new designs, so it's easy to refer to and use without having to copy RGB or hex values.

Our approach

In addition to these tools and project-level improvements, we have a number of "rules" around our use of IB to keep things sane:

Do as little as possible in code, do as much as possible in IB. That means fonts, colors, images, and other properties should not be set in code if they don't change at runtime.
Use @IBInspectable on custom views whenever possible.
Create as much Auto Layout constraints in IB as possible. Sometimes this means being clever with how we create constraints so that at runtime we need very little code to manipulate a layout.
If we do need to create constraints in code, we don't use the NSLayoutConstraint (or NSLayoutAnchor) methods directly. Instead we use SnapKit's convenience methods.
We still manually push and present view controllers where possible. Even though we have created some niceties around using segues, it's still easy to accidentally remove one and not find out about it until runtime.
We tend to create a new storyboard when we recognize a common theme in related view controllers. Just as with code, we don't want bloated storyboards with all kinds of unrelated things in there. Most of our storyboards have fewer than 10 scenes.
Our outlets are defined carefully.

Of course, even with these improvements everything is not peaches and cream. There are definitely still problems. New versions of Xcode often change the XML representation which leads to a noisy diff. Some properties can simply not be set in IB meaning we're forced to break our "do everything in IB" rule. Interface Builder has bugs we can't always work around.

However, with our improved infrastructure and the points from above, we are happy with how IB works for us. We don't have to write tons of Auto Layout code (which would be incredibly painful due to the nature of our UIs), get a visual representation of how a view looks without having to run the app after every minor change, and maybe one day we can get our designers make changes to our UI without developers' help.

Keeping the Lyft iOS App Accessible

2017-01-18T00:00:00-08:00

Note

This article was written by me but originally published on the Lyft Engineering Blog.

At Lyft we’re in a unique position: every day we work on an app that affects people in the real, physical world — not just the digital one. This has an especially large impact on visually impaired users, because our app is easier to use than the real world alternatives — navigating a train station or queueing up at a taxi stand. Lyft aims to make a product that is accessible and easy to use for all of our users.

Accessibility at Lyft

If an app uses Apple’s standard controls and UI elements, it will likely already work well with VoiceOver; however, Lyft’s UI deviates enough from standard controls such that we don’t get that benefit out of the box. Another complication is that many portions of the app are controlled by the server, including a lot of the text for buttons and labels. Making these UI elements compatible with VoiceOver often requires tweaking them manually, even if we use native controls.

Since we try to keep all of our UI-related code in Interface Builder, and VoiceOver is just another form of UI, we have written a simple UIView extension that allows us to enable accessibility on most of our UI directly from Interface Builder. In this extension, we add 2 properties to UIView:

accessibilitySources: An IBOutletCollection of UIViews
accessibilityFormat: a simple string that represents the format of the accessibility label, which is subsequently passed to String(format:). Every occurrence of %@ in this string will be replaced with the next element of the accessibilitySources, and [self] will automatically be replaced with the current view’s accessibilityLabel.

We can ctrl + drag UI elements into the accessibilitySources, and by marking accessibilityFormat with @IBInspectable we can specify the string and the sources all from Interface Builder, keeping the code clean and to the point.

For example, we have an accessibility format on the UILabel that displays the selected ride mode:

[self] is replaced by the accessibility label, which for UILabels is the text of the label itself. %@ is replaced by an accessibility source, which we can set up like this:

By disabling the accessibility label for the subtitle, the top label’s accessibility label will read “Selected ride mode: Line. Carpool, 2 people maximum.” without touching any code at all.

Changing the process

As we ramped up our VoiceOver efforts, we wanted to assess whether the changes we made had a meaningful impact to end-users. As developers, we’re too familiar with our own apps to make an honest call about their usability, and when it comes to visual impairment, even a standard usability review could brush over things that would be challenging to a blind or a visually impaired user.

This is why we’re working with a dedicated accessibility expert, himself a native VoiceOver user, to constantly validate our work. All the feedback we’ve been getting from VoiceOver users have further motivated our investment in accessibility. We have optimized VoiceOver in the main flows of our app, and we run weekly regression tests to ensure consistency and stability. Our VoiceOver user also works directly with QA engineers, to let them know what he is looking for and what is missing.

Over the last few months, we have made many improvements in various parts of our app, but also in how seriously we take VoiceOver-related bugs: we block new releases if VoiceOver users experience bugs when going through a ride. All new features are expected to be optimized for VoiceOver from the start, and we are working hard to optimize existing features as well.

We think of accessibility as part of the user interface, just like labels, buttons, and text fields. By having our developers implement support for VoiceOver as part of the initial feature, our visually impaired users will be able to use these features as easily as our regular users.

Silencing NSLog

2016-08-01T00:00:00-07:00

When your app has a lot of third-party dependencies, what often happens is that those libraries log a bunch of things to the Xcode console to help their own debugging. Unfortunately, a lot of these logs are useful only to the developers of the library, but not the developers of apps that integrate the library. For example, they log things like <SomeLibrary> (version 1.2.3) initialized, or <SomeLibrary> started <primary functionality>, sometimes with a long list of parameters or input sources that are irrelevant to you.

Finding your own log statements in a jungle of other logs can then be very difficult and adds to the frustration of not being able to work the debugger as you would like to.

If a library is open source you can suggest a change by removing the log or otherwise make it less obtrusive. However, if your change gets accepted at all, that doesn't solve the immediate problem of being able to debug your own code using the console.

Meet _NSSetLogCStringFunction(). This C function has been around in Foundation for a long time, and while there is some documentation on it, it's still a private method. However, that doesn't mean you can't use it in debug mode when your logs are the most valuable!

In short, this function lets you set a function pointer that can log C strings, which NSLog then uses instead of the normal implementation. You can do this in two ways.

The first one is by adding this to your Objective-C bridging header:

#if DEBUG
extern void _NSSetLogCStringFunction(void(*)(const char*, unsigned, BOOL));
#endif

and then use it like this:

func disableNSLog() {
#if DEBUG
    _NSSetLogCStringFunction { message, _, _ in
        // no actual logging, message just gets lost
    }
#endif

If you want to stick to pure Swift, you can do so by adding this to your code somewhere:

@_silgen_name("_NSSetLogCStringFunction")
func setNSLogFunction(_: @convention(c) (UnsafePointer<Int8>, UInt32, ObjCBool) -> Void)

and then use it like this:

func disableNSLog() {
#if DEBUG
    setNSLogFunction { message, _, _ in
        // no actual logging, message just gets lost
    }
#endif
}

Obviously, you can do anything you want inside the closure, including writing to a file, annotating the message with a date/time, passing it to your custom logging library, etc.

One downside of this is that Apple's frameworks use NSLog extensively as well, so in the above case of completely disabling logging, helpful messages get lost as well. You won't be able to use NSLog yourself either anymore, so I suggest you use print() or a custom logging framework that's not NSLog based.

If you're not afraid of doing (more) horrible things in your codebase, you can avoid losing Apple frameworks' messages by parsing the stack trace and looking at the framework that called this function and see if it's something you want to let through:

func disableNSLog() {
#if DEBUG
    _NSSetLogCStringFunction { message, _, _ in
        // message is of type UnsafePointer<Int8> so first see if we can get a
        // normal String from that. Safety first!

        guard let message = String.fromCString(message) else {
            return
        }

        let callStack = NSThread.callStackSymbols()
        let sourceString = callStack[6]
        let separatorSet = NSCharacterSet(charactersInString: " -[]+?.,")
        let stackFrame = sourceString.componentsSeparatedByCharactersInSet(separatorSet)
        let frameworkName = stackFrame[3]

        if frameworkName == "UIKit" || frameworkName == "Foundation" {
            MyCustomLogger.log(message)
        }
    }
#endif
}

This discards all logs, except if they're coming from UIKit or Foundation. The stack trace parsing is by no means safe (its format could change, for example), but since it's wrapped in #if DEBUG directives it won't mess with anything in the App Store build.

Note that static libraries are part of your main app's target, which means you have to filter out logs from your own target to hide those.

You could even go a bit farther and check the message for keywords you like or don't like and make a decision on whether you want to log or not. Keep in mind, though, that any work you do here needs to be fast as you don't always know just how much is being logged.

Outlets: strong! or weak?

2016-03-21T00:00:00-07:00

There are a lot of styles out there when it comes to using Interface Builder outlets in Swift. Even Apple's documentation and sample code isn't always consistent. The most common one, the one Apple uses in its sample code, follows this pattern:

@IBOutlet private weak var someLabel: UILabel!

Let's break this down by keyword:

@IBOutlet makes Interface Builder recognize the outlet
private ensures the outlet isn't accessed outside the current class
weak is used because in most situations the owner of the outlet isn't the same as the owner of the view. For example, a view controller doesn't own someLabel - the view controller's view does.
var because outlets are, by definition, set after initialization
someLabel: UILabel is just an example, this applies to outlets of any kind
!, or the implicitly unwrapped optional, is convenient because you don't have to litter your code with ? and if lets (or just !) everywhere

While at first this seems like a solid approach, at Lyft we quickly realized we weren't fans of this one-size-fits-all way of defining outlets. Instead, the behavior and consequences of the different elements should define the outlet's exact syntax, just like any other variable.

For example, if there is a code path that removes an outlet from its superview, or the outlet is (intentionally) not hooked up in the storyboard, it needs to be an optional because the outlet is not guaranteed to be there when it's accessed.

@IBOutlet private var someLabel: UILabel?

If there is no code path that re-adds the outlet to the view hierarchy, it would also be good to make it weak to not hold on to it unnecessarily when it gets removed:

@IBOutlet private weak var someLabel: UILabel?

This ensures that if the label is removed from the superview, it's not being kept in memory by the strong reference in the view controller. In the most common case, where there is an outlet that will always be there, a strong, implicitly unwrapped optional is appropriate:

@IBOutlet private var someLabel: UILabel!

The outlet isn't weak in case the code ever changes so that there is a code path that removes the view from the view hierarchy but you forget to update the optionality of the property. The object will stay in memory and using it won't crash your app.

These examples all follow 3 simple rules:

! needs a guarantee that the view exists, so always use strong to provide that guarantee
If it's possible the view isn't part of the view hierarchy, use ? and appropriate optional-handling (optional binding/chaining) for safety
If you don't need a view anymore after removing it from the view hierarchy, use weak so it gets removed from memory.

Applying these three rules means you properly use the optional semantics. After all, using ! for a view that may not exist is no different than defining any other property as an implicitly unwrapped optional that may not exist.

@objc class prefixes fixed in Xcode 7 beta 4

2015-07-23T00:00:00-07:00

Back in December I wrote about what I thought was a bug in the Swift compiler that would expose the wrong class name for a Swift class in Objective-C. I then later found out everything worked as intended and I had just misunderstood what @objc() exactly did. Apparently it was never supposed to modify the class name at compile time, but only at runtime.

I'm sure changing the class name just at runtime has its uses, but in my opinion, this would be most helpful if it also affected the compile time name of Objective-C classes. It allows you to namespace your classes in Objective-C using your three-letter prefix, without needing that prefix in Swift because you could namespace by way of modules.

And fortunately, in Xcode 7 beta 4, they have actually modified the @objc() notation so that it does do this. For example, if I have a Swift module that I want others to be able to use in their Objective-C codebase, I could write a class like this:

@objc(SDCMyClass)
class MyClass: NSObject {
    // ...
}

And in MyProject-Swift.h the Objective-C class is defined as:

SWIFT_CLASS_NAMED("MyClass")
@interface SDCMyClass : NSObject
- (nonnull instancetype)init OBJC_DESIGNATED_INITIALIZER;
@end

In Swift I can simply use the class as MyClass, but in Objective-C its name is SDCMyClass, which ensures it doesn't collide with other classes named MyClass. Needless to say, I'm very happy they changed this behavior, it makes much more sense now.

The power of UIStackView

2015-06-13T00:00:00-07:00

I was in the audience for "Implementing UI Designs in Interface Builder" at WWDC, where Apple touted UIStackView as a new, better way to lay out your views that in a lot of cases didn't require Auto Layout.

While the presentation looked good, I wasn't quite sure this solved a real problem, as the required constraints weren't too complicated to build in the first pace. However, after I found some time to play around with UIStackView, I'm convinced. This view is very, very powerful and can make building common UIs a lot simpler. Take, for example, a number grid:

[1] [2] [3]
[4] [5] [6]
[7] [8] [9]
    [0]

It would take a while to build this kind of UI in Auto Layout. You would have to create constraints between individual labels, make the labels the same size everywhere, make the spacing between all the labels equal, and avoid hardcoding any numbers to keep the whole thing adaptive. This can be a tedious process in Interface Builder, but imagine you're building this in code. It would take forever, especially after debugging your UI.

With UIStackView, doing all of this takes about 30 seconds. After dragging out all the labels, you just need to embed every row in its own stack view. Set the distribution (in code that's UIStackViewDistribution) for these stack views to "fill equally" (.FillEqually), then embed all four stack views in their own stack view.

The top-level, vertical stack view should get top/leading/trailing/bottom space to its superview (or the layout guides), the 4 horizontal stack views an "equal width" constraint to their superview. Finally, center the text of the individual labels (you can select all labels at once and do this with 1 action). Done - that's it.

But it gets better. Say you want to conditionally show or hide the 0 label at the bottom. I don't know why you would want that, but just go with it 😛

To do this, all you have to is toggle the hidden property of that label. The containing stack view will automatically reposition its subviews. If you put that line in an animation block, it will reposition its subviews in an animated fashion.

That last part is a very welcome feature for developers that work with a lot of dynamic views. Instead of creating redundant constraints with lower priorities, removing views from their view hierarchies, and re-adding the view and all its constraints if the new views needs to be re-shown, you can simply toggle hidden instead.

As more people get their hands on UIStackView I'm sure it will show off more of its powers, but needless to say I'm sold. Too bad I can't use it for a while...

@objc creates a wrong class name in Objective-C

2014-12-15T00:00:00-08:00

A few months ago, I decided I'd get started porting SDCAlertView to Swift, but I was only a few minutes in until I ran into a problem I had no idea how to solve: I couldn't get my class names right in both Swift and Objective-C. Even though there are copious amounts of documentation covering the interoperability of Swift and Objective-C, somehow I couldn't get it to work and I brushed it off as me being stupid.

Tonight I tried again, and after some more research it turned out that the behavior I saw was actually a bug in the compiler! I'm surprised that the latest Xcode version is 6.1.1 and that apparently not enough people have run into this problem for Apple to make it a priority.

The bug can easily be reproduced by creating an Objective-C project in Xcode, and then adding the following Swift class:

import UIKit

@objc(SDCMyLabel)
class MyLabel: UILabel {
}

You would expect that, once you import MyProject-Swift.h in your Objective-C class, you could instantiate a class named SDCMyLabel. However, instead, you can only instantiate a class named MyLabel.

I found this very recent Stack Overflow question which pretty much asks the same thing. "milos" gives a great answer by explaining the observed behavior in Xcode 6.0.1, and the expected behavior according to the WWDC session video.

After reading the answer and watching the relevant parts of the vide, I slightly changed my previously-drawn conclusion from "I'm stupid" to "Xcode's stupid" and filed rdar://19261044. If you're running into the same problem, please duplicate and cross your fingers the engineers at the fruit company will fix it soon.

Dev-only iPhones

2014-10-20T00:00:00-07:00

With today's release of iOS 8.1, most app developers are looking at 4 significantly different iOS versions they will be supporting: iOS 7.0, iOS 7.1, iOS 8.0, and iOS 8.1. Factoring in the number of devices (iPhone 4S, iPhone 5, iPhone 5s, iPhone 6, and iPhone 6 Plus) that run these OS versions, there is a grand total of 16 different configurations. That's without even counting the iPhone 5c, which is internally pretty much the same as the 5, or the rumored iOS 8.2 and iOS 8.3 updates.

Assuming an average off-contract price of $400 for these models, that means you're looking at $6,400 for 1 set of iPhones used for development. Creating a universal app? Your total will now exceed $10,000.

So now you have these 16 phones that will in most cases be used for testing maybe a handful of apps, that have chips and software functionality in them that will be used very little (if at all), and will most of the time just sit in some desk drawer with a dead battery. I could think of better ways to spend money.

This problem could have a very simple solution: dev-only iPhones. Remove or disable the cellular chip (you can simulate cellular networks using the Network Link Conditioner), give it an 8GB storage chip, remove apps such as Weather, Stocks, Calculator, Clock, etc., disable the App Store for all but the developer's own apps, allow any supported iOS version to be installed using Xcode, and sell at-cost, but only to developers in the iOS Developer Program.

By disabling cellular and dumbing the OS down to only include parts that developers can interact with, it becomes pretty useless for people who are just trying to look for a sweet deal on an iPhone/iPod touch. The win for developers is that they only need 1 of each device, but they're also cheaper.

You could even take it a step further and set memory, CPU and screen size limits (meaning only use 4" of the available 5.5"), allowing you to simulate an iPhone 5s on an iPhone 6 Plus. Now developers only need to buy the iPhone 6 Plus to be mostly covered, though I'd still recommend also getting an iPhone 5 or iPhone 5c for 32-bit devices.

I may be way off course here due to technical implications or limitations that I'm not aware of. There are also still cases in which you'd need an actual device on the actual software as consumers use it. Developers don't always need to test against every iOS version on every supported iOS device. But for developers who do and don't want to spend the money on all these different devices, a dev-only iPhone may be exactly what they need.

Update (February 2026)

This was never really realistic for a variety of reasons, but I still think the cost of entry for iOS development is unnecessarily high. The simulator is still pretty good and has gotten much better over the years, but entire classes of apps can't be simulated properly. The number of software updates, device matrix, and hardware/software capabilities make dev-only iPhones also not really scalable.

The Apple enthusiasts still get new phones regularly enough that used phones have become cheap enough to cover a bit more of the testing matrix too.

UIMenuController and the responder chain

2014-09-15T00:00:00-07:00

The responder chain is a very important paradigm in the world of iOS development, and not terribly hard to understand. Dozens of articles have been written about it, and with some examples, the concept of finding a responder to a certain event by traversing a chain of potential responders is fairly straight-forward.

But today it completely threw me off. The goal was very simple and has been done many times before: showing a label whose text can be copied to the clipboard. Having never worked with UIMenuController, I fired up Google and of course found an excellent NSHipster article near the top.

I did as the article said. I created my UILabel subclass (only accepting copy: as an action it can perform), added my gesture recognizer, and configured and showed the UIMenuController. It worked, but instead of only showing the Copy menu item, it also showed the Select All item.

Well, that's weird. I implemented canPerformAction:withSender: like this:

- (BOOL)canPerformAction:(SEL)action withSender:(id)sender {
    return action == @selector(copy:);
}

I made sure that this method really only returned YES for the Copy item, proceeded to explicitly return NO for selectAll: and, when that failed as well, even changed the implementation of this method to just return NO for any item. But Select All doesn't take NO for an answer, and it stubbornly showed up anyway! I was baffled and could not get rid of this Select All item.

I did some research, and learned that UIMenuController uses the responder chain to figure out what items to show. Furthermore, the documentation for canPerformAction:withSender: read:

This default implementation of this method returns YES if the responder class implements the requested action and calls the next responder if it does not.

That would explain the problem, if it weren't for the fact that Select All was the only other item that showed. Cut, Paste, Select, etc. did not. What was so special about Select All that no matter what I did, it always decided to make an unwanted appearance?

Finally I saw it. One of the last methods of the view controller that created this label had a method named, you guessed it, selectAll:. I didn't immediately connect the dots, but at least renaming that method to selectAllContacts: (which was a better name for that method anyway) got rid of Select All.

But how? I returned NO from my label's canPerformAction:withSender: for all actions except copy:. This means that for all other actions (see the informal UIResponderStandardEditActions), the next responder in the chain would be called. And (if necessary) the next, and the next.

At some point, my view controller, which participates in the responder chain, became the first responder and returned YES for the selectAll: action, simply because the method was implemented and part of UIResponderStandardEditActions.

So if implementing a method in that protocol is all that's needed to show the corresponding menu item, that would mean that implementing canPerformAction:withSender: in my UILabel subclass was unnecessary. I removed the method altogether and sure enough, the Copy menu item was still there. Problem solved.

Xcode & Objective-C Oddities

2014-08-10T00:00:00-07:00

Any developer that has worked with Xcode to write a little more than just "Hello, World" knows that Xcode and Objective-C have their quirks. Chances are you have heard of @TextFromXcode, the Twitter handle that portrays Xcode as a high school bully in fake text conversations like this:

But it's not always Xcode that makes Apple platform developers sometimes frown and sigh. Sometimes it's the developers themselves, sometimes it's the documentation, and sometimes a hidden gem from within Apple frameworks makes an appearance. I've compiled a short list of things I've encountered. Because it's Sunday and I didn't have anything better to do.

`UIGobblerGestureRecognizer`

Say what? A "gobbler" recognizer? Does it recognize when the user imitates a turkey? Well, maybe, but according to BJ Homer, it is used to avoid recognition of a gesture while animations are in progress. Ah of course! Now the name "gobbler" makes perfect sense! 😶

`UITapAndAHalfRecognizer`

Speaking of gesture recognizers, there's another remarkable one that lives in the private section of UIKit: UITapAndAHalfRecognizer. This is a private subclass of UIGestureRecognizer that records "a tap and a half".

So what does that mean? Does it detect whether the user goes in for a second tap, but never actually touches the screen? Or does the user touch the screen ever so slightly that the second tap can hardly be considered a complete tap? Nope! This recognizer fires when a second tap stays on the screen. Not sure for what functionality Apple needs this, but it's been around since at least iOS 4, so it probably has a purpose.

Naming is hard

There are only two hard things in Computer Science: cache invalidation and naming things.
- Phil Karlton

Naming is hard, but Objective-C developers always say that verbosity is one of Objective-C's strengths because its naming conventions are self-documenting. Normally I'd agree, but in this case, I think Apple may want to consider a different name.

HMCharacteristicValueLockMechanismLastKnownActionUnsecuredUsingPhysicalMovementExterior is a brand new constant in iOS 8 and has got to be one of the longest constants that's available in iOS. Try saying it without taking a breath in the middle.

I found it in the iOS 8 API diffs, but it did make me wonder. What is the longest Objective-C method available in Cocoa Touch? Well, a quick Google search led to a blog post by Stuart Sharpe, who used the Objective-C runtime to generate a list of methods in the iOS 7 SDK.

Turns out, the longest method in the iOS 7 SDK is

+[CUIShapeEffectStack shapeEffectSingleBlurFrom:
                               withInteriorFill:
                                         offset:
                                       blurSize:
                                   innerGlowRed:
                                 innerGlowGreen:
                                  innerGlowBlue:
                               innerGlowOpacity:
                                 innerShadowRed:
                               innerShadowGreen:
                                innerShadowBlue:
                             innerShadowOpacity:
                                   outerGlowRed:
                                 outerGlowGreen:
                                  outerGlowBlue:
                               outerGlowOpacity:
                                 outerShadowRed:
                               outerShadowGreen:
                                outerShadowBlue:
                             outerShadowOpacity:
                            hasInsideShadowBlur:
                           hasOutsideShadowBlur:]

Unless iOS 8 introduces a longer method name, this one takes the cake with 22 arguments and 352 characters. If you have Xcode configured to line-break at 80 characters (yes, some people still do that), this method signature alone, without any arguments, takes up 5 lines.

Another beauty of a method lives in Core Animation and its method signature is

- [CAMediaTimingFunction functionWithControlPoints::::]

::::? Is that even valid syntax? Yes, and you call the method like this:

[CAMediaTimingFunction functionWithControlPoints:0.25 :.50 :0 :1.0];

Was an array really too much to ask...?

`[NSDate nilDate]`

This one has made the rounds throughout the developer community before, but I'm adding it here in case you haven't seen it yet. Try running the following code:

NSCalendar *calendar = [NSCalendar currentCalendar];
[calendar components:NSCalendarUnitYear fromDate:nil toDate:[NSDate date] options:0];

In the console log, you'll find the following output:

*** -[__NSCFCalendar components:fromDate:toDate:options:]: fromDate cannot be nil
I mean really, what do you think that operation is supposed to mean with a nil fromDate?
An exception has been avoided for now.
A few of these errors are going to be reported with this complaint, then further violations will simply silently do whatever random thing results from the nil.

Either a grumpy Apple developer woke up at the wrong side of the bed or has a great sense of humor. In any case, I wouldn't mind if more sarcastic warnings started popping up in Xcode's console.

Defying the Uncertainty Principle in iOS

[I]n 1927, Werner Heisenberg stated that the more precisely the position of some particle is determined, the less precisely its momentum can be known, and vice versa.
Wikipedia

If that's true, and it's fairly safe to assume that it is, I'd avoid using -[CLLocation speed] for apps like radar detectors. I wonder if we're ever going to get a -[CLSpeed location] method, which has a more accurate speed and a less accurate location.

Xcode at it again

Lastly, the following is a screenshot I personally took at work that completely baffled me.

This would not go away, even after cleaning the build folder and rebuilding. In the end I resolved the problem by running

$ git stash
$ git reset --hard HEAD

Then, after a clean build and git stash pop the errors finally went away...

That's just a few things I've found while working with Xcode and Objective-C over the years. If you have more, please share!

Objective-C prefixes: a thing of the past?

2014-07-25T00:00:00-07:00

This past week, there was, again, a lot to do about Objective-C and prefixing. To most iOS developers, the story sounds familiar: one camp is strongly in favor, another camps is strongly against, and a third camp couldn't really care less.

Unless I'm unaware of any other platforms where the discussion was also a hot topic, this time I was at least a little responsible for instigating a debate that will never see a clear winner, with the following tweet:

@bobmccune @invalidname Also no option to enter class prefix anymore, even for Objective-C projects
— Scott Berrevoets (@ScottBerrevoets) July 23, 2014

Let's first clear up that Swift doesn't need to have class prefixes, because it has built-in support for namespacing through modules. From what I read, earlier Xcode 6/Swift betas did not have module support, but at least we know it's coming before 1.0 hits.

However, this doesn't solve any of the problems Objective-C has, and so it was surprising to see this field was removed when creating a new Objective-C project. You can still set this prefix per project after you create it, but since most Xcode templates create source files for you, those files will be created without a prefix.

I noticed the lack of this option, as well as the lack of a file template for Objective-C categories, back in beta 2 and immediately filed two bugs. The missing file template is as of this writing still open, but the class prefix got closed a few days later. Normally, radars aren't known for their wealth of information related to the issue the radar was filed for, but Apple Engineering made an exception this time.

After much deliberation, engineering has removed this feature.

This was removed intentionally. We are no longer encouraging the use of prefixes for app code, and for frameworks, you can create a prefix in the Project Inspector after creating the project.

Okay, so no more prefixes for app code. Didn't see that coming. Does Apple now encourage developers to start making extensive use of frameworks?

No. If you want to use a prefix, you can set one in the project inspector. Especially for frameworks, this is easy since the template creates no source files that should be prefixed. If you really want to prefix the classes in your main app binary, you might need to rename the few that are created initially, but the recommendation is generally that frameworks should use prefixes (in Obj-C, not in Swift) to avoid namespace issues, and apps generally don't need to.

The key part here is in the last few words: "don't need to".

Third-party libraries, especially frameworks that don't ship with the source code, need a prefix, because the chances of naming collisions with other code or, even worse, other libraries is significant. Users of the libraries can't (and even if they can, are likely not willing to) change the name of your classes because they collide with some other library's code.

"App code" on the other hand, is very unique to one particular app. It contains the UI and some of the business logic that puts your app together. Most view controllers, for example, are app code. App code is not likely to be reused, because it's very specific in what it does and is therefore unlikely to collide with other classes (assuming you name your classes well). If you think "well, this functionality may be reused in some other project", it's a great candidate for a framework!

I was always a big fan of the class prefixes, and while it was sometimes hard to come up with what prefix to use, I've come to actually like how they look, too. Classes that don't have a prefix feel like they're missing something. However, the guideline of "prefix frameworks, not app code" does make sense, so I will start using that from now on as well.

Scott Berrevoets - blog

Review your own AI-generated code

All in on Interface Builder: 10 years later

Scaling my git/tmux workflows for AI agents

Localization troubles with Swift PM

Managing code deprecations on iOS

Flywheel of tech debt

Art of the state

Prefer value types

Avoid singletons

Separate DTOs from domain models

Avoid state impossibilities

Minimize redundant state

Reduce optionals when possible

Handle optionality as early as possible

Optional vs. empty arrays

Consider enums instead of optionals

Closing

Composing a resume in markdown

Incremental complexity in iOS development

Looking up words in a dictionary with Neovim

dict

Neovim integration

Configuring K

Shifting the testing culture: Code coverage

llvm-cov

Tracking coverage

Minimum coverage

Raising the bar

Shifting the testing culture: Infrastructure

Modules

Avoiding flakiness

Making simple things simple

Mocking

Other improvements

Shifting the testing culture: Motivation

Motivation

Testing methodologies

Benefits

Drawbacks

Migration strategies in large codebases

Migration tracker

Timeline

Priorities

Incremental value

Only invest in the new

Develop great partnerships

Avoid new uses

Support, support, support

Human factors in choosing technologies

Third-party libraries are no party at all

Risks

Runtime risks

Development risks

Business risks

Mitigating the risk

Evaluation criteria

Blocking criteria

Major concerns

Final notes

iOS Architecture at Lyft

Requirements

Modules

Module types

Dependency Injection

Flows

Plugins

Unidirectional Data Flow

Declarative UI

Putting it all together

Re-binding self: the debugger's break(ing) point

Using Interface Builder at Lyft

Improving the workflow

storyboarder script

Strongly-typed segues

NibView

Basic @IBDesignables

Linter

ibunfuck

Color palette

`dict`

Configuring `K`

`llvm-cov`

`NibView`

Basic `@IBDesignable`s

`UIGobblerGestureRecognizer`

`UITapAndAHalfRecognizer`

`[NSDate nilDate]`