Build and Run - The dos and don’ts of teaching iOS & Swift to non-programmers!

Over the past 2 years, Jeff has been designing curriculum and teaching iOS development to students with little to no programming experience. The curriculum is designed for them to be able to walk out of classes with a useful app in less than 5 hours of teaching time. But iOS is a big platform and that makes choosing what to teach and what not to teach critical to achieving success. Jeff discusses what he learned as an iOS teacher to help us all become better teachers.

---

Do a Fully Functional App (4:07)

The first thing to do when teaching iOS to non-programmers is to teach a fully functional app. Traditionally, people start with very simple ‘hello world’ apps, but the world has moved on. People now know the world of the App Store and consider Instagram a ‘simple app’.

In our course, we have two projects we normally do for people that have never programmed. The first is we build a little tip calculator - it has some fields where you can put in the tip amount and the percentage and then push a button and it calculates the tip. It lets you play with the storyboards, outlets and actions and some basic math in Swift. The second app is for students that have already programmed but maybe not with iOS, and we do what we call a Rotten Tomatoes app.

The second app downloads JSON, parses it, you get the storyboards and then you do a table view. I love this project because this is essentially every app – it downloads stuff off the internet and display it into a table view. So it’s really nice with the students when they get to build an app that they’ve seen and like walk out and know that this is the fundamental basis for all iOS apps.

Know the Existing Skill Level of Your Students (6:46)

In terms of assessing students, some very basic questions to ask are:

• Do you know what a variable is?
• Do you know what a function or a method is?

If they say yes to either of these, they’re probably already in the more advanced bucket of your students, and I’m not kidding. If they’ve heard of object oriented program - not if they know what it is, but if they’ve even heard of it - they’re likely advanced.

Don’t Assume Everyone Knows How to Use a Desktop (8:15)

Don’t assume people know how to use desktop computers. We live in this mobile world and we’re used to iPads and iPhones. So very often I have seen, people struggling with the basics of folder/directory management for example, or working with windows on the screen.

Believe in Your Student’s Ability to Learn (9:37)

It’s important to remember that when people get stuck, it’s not because they’re dumb or can’t do it. As illustrated in the chart of how we think we learn something versus how we actually learn, the learning process is not a perfect curve. Rather, it’s rigid, and sometimes, students need extra attention and time to process/understand the information.

Show Common iOS Design Patterns (10:41)

iOS has four basic design patterns that everyone knows.

• Table Views
• Push Navigation
• Modals
• Tab Bar Controller

To demonstrate these designs, you can make use of QuickTime to record videos to show them in action.

Don’t Fight the Frameworks (12:16)

Don’t fight the framework. I know Apple people love to say this and it drives us crazy, but this translates to griping to your students. Don’t complain about this stuff while you’re teaching it. It’s already difficult to explain how to use a view controller, so telling them how terrible it is on top of that is distracting.

Don’t Teach Swift (10:41)

Don’t teach the intricacies of Swift. We all like Swift here, we like immutability and we like using structs instead of classes, and we like functional programming. But at this stage of learning for students, none of that applies and it’s just going to go over their heads.

It’s pointless to make the distinction between reference versus value types, so only teach as much Swift as you need for the project at hand.

Be Prepared (14:18)

This is one of the tougher ones because it requires a lot of preparation and time. One thing to ask yourself is how long do have to teach. Is it two, four, or eight hours? Is it a week? Would I be teaching an entire class like General Assembly? This is important to note because a group will move more slowly.

Build and Run Often (15:41)

Check to see if you’ve built the sample app your working on with the latest non-beta version of Xcode in case Swift has changed or if the frameworks have changed. This is important because it’s disruptive trying to teach when something doesn’t work and you have to attempt to debug it during the lesson. You need a constant feedback loop and this can happen only if all the details are taken care of.

Crash Often (16:52)

It’s important to crash often, as it’s part of the feedback loop. It’s easy to crash, but if you intentionally crash with some of the most common mistakes, it can be a good learning experience to figure out how and why for the students. For example, hook up that IB outlet and then rename the variable, rename the property. Same with the IBActions; if you’re doing table views, use the wrong cell identifier. Then in Swift we can always have the implicitly unwrapped optionals and that kind of fun stuff.

Don’t Lecture (17:55)

This is also related to the feedback loop, in that you don’t want to have too much time pass without doing something or getting input from your students.

Err on the Side of Storyboards (19:07)

Err on the side of storyboards rather than code. Especially for beginners, storyboards are great. There’s no other platform that has anything quite like it where you get to draw your whole UI. It’s also not simply a code generator that generates the code and then you go edit it later.

Don’t Be a Code Nazi (20:19)

Don’t be a code Nazi. We’re not just teaching Swift, we’re teaching iOS mostly. So be quicker and more unsafe generally just because it’s faster to type things in and explain a little less. But tell them the exclamation mark means it’s going to crash if something goes wrong for example. So use exclamation mark when unwrapping optional for simplicity.

Provide a Starter Project (21:55)

Sometimes it is worth building a starter project. I try not to do it, because it’s nice to start with a completely fresh project. But sometimes it’s needed because you want to teach how to use table views or how to download data. You don’t want to teach how to use CocoaPods, as they can look that up online. It would take much too long to do the pod init and get the pod file working in addition to Ruby working on their Mac.

Don’t Teach Auto Layout (23:16)

There are too many buttons, too many fiddly things, and too many rules. When we’re actually teaching auto layout, it’s a longer class. Usually, it’s just too much for a beginner on the first day. What you can do instead when going through storyboards is to cover the different screen sizes so that they’re aware of the concept.

Save Time For Customization at the End (26:12)

In the process of learning, your students been following along and blindly typing things, but may not be fully understanding everything. So let your students go into the storyboard to change background colors and fonts to customize their app at the end, so that they can learn to do that. This helps your students connect and learn Xcode, which they may not fully get to do while in a one-day workshop.

Q&A

• When do you tackle device provisioning?

You do that during the day you’re installing Xcode, before the class.

• Have you used Playgrounds, and is it a good tool in your class?

I found the problem with Playgrounds is that it’s more focused on teaching Swift and less focused on building an app, which is generally what we found people want to do.