FAQ

Q: What version of Swift do you use in the series?

A: I used Xcode 7 for all projects, which means Swift 2.

Q: Do I need to follow the series in order?

A: Yes, preferably, and definitely so if you're a beginner. Each project builds upon concepts learned in previous projects, so if you skip ahead you might get confused. Some of the technique projects return to earlier apps to fix bugs by teaching a new concept, so if you've finished project 7 (for example) and think, "boy this sucks!" then sit tight: project 9 fixes the problem.

Q: How come all this stuff is free?

A: Originally Hacking with Swift wasn't free, but after about six weeks I had earned enough to cover all my costs so I wanted to find a way to make the same information benefit more people. My solution: put it all online. This wouldn't have been possible without support from all the purchasers, and I'm very grateful to them.

Q: How can I support your work?

A: Any support is very welcome, and very generous too – see the answer below!

Q: How can I read these tutorials offline?

A: You can buy the complete Hacking with Swift book set from Gumroad. It's "pay what you want", so you can pay $0 if you'd like to download it for free. If you'd like to support my work, any money you can spare is most welcome.

Q: What are "Pulp Fiction brackets"?

A: Pulp Fiction brackets are < and >, also known as "angle brackets."

Q: Why did you make another tutorial series when there are lots of good ones already?

A: There are some great tutorials out there right now, for example I'm a huge fan of the RayWenderlich.com work. But there's always room for more: the Hacking with Swift approach teaches you Swift with 30 hands-on projects, it's accessible even to beginners, and you can buy only the parts you need.

But there's another, more personal reason. Shortly after Apple released its WatchKit SDK for the first time, a chap called Nick Walter produced a free one-hour video teaching people how to make Apple Watch apps. He didn't make anything exciting, but it was helpful and well made, and it was completely free. When I was reading a news story about the video, I came across this quote: "One developer we spoke to, though, did say that the approaches taken in the video don’t always represent best practice and that if you want to develop an in-depth knowledge, you might be better off keeping an eye out on iTunes U."

That struck me as an unhelpful thing to say. Partly because the developer didn't have their name attached to the quote, partly because it's easy to snipe at someone else who is trying their best, but mainly because I don't know any developer who writes code that always represents best practice. Heck, developers struggle even to agree where to place braces, never mind agreeing on best coding practices!

So, I decided to make Hacking with Swift. I don't claim I always teach coding best practices, I don't claim to give you an in-depth knowledge on every topic, but I can promise that you're going to make a lot of awesome stuff and hopefully have fun at the same time.

Q: Why didn't you cover more functional programming?

A: There's a fantastic book already available called Functional Programming in Swift. Although it hasn't been out long, this book is already the standard reference for functional Swifters, and there really is no point me trying to teach what has already been done so well.

Q: Why don't you distinguish between parameter and argument?

A: Technically, "argument" is the data you pass into a function, and "parameter" is the data you receive, but in the books I use "parameter" exclusively. There are two reasons. First: the difference doesn't really matter, and I've never met someone who found it confusing to refer to parameters as meaning things passed in or received. Second, "argument" is A Very Silly Word, and most people new to programming will associate it with "fight" not "data being sent to a function."

Q: Your description of X is incomplete. Why don't you fix it?

A: As you climb up Wittgenstein's ladder, you'll start to realise that some of my explanations – such as optionals – have been simplified to help you get moving. This isn't me trying to deceive you! Instead, I'm just trying to build a broad cognitive framework that gives you the least you need to know to get results. Sometimes I expand on explanations in later projects, and sometimes you'll need to do extra learning yourself. But in the latter case, I do recommend you complete the series first.

Q: Why do you insist on teaching using projects?

A: My teaching method skips out a lot of theory. It skips out the smart techniques that transform 20 lines of easy-to-understand code into 1 line of near-magic. It ignores coding conventions by the dozen. And perhaps later on, once you've finished, you'll want to go back and learn all the theory I so blithely walked past. But let me tell you this: the problem with learning theory by itself is that your brain doesn't really have any interest in remembering stuff just for the sake of it.

You see, here you'll be learning to code on a Need To Know basis. Nearly everything you learn from me will have a direct, practical application to something we're working on. That way, your brain can see exactly why a certain technique is helpful and you can start using it straight away.

This series has been built on the back of my personal motto: "Programming is an art. Don't spend all your time sharpening your pencil when you should be drawing." We'll be doing some "sharpening" but a heck of a lot more "drawing" – if that doesn't suit your way of learning, Hacking with Swift isn't for you.

Q: What should I do if I spot a mistake?

A: If it's a typo or a coding error, please do email me or find me on Twitter. However, please keep in mind that these projects were designed to be simple and digestible learning examples, not fool-proof, App Store-ready perfections. That means sometimes there are bugs that exist because some longer or more difficult code has been removed or simplified – you're welcome to fix these in your own projects, but I think it would just confuse learners to fix them here.

Q: Does Hacking with Swift have any Firefly references? I want Firefly references. Where are the Firefly references?

A: They are, quite literally, all in the official Swift reference from Apple. Shiny!

Q: What do you have against penguins?

A: Because I'm actually Dr Octavius Brine, and I was adored in Central Park until those pesky penguins stole the show! Actually, wait a minute, that's the plot from Penguins of Madagascar – I just used penguins because they had a good cartoon image that was available in the public domain. And I would have gotten away with it too if it weren't for you meddling kids…