Blog

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.

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.

Background

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.

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.

Assessment

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.

Timing

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!

Recently, I took my family on a trip to France. We had a wonderful time but it was slightly marred by the events of the last evening in Paris when one of our bags was stolen from literally at our feet in a restaurant.

A number of things were lost but the most concerning one was my wife's iPhone. We were able to quickly disable her bank cards and her SIM card, so nothing serious was lost, except photographs, but the incident got me thinking about what I would do if my own devices were lost in this way.

Fortunately, the bag was stolen on the final day of the trip and not the first, otherwise we would have had serious problems throughout the holiday. This is another post for another time, but it's kind of shocking how crippling the loss of a phone is.

Certainly, the loss of the devices themselves is not trivial but the bigger concerns are (a) how to protect the data that is on those devices or accessible through them and (b) how to get back into my accounts and data in order to continue my trip.

My Typical Setup

I use iOS devices and I use 1Password religiously. Every account I have is stored in 1Password and I have memorised none of those passwords. I recently changed my Apple ID password to an unmemorable password (a mistake, as we shall see later), so the only password I have memorised is the one to unlock 1Password.

I use 1Password for Families, so my data is hosted by 1Password itself. I have 2-factor authentication turned on for every account that supports it, including my Apple ID, personal and work Google accounts, Dropbox, Evernote and others.

All my devices have passcodes. I use alphanumeric passcodes on my iOS devices. I have Touch ID enabled. My Apple Watch locks when I take it off. Find My iPhone is turned on for all devices and Activation Lock is enabled.

I'm really doing my best here. Ironically, though, it's this good level of security that makes the recovery trickier.

My Disaster Scenario

Fortunately for us, only one device was lost in the random snatch of a single bag. For this post, though, I'm going to assume the absolute worst case scenario and, if I can work back from that, I can work back from anything less bad than that.

Let's say, for the sake of argument, that I'm walking down the street in a large city somewhere abroad and I'm approached and forcibly relieved of all the valuable possessions on my person. In a typical tech conference scenario, that would be my iPhone, iPad and Apple Watch all gone.

What now? Well, there are two phases to this: damage limitation and disaster recovery.

Damage Limitation

The first concern is to limit the exposure of my data to attackers and Find My iPhone is the first place to go here.

Find My iPhone can be accessed through an app on another iOS device or on the web. Sensibly, you don't need to go through 2-factor authentication to get to this - I mean, you've just lost one of those factors - so you just need your iCloud password.

Here was my first problem: I don't know my iCloud password. It's long, it's random and it's stored in 1Password. So now I have to get into 1Password, just to send an erase command to my devices.

For me, that would take too long so my first task in this security audit is to change my password to something complex and long but still memorable without support.

Assuming I can get into Find My iPhone, the next thing I would do is put all my devices into Lost Mode. Lost Mode does a number of things but most importantly it disconnects any bank cards you have in Apple Pay from being used through any device in Lost Mode.

Lost Mode is actually better than immediately sending a remote wipe to your device. A wipe requires the device to be online to receive the command but Lost Mode will kill your Apple Pay in Apple's payment processing back end so you are immediately protected whether or not the device is online.

If you can see the device, then you might be in good shape to try and get it back. Many criminals, however, know to either turn off the iPhone or remove the SIM card, so it goes dark immediately. In my opinion, iOS devices should have locking SIM trays and require a password to shut down the device to close this loophole.

A point about getting devices back: I do not recommend you just follow the map and try and find your device. Instead, hand this information over to law enforcement and let them chase the bad guys.

Disaster Recovery - iCloud

So, assuming the worst happens and all your devices are gone forever - what now? Well, I need to get back into those accounts.

Let's assume that somehow I can acquire a new device. As a side issue, ask yourself how you would even do that. If everything was gone - how would you call home? How would you get money? Do you even have those numbers written down anywhere that isn't in your phone?

Also bear in mind that to activate an iPhone you might also need a working SIM card. I'm not sure if this is true everywhere on all networks, but I've certainly seen that requirement in the UK.

