An honest look at the WWDC announcements

profile picture

David Tech Lead

23 Jun 2016  ·  12 min read

Our Apple Tech team talks messages, Swift, and more as they share their takeaways from last week’s WWDC opening keynotes.

For us iOS developers, the month of June always brings some pretty big news from Apple. Livestreaming the opening keynote of WWDC is a tradition at November Five!. Even though some of us were already pretty hyped up about the European Championship soccer match against Italy and/or our weekly Game of Thrones episode viewing that same day, our dedicated Apple Tech Team and fanclub still assembled in front of the big screen on Monday evening… with pizza and beers, of course.

Of course, there’s plenty of articles to be found that recap Apple’s latest announcements if you couldn’t find the time to watch the keynotes yourself, so we figured we’d take a slightly different angle. In this week’s blog post, we decided to let you get to know our Apple Tech team a bit better! David, Seppe, Bart, Yannick and Jens talk about the best, worst and weirdest announcements from the past WWDC.

Let’s lead with the good stuff: our favourite announcements from WWDC 2016

Bart: I was very keen to see the updates to Swift. Since its initial release two years ago, Swift has seen a steep adoption curve, even more so ever since Apple open sourced it last December.

However, one disadvantage of a young programming language such as Swift is that everyone knows that it’s still in development – syntax and conventions are bound to change over time. We’ve seen this during the transition between Swift 1 and Swift 2. Porting an existing project from one to the other takes time, which developers sometimes just don’t have. And because the version of Swift is tied to the version of Xcode, not knowing what’s going to change to the language in the future is a valid concern.

With Swift 3 we’re starting to see the positive results of Swift going open source. There is now an open roadmap, meaning the community is completely in the loop on all upcoming changes to the language, but is also able to contribute. Over 100 proposals have been made, from the community, on how Swift should evolve in the future. The goal of Swift 3 is to get rid of all the early issues that previous versions of Swift suffered from and create a stable foundation for years to come.

Jens: I agree. Swift 3 is pretty much the version we’ve all been waiting for. This version is a big change for the language: the latest changes in the syntax make it much more readable and comprehensive and thus also more fun to use. Now that Swift is moving to other platforms as well, it’s quickly becoming a programming language not only Apple developers should take note of. As for our team – I’m not saying we’ll be abandoning Objective-C entirely, but with Swift 3, the language will definitely play an important role in our development process.

Swift Playgrounds

And while we’re on the topic: let’s not forget the announcement of Swift Playgrounds. Apple is convinced every kid today should learn to write code, and with Swift Playgrounds for the iPad, they’re trying to promote that vision. The app is aimed at teaching children to write code and develop apps in a fun way. The most exciting part for me is that Apple intends to open up the platform later this year, which means experienced developers will be able to create additional content for less experienced developers to learn from. I think this has the potential of replacing some existing teaching tools and that it will be highly beneficial for developing technical and logical thinking skills in children.

Also, kudos to Apple again for the way they handle their users’ private data by using differential privacy.

David: For me, the biggest announcement preceded WWDC: the shortened review times for the App Store. Every application that is submitted to the App Store goes through an extensive review process where Apple employees manually test your application. Up until now, these review times would vary a lot, ranging from a few days (if you were lucky) to a whopping 3 weeks (if you were extremely unlucky). Because of this, we currently calculate a two-week buffer period for iOS app submissions at November Five. Of course, for many projects, this is not ideal: sometimes things change quite late in development, and there’s always the chance of a last minute feature that needs to be added or removed, a backend issue that isn’t discovered until late…

So in short: these long and unpredictable review times have been a thorn in many iOS developer’s sides for ages. But several weeks ago, we started noticing a different trend. Our applications would consistently get approved between one to two days after submission. It quickly became clear that we weren’t the only ones doing a little happy dance in their seats. Shortly before WWDC, Apple’s Phil Schiller confirmed that internal policy and staffing changes along with tool improvements will lead to 50 percent of all apps to be approved within 24 hours and 90 percent within 48 hours. This seemingly small change is huge for us: we can now decrease the buffer time, resulting in more flexibility for the client, faster release cycles and faster bug resolving.

