On Switching from an iPad Pro and a Macbook to a Pixelbook

The stranger and more complex story of change in my computing life is the decision to move from an iPad Pro and a Macbook to a Chromebook. My computing is complicated and I wear too many hats but what I’m talking about here is my day-to-day main portable computing device.

In late 2015, I decided to go all-in on the iPad Pro. That actually worked pretty well for a while and, for all of 2016, I didn’t have a Mac at home and relied solely on my iPad Pro for daily work. I made a lot of progress with that setup and was even able to launch a successful podcast which has almost entirely been recorded, edited and published using iOS.

My work was evolving and so was iOS. In late 2017, I was appointed Head Teacher of the school where I work, taking up the post in August 2018. That was a more significant shift in my workloads than I had perhaps anticipated - not just in the volume of work but also the type of work that my computer was required to support.

At the same time, iOS 11 had shipped and it simply broke my relationship with iOS on the iPad. There was nothing about its new multitasking system that I liked and little that I could even tolerate. From its unhelpful app-pairing feature to its devaluation of the Home Screen and overloading of the Dock, I just could not get comfortable with it at all. Then iOS 12 came along and made it even worse in some ways with its aping of iPhone X gestures and ever-finer distinctions between a little swipe up to display the dock and an ever so slightly longer swipe up to show multitasking. Touch just isn’t built for such fine distinctions.

My school is known as an “iPad school” - we were the first whole-school 1:1 iPad deployment in the world - but we have been a “Google school” even longer. We have been on what is now GSuite since it was called “Google Apps for Your Domain”. The first thing I ever did when I started at the school was to sign up for GAFYD and we have been on it ever since.

When Google Drive launched in 2012, we started making more use of it and Google Docs. In the six years since, we have really gone all-in on these apps. I was never a huge fan of web-based software but we started with one particular project where we cut so much time and effort out of the process that I couldn’t help but get interested.

That project was the process of writing report cards. Previously, every teacher used to produce and print a Pages document for their pupils. That pile of documents would get delivered to the secretary who was then responsible for dividing them up and assembling report cards from them. This process was time-consuming and hugely error prone. We replaced that with a process where I create a template file in Google Drive for each pupil and then teachers write their reports in a single shared file per pupil and then we print them all at the end. That was when I got interested in Google Docs in a big way.

Fast forward to 2018 and virtually all of the work I do at school is now in Google Docs. I don’t think I’ve created anything new outside Google Docs for a couple of years now. As I was preparing to take over as Head Teacher, more and more of my work became about higher levels of complexity, involving more data sources and requiring larger work spaces than ever before. Big spreadsheets to build timetables, school budgets, pupil information and the like.

If I can refer back to an article I wrote in 2013 called “Beyond Consumption vs Creation”, which I still think is the most coherent thing I’ve written on the topic, I observe that mainly what happened my work took me outside that boundary of complexity and duration that the iPad can support.

At the same time, Chromebooks have been on the rise. They are killing Apple in US K-12 education but it’s still not clear exactly what impact they are having on the wider market if any. It does seem obvious to me, though, that Google knows exactly where their strength lies and it actually has very little to do with ChromeOS itself.

My school runs on GSuite but we usually access it through iPads. What I have found, though, is that the GSuite iOS apps are not very good. They lack important (and sometimes basic) functionality found in the web version of GSuite and they take a long time to adopt iOS platform features.

The point, though, is that GSuite is so powerful and so much at the heart of everything I do at school that if you asked me to decide between giving up GSuite and giving up iPad, I’m afraid iPad has to go. It is for this reason that I have been vocally advocating that Apple make iOS Safari as close to a “desktop class” browser as it can be. I don’t know the technical reasons why GSuite can’t be accessed in Safari on iOS. I don’t know if the browser has limitations that mean the apps genuinely can’t run in it, or whether they could but Google just chooses not to allow it.

I’m entirely willing to believe that this isn’t Apple’s fault. That doesn’t mean it’s not their problem. Lack of feature-complete access to GSuite is, I believe, as serious a risk to Apple in K-12 as the potential lack of Photoshop and Office on Mac OS X was to its role in business back in the early 2000s.

