Archive for the ‘WWDC’ Category

Playgrounds Part II

Apple’s pretty highlight page on Swift Playgrounds is here.

Screen Shot 2016-06-14 at 8.09.21 AM

Jonathan Penn figured out how to send documents between my Mac and iPad: just use AirDrop. With that tip, I was easily able to create content on the iPad and move it Macwards and see the material that Apple provided itself.

Here’s how to go from iPad to Mac:

  1. Open AirDrop on your Mac
  2. Tap “My Playgrounds” (4 squares)
  3. Tap Action (top-left, square with arrow pointing up)
  4. Tap the playground you want to send
  5. Tap an AirDrop destination
  6. Wait for the transfer.

iPad Playgrounds use a new format: “Playground Book”:

Screen Shot 2016-06-14 at 8.14.51 AM

It consists of the playground’s contents and user-created edits (stored as a diffpack), which are stored separately. The contents consist of chapters, which in turn have individual playground pages, shared resources and sources. It’s basically the playground we’ve come to know and love on steroids and hallucinogens.

Want to know more about playgrounds? I have a fairly extensive book on playgrounds that’s available right now, which you may be interested in checking out.

The iPad playgrounds app consumes at least two kinds of playground pages: standard pages and cut scenes. These are included as parts of a playground book, which consists of playground chapters, in which the pages and cut scenes are stored. You can read more about the Playground Book Package Format on Apple’s website. (Thanks to Matt Gallagher for the pointer.)

I’m going to warn you in advance that Swift does not play a huge rule in cut scenes. Instead, the cut scenes were constructed using HTML and Javascript. I’ve pasted a fairly short cut scene here, along with a screen shot of some of the resources to create just this one element:

Screen Shot 2016-06-14 at 8.18.42 AM