Seppe: Another thing that wasn’t mentioned during the keynote (and probably flew under many people’s radar) is that, under iOS 10, a select number of iOS devices will be able to shoot RAW photos. In other words, these are exciting times for iPhone-toting photography enthusiasts. Shooting in RAW will greatly improve post-processing options. The best part: this functionality is not limited to the native camera app. Developers can implement it in their camera apps, too! You’ll be able to shoot RAW photos using the rear camera of the latest iOS devices: the iPhone 6S, 6S Plus, and SE, and the 9.7” iPad Pro.

RAW photography with iPhone

I’m also very glad that SpriteKit and SceneKit are coming to watchOS. In watchOS 2, animations were mostly limited to image sequences, but the arrival of SpriteKit and SceneKit opens a whole new world for games and entertainment apps on the Apple Watch.

Yannick: The Apple Watch announcements were also my favourites. I’m really impressed by the performance improvements of watchOS 3, especially since watchOS 2 was already a big improvement over the first version. Apps will now launch up to 7 times faster than on watch OS 2. The system will remember the user’s favourite apps, and keep them in the new dock you can reach by pressing the side button below the Digital Crown. This will allow them to be launched almost instantly.

WatchOS 3 now also supports background syncing, something iOS has had for a couple of years now. Applications will be notified by the system when they need to update their data, so that it’ll already be there when a user opens the app. In addition, Apple has updated the way a user navigates through a watchOS app, reducing the number of interactions necessary to fulfill his intentions.

Watch and watchfaces

And finally, we got access to more hardware features of the Watch, such as real time access to the heart rate monitor, accelerometer and gyroscope, additional types of Digital Crown input, new gestures and much more. This will greatly improve the creativity and possibilities for watchOS developers!

David: And of course, let’s not forget the Minnie Mouse watch face :)

(Constructive) criticism: the less convincing bits

David: While I was watching the opening keynote, the elaborate section on Messages left a sour taste in my mouth. I can’t believe Apple spent over 20 minutes talking enthusiastically about some fireworks effects, selfies, (bigger) emojis and stickers… These additions seem incredibly gimmicky to me – they’re things you’d expect in a third-party messaging app, not the official messaging app of your device. Where is the time when Steve Jobs said that the most used functionalities of a phone were calling and messaging and therefore these apps should be kept as simple as possible?

I can already imagine the ways these effects will be abused and overused in the first weeks after the release of iOS 10. And if the built-in effects weren’t cheesy enough already, Apple also announced a Messages app store, where developers can publish their own Messages extensions and effects. Creating these mini apps will be so easy, I’m pretty sure everyone with a Mac and $99 to spare for a developer account will cobble something together trying to earn a quick buck. I fear for the App Store’s Top Charts list when iOS 10 is released…

Seppe: I’m not too worried – for power users these features may sound silly and useless, but you just know that the whole world will go crazy for these effects. And I can’t blame them: sometimes sending messages with emojis and “lame” effects is just fun! Our office Slack channels are proof of that…


Bart: I’m quite sceptical about Messages as well. And despite all the new (and often welcome) features that are being introduced in iOS 10, there’s nothing really groundbreaking that we haven’t seen before in third-party apps or on other platforms. I was also disappointed by the announcements concerning Siri. The prospect of being able to include Siri in our apps sounded great during the keynote, but it was then revealed that this functionality would be rather limited. Only apps used for messaging, VoIP calling, payments, booking rides, searching photos and fitness will be able to benefit from this new Siri integration.

Jens: I’m actually pretty satisfied with the announcements made during this WWDC – no big disappointments for me!

Let’s talk dev: the improvements with the biggest impact

