Slide 1

Slide 1 text

Lessons From Becoming an SDK Developer iOSConf SG 2019 1

Slide 2

Slide 2 text

Oscar Swanros @Swanros [email protected] iOS Software Engineer PSPDFKit GmbH pdfviewer.io

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

twitter.com/tapirofoto

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

Photo by Iker Urteaga on Unsplash

Slide 12

Slide 12 text

Photo by Johny vino on Unsplash

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

Sounds familiar? ✋

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

⛑ Congratulations!

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

Building an SDK involves much more than tools.

Slide 22

Slide 22 text

The lessons I've learned

Slide 23

Slide 23 text

• Empathy is your first line of defense. The lessons I've learned

Slide 24

Slide 24 text

• Empathy is your first line of defense. • You've gotta think about design! The lessons I've learned

Slide 25

Slide 25 text

• Empathy is your first line of defense. • You've gotta think about design! • Being patient pays off. The lessons I've learned

Slide 26

Slide 26 text

Empathy

Slide 27

Slide 27 text

Empathy the ability to understand and share the feelings of another.

Slide 28

Slide 28 text

Having empathy is…

Slide 29

Slide 29 text

Having empathy is… • not wasting your users' time.

Slide 30

Slide 30 text

Having empathy is… • not wasting your users' time. • helping them get out of trouble (before they even get into it).

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

If someone is trying to use your SDK…

Slide 34

Slide 34 text

If someone is trying to use your SDK… • are they in a rush?

Slide 35

Slide 35 text

If someone is trying to use your SDK… • are they in a rush? • are you solving something super complicated?

Slide 36

Slide 36 text

If someone is trying to use your SDK… • are they in a rush? • are you solving something super complicated? • all of the above?

Slide 37

Slide 37 text

If someone is trying to use your SDK… • are they in a rush? • are you solving something super complicated? • all of the above?

Slide 38

Slide 38 text

Saving time

Slide 39

Slide 39 text

Saving time • Be as transparent as possible.

Slide 40

Slide 40 text

Saving time • Be as transparent as possible. • Make an effort to feel right at home.

Slide 41

Slide 41 text

Saving time • Be as transparent as possible. • Make an effort to feel right at home. • Don't overcomplicate stuff.

Slide 42

Slide 42 text

Helping out

Slide 43

Slide 43 text

Helping out • Invest in documentation.

Slide 44

Slide 44 text

Helping out • Invest in documentation. • Doing support as a mean to get better.

Slide 45

Slide 45 text

Doing support for an SDK is like code review, but 100x better.

Slide 46

Slide 46 text

Design

Slide 47

Slide 47 text

Design guides our users into the correct way of using our products.

Slide 48

Slide 48 text

Designing…

Slide 49

Slide 49 text

• UI Designing…

Slide 50

Slide 50 text

• UI • API Designing…

Slide 51

Slide 51 text

• UI • API • Architecture Designing…

Slide 52

Slide 52 text

• UI • API • Architecture Designing… • UI • API • Architecture

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

• It is what it is.

Slide 56

Slide 56 text

• It is what it is. • You decide what ships.

Slide 57

Slide 57 text

• It is what it is. • You decide what ships. • Features are not included "by mistake."

Slide 58

Slide 58 text

• It is what it is. • You decide what ships. • Features are not included "by mistake." • It is what it is.

Slide 59

Slide 59 text

• It is what it is. • You decide what ships. • Features are not included "by mistake." • It is what it is. • There's no guarantee what it could be.

Slide 60

Slide 60 text

• It is what it is. • You decide what ships. • Features are not included "by mistake." • It is what it is. • There's no guarantee what it could be. • Users will hold it wrong.

Slide 61

Slide 61 text

Relevant questions…

Slide 62

Slide 62 text

• What will this UI/API imply? Relevant questions…

Slide 63

Slide 63 text

• What will this UI/API imply? • Is this something that can fail? Relevant questions…

Slide 64

Slide 64 text

What will this UI/API imply?

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

let result = component.perform(with: [items])

Slide 67

Slide 67 text

let result = component.perform(with: [items]) objectStore.fetchInBackground(completion: (Result) -> Void)

Slide 68

Slide 68 text

No content

Slide 69

Slide 69 text

What's the implication?