To sign into a new device, you need your iCloud password and a way to access your 2-factor information. With Apple's current implementation of 2-factor authentication, you can use a number of methods to get that second factor.

First, you can get it from another trusted device. This is when that dialog pops up and tells you that someone is trying to log in from a specific location, you tap OK and then you see a 6-digit code that you can provide.

Except in this scenario, all your trusted devices are gone. So that's out.

The next thing you can do is have a code sent to a trusted phone number. But your phone is gone and the SIM card is gone with it, so no calls or texts to that number.

Here, I discovered the second flaw in my setup. I only had my own devices set up as Trusted Devices and I only had one phone number set up as a Trusted Number - namely, my iPhone's phone number.

So, second task in this security audit: register a few other Trusted Numbers with Apple, and make sure that at least one of them is someone that you're not travelling with. Additionally, make sure you know how to get in touch with that person without access to any devices or iMessage or any social media.

It's also worth noting that, unlike most 2-factor authentication schemes, Apple no longer provides a "recovery key". Recovery keys for 2-factor authentication are like "safety net" keys that you can enter instead of getting a 2-factor authentication code from any of the usual channels. Google, Dropbox, et al. provide these kind of keys but Apple does not. Your only options are Trusted Devices, Trusted Phone Numbers or talking to Apple Support about getting back into your account.

Disaster Recovery - 1Password

The last thing I need to do to get back up and running is to get into my 1Password database. I'm using 1Password for Families and I do know my 1Password master password. However, that's not enough to get into 1Password.

1Password requires two pieces of information to get in: the master password and the account's Secret Key. When you are using 1Password for Families or Teams, you can create what is called a 1Password Emergency Kit. This is a PDF that contains your 1Password Secret Key and your login information (but not your password). I wasn't carrying this, but I had it stored in ... a place that I couldn't get to without access to 1Password!

So, third to-do item in this process: print and carry a copy of my 1Password Recovery Kit. It's probably also wise to create a second copy and leave it with someone you trust and can contact, just in case you are stripped of literally everything.

Wrap Up

With memorable passwords for iCloud and 1Password, and a copy of my 1Password Secret Key, I feel sure that I could get back to a working system from zero.

Have methods of getting in touch with the owners of my other Trusted Phone Numbers if needed.

Certainly, what I have proposed here is the absolute worst case scenario I can think of that doesn't involve my being personally incapacitated or killed. Digital estate planning is a whole other consideration but the basics will be similar to what I have presented here.

With iOS 10.3, Apple have released Apple Classroom 2.0. Apple Classroom first shipped alongside iOS 9.3 and provided tools to help teachers in an iPad-based classroom.

Apple Classroom provides a range of features including observing student screens, launching apps and URLs and locking student devices.

In the initial release of Apple Classroom, the way that the system worked was that your school Mobile Device Management server had to create and send an "education payload" to teacher and student devices. This payload included information about which users are teachers and students, and which teachers teach which classes and so on. This also prevented students from downloading and using Classroom to control other students' devices.

This made it very easy for teachers in such schools to just pick up and use Classroom. Unfortunately, it made the job rather difficult for school administrators and MDM vendors. So difficult, in fact, that most MDM vendors simply have not shipped support for Apple Classroom. As a result, very few schools are using Apple Classroom to its full extent.

Apple Classroom 2.0 goes a long way to fixing most of these issues.

Infrastructure Changes

Previously, the infrastructure requirements for Apple Classroom were reasonably high. You needed an MDM server that supported the Apple Education payload and student devices had to be supervised. Essentially, that describes a managed school deployment.

Apple Classroom 2.0 can now work without any of these requirements being met, albeit subject to a range of privacy limitations.

At its most basic, now, anyone can download the Apple Classroom app from the App Store and set up an ad-hoc class. However, the degree of control is limited because of privacy concerns. In Apple's terminology, these ad-hoc classes are called "unmanaged classes" and the MDM-provided classes are called "managed classes".