None of this is to say that iPad and iOS has suddenly become a bad platform. It has not - although I could make a strong case that every change made to multitasking in iOS 11 worsened the experience in every way. iPad is still a good platform for the things it was good at back in 2015/16 when I was using it full time. What has really changed more than anything are my own personal computing needs and the strength of the competition.

iOS has a particular software lack in a particular sector. It just so happens that I work in that sector and I work extensively with deep features of that suite of software that iOS lacks. We might fairly ask why Apple has chosen not to compete with GSuite. It has, from time to time and piece by piece, but in no way is it a realistic proposition for a school heavily invested in GSuite to consider switching to iCloud. The concept simply doesn’t make sense. It’s not that Apple’s equivalent features are better or worse; it’s that in many cases they simply don’t exist. There are no shared folders in iCloud Drive, no organisational units, precious little control over iCloud feature availability, no auditing or security tools. Collaboration tools do exist in iWork apps but the workflow is ad-hoc and on a per-document basis. There’s nothing like Google Drive’s Team Drives feature. There are no fine-grained controls over spreadsheet editing. If we were to take the top 20 daily-actively-used features of GSuite, I don’t know if Apple’s cloud infrastructure has equivalents for almost any of them.

So, you see, my point is not that the iPad is a bad computer or that iOS is a bad operating system. Neither of these things are true. I do have a question, though, about what Apple thinks people should be buying from their product line.

Notice that the premise of this article is how I came to switch from a 12.9” iPad Pro and a 2015 MacBook to a Chromebook. It honestly seems to me that Apple might seriously expect people to own more than one £1000+ computing device just to get the benefits of both a laptop and a touch screen. Macs can do some things that an iPad can’t do - like access the full GSuite - and an iPad can do some things that a Mac can’t do. Should people really have to buy two computers from Apple to get the best of both worlds?

The Google Pixelbook I have been using seems to do a much more balanced job of providing laptop features and tablet features in one coherent device. It is virtually identical to the new 12.9” iPad Pro in terms of physical dimensions and weight. It opens like a traditional laptop with a very nice keyboard and trackpad but then folds back to become a tablet when required. It makes you wonder what might have been if Apple hadn’t been so determined to keep the Unibody MacBook Pro form factor essentially inviolate for a decade. The Google Pixelbook isn’t cheap in Chromebook terms but it’s significantly cheaper than the iPad Pro/MacBook dyad that Apple wants to sell you.

Is the Google Pixelbook a genuinely great tablet computer? No, certainly not. It’s a very good laptop that does a passable job of some kinds of tablet tasks. In tablet mode, it’s great for Netflix, YouTube, casual web browsing and that sort of thing. Would I put the Pixelbook into tablet mode to go deep on a Google Sheets document? Of course not. Having said that, I reflect on how often I used my iPad Pro in pure “tablet mode” too - it wasn’t all that often either. It seems that as laptops get more tablet-y, tablets are getting more like laptops. The Pixelbook isn’t a better laptop than a MacBook, and it isn’t a better tablet than an iPad, but this one device satisfies 98% of my computing needs in a single package. It also costs less than half of what I would need to buy from Apple to get the same set of capabilities.

As for doing “real work” on the Chromebook, I’ve been in that world for some time already. That part wasn’t even a concern for me. I had proven all that some time ago - my Macbook literally had no non-default software on it except Chrome. It effectively was a Chromebook in all but name. Sure, the Chromebook doesn’t run all the software in the world, but it runs the software that I actually need and use every day absolutely flawlessly.

One other thing that hurts to say but I believe is true is this: ChromeOS is getting better faster than iOS on iPad. Apple seems now to be on a two-year cadence for meaningful iPad-related software updates and, honestly, that’s just not fast enough. ChromeOS is moving very quickly. Probably, iOS is ahead for now but I hate waiting on an “iPad year” WWDC and then hoping that something will happen for the OS features I happen to care about. There are some parts of iOS that have lain fallow for years now - Mail, Calendar, Safari - that need some serious investment. Third party apps might fill some of the gaps but iOS doesn’t let them be full replacements for the system apps. Honestly, I'm bored waiting for progress on some of these platform basics that have been on iPad users' wish lists for literally half a decade or more now.

