Catching up with Swift - Speaker Deck

Slide 1

Slide 1 text

Catching Up with Swift Ash Furrow, Artsy

Slide 2

Slide 2 text

“What’s the worst that could happen?”

Slide 3

Slide 3 text

Agenda 1. Swift was needed 2. Swift met those needs, mostly 3. Writing Swift is great, mostly 4. Using Swift in production 5. The future of Swift

Slide 4

Slide 4 text

Swift Was Needed.

Slide 5

Slide 5 text

Objective-C • From the early 1980’s • Originally, a C preprocessor • Then an advantage • Now a burden

Slide 6

Slide 6 text

Objective-C • Moderate use until the mid 2000’s • Used to make OS X apps • Niche market • Then the iPhone happened

Slide 7

Slide 7 text

Source: http://bit.ly/1E2BOCs

Slide 8

Slide 8 text

Objective-C • Sudden interest, despite: • Esoteric syntax • Unusual memory management • Arcane knowledge

Slide 9

Slide 9 text

Objective-C • Three distinct groups of developers emerged: • First wave, developers from the 80’s/90’s. • Second wave, OS X developers from the 2000’s. • Third wave, developers attracted by the iPhone.

Slide 10

Slide 10 text

Friction.

Slide 11

Slide 11 text

Objective-C • Tension. • Disenfranchisement. • Resentment.

Slide 12

Slide 12 text

—John Siracusa “While hardware performance increases over time, the human capacity to deal with complexity does not.”

Slide 13

Slide 13 text

Objective-C • New features were developed by Apple: • Dot property syntax. • Closures. • Decreased boilerplate, headers. • Automatic reference counting. • Collection literals. • Primitive boxing syntax.

Slide 14

Slide 14 text

“See? Objective-C is getting better! We don’t need to replace it!” —First/Second Wave Developers

Slide 15

Slide 15 text

False.

Slide 16

Slide 16 text

