Tailor your Swift
Hand-crafting code as an Apple Developer
What does it have?
Has all the things
classes, structs, enums (super-powerful)
blocks (with lamba-expression syntax)
class and protocol extensions
Can do all the things
Easier to read syntax
Robust compile time checking (without building)
Why is writing better code important?
The complex programmer
• writes cryptic, complex code
because they can.
• never reads programming books
or attends meetups, code
• no documentation, if you can’t
read it, you’re just a bad
• basically a ‘lifer’ at the
The thoughtful programmer
• writes clean, patterned and thoughtful code.
• always strives for improvement and not for the
sake of making more money.
• documents code with proper naming, patterns
• uses peer-reviewed pull requests to learn from
thoughtful coding in Apple’s language
speaking of conditional statements
Unintended method consequences
What does that have to do with populating?
Either name it properly or move it out
• It’s clear that if a new form condition holds, 2
things need to be done.
• prepopulateForm( ) is back to doing 1 job.
• It easy, lazy and dangerous to add new code
inside a method that had a different purpose.
Prefer Swift’s method naming conventions
methods should read like human speech
Like a book.
Group sentences into thoughts, or paragraphs
making code easier to
read for yourself as well
Use , instead of &&
only applies to if/else statements
still need || if you want to OR
unwrap and add a conditional
clean up optionals with guard
• early termination (no need to carry on if
conditions aren’t met).
• cleans by removing if let optional bindings and
community agreement on optional
• prefer to use the same name as the optional, or “same-
name shadowing” per Erica Sadun.
• the compiler has no issues, and it will only be local to the
• The same goes for guard, use the optional’s name for the
don’t return an optional just
because you can
More than just mutually-exclusive conditions
too many ifs
Use when your type can represent “states”
in an “or” relationship, but still needs data
associated with each state.
An alternative to subclassing
The classic problem
• Subclassing is great until it is overused and no
longer makes sense
• Derived types start taking on too many unique
• Historically you’d use composition in other
languages to prevent subclassing.
Associated values again
When to use what
• Subclassing is useful when you have a hierarchal
design that you don’t anticipate changing very
• If your types can be light-weight structs, use an
enum with associated values.
• Mix in some protocols to promise behavior.
• assertionFailures should be used in place of many
NSLog and print statements.
• You the developer need to find crashing conditions
early not in QA
• Go through every console log (NSLog, print) and
replace with error reporting and/or add to them
with an assertFailure
• A great place to use them is in fail early guard
• They are stripped out for a release build
(assuming you’re using different builds).
• fail early and stop to solve bugs during
development and not from a QA bug ticket.
I see dead comments
• Comments are part of the code, treat them as such
• The less noticeable they are, the more likely they’ll
• Change their color to stand out more
• Pay attention to comments in pull requests.
Take care of warnings
• _ = lets you suppress the unused result warning,
and explicitly tells the reader “I am intentionally
ignoring this returned value.”
• Follow Xcode’s instructions or fix the code to make
the warning go away
• Sign of a broken-window-theory project are
hundreds of warnings.
• Add a (pragma) mark above every set of protocol code (for each)
• This gives you a nice visual divider in the code and the
quick search drop-down
Extract and extend
take the code out of the VC and add an extension
• naming convention: className+protocol.swift
• technically it’s still a part of the class but it reduces
the size of the class and organizes the code better.
Lighten the load
use the coordinator pattern for viewControllers
• The heart of the problem is that segues and
navigation are usually implemented in the view
• This tightly couples 1 view controller to another.
• Remove this responsibility with a Coordinator
everything in software should have 1 job.
• Every view controller gets a coordinator
• All vc coordinators are controlled by an AppCoordinator
• Makes the ViewControllers do only what they’re supposed to, update
• Segues are negated, as the coordinators now control the navigation
and app workflow
manage model objects as protocols
• Apple strongly suggests protocol-based development
and you see it through out CocoaTouch.
• Protocols let you swap out dependencies easily at
• Coordinators can hold onto these protocol-based
dependencies instead of ViewControllers.
• Protocols enforce the you-have-1-job rule better.