Slide 70

Slide 70 text

No content

Slide 71

Slide 71 text

No content

Slide 72

Slide 72 text

No content

Slide 73

Slide 73 text

In which scenarios won't this work?

Slide 74

Slide 74 text

Distinguish between user errors and programmer errors

Slide 75

Slide 75 text

Distinguish between user errors and programmer errors

Slide 76

Slide 76 text

Distinguish between user errors and programmer errors podtail.com/podcast/fatal-error

Slide 77

Slide 77 text

User Error Programmer Error

Slide 78

Slide 78 text

User Error • Maybe the user can fix it at runtime? Programmer Error

Slide 79

Slide 79 text

User Error • Maybe the user can fix it at runtime? • But we don't crash: we try to present an alternative or a way forward. Programmer Error

Slide 80

Slide 80 text

User Error • Maybe the user can fix it at runtime? • But we don't crash: we try to present an alternative or a way forward. • It's obvious, reflected on observable app state. Programmer Error

Slide 81

Slide 81 text

User Error • Maybe the user can fix it at runtime? • But we don't crash: we try to present an alternative or a way forward. • It's obvious, reflected on observable app state. •There's no way this will work. Programmer Error

Slide 82

Slide 82 text

User Error • Maybe the user can fix it at runtime? • But we don't crash: we try to present an alternative or a way forward. • It's obvious, reflected on observable app state. •There's no way this will work. •Decide if it's fatal or we can still carry on. Programmer Error

Slide 83

Slide 83 text

User Error • Maybe the user can fix it at runtime? • But we don't crash: we try to present an alternative or a way forward. • It's obvious, reflected on observable app state. •There's no way this will work. •Decide if it's fatal or we can still carry on. •Show a big scary error message. Programmer Error

Slide 84

Slide 84 text

User Error • Maybe the user can fix it at runtime? • But we don't crash: we try to present an alternative or a way forward. • It's obvious, reflected on observable app state. •There's no way this will work. •Decide if it's fatal or we can still carry on. •Show a big scary error message. •Crash. Programmer Error

Slide 85

Slide 85 text

Think like an engineer.

Slide 86

Slide 86 text

Think like an engineer. Meaning, you probably won't read the instructions.

Slide 87

Slide 87 text

Patience

Slide 88

Slide 88 text

Patience the capacity to accept or tolerate delay, problems, or suffering without becoming annoyed or anxious.

Slide 89

Slide 89 text

Slide 90

Slide 90 text

Quicker == better

Slide 91

Slide 91 text

Slide 92

Slide 92 text

"You've got to think more about what you're doing." ✋

Slide 93

Slide 93 text

Rushing things ends up making your customers trust you less.

Slide 94

Slide 94 text

No content

Slide 95

Slide 95 text

Patience

Slide 96

Slide 96 text

• Is a virtue that you have to consciously exercise. Patience

Slide 97

Slide 97 text

• Is a virtue that you have to consciously exercise. • Not always easy to stay calm! Patience

Slide 98

Slide 98 text

• Is a virtue that you have to consciously exercise. • Not always easy to stay calm! • It pays off. Patience

Slide 99

Slide 99 text

You can only afford to be patient if you've invested in empathy and design.

Slide 100

Slide 100 text

Quicker != better

Slide 101

Slide 101 text

Tips to reach zen

Slide 102

Slide 102 text

• Robust test suite. Tips to reach zen

Slide 103

Slide 103 text

• Robust test suite. • Good documentation. Tips to reach zen

Slide 104

Slide 104 text

• Robust test suite. • Good documentation. • Keep improving your work every time you change something. Tips to reach zen

Slide 105

Slide 105 text

• Robust test suite. • Good documentation. • Keep improving your work every time you change something. • Make sure information is accessible. Tips to reach zen

Slide 106

Slide 106 text

To recap

Slide 107

Slide 107 text

No content

Slide 108

Slide 108 text

• Be empathetic towards your users.

Slide 109

Slide 109 text

• Be empathetic towards your users. • Make an effort to be conscious about the design decisions you make.

Slide 110

Slide 110 text

• Be empathetic towards your users. • Make an effort to be conscious about the design decisions you make. • Understand that patience is key.

Slide 111

Slide 111 text

Thank you! @Swanros [email protected]