<!DOCTYPE html>
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
 <meta http-equiv="X-UA-Compatible" content="chrome=1,IE=edge" />
 html {
 body {
 <!-- copy these lines to your document head: -->

 <meta name="viewport" content="user-scalable=yes, width=1024" />

 <script type="text/javascript" src="simpleCommands.hyperesources/StopPoints.js"></script>
 <script type="text/javascript" src="simpleCommands.hyperesources/HypePagingSupport.js"></script>

 <!-- end copy -->
 <!-- copy these lines to your document: -->

 <div id="simplecommands_hype_container" style="margin:auto;position:relative;width:1024px;height:768px;overflow:hidden;" aria-live="polite">
 <script type="text/javascript" charset="utf-8" src="simpleCommands.hyperesources/simplecommands_hype_generated_script.js?65524"></script>
 <!-- end copy -->
 <!-- text content for search engines: -->
 <div style="display:none">
 <div>Simple Commands</div>
 <div>Your goal is to figure out which instructions, in which order, will result in something great.</div>
 <div>Writing code allows you to create your own set of instructions for your iPad to carry out.</div>
 <div>Notice the mashed-together words? Code is punctuated and spaced like human languages, but commands have no spaces between words.</div>
 <div>You need to follow the instructions in the correct order, or you'll end up with something…unexpected.</div>
 <div>For example, you'll tell Byte to move forward:</div>
 <div>Commands always end with parentheses. You'll see why later!</div>
 <div>You’ll start by writing commands to move a character named Byte around a puzzle world, performing tasks.</div>
 <div>Now it's your turn to write some code!</div>
 <div>Have you ever followed a recipe to bake something delicious?</div>
 <div>Or followed instructions to assemble something cool?</div>
 <div>Learn to Code
 <div>Or collect a gem:</div>
 <!-- end text content: -->

Yeah, I know.

Playground pages include separate Contents.swift and LiveView.swift files, which really surprised me.  The Live Views use a poster asset (simple JPG), and there’s a metric ton of Super Sekrit meta-comment annotation for setting up each page:

 **Goal:** Find the bugs and fix them.
 When you write code, it’s easy to make mistakes. A mistake that keeps your program from running correctly is called a [**bug**](glossary://bug), and finding and fixing bugs is called [**debugging**](glossary://debug).
 The code below contains one or more bugs. To debug it, rearrange the commands into the right order to solve the puzzle.
 1. steps: Run the code to see where the mistake occurs.
 2. Identify the command that's in the wrong place, then tap it to select it.
 3. Drag the command to the correct location, then run the code again to test it.
//#-code-completion(everything, hide)
//#-code-completion(identifier, show, moveForward(), turnLeft(), collectGem(), toggleSwitch())
//#-editable-code Tap to enter code
// Contents.swift
// Copyright (c) 2016 Apple Inc. All Rights Reserved.

As you see, you can control which elements are presented to the reader/user/coder, to allow a subset of coding to be accomplished with simple taps. It’s a pretty limited approach for end-user consumption.

The entire system is run using a new PlaygroundSupport library, which appears to be iPad only for the moment but will replace XCPlayground, presumably soon in Xcode 8 (despite this screen shot).

Screen Shot 2016-06-14 at 9.20.59 AM

According to docs, the PlaygroundSupport module enables you to access a playground page and manage execution, display and dismiss live views, and share and access persistent data, which you use for creating a consistent experience throughout the interaction with your playground book.

A quick check shows that you can refer to: PlaygroundPage (for page state control), PlaygroundValue, PlaygroundQuickLook (should act like the current version), PlaygroundLiveViewable (protocol for live-view suitable types), PlaygroundKeyValueStore (for persistent data storage), PlaygroundRemoteLiveViewProxy,  PlaygroundLiveViewMessageHandler, PlaygroundLiveViewRepresentation  (type enum for items that can act as live views), PlaygroundRemoteLiveViewProxyDelegate.

Carl Brown tracked down some of this in the “Answers” example playground, which uses custom show() and ask() functions built around these new features.

For example, the AnswersLiveViewClient class works as a proxy delegate for interactions in the live view. It’s a subclass of the Apple-supplied PlaygroundRemoteLiveViewProxyDelegate class that acts as a PlaygroundLiveViewMessageHandler for receiving and processing live view requests.

As far as I can tell, there are not yet any tools on the Mac side that build these pieces. So don’t go looking for iPlaygroundAuthor or even an iPlaygroundBookstore quite yet.

Screen Shot 2016-06-14 at 8.35.34 AM

So what is this entire app good for then? Other than some goodwill Apple outreach? Well, it’s cool having interpretable Swift on your iPad (take that original App Store restrictive rules!) and it’s clearly meant for an audience that accepts limited tap-based interaction, with a lot of beautiful highly designed iBooks-Author-esque HTML support.

Without tools to create content (yet) or a storefront to distribute and potentially monetize, it feels like a proof of concept more than an app. We’ll see how things (if you pardon the pun) develop.

iOS Playgrounds

Screen Shot 2016-06-13 at 4.59.35 PM

Really early days:

  • App is baked into iOS 10. Just install a beta to your favorite (newerish) iPad.
  • Houdah’s Type2Phone is the best for working with iOS playgrounds. Really great for copy/pasting.
  • Some (but not all) Emacs keybindings work, which makes editing much easier. However, ^A/^E don’t respect the onscreen folding, so in squish mode, they’ll jump to the start and end of each \n-delineated line, not the folded version.
  • I can’t figure out how to get things onto and off of the iPad: tried emailing playgrounds, playground pages, tried going through iTunes, looked in Xcode, even used PhoneView (Ecamm) and iBrowser (my little hack app) to try to track this stuff down. No luck so far.
  • XCPlayground seems to be PlaygroundSupport — took me forever to figure that out because it’s still XCPlayground on the desktop. And of course, all the new ObjC name import stuff isn’t working as expecting, so you do have to hunt around. Live views are PlaygroundPage.current.liveView assignments.
  • To see both code and live view (or just live view), slide from the right.

Lots still to explore!


WWDC Thoughts

Screen Shot 2016-06-13 at 12.42.33 PM

This year, Apple offered a particularly subdued WWDC keynote introducing refreshes along all its product lines with few surprises or innovations. While the audience was politely enthusiastic, I’m not sure the tech press will be wowed.

I love the iOS playgrounds, although I think this is a better opportunity for institutions (say, Stanford) than little tutorial writers, and I got Sherlocked. Xcode introduces source editor extensions and there’s a Siri API using extensions.

Screen Shot 2016-06-13 at 1.06.26 PM

The download and upgrade process for Xcode, OS X (I mean macOS), and iOS has been amazing — just a dream process compared to previous years. Everything is operating smoothly from updating the conference schedule to providing bandwidth for desperate developer downloads. Fingers crossed this continues as well as it has started. I’m amazed at how clean the download site is, how simple the configuration profile approach is working (“Can I temporarily remove some large apps for space and re-install them later?” “Why YES!”). Big applause to whoever made these improvements.

Looking forward to the state of the union later today.



  • What’s new in Swift: Tues 11-11:40
  • Getting Started with Swift: Tues 2:40 – 3:40
  • What’s new in Foundation for Swift: Tues 5 – 5:40
  • What’s new in LLVM: Tues 6-6:40


  • Introducing Swift Playgrounds: Weds 12-1
  • Modern Best Practices: Weds 4-4:40
  • Swiftogether: Weds 7:15-8:45


  • Using and Extending Xcode’s Source Editor: Thus 6-6:40


  • Server-side with Swift Open Source: Fri 10-10:40
  • Swift Performance: Fri 12-1
  • Debugging Tips & Tricks: Fri: 2:40 – 3:40
  • Concurrent GCD w/ Swift: Fri 5-5:40
  • Protocol and Value Oriented Programing (in UIKit Apps): 5-5:40

Not Swift:

  • What’s new in Cocoa: Tues 12-1
  • What’s new in Cocoa Touch: Tues 2:40-3:40
  • Typography and Fonts: Weds 10-10:40
  • Speech Recognition API: Weds 5-5 (!?)
  • Intro to SiriKit: Weds 6-7
  • Extending Apps with SiriKit: Thus 2:40-3:40
  • What’s new in GameplayKit: Thus 10 – 10:40
  • Making Apps Adaptive: Thus 12-12:40, Fri 10-10:40
  • Proactive Suggestions: Fri: 2:40-3:40
  • Measurements and Units: Fri 5-5:40

Also: Some nice internationalization and accessibility sessions, a couple of worthy “adopting Metal” sessions, CloudKit best practices

iOS 10 Compatible Devices

I think this is probably the most reliable screenshot:

Screen Shot 2016-06-13 at 1.43.05 PM

There’s also this:

Screen Shot 2016-06-13 at 12.46.07 PM

and this:

Screen Shot 2016-06-13 at 1.46.51 PM

macOS Sierra Compatible Devices

Screen Shot 2016-06-13 at 1.59.25 PM


Nostalgia Tuesday: By request, my 2012 Siri Post

Well, if anything does happen on Monday, we can play “How badly did she get it wrong“, right? And to add some icing, here’s a what-if post about Siri controlling your Apple TV and a proof-of-concept Siri-style dictation used in-app.

(There’s a comment on the video that I particularly love: “Scammer watch the mouse across the screen at the end.” I hate to destroy the tinfoil but I was feeding the Apple TV output through EyeTV and recording the output on my Mac. Bless that person’s conspiratorial heart.)

How 3rd Party apps might integrate with Siri

Third-party integration into Siri remains at the top of many of our TUAW wish lists. Imagine being able to say “Play something from Queen on Spotify” or even “I want to hear a local police scanner.” And Siri replying, “OK, you have two apps that have local police scanners. Do you want ScannerPro or Wunder Radio?”

So why doesn’t Siri do that?

Well, first of all, there are no third party APIs. Second, it’s a challenging problem to implement. And third, it could open Siri to a lot of potential exploitation (think of an app that opens every time you say “Wake me up tomorrow at 7:00 AM” instead of deferring to the built-in timer).

That’s why we sat down and brainstormed how Apple might accomplish all of this safely using technologies already in-use. What follows is our thought experiment of how Apple could add these APIs into the iOS ecosystem and really allow Siri to explode with possibility.

Ace Object Schema. For anyone who thinks I just sneezed while typing that, please let me explain. Ace objects are the assistant command requests used by the underlying iOS frameworks to represent user utterances and their semantic meanings. They offer a context for describing what users have said and what the OS needs to do in response.

The APIs for these are private, but they seem to consist of property dictionaries, similar to property lists used throughout all of Apple’s OS X and iOS systems. It wouldn’t be hard to declare support for Ace Object commands in an application Info.plist property lists, just as developers now specify what kinds of file types they open and what kind of URL addresses they respond to.

Practicality. If you think of Siri support as a kind of extended URL scheme with a larger vocabulary and some grammatical elements, developers could tie into standard command structures (with full strings files localizations of course, for international deployment).

Leaving the request style of these commands to Apple would limit the kinds of requests initially rolled out to devs but it would maintain the highly flexible way Siri users can communicate with the technology.

There’s no reason for devs to have to think of a hundred ways to say “Please play” and “I want to hear”. Let Apple handle that — just as it handled the initial multitasking rollout with a limited task set — and let devs tie onto it, with the understanding that these items will grow over time and that devs could eventually supply specific localized phonemes that are critical to their tasks.

Handling. Each kind of command would be delineated by reverse domain notation, e.g. When matched to a user utterance, iOS could then launch the app and include the Ace dictionary as a standard payload. Developers are already well-acquainted in responding to external launches through local and remote notifications, through URL requests, through “Open file in” events, and more. Building onto these lets Siri activations use the same APIs and approaches that devs already handle.

Security. I’d imagine that Apple should treat Siri enhancement requests from apps the same way it currently works with in-app purchases. Developers would submit individual requests for each identified command (again, e.g. along with a description of the feature, the Siri specifications — XML or plist, and so forth. The commands could then be tested directly by review team members or be automated for compliance checks.

In-App Use. What all of this adds up to is an iterative way to grow third party involvement into the standard Siri voice assistant using current technologies. But that’s not the end of the story. The suggestions you just read through leave a big hole in the Siri/Dictation story: in-app use of the technology.

For that, hopefully Apple will allow more flexible tie-ins to dictation features outside of the standard keyboard, with app-specific parsing of any results. Imagine a button with the Siri microphone that developers could add directly, no keyboard involved.

I presented a simple dictation-only demonstration of those possibilities late last year. To do so, I had to hack my way into the commands that started and stopped dictation. It would be incredibly easy for Apple to expand that kind of interaction option so that spoken in-app commands were not limited to text-field and text-view entry, but could be used in place of touch driven interaction as well.


If I had my druthers: Swift 2.2, Swift 3.0, ABIs, etc

If I could wave a magic wand, I’d push Swift 3.0 out by a year or even better three years and fix Swift 2 as the standard App Store language (and for Linux, and upcoming Windows) exactly as is, barring a few tweaks and fixes over this time.

[tl;dr summary: Make big breaking changes later and once rather than sooner and multiple times. If a delay allows a single stable language transition, it is to be preferred. Aim for post-3.0 language updates to be additive not transformative.]

Swift 2.2 is a great language. It’s amazing to work in. It offers utility and concepts that Objective-C cannot provide. It pushes iOS and OS X development forward in an important and exciting way, affecting development not just on Apple platforms but wherever Swift touches. From first class structure and enumeration types to protocol oriented programming, Swift 2.2 delivers the goodies.

If you need just one compelling single example, take CGRect: Swift 2.2 lets you expand this essential structure with methods and properties that let you center on a zero origin, or scale and transform, or add math to combine instances. It’s so practically useful that going back to ObjC to work in geometry metaphysically hurts.

Swift 2.2 gets it right in so many ways, that it seems ridiculous to throw it away at the end of the year. A language this good should have a lifetime longer than 8 or 10 months. I’d be really happy if at the WWDC keynote, Tim Cook said, “We got it so right, we’re going to stick with Swift 2, let you build your code for long term use, and make sure the transition to Swift 3 will be perfect.”

The move to Swift 3.0 isn’t just going to be disruptive. It’s going to be traumatic. With its expansive renamification and redesigned core types and APIs, Swift 3 is going to be a tidal wave of retraining and refactoring. And with a list of objectives that didn’t quite make the cut, and a laundry list of of items that should have, Swift 3 just doesn’t have enough time or scope to be perfected.

So why not just push it back?  Let us devs use Swift 2.2, which is terrific, for a few more years and get Swift 3 right the first time?

It’s not as if Swift Evolution needs to be fast paced and hectic. The bikeshedding, the simple natural discussion overhead, the need to foster a courteous open source community means the natural speed of development has taken a huge hit.

These arbitrary “update every year” advances that Apple has bought into are more than a little ridiculous when it comes to firmware and OS updates; for languages it pushes beyond the practical.

Orson Welles promised that Paul Masson would sell no wine before its time. Apple should take a lesson from Welles and ship no language before the follow-up version has properly evolved.

I want to see Apple slow down, take some deep breaths, and seriously consider letting Swift 2.2 come into its own rather than cutting it down after a few months of use.

As it is, I am constantly having to answer “Is it time yet to switch to Swift?” As this breakneck development continues, I’ve been hesitant to recommend jumping aboard the Swift train for simple practical reasons.

I’d be far more confident with my advice if I could see a 2-3 year window with stable code that could benefit from Swift’s modern language features, and a payoff of investment in training and refactoring that won’t have to be re-addressed with each new beta and each new release.

To paraphrase a line from Aesop, slow and steady really does win the language race.

Like my posts? Consider buying a book or two or three. Thanks!

What you need to know

I will keep updating this post. The downloads are on the new developer site in Resources > [technology] > Download


Where this apparently ridiculous term comes from.


If I’m reading this correctly, it’s full steam ahead:

You will not be bound by the foregoing confidentiality terms with regard to technical information about pre-release Apple Software and services disclosed by Apple at WWDC (Apple’s Worldwide Developers Conference), except that You may not post screen shots of, write public reviews of, or redistribute any pre-release Apple Software, Apple Services or hardware.

This is pretty much identical to what Ole Begemann found in last year’s terms.

Swift 2.0

Swift updates to version 2.0. What’s new in Swift 2.0 page is now live. Read here.

  • A pre-release version of both the Swift Programming Language and the Cocoa book are now available in the US iBooks store.
  • New language features.
  • If you do not have access to the US store, you can read the online docs at this link.
  • Get your fresh Swift Standard Library reference here.

This bit is my favorite: The SDKs have been updated to annotate API that cannot return nil so you don’t need to use optionals as often.

Swift 2.0 supports error handling:

func loadData() throws { }
func test() {
 do {
    try loadData()
 } catch {

Swift 2.0 adds syntax to support:

  • Powerful control flow with do, guard, defer, and repeat
  • Keyword naming rules unified for functions and methods
  • Protocol extensions and default implementations
  • Extended pattern matching to work in if clauses and for loops

Swift 2.0 also provides availability checking for language and API features. You’ll find more information about Swift 2.0 on the Swift dev blog.

WWDC Sessions

The WWDC session schedule is now live.

Developer Program

The iOS and Mac programs have merged into a single membership.

The new Apple Developer Program combines everything you need to develop, distribute, and manage your apps on all Apple platforms into one single program, making it easier than ever to bring your creativity to over a billion customers around the world. Get your apps ready for the App Store on iPhone, iPad, Mac, and Apple Watch, by enrolling in the Apple Developer Program today.

There’s a transition page that doesn’t seem to be live quite yet. This is the link to it (for when it does go live).

Edit your and bookmarks. They no longer work. Point your browser to instead.

Technology overview pages are live. Read about watchOS 2, iOS 9, OS X Elk(apitan) here.

The Developer program no longer requires you to be a paid member to test on devices:

Xcode 7 and Swift now make it easier for everyone to build apps and run them directly on their Apple devices. Simply sign in with your Apple ID, and turn your idea into an app that you can touch on your iPad, iPhone, or Apple Watch. Download Xcode 7 beta and try it yourself today. Program membership is not required.

Paid membership is still required for pre-release access and other familiar benefits.

Xcode 7

What’s new in Xcode 7

Xcode 7 includes everything you need to create amazing apps for iPhone, iPad, Mac, and Apple Watch. The Swift programming language has been updated and is now faster than ever, with great features that make your code even easier to read and write. And with the new playgrounds you can experiment with new APIs or author gorgeous interactive documentation using embedded resources, additional source code, and rich text comments. Xcode’s user interface testing feature can even record your app in action and generate tests for you.

New features include code coverage (which bits of your source are tested), UI Testing (“ensuring that changes you make in code don’t show up as unwanted changes to your users”), iOS Energy gauge (“The new iOS energy gauge alerts you to times when your app is using significant energy”), and more. Full details here.

Download your copy of Xcode 7 here. (4.22 download. 8.7 GB install. Holy crap.) Release notes here.


“App Thinning”/Slicing similar to what I suggested here. Apps will automatically update to new processors without having to lipo your builds.

The App Store will allow 64-bit-only software submission starting later this year.

Interface Builder

Screen Shot 2015-06-08 at 2.26.41 PM

Interface Builder adds a new constraint visualization tool so you not only see the list of constraints, you get a rough idea of how they fit into your design.


ObjC introduces generics. Can’t wait to play!

Dev Forum

Get your premium dev forum user id now. I just snagged “erica”. W00.


Download your own copy of the San Francisco font here.