So where do we go next? On the one hand, we have Apple with a wildly successful phone product and a tablet product sharing the same basic OS. They also have a legacy desktop platform that's adopting mobile app APIs to fill functionality gaps. That said, after nearly a decade of iOS on iPad, we seem to still be staggering our way along the road to a full-power iOS. Every single year, we iPad users talk amongst ourselves about how “next WWDC” will fix everything - many people who have dropped laptop money on the 3rd generation iPad Pro are really buying it on more of a hope, even, than a promise that iOS 13 will make it sing.

Google, on the other hand, has a numerically successful phone platform that still has some quality challenges and an all-but-abandoned tablet strategy. They have a moderately up-and-coming hybrid laptop/tablet platform in ChromeOS that is seeing significant work and investment and is shipping significant feature updates on a regular basis. (Interestingly, said platform is also adopting mobile APIs/runtimes to fill functionality gaps.) Google also have a genuinely wonderful collaboration platform in GSuite that has become the most important software in my life bar none. Clearly, it’s become more important to me than any software that Apple makes.

Ironically, the web browser was what opened the door for the first Mac revival in the original iMac era. The lack of a fully-capable web browser is what’s closing the door on the iPad for me.

Wasn’t there an app for that?

On Switching from iOS to Android

I may be having the most boring mid-life crisis that any man has ever had, or I may be opening a whole new chapter of my computing life. I don’t know.

This year, I decided to make a change. I switched from an iPhone X to a Google Pixel 2XL phone, and then switched from a combination of Apple portables - a 12.9” iPad Pro and a 2015 MacBook - to a Google Pixelbook.

This change has been so surprising to some people that I am told that friends are asking friends if I’m psychologically OK. Don’t worry about me - I’m absolutely fine. I thought I would try and get back into longer-form writing by trying to explain my thinking here and see if it’s really what I think.

There is no single reason why I decided to make these changes, and the reasons are different for the phone and the laptop cases. Some have been brewing for a long time and others are more recent. In this post, I’ll concentrate on the phone question and come back to the laptop question later.

The phone story is perhaps simpler, and mostly revolves around price. I had misgivings about the value of the iPhone with the release of the iPhone X and it breaking the £1000 barrier. I wondered if Apple would be able to continue to increase the price of iPhones much more. Still, I ended up with a new iPhone X last December. That deal ran out and I wondered about what to do next.

This year, Apple released iOS 12 and along with that came a feature called Screen Time. In iOS 12 you can look in Settings and find out how much time you spend in particular apps and what you really do with your phone.

I always imagined myself to be a high-end iPhone user. I had all the powerful iOS apps installed: Keynote, Pages, Word, Excel, Ulysses, OmniFocus. Then I turned Screen Time on early in the beta versions and started to watch what I really did with the phone.

