#iOSDevUK: Natasha Murashev – The Swift Architect

My notes from @NatashaTheRobot‘s talk at iOSDevUK.

2014 – when swift came out. Everyone was like what’s going on? People clapped but hesitant. Some people were unhappy. Especially people who had just learned Objective-C. Scary time. Everything I know has changed. Genius with swift is it looks very familiar. If you have worked with any other language. Obj-C was pretty alien.

Immediate – genius of swift. Whole new language, but you kinda know it.

Flappy bird – the hello world program of 2014. Felt behind right away. After WWDC everyone went back to their job, app was in Obj-C. Kinda died down. Was weird, this is not Obj-C anymore. Functional programming in Swift book. Until then just using very basic swift. Doing what always knew, just doing it in Swift. Only understood like 10%. Was like – wow Swift is not this easy fun language, it can get pretty complicated, I have a lot to learn.

When you’re learning Swift, see a lot of Obj-C devs, start writing in Obj-C but in Swift. You can do that, and Swift is made to do that, easy to fall into that habit. But be a swift architect, use the power of the language to make your code better.

Start with a blank slate. Have to question all your assumptions. Have all these schemas in your brain. It’s quick. Learning something new is painful. Have to relearn your habits, learn to think in a new way.

Different learning strategies. Become an active learner of the language. Work with others. Learning and the social context is one of the best ways to learn.

Working with senior devs, pairing a lot. Learned get the answer, see if there’s a better answer, then a better one.

Teaching. Does a lot of speaking and blogging because forces her to learn. One level of learning you might skim it. But when you’re teaching it you have to really know your stuff.

Put yourself out there. People get hesitant, because it’s not perfect, what if other people critique it? Always learning, Just like this is me at the time. Putting it out there, get a lot of comments. Internet is filled with really smart people. Write a blog post, get suggestions. Obviously sometimes you get the bad comments. We want to be at the place where everyone can feel comfortable putting something out there. When someone does make the effort, be on the nice side.

Expose yourself to advanced topics. Learning is a wonderful experience because you have to admit that you don’t know something. You have to fall and learn multiple times. Community has an “I know everything” attitude. Need to be OK with something being hard and take a while to learn it.

Celebrate breakthroughs. Have a moment of happiness whenever learn something, even if think it’s a really simple thing that everyone else knows.

“Never put yourself in a position where you’ll be treated as foolish for learning” – @ashsmash – if people aren’t open to you learning either change that culture or put yourself in a better place where people are open to you learning.

Three things That Stood Out

• Value Types
• Optionals
• Testing

Value Types

Obj-C operates all in reference types. Pass the location of the object, and then modify the same one object. In Swift, value type heavy. Structs. Emums. Tuples. Pass a copy of that value, not a reference. The original thing has not changed.

When switched to swift, made everything a class. Watching talks understood making things a structs or a value type.

What about subclassing? For structs and value types, have to get rid of subclassing. For your own stuff, use value types. Use protocol orientated programming instead. Protocol extensions are magical. Classes are the exception rather than the rule.

Swift standard library – 87 structs, only 4 classes.

Optionals

Can’t talk about swift without talking about optional. Started using options, fell in love with them. Like bumpers at the bowling alley. Kinda nice and fun and you always win.

A lot of Obj-C devs come to swift, get frustrated, force-unwrap all optionals. Get rid of the bumpers – don’t do that.

Sunset Lake did an audit of all their bugs. Found 40% would have been prevented by swift. Obj-C nil messaging was one of the biggest categories.

Testing

Swift makes it easier to test code. Culture in iOS of not testing. Apple has doubled down on testing. Adding a bunch of stuff in 2014 and 2015. Reason was because people were just making tiny fun apps, hacking culture, release your app and it’s fun. Now we’re at the point where mobile is first, flagship product for your company. No longer a little fun app, an actual product, have to think long term. You have apps that you’re starting, you don’t test, you get them out the door. Eventually it’s so hard, you rebuild the app from scratch.

Swift is an opportunity to rewrite your app from scratch, time to write tests. Do you want something that you want to throw out in 2 years? Or something that people will still be happy to work on when you’re gone.

Now there’s a testable framework, can test internal things, not private, just internal.

Quick. BDD style framework. XCTest is not as fun with swift, it’s not made for value types and optionals. Sometimes just use nimble.

Another thing testing does for swift, makes you write more functional. Remove side effects.

Lots of excuses for why people don’t test. When want to move fast, do I test? How long do you move fast for? [tweet]

Take cue from Apple. Going to build things that are here for the long term.

“Live as if you were to die tomorrow. Learn as if you were to live forever.”