When a 'teacher' creates an unmanaged class, the class availability is broadcast via bluetooth. A new Classroom section appears in Settings where students can see available classes and join them. There is then a code-based confirmation step, as in many such enrolment systems, and then the 'students' are now in class.

The nice thing about this is that only the teacher device needs to have Apple Classroom installed. The client-side software is built into iOS 10.3 so, as long as all devices are up to date, there is no need to coordinate everyone getting the app installed before you can get to work.

Unmanaged classes, once created, are persistent and by default students will automatically re-join classes when the teacher opens the class in their Classroom app. This can be changed in Settings so that students have to be prompted to join the class before a teacher can control the device. Students can also un-enroll from classes at any time.

As unmanaged classes can be created on any device, the 'student' devices have a lot more control over their visibility and privacy than do students in managed classes provided by a school. In the first place, students can simply not enrol in the class. Secondly, the student has control over two privacy settings: "Lock Apps and Device" and "AirPlay and View Screen". These are two settings, each of which control two features.

Each of these settings has three possible values: Ask, Always and Never. The default for both is Ask. When a teacher tries to lock a device or view a screen, the student sees a permission dialog where they can "Allow" once or "Always Allow".

In a situation where a school has devices supervised in MDM but their MDM does not support creating Managed Classes, there is a restriction that removes students' control over these two settings so that they cannot refuse locking or screen viewing. This is only applicable to supervised devices, so that generally implies institutional control.

It's also worth mentioning that managed classes and unmanaged classes are mutually exclusive. You can't mix and match. If a teacher device has an Apple Education payload installed by MDM, it will not be able to create any unmanaged classes. Similarly, if a student device has an Education payload, it will not be able to join unmanaged classes. Under iOS 10.3, a student in a managed class can look in the Classroom settings, see which classes they are in and see which teachers have access to that class. The privacy controls for locking and screen viewing are hidden in this scenario.

Teachers in BYOD schools where the iOS deployment is not managed in any meaningful way might wonder whether the more general availability of Apple Classroom presents any kind of security or privacy problem for teachers if students were to come into school with Classroom installed on their devices.

Honestly, I don’t think so. In order to exercise control over another iOS device, the ‘teacher’ device has to create a class. The owner of the ‘student’ device then has to:

Unlock the device

Go to Settings > Classroom

Tap on the class name

Enter a code that’s only displayed on the ‘teacher’ device

Be accepted into the class by the ‘teacher’ device

That’s a pretty difficult process to go through accidentally.

The other question is about students creating their own unmanaged classes to control other students’ devices. Again, this would require the setup steps mentioned above and students can always delete any unmanaged class that is causing them difficulty. If your school has Apple Classroom support in MDM, turning it on prevents any problems.

Teacher Features

The major focus of Apple Classroom 2.0 is the loosening of these infrastructure requirements. The update also brings a few new features for teachers.

Firstly, the class list has been redesigned. This now allows you to reorder the classes and is a much more compact representation than the simple screen-wide table view of Classroom that was in Classroom 1.x.

The single new feature in the class view is the addition of a button that will immediately mute all the devices in the class. I'm sure this will be a welcome addition for many teachers! This is simply an action that sets the volume once but doesn't lock it.

The bigger feature in Classroom 2.0 is the enhancement to AirDrop. Classroom 1.x had a Share Sheet extension that allowed you to share URLs from Safari to your class. Classroom 2.0 takes this idea and supercharges it.

Classroom 2.0 has the idea of the "current class". That is, the class that you currently have open in Apple Classroom. This is why the "Close" button in Classroom has changed to "End Class".

While you have a class open, the system-wide Share Sheet gets a new trick. The current class, as well as any sub-groups that you have defined, appear as AirDrop targets at the top of the sheet.

What this means is that teachers can now share a URL, photo, video or any file, to the entire class in one tap. This far exceeds the capabilities of the old Classroom Share Sheet extension that only allowed sending URLs to students. Now, anything that can be AirDropped can be sent to the entire class in one go.

Between Classroom 2.0, recent enhancements to Swift Playgrounds and the new "education edition" 9.7" iPad, someone at Apple is clearly listening to the needs of education.