How I taught myself Swift (and SpriteKit) to create Wide Awake Pip
Software has an amazing deceptive quality that masks what’s going on. The end product works beautifully (sometimes) but it belies the days of toil getting it to such a state.
Even now, I get surprised when I watch someone playing Wide Awake Pip and it doesn’t crash half way through.
I’ve played the game thousands of times, but my experience of it was 15 seconds of play, followed by a bug, a crash, and occasionally a complete reboot.
But as I’ve got more experienced, and worked alongside more senior developers, I’ve begun to realise that this is the norm. Development is a process of coding followed but painful periods of bug hunting and fixing.
I eventually made Wide Awake Pip work. It took a long time, but with enough persistence (and heavy use of stack overflow) I’m sure you will get there too. In this article, I haven’t listed any of my keys learnings. Rather I’ve tried to list some of the ways I managed to learn.
The end result that belies the toil: Wide Awake Pip
How I started out
I got lots of recommendations of courses, online teaching sites, bootcamps etc. However, I found the most useful thing was watching YouTube videos of people flinging together quick and simple single page apps (shout out to The Swift Guy and Archetapp).
The advantages of short, simple ‘how to’ YouTube videos
To be clear, this is not the route that a Computer Science student would take at all and you risk missing out on deeper understandings of what is going on if you only watch youTube “how to’s”, BUT I would argue that there are a few huge advantages when getting started (I also assume that if you’re reading this article you haven’t got the free time of a student and are trying to do things part time around other tasks). The advantages of short simple apps shown on YouTube are:
- They show you, in a very short amount of time, the practicalities of how to get an app up and running. There’s way more to building an app than learning Swift. You need to know your way around XCode, work out how to get the simulator working, learn about what APIs are actually available for you to use (instead of trawling through a document library).
- Quick turnover of apps let’s you see things at a meta level — patterns emerge, you don’t get too lost in the details, you get a greater feel for the direction of travel.
- You see the YouTubers make mistakes! This is really helpful as a beginner. You spend your life trying to decode cryptic error messages. Most of them are relatively simple to fix — you’ve just got to know what they mean and what the standard fix is.
- Mentally you need to get a few quick wins under your belt. Coding can feel like a long hard slog so if you don’t get a the dopamine hit of launching something then you’ll just experience the painful side of coding and probably give up. Make learning into lot’s of mini-sprints rather than a marathon.
The advantages of taking a more academic approach
By ‘more academic approach’, I mean, investing the time in something like Stanford’s iOS and Swift Course or reading through Apple’s Swift documentation. To be honest, I’m not sure there is much of an advantage… the only thing I can think of is possibly that they will focus more on underlying theories which explain the ‘why’ not just the ‘how’ … but you can probably find a snack-sized YouTube video for that too as and when you need it…
What to do when you get stuck
You will get stuck. A lot. So you almost have to learn a strategy for getting unstuck. Here are some of the things I did to get unstuck:
- Firstly, you can lean on Xcode a bit. The benefit of a strongly typed language like Swift is that Xcode can often make pretty good suggestions for how you should fix your code. Listen to Xcode when it’s giving you advice!
- Use Xcode’s debugging tools (eg: insert breakpoints and step through the code). They are there to fix problems. Though I have to admit, the types of bugs I encountered, stepping through the code often didn’t help.
- Search Stack Overflow and post a question if a question like yours doesn’t already exist. Remember that you need to give the Stack Overflow community as much info about your issue as possible to give them the best chance of solving it. So be sure to add code snippets where appropriate and carefully detail out the context and the situation in which you find the issue. This brings me on to point 3…
- Can you clearly articulate what is causing the issue? Often while trying to phrase a question for Stack Overflow, I found myself forced to clearly document out the steps of what I was doing, which actually unearthed the solution for me. For example there was a logic step I’d missed, or I’d created a class but not initialised it correctly.
- Try commenting out sections of your code until it works again. Isolating the problematic code is often half the problem. Pressing cmd + / will help you comment out the code so you can leave it in situ and reinstate it easily later.
- Adding in ‘print’ statements in lots of places (eg, printing out variables or objects that are likely to be the cause of an issue). I once heard this referred to as ‘poor man’s debugging’ and it’s true the Variable View in the debugging area of XCode can be a better way to inspect the code in some situations. But I’d suggest you shrug off any inhibitions and embrace print statements. The Variable View only gives you a snap shot at one point in time (and stepping through the code can be slow) so printing is a pretty quick way to get to the answer.
- Creating mini-projects. Don’t be afraid to spin up a new Xcode project to test out a single idea. Isolating parts of complicated code from the rest of your app can help track down particularly elusive bugs such as scope issues where you’ve accidentally used the same variable name twice or race conditions where code running in parallel is actually the cause of your issue.
Mentoring
This is the greatest learning advantage - having someone a bit more experienced than you willing to help you out. And the best way to get a mentor is actually in a job. When people are working in the same company, it’s the senior developer’s responsibility to make sure you’re ok. You shouldn’t feel embarrassed to ask silly questions. Everyone has to ask the stupid questions once in their career — it’s better to get them over and done with early on than masking a secret truth that you never really understood something only for it to come to light later on.
Other ways to get a mentor: I’d suggest searching your LinkedIn or Facebook network. If you don’t have one, then set out to build one.
What if you still can’t fix your bugs and you’ve exhausted the goodwill of your mentor
This did happen to me a couple of times. You have a really specific question; Stack Overflow hasn’t come up with anything; I’d asked just one too many questions of my friends…
Possibly consider paying someone on Upwork to review your code. This doesn’t have to cost the world, and if you’re really stuck on a problem then it can be amazingly good value!
Don’t expect to get the feeling that you’ve “learnt” a language
The more you know, the more you realise you don’t know. Don’t set yourself the overly ambitious goal of learning all of Swift and everything it can do with an app. You’d be bound to fail and feel depressed.
I’m not sure how many Swift developers actually feel like they know the entire language and all the APIs for iOS app development. I suspect, most people get to a stage where they’re happy with the core feature set and they’ll have learnt some of the niche skills for what they’re doing (eg SpriteKit) but they still won’t know much about other areas of the Swift and Apple ecosystem (eg VRKit or SpeechKit). I think the best you can expect is to get to a stage where you feel comfortable that you could work things out if you needed to.
I hope that helps some of you out! If you’ve found this useful please consider sharing Wide Awake Pip to people who might enjoy it. Many thanks! Ben