Language Evolution • Machine code. • Assembly. • Procedural languages (C). • Object-oriented languages (C++, Objective-C). • Virtual machines (Java, C#, Ruby, etc).

Slide 17

Slide 17 text

archaic Eventually, writing Objective-C will seem competitive disadvantage. and relying on it would be a

Slide 18

Slide 18 text

“Eventually.”

Slide 19

Slide 19 text

decades. Replacing your home-grown programming language takes

Slide 20

Slide 20 text

Objective-C • Could not escape its C roots. • Apple began work on Swift in 2010.

Slide 21

Slide 21 text

Swift Objective-C improved of because

Slide 22

Slide 22 text

Objective-C Replacement • Needs to… • abandon all C roots. • be memory managed. • have native unicode strings, native collections. • be concise. • have named parameters.

Slide 23

Slide 23 text

Swift Met Those Needs. Mostly.

Slide 24

Slide 24 text

Swift • Announced June 2014. • Betas released until a 1.0 in the Autumn. • “Objective-C without the C.” • Mischaracterization.

Slide 25

Slide 25 text

Swift Needed to… ! abandon all C roots. ! be memory managed. " have native unicode strings, native collections. " be concise. " have named parameters.

Slide 26

Slide 26 text

Abandon C Roots • Swift needed to have full Objective-C interop. • Which means full C interop. • It’s possible to write Swift to interact with C APIs. • It’s ugly and discouraged. • Well, I discourage it anyway.

Slide 27

Slide 27 text

Be Memory Managed • Objective-C introduced ARC in 2011. • Replaced garbage collection on OS X. • Replaced manual memory management on iOS and OS X.

Slide 28

Slide 28 text

Be Memory Managed • Automatic Reference Counting. • Same as manual memory management. • Inserted for the developer at compile-time. • Reasoned about and optimized by compiler.

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

Be Memory Managed Pros • Familiar, stable technology. • No garbage collector overhead. Cons • Can’t detect reference cycles.

Slide 31

Slide 31 text

Native Unicode Strings • Got ‘em. • Strings are a Swift struct. • Bridgeable to Objective-C NSString instances. • Handle double-byte Unicode characters.

Slide 32

Slide 32 text

Native Unicode Strings func () -> RACSignal { return hideAllTheThingsSignal() } func #(snapshottable: Snapshotable) { expect(snapshottable).to( recordSnapshot() ) }

Slide 33

Slide 33 text

Native Collections • Collections are also Swift structs, on generics. • Array, Dictionary, and Set. • Bridgeable to Objective-C equivalents. • Concise syntax.

Slide 34

Slide 34 text

Be Concise • Subjective, but I’m happy. • Simple things are easy. • Difficult things are possible.

Slide 35

Slide 35 text

Named Parameters • Optional(ish) • Compiler does weird things for Objective-C interop. ¯\_()_/¯

Slide 36

Slide 36 text

Named Parameters func compare(lhs: String, to rhs: String) -> Bool { return lhs == rhs } compare("Hi", to: "Hello")

Slide 37

Slide 37 text

Writing Swift is Great. Mostly.

Slide 38

Slide 38 text

different from Problem-solving in Swift needs to be Objective-C syntax. problem-solving with

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

Generics • Objective-C is dynamically typed. • Swift is statically typed. • Awesome. • (ish). • Compile-time type safety.

Slide 41

Slide 41 text

Generics • Objective-C distinguishes primitives and classes. • Swift is all like (°□° • Arrays, dictionaries, and sets all use generics.

Slide 42

Slide 42 text

Generics struct Stack { private var contents = Array() mutating func push(value: T) { contents.append(value) } mutating func pop() -> T { return contents.removeAtIndex(0) } var isEmpty: Bool { return countElements(contents) == 0 } }

Slide 43

Slide 43 text

Generics var intStack = Stack() var stringStack = Stack() var stackStack = Stack>() intStack.push(1) intStack.pop() // Returns 1

Slide 44

Slide 44 text

Lazy Swift • Language-level concept of lazy evaluation. • Applied automatically to global variables. • Can be applied to any property.

Slide 45

Slide 45 text

Lazy Swift • Assigned on first access. • Can be overridden by setting before first access. • Really cool trick with closures.

Slide 46

Slide 46 text

Lazy Swift class MyClass { lazy var name = "Ash Furrow" } MyClass().name // Returns "Ash Furrow" let instance = MyClass() instance.name = "Orta Therox" instance.name // Returns “Orta Therox"

Slide 47

Slide 47 text

Lazy Swift class MyClass { lazy var name = "Ash Furrow” lazy var greeting: String = { return "Hello, \(self.name)" }() } MyClass().greeting // Returns "Hello, Ash Furrow" let instance = MyClass() instance.name = "Orta Therox" instance.greeting // Returns "Hello, Orta Therox" instance.name = "Eloy Durán" instance.greeting // Returns "Hello, Orta Therox"

Slide 48

Slide 48 text

Extending Types • Objective-C has “categories” to extending existing classes. • Swift has “extensions”, instead. • The work on all types.

Slide 49

Slide 49 text

Extending Types extension Int { var hours: NSTimeInterval { return NSTimeInterval(3600 * self) } } extension NSTimeInterval { var fromNow: NSDate { return NSDate(timeIntervalSinceNow: self) } var ago: NSDate { return NSDate(timeIntervalSinceNow: -self) } } 4.hours.fromNow 4.hours.ago

Slide 50

Slide 50 text

Index Paths • Used to identify cells in a table view. • Section, row. • Lots of horrendous code. • It’s so bad. • Seriously bad.

Slide 51

Slide 51 text

Index Paths if (indexPath.section == 0) { if (indexPath.row == 0) { } else if (indexPath.row == 1) {   } else if ... } else if (indexPath.section == 1) { if (indexPath.row == 0) { } else if (indexPath.row == 1) {   } else if ... } else if ...

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Index Paths switch (indexPath.section, indexPath.row) { case (0, 0): case (0, 1): case (1, 0): case (1, 1): default: // nop }

Slide 54

Slide 54 text

better? Is that

Slide 55

Slide 55 text

No.

Slide 56

Slide 56 text

Index Paths switch (indexPath.section, indexPath.row) { case (0, let row): // Executed for any section 0, row is row. case (let section, 0) where section % 2 == 1: // Executed for first rows of odd sections. case (let section, let row) where validate(section): // Executed when validate() returns true. default: // Executed on all other cases. }

Slide 57

Slide 57 text

better? Is that

Slide 58

Slide 58 text

Maybe.

Slide 59

Slide 59 text

Let’s look for new ways to solve familiar problems.

Slide 60

Slide 60 text

Let’s ask other communities how they solve problems.

Slide 61

Slide 61 text

Swift in Production

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

No content

Slide 64

Slide 64 text

Open Source by Default • Decided to develop the app in the open. • Because why not? • No, seriously. Why not? • Helpful for asking for assistance from others. • “Here’s my code – what’s wrong?”

Slide 65

Slide 65 text

github.com/artsy/eidolon

Slide 66

Slide 66 text

August • Swift had been out for two months. • Stability had improved. • Swift seemed ready.

Slide 67

Slide 67 text

Nope.

Slide 68

Slide 68 text

September • The language was great. • Lots of frustration with tools. • 3rd party tools weren’t ready, or didn’t exist. • So we built some. • And contributed to others.

Slide 69

Slide 69 text

October • Running behind schedule. • “Hard deadline.” • Explored options to speed up development. • Brought on an extra developer to help.

Slide 70

Slide 70 text

—My boss “We don’t expect to meet our deadline.”

Slide 71

Slide 71 text

We made our deadline. $

Slide 72

Slide 72 text

Burnout.

Slide 73

Slide 73 text

technical debt. Significant

Slide 74

Slide 74 text

Problem Solving • Compiler optimizations segfault the compiler. • Disable optimizations. • App is too slow without optimizations. • Buy faster iPads. • Tools didn’t exist. • So we built them.

Slide 75

Slide 75 text

hands on. Swift is still

Slide 76

Slide 76 text

awesome. But it’s also

Slide 77

Slide 77 text

Future of Swift

Slide 78

Slide 78 text

Safe Bets • Tools will continue to improve. • Always a year away from being stable. • Language will continue to be awesome. • And get more awesomer.

Slide 79

Slide 79 text

Predictions • More functional-esque APIs from Apple. • More functional-esque APIs from the community. • No Swift-only APIs from Apple, for now. • Apple doesn’t want to disenfranchise first/ second wave developers.

Slide 80

Slide 80 text

Recap 1. Swift was needed 2. Swift met those needs, mostly 3. Writing Swift is great, mostly 4. Using Swift in production 5. The future of Swift

Slide 81

Slide 81 text

@ashfurrow @ashfurrow leanpub.com/yourfirstswiftapp Thanks!