Swift for many many reasons. • Unless you’re students are already developers, they likely won’t understand those reasons. • Focus on getting things on the screen. • Don’t teach Swift features or syntax beyond what is needed for the project at hand.
• Is this the only session or is this daily / weekly? • Is this one-on-one or is it a group? • What am I teaching today? • Have I built this app on my own recently? • Getting lost in your own content is extremely disruptive.
the time to get the app running on their device (remember, its free now) • When you hook up an IBAction, use print() to show it works • When you hook up an IBOutlet, change the text to show it works. • Coding for more than 10 minutes straight is a complete SLOG. Try to keep it to no more than 5 minute stretches of code.
them, they’re amazing. • No platform has anything as powerful • Its even great for designers, you can make such great workflows with ZERO code • (I know android has the equivalent of NIB’s, but they don’t have storyboards)
• A lot of custom UIViewController and UITableViewCell subclasses? • A lot of boilerplate code? NSURLSession code? • Does any API used by the project use completion handlers? • Is there an API key for the service you’re using? • Does ATS f*ck up network access?
• Customize fonts in the storyboard • Show how to have even/odd cell layouts • Show how to add an about screen • This sounds small. But this is HUGE. The satisfaction level of students that experience this step is ginormous compared to the students who didn’t.
know your student(s) existing skill level. Do show common iOS design patterns. Do be prepared. Do Build and Run often. Do crash often (on purpose). Do err on the side of Storyboards, rather than code. Don’t lecture Don’t be a soup code Nazi Provide starter project (If needed). Don’t teach AutoLayout Do save time for customization at the end. Don’t fight the framework. Don’t teach (the intricacies of) Swift Do a fully functional app. Do believe in your students ability to learn this stuff