David: The changes to Xcode 8 contain improvements that developers have been asking for for years, and then some. Apple has really (finally) listened to the community. Sure, several of the new features (line highlighting, inline color and image picking) are things that we’ve been using for years thanks to a number of plugins, but even for those, it’s nice to see them become standard.

Seppe: I’m especially happy that Xcode 8 will finally have official support for plugins, or Xcode App Extensions as they are now called. We’ve all used Xcode plugins in the past, but making them was far from easy. Documentation was almost non-existent; you had to figure everything out by yourself or by looking at existing plugins; installing a plugin was a hassle; and every time Xcode was updated through the App Store, your plugin was usually gone and had to be reinstalled. I was a happy user of Alcatraz, a plugin manager for Xcode, which helped with installing and managing plugins, but this of course didn’t solve the pain of actually developing one.

Xcode App Extensions will allow developers to write a plugin and distribute it through the App Store for all to download. On the downside, an Xcode App Extension (like every other extension on macOS or iOS) runs in a separate process in a sandbox. This means that the extension has only limited access to what the user is doing in Xcode, while an “old” plugin has near-complete access.

Jens: I especially like the Memory Debugger. When they premiered it during the State of the Union presentation, the crowd went wild, and for good reason. Finding memory issues has always been a tedious job: they’re challenging to identify and often not that easy to fix. However, the new Memory Debugger in Xcode 8 is going to improve this process considerably! You can now see a graph for each object that is being retained in memory by your application, and check which other objects are keeping a reference to it. This makes it very easy to spot objects that are being kept in memory but shouldn’t be.

Memory and view debugger in Xcode 8

David: There’s also quite a few improvements to the Interface Builder this time around, including one I’ve wanted since I first started using Interface Builder all these years ago: zooming. Yes, it’s finally possible to zoom in and out, both in Xibs and Storyboards. This might seem like a very small addition, but if you’ve ever tried working with tvOS Xibs on a Macbook, you’ll know what I’m talking about.

Another huge improvement was made to the View Debugger, which, just like the Memory Debugger, was greeted with a huge applause. When using Auto Layout to create the layout of an application’s UI, every view has a set of rules for how it reacts with other views. These are called View Constraints. Sometimes these rules can conflict with one another; this means one of the rules you’ve set up for the UI has to be broken, which results in a UI state you may not expect. Previously, debugging these issues was a huge pain. You’d receive a very cryptic error message from Xcode, and had to set off on an adventure quest trying to figure out which views and which constraints were affected. The improved View Debugger now does this for us: it shows exactly which views are affected by the issue and which conflicting constraints are causing it.

Yannick: I’m also really impressed by the new features in the Interface Builder! Since the release of iOS 9 last year, we’ve had multitasking on a number of iPads, which means our applications are being run in more different sizes. With Xcode 8, it’s easy to preview all the different ways an application can be displayed on multiple devices. This makes it much simpler to make adjustments for each specific situation. I also really like the zoom functionality, which will allow us to make our apps even more pixel-perfect than they already are.

Another major improvement is the new automated code signing. For years, code signing has been a major hassle for iOS developers, and adding an extension or Apple Watch app to a project made it even worse. Apparently, the Xcode team is aware of this; they joked about it during the keynote, even going as far as admitting that their previous solution was more frustrating than the original problem (this is genuinely true). Luckily for everyone, they’ve learned from their mistakes. Code signing has been rebuilt from the ground up for Xcode 8, which means it should now be handled completely automatically (fingers crossed).

Bart: Also improved in Xcode 8 is the API reference documentation. Before, the documentation came as an additional download that had to be installed separately after each major Xcode update. Unless you knew exactly what you were looking for, I’ve always found the documentation hard to navigate. In most cases, just looking up a particular problem through Google was faster than wading through the local API reference! In Xcode 8, the API reference comes included and is immediately available offline. And thanks to fuzzy matching, it will now be easier than ever to find exactly what you’re looking for.

All in all, an interesting edition – we’re all looking forward to putting some of these new features and additions to use…