It turned out that, consistently, what I did with my phone was exactly this, in order of screen time:

  • Twitter
  • iMessage
  • YouTube
  • Google Maps
  • Instagram
  • Overcast (although Screen Time doesn’t count screen-off time, which would have put Overcast at #1 by a country mile.)

Everything else was typically minutes per day at most. This started to sow a seed of doubt in my mind - why do I have this £1,000 phone to do such, well, basic things?

Then the iPhone XS and XS Max came along. The iPhone Upgrade Program prices in the UK ranged from £51.45 to for the 64GB XS to £73.95 for the 512GB model - this is without any carrier service added. Even the lower-cost XR ran from £41.45 to £48.95.

At the same time as this, I have three children - two of whom are old enough to be phone users now too. I suppose I just started feeling the pinch, imagining how I would be able to fund even infrequent iPhone purchases for three people.

As I was coming to the end of my year on the iPhone Upgrade Programme, I decided to see what life might be like on the other side. I saw a deal for the Google Pixel 2XL phone which was £33/month. I was already paying £18/month on top of my iPhone program costs for carrier service on my iPhone, so this was effectively a brand new flagship Google phone for £15/month.

So one Friday, armed with my Screen Time data and the knowledge that all but one of my most-used iPhone apps were also available for Android, I just took the leap and signed on for a 2 year plan on the Pixel 2XL.

My expectation was that I would find it almost entirely fine but that I would eventually come across something that I really hated about it. So far, that honestly hasn’t happened.

I’m aware that I’m still using Android with a heavy iOS accent. My launcher is organised to be mostly like an iPhone; I can’t stop opening Chrome before starting a search and I cannot swipe-to-type for all the tea in China. I have no clue about home screen widgets. However, I’m getting used to it and I’m as productive as I need to be on a phone.

Like many others, I thought that the loss of iMessage would have been a serious limitation. It simply hasn’t been. I never cared about iMessage stickers or apps and it turns out that, in Europe at least, almost literally everyone is also on WhatsApp. Chats with some American friends have moved to Twitter DMs as WhatsApp doesn’t seem to be so big over there.

I replaced Overcast with Pocket Casts. I still liked Overcast better but Pocket Casts is honestly fine. I replaced OmniFocus with Todoist. Honestly, I was doing a terrible job of my GTD system in the six months before the switch, so there was practically nothing that had to be moved over there.

Virtually every app that I used on my iPhone also exists on the Android side of the house and they’re all virtually identical - not just at the feature level but almost down to the pixel level. It’s interesting that so much of Google’s Material Design influence had rubbed off on iOS apps - particularly Google’s apps but others too - that the shift from iOS to Android hardly even looks different in many apps.

One thing that is very alien, but very interesting as an iOS user, has been watching the various parts of Google update their Android apps on a rolling basis. As Apple users we are used to watching WWDC with the hopeful expectation that whatever part of iOS or macOS that you particularly care about will get its moment in the sun this year.

Unfortunately, several parts of the Apple ecosystem seem to go years and years without being significantly improved. Look at Mail, Calendar, Contacts and even Safari. They’ve had virtually no engineering resources devoted to new user-level features in multiple years now. At the same time, though, I watch the updates rolling through on this Android phone and I see the Contacts app getting an update, the Calendar and Gmail apps getting regular feature improvements. Even the Camera app just delivered this incredible new Night Shot feature in an overnight update.

Maybe I’m just old and boring now. Maybe I just want to clear my inbox and go home earlier and maybe I don’t want to do any of this in an Augmented Reality battle-scape. This is what I want now - I want my email to help me go on a trip. I want the lock screen of my phone to surface useful and timely information. I love being able to just quickly and precisely search my email on my phone.

I also like that it came with a rapid charger in the box. The physical design of the phone is fine to me. It’s another black rectangle. The placement of the fingerprint sensor on the back is weird to an iPhone user but it works OK - although it’s much less forgiving than Touch ID ever was. The only thing I really don’t like about the physical design of the phone is that the only shortcut to launching the camera when the phone is locked is to double-press the power button. The button is small and narrow and I find it very difficult to do the double-press accurately and fast enough for the OS to recognise it.

Honestly, the switch from iOS to Android has been fine. Much, much easier than I expected and far more interesting. The iOS 12 team should take great heart - I am spending much less time on my iPhone since I started using it!

Building our School's Third-Generation WiFi Network

I recently completed our school’s third wifi deployment which has been by far our best and most comprehensive network to date. I thought I would write up a bit about it here.

To understand a bit about our deployment, you need to know that our school building is an old stone building from the second half of the 19th century. It was very definitely not built as a school and the original designers did not take a lot of care to make WiFi deployments easy!

We cabled most of the building in the mid-2000s to accommodate wired networking for, at the time, desktop computers. Since we moved to iPad in 2010, a lot of that network has lain dark and unused.

Our first WiFi network was installed in 2008. At that time, we were using Apple Airport Extremes. The school at the time was quite small numerically - we had just moved up from a much smaller building - and we were recruiting new pupils all the time.

The AirPort Extreme network worked fine for the internet capacity and number of machines we had at the time. I think we probably had about 20 machines on the WiFi and the entire school ran off a 5 megabit internet connection.

At the time, we also had a fairly basic Netgear smart switch connecting everything in the networking cupboard. This switch was the unit that wouldn’t die and served us well right through to our new deployment.

In 2010, we went one-to-one iPad and, remarkably, the combination of Airport Extremes and a 5 megabit internet connection coped well for the first few years of the deployment. Again, you have to remember that people’s expectations of the internet were quite low at this time. Many people didn’t have very good or reliable wifi at home and their broadband speeds were quite low as well. Additionally, we were still learning how to be a one-to-one school and few teachers were prepared to depend on the internet connection for the critical work of the school. All of that is different now.

In 2012, we moved to Aerohive. Due to various constraints, we basically replaced the Airport equipment with the Aerohive equipment unit-for-unit. This left us with a network of 9 Aerohive AP330s which, again for the time, was enough to see us through.

As the school grew and grew and more rooms in the building were brought into use, our network started to strain a bit at the edges. We have 15 teaching rooms in the school and with only 9 access points and thick walls to penetrate, things got to the point where I had tweaked and tweaked every setting I could find on the Aerohive network but I wasn’t able to wring any more performance or coverage out of that set of equipment.

On top of that, we were now running iPad hardware that was 802.11ac compatible. Our three iPad deployments to date have been: original iPad, 4th generation iPad and, currently, a split 9.7 iPad Pro/4th generation iPad mini deployment. Finally, we are on student equipment that supports 802.11ac. It was time to do something.

Ubiquitous Ubiquiti

My first idea was to buy some additional used Aerohive equipment to expand the network just a bit. Unfortunately, that was a non-starter as Aerohive equipment is tied to a server-side license and Aerohive won’t sell you a license for used equipment.

So we started to look around. It seemed to me that we really needed to redesign the whole network since we hadn’t really touched the core switch gear since the mid-2000s and my sense was that, after more than ten years continuous operation, our switch might fail at any time and leave us in a pretty bad situation.

To do the whole network at the quality level I wanted, the main aim was to simply get more radio hardware into the building - one access point per classroom was my goal. That would let us maintain the coverage but reduce the power levels on the access points so that every class was provided with a good signal for that room and iPads would be strongly encouraged to connect to the AP in the room they were in.

Previously, because of our need to penetrate thick walls, we were running several access points at maximum power and this was causing problems with devices not roaming correctly to the closest AP. This caused a lot of trouble with people moving around the school with iPads open and getting stuck on various high-powered access points - which sometimes were quite far away from where the students were.

So I put together a proposal to basically replace everything with modern, supported and managed networking equipment. Realistically, for our budget and the scale we wanted to operate at now, Ubiquiti’s Unifi range was more or less the only game in town.

The final proposal was as follows:

  • One Ubiquiti Security Gateway to act as our border router (we still had one AirPort Extreme doing this job for us!)
  • One US-24-250W switch to connect the ground floor together
  • Two US-8-150W switches to connect the first and second floors together
  • 20 Unifi AP-AC-PRO access points

20 APs would give us:

  • One AP in each working room in the school
  • Two APs in the lunch room and our biggest classroom which is often used by many students simultaneously
  • An AP in the hallway on the first two floors
  • One spare

The proposal was approved quite quickly and it was on to designing the roll-out.

Deploying the Controller

The Ubiquiti licensing model is both more straightforward and far cheaper than most (all?) “enterprise” wifi networking systems: you buy the kit and download the controller from their website and you’re off to the races.

I decided, as is my wont, to deploy the controller on an Amazon EC2 Linux machine running Ubuntu server. This is how we do our MDM server too and it works well for us.

Well before the equipment was even ordered, I had set up the controller and had designed the shape of the network so that, when the kit arrived, it was a matter of going through what Ubiquiti calls “adoption” for each piece of kit and it would all be up and running.

The big difference between running the controller on your LAN and running it in the cloud is that you need to do what’s called “[Layer 3 Adoption]” - that is, you need to tell the equipment where its controller is. If you’re on the same LAN, it will be automatically discovered.

Rolling Out

The first job was to replace the last AirPort Extreme with the Security Gateway. The USG is basically a two-port router that sits on the edge of your network. I configured ours so that one port would be the new network and the second port would emulate the old network. That way, I could drop in the USG between the existing network and the internet and nobody would notice anything.

That step actually worked beautifully and I was able to start setting up the new network in parallel with running the old network. I next installed the 24-port switch and hooked it up to the USG - our new network was off to the races.

My next steps were to unpack and set up the other two switches and all the access points. I wanted to do this at my desk because we were going to install some of these APs in reasonably inaccessible places and if anything was going to go wrong with them, I wanted to know before we got the ladders out.

I started working through the APs, connecting them to the switch, adopting them into the controller and giving them friendly names and then, crucially, physically labelling them with the same name that they have in the controller.

I can’t emphasise this last point enough: 80% of effective systems administration is labelling things correctly and methodically.

Between other things, this process took me a couple of days. The equipment had been delivered on Monday lunchtime and by Wednesday evening I was ready to start installing equipment. We worked all day on Thursday mounting APs on the walls and cutting new cables to connect everything up. Some rooms had dark cable in the walls so it was a simple job to cut a drop cable and wire up the AP.

Other rooms had existing unmanaged switchgear in so we mounted the new equipment in parallel with the old stuff and waited until we were about to switch over. By about 5pm on Thursday we had all the APs installed and the switches on each floor were ready to go.

On Thursday evening I went back into school with the intention of trying to hook up a few APs and test the signal. In the end, I decided that I was so close to being done that I might as well complete the job. In about 4 hours of pulling cable and re-wiring, I had the entire new network up and running. It felt great to pull out all that old gear and eliminate all the little unmanaged switches we had accumulated over the course of ten years of piecemeal network expansion.

On the Friday, we ran for the first day on our new network and, as best as I could tell, it was a rousing success. Many of the worst-served classrooms reported much more stable, reliable and fast connections. The better-served classrooms simply didn’t notice anything.

WiFi is one of these “hygiene” features in school - there’s no great kudos for having it work perfectly all the time but there is a ton of heartache when it doesn’t work well for everything. Ideally, I want nobody to notice the WiFi at all. If people are talking about it, there’s a problem.

iPad Configuration

Moving from Aerohive to Ubiquiti was not without a couple of interesting issues. We had been using Aerohive’s Private Pre-shared Key feature to give every student a unique password to the network. This is a flagship Aerohive feature and it has some significant advantages but I found that, in practice, it had a number of downsides too.

We had arranged things so that each student password was only good for one device but, since the students knew their own password, they could easily use it on another wifi device that they owned and brought to school - usually their smartphone but I did see the occasional Kindle appearing too. What this resulted in was a kind of race condition where the first device that came in the door in the morning would “use up” the slot for that student and their school iPad wouldn’t be able to join the network.

Ubiquiti doesn’t have an equivalent feature - except by using RADIUS, which I didn’t really want to set up - so before I rolled out the new network, I sent a configuration profile to all the student iPads with a new WiFi payload that contained the SSID and password for the new network.

This also worked very well. As soon as I brought up the new WiFi network, student devices started to join the new network without my ever touching them.

On the first day of operation, I spent time watching the Ubiquiti dashboard alongside the school timetable. What I was looking for was to see that iPads were roaming correctly to the AP in the class that the student was actually sitting in. For the most part that worked very well and I could usually find a student iPad by looking at the client list for the classroom that the timetable said they would be in.

I did some work to manually set channels and power levels for all the access points. I set the 2.4GHz radios to “low” power (9 dBm) and the 5GHz radios to “medium” (17 dBm) everywhere. I’m still tweaking some channels to make sure that APs are not interfering with each other. Ubiquiti’s auto channel selection system basically chooses the best channel at startup and stays there (other systems perform occasional background scanning and switch), so it does rather lead you to hand-tweaking just to be sure.

So that’s the story of our new network and how we built it in a week. I’ve been very pleased by both the price and performance of the Ubiquiti equipment. The licensing model is the kind that I like (i.e. not very “enterprisey”) and I didn’t even mention this but the Unifi iOS app is one of the best native apps I’ve ever seen for wifi management.

A Year of Teaching Swift

We are nearly at the end of the school year here in Scotland and I wanted to take some time to reflect on the experience of teaching the Computer Science curriculum this year using Swift Playgrounds and Apple's Learn to Code curriculum.


One of the projects I have been engaged with over the past few years is to move our Computer Science teaching out of the senior years and into the earlier years of secondary school. I'm not done with this yet but we are getting there.

In 2016/17, I taught the following courses:

  • Primary 7 (6th grade) - Introduction to Computational Thinking using Pixar in a Box
  • Primary 7 (6th grade) - Introduction to Computer Programming with Hopscotch
  • Secondary 1 (7th grade) - Learn to Code 1 & 2
  • Secondary 2 (8th grade) - Learn to Code 1 & 2

I taught the same course to S1 and S2 this year because we were still making the transition and this class hadn't done it before. In general, we obviously wouldn't teach the same course two years in a row.

I want to review the experience of teaching Learn to Code 1 and 2 here. Pixar in a Box is another post for another time but the idea with that is to promote the ideas of Computational Thinking without necessarily going straight to code.

Learn to Code

In the Learn to Code curriculum, there are three books called Learn to Code 1, 2 and 3 which use the Swift Playgrounds app as their learning tool. There are also two earlier books called Get Started with Code 1 and 2 which use either Tynker or Codespark Academy, and two later books called Introduction to App Development with Swift and App Development with Swift. These later two books use Xcode and macOS and extend up into college years. I'm only going to focus on the Learn to Code books here.

Learn to Code 1 and 2 were introduced alongside Swift Playgrounds at WWDC 2016. I started teaching them in October 2016, just after iOS 10 shipped.

Course Structure

The structure of the two books are really of a piece. Together, they provide a curriculum that covers much of the basics of a Computer Programming curriculum: commands, functions, loops, conditionals, variables, constants, arrays and basic object oriented programming.

In general, I think that the books introduce most of the concepts in an accessible way and do a good job of providing a staged progression through each of the topics.

Both classes that I taught Swift to this year had one term's prior experience in programming with Hopscotch and had also been through the Introduction to Computational Thinking class.

The Learn to Code World

Each of the books provide a series of exercises in each chapter that introduce and progressively challenge the skills that students are supposed to be learning at that point.

The format is nearly always the same: there is a character in a 3D puzzle world and the student is required to write code to "solve" the puzzle - however that is defined in the specific challenge.

In the world, there are collectible gems, toggle-able switches, moveable platforms and portals that transport you to other parts of the map. All of these make for quite an engaging game-like world and provide enough variety that the challenges rarely seem repetitive.

One issue I have with the constant use of a 3D map based approach is that, in my experience, it does disadvantage students who are not as strong in spatial reasoning and to some extent advantages students who are strong in that area but may not be as good at abstract reasoning as others.

Swift as a Teaching Language

I have taught a range of programming languages over the years. Primarily Visual Basic, Ruby and Python. I liked Ruby the best so far and hated Python for its crazily inconsistent library programming.

Swift is the closest thing to Ruby I've used. It is very consistent and predictable in its syntax and mostly makes sense as you read it. My only actual bugbear in the syntax that you explore in Learn to Code 1 and 2 is that the use of let to declare a constant isn't as intuitively obvious to students as var is.

Swift is a pretty decent teaching language at this level. It doesn't require much in the way of obscure ceremony or boilerplate code. I've seen students really start to bend the syntax to their will in some of the later exercises and this is really pleasing to see.

The Student Experience

From observation and talking with students during the class, I observed a few significant differences from any previous programming curriculum that we had used.

In times past the experience was that, if you were an able student in Computing, you would get your programs working. If you were not an able student, your experience would be almost insurmountable challenges to get anything working. Working or not-working was the differentiator in the class.

In the Learn to Code curriculum, I found that everyone got something working. The difference between the stronger students and the weaker students then was more to do with evaluations of the complexity of their solution, the understandability and style of their solutions or other factors like memory and time efficiency.

I have never really had these kinds of conversations in classes at this level before. It has been an incredibly satisfying year to get the opportunity to debate which of three possible solutions is the 'best' for a given problem and, further, what definition of 'best' we should accept.

For example, we looked at some solutions where students had written extremely compact code. It became a bit of a competition in the class to see who could solve a problem with the least code. Of course, this is almost never a desirable metric in practice, so I spent quite a lot of time teaching about Brian Kernighan's maxim:

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

I can't point to many areas of the course that students found overwhelmingly difficult. The course is well-paced with enough practice on each technique that students can consolidate their learning. The later section in Learn to Code 2 in which Arrays are introduced could use a slightly shallower learning curve, but it wasn't too difficult overall.

The Teacher Experience

Apple provides a teacher guide for all of their courses. In the early days I kept to that guide quite closely but as the term wore on and I gained more confidence in the material, I felt freer to move away from that document. This was good and bad. Some of the things in the teacher guide I was kind of uncomfortable doing in class - there's one chapter that asks you to lead the class in dancing and that is simply not going to happen. At other times, though, I think I could have delivered a better class if I had used their lesson starters instead of my own.

Apple's teacher guides also encourage you to use Seesaw to gather evidence of the students' work. I quickly abandoned this practice as the sheer volume of material produced was quickly overwhelming. Between screenshots and code exercises, my class of 12 could easily produce 50-60 individual items that I was supposed to look at and approve in Seesaw in one class hour.

Instead, I took the approach of simply being far more active in the classroom. Instead of silent work for an hour and then offline grading, I asked the students to show me their solutions as they completed them and we would have conversations about the success or failure of their solutions live in class. This was, in some ways, much harder and more active work for me but it meant that I got to have those qualitative conversations about code that I had been looking for for so long.


What Learn to Code 1 and 2 rather lack is any way to formally evaluate a student's learning. A rubric is supplied, which I used, but there are no tests as such and no homework exercises. I ended up designing my own end-of-year test for Learn to Code and used the results of that test alongside the Learn to Code rubric to report to parents.

During the year, I also designed a series of weekly homework exercises based on Learn to Code 1 and tested them with the students going through the class this year (their results were not formally recorded as grades).

I have always found it difficult to set homework in computer programming classes because there is so little support available at home in this area that students can have wildly varying results. Instead, what I have done, is focus on code comprehension rather than code writing in exercises that will go home. I don't ask students to write code outside of class but to read code that I have written and either debug it or describe its behaviour. I'm in the early stages of doing this but I think this is a more sensible approach to programming exercises without teacher support.


Teaching Learn to Code 1 and 2 took me about 60 class hours over the course of this school year. I think this would have been slightly longer if I had stuck more rigidly to the Apple teacher guides and gone through all the exercises before letting the students code.

On reflection, I think that covering both Learn to Code 1 and 2 was maybe just a little too much for one school year. The learning went very well overall but both I and the pupils were somewhat running out of steam by the end of LtC 2 and I think we were all glad to finish when we did.

Future Improvements

I am definitely going to continue teaching Swift at school. As we go forward, I think a few improvements could be made.

Firstly, I would like Apple to publish a road map for future Learn to Code books. When I started planning the year, Learn to Code 1 and 2 were the only books in existence and we didn't know that there would ever be a Learn to Code 3 until the day it shipped. We plan learning experiences over the long run and it would be very helpful to know what's coming - or even if nothing else is coming.

I don't think many changes are needed in the Learn to Code 1 and 2 course itself. I'm looking forward to teaching it again. However, the aforementioned lack of summative assessment is something that would be worth looking at.

I would like to see a Learn to Code 4/5 where some iOS APIs are introduced within Swift Playgrounds. SceneKit and MapKit might be good candidates for "fun" APIs but I'm also interested in using lower-level network programming to teach about the structure of the internet.pl

The Swift Playgrounds app has worked well for us in general but a few things could help:

  • I would like to see a "teacher screen" mode where the code is much larger for the students to see.
  • Power efficiency was an issue at some points during the year but recent updates to the app have improved that significantly.
  • Some ability to transfer individual solutions between devices without having to transfer the entire book would be welcome. Sometimes you need to give a student a complete or partial solution for various reasons.
  • The ability to extract an individual page of a Playgrounds book would be convenient. Sometimes you want to use individual exercises by themselves.
  • You currently can't reset the in-book world to its initial state without re-running the program.
  • More debugging options would be helpful, such as breakpoints and variable inspectors.
  • When the books get updated, a detailed explanation of what changed and why would help. It's weird when your 'textbook' changes out from under you.
  • Integration with Apple Classroom to be able to open students directly into a particular exercise.

Overall, teaching Swift has been a pleasure this year and I look forward to doing more!