Today, Apple released WatchKit, providing the software tools necessary for developers to begin creating apps for the forthcoming Apple Watch. There are a lot of takeaways from the WatchKit Programming Guide and the rest of the accompanying documentation.

What is a Watch App

First, and most importantly, the bulk of the functionality for these apps is enabled through Watch Extensions contained within their companion iPhone apps. In other words, the iPhone is the workhorse for Watch Apps. Watch Apps consist only of a Storyboard and accompanying resources. This places a significant number of constraints on the apps that developers can make today. An iPhone must be nearby to run third-party apps, as launching a Watch App causes its Watch Extension to be launched simultaneously on the phone. Access to the specialized hardware and sensors of the Apple Watch is also largely restricted. The digital crown, taptic feedback, accelerometer, heart rate sensors, bluetooth, NFC, microphone—none of these can be used for input or directly manipulated except as allowed by built-in components. If you watched the original Apple Watch announcement, you may be disappointed to learn that many of the interactions and UI elements that were demoed in Apple’s own Watch Apps are not (yet) available to third-parties.

Apple also makes a few recommendations about iOS technologies and patterns to avoid, namely that background tasks, long running tasks, and tasks that might trigger requests for extended permissions should be avoided. That last one is a doozy: if your extension needs to ask for permissions the first time your Watch App is used, the prompt will appear on your phone and not the watch that likely has your user’s attention.

Despite the restrictive nature of Watch Apps, Apple’s WatchKit Press Release does give hope for a more fulfilling future for developers: “Starting later next year, developers will be able to create fully native apps for Apple Watch.” If you’ve been following Apple for any amount of time, this cautious, measured, iterative approach is not at all surprising. In fact, iOS 8 laid the groundwork for a lot of what we saw today. Extensions, Interactive Notifications, and Handoff are all necessary precursors to WatchKit.

Battery life and performance are integral to the success of the Apple Watch, and the concessions made in this first version of WatchKit should go a long way towards conserving energy. The Watch App is provided with 20MB of storage for an image cache that developers can use to store frequently shown dynamic images to avoid costly phone to watch transmissions. Likewise, dynamic changes to text and other UI elements are coalesced into batched operations. The announcements don’t mention how data is transmitted between the watch and phone, so it’s still unclear whether your phone’s bluetooth must always be on. The docs simply state that, “Through a series of transparent handshakes, your Watch app and WatchKit extension are connected to each other so that messages can flow between them”.

Oh, and if your plan was to monetize your Watch App directly, it won’t be easy. These apps are not sold separately. It may be possible to open up additional functionality through the use of In-App Purchase, but it’s unlikely that this will be the norm.

Glances and Notifications

In addition to the Watch App, there are two other ways that you can present information to users on the Apple Watch:

• Glances - a single-screen interface that is not interactive. Watch Apps are limited to one glance each. In some ways, these are analogous to Notification Center widgets on the iPhone.

• Notifications - both local and remote notifications can be displayed in custom interfaces. Initially, an abbreviated Short-Look Interface is displayed which is system provided, and shows only the app’s icon, title, and a custom notification string. If a user continues to view the notification, it will then transition into a Long-Look Interface, which has room for additional content and action buttons.

The WatchKit User Interface

WatchKit is an iOS technology, but it doesn’t rely on UIKit constructs¹; this is a UI framework of its own. There are currently two form-factors for the Apple Watch, 272x340 and 312x390. The screen is surrounded by a hardware bezel, so interface elements should span the full width of the screen; there’s no need for extra padding. The top-level UI element is an Interface Controller—UIViewController without the extra baggage.

Interface Objects. Eleven types of interface objects are available to developers, each carrying the WKInterface prefix: Button, Date, Group, Image, Label, Map, Separator, Slider, Switch, Table, and Timer.

Images. All Apple Watch screens are “retina”, and as such, accept @2x-named images. They can be provided as a single image, or as a sequence of images. Image sequences are a Watch App’s only means for custom animation.

Text-Input. There is no text field element, but controllers can present a modal interface for input. The text-input interface includes a list of app-specified suggestions, access to emojis, and allows for users to provide their own response via dictation.

Layout. Interface objects are not placed at set coordinates, but instead flow from top to bottom on the watch’s screen. Groups can be used as containers to horizontally or vertically organize objects. Interface objects can also be sized relative to their containers and given vertical and horizontal alignments. If you’ve ever created an web page entirely with HTML tables, you should feel right at home. Every interface must contain all possible elements in advance. Interface objects can be hidden at runtime, but cannot be added.

Gestures. Gestures are not available, so you must design your interfaces wisely, such that a tappable group is part of a Button (or table row). Force Touch is only intended for bringing up context menus, so it is also off limits to developers for other uses.

Navigation. Watch Apps have two navigation styles: page-based and hierarchical. You can also present a modal interface, when you need to temporarily interrupt a workflow. Unlike iOS, on the Apple Watch, color is not to be used as the sole indicator of interactivity.

Fonts. The default system font is designed by Apple and called San Francisco². Custom fonts can also be used.

Handoff. Interface Controllers are also capable of coordinating handoff activities to pass context from Glances to Watch Apps, or from Watch Apps to their iPhone counterparts.

¹   _{Technically, it’s all UIKit under the hood, as the private PepperUICore framework reveals. That’s also a good indication that the Apple Watch will indeed be running iOS.}

²   _{Homage to one of the original Apple Macintosh typefaces, as pointed out by John Gruber.}

For as long as developers have been creating apps in the Apple ecosystem, distributing prerelease (or ad hoc) versions of apps has been troublesome. There are many pain points, but they have largely boiled down to:

• Ad Hoc Distribution is based on Provisioning Profiles, which set a hard limit on the number of testers that can participate. Deleting entries in a profile does not free up a new slot in that profile until the yearly anniversary of the developer program.
• Each entry in a Provisioning Profile is a unique device, not a unique user. That means when testers upgrade their devices, additional slots are required. If you’re building a universal app, you’ll need room for a tester’s iPhone and iPad.
• Devices are assigned using a Unique Device Identifier (UDID) of their devices. Non-developers are generally unaware that this identifier exists or how to retrieve it.

Third-party businesses have sprung up to improve the process including TestFlight, HockeyApp, and Beta by Crashlytics, though the 100 device limitation is inherent to the process. Some developers have also turned to the Enterprise Program to work around these limitations, though Apple’s terms state that the program is intended only for distribution to in-house employees.

So, when Apple acquired Burstly, the owners of TestFlight, in early 2014, they raised a lot of questions for the developer community. Many of us were hopeful that this signaled a sea change. A few months later, at WWDC, Apple revealed their future plans for the product, including internal and external iOS beta-testing integrated directly into a refreshed new version of iTunes Connect. The number of external testers was upped from 100 to 1000, and were now tied to Apple IDs. The OS would even identify beta apps installed on a device with an amber circle below the app’s icon, and notify users when new builds were available. Developers rejoiced, though with some hesitation, as this beta process was now also subject to Apple Review. Apple opened the doors to this new external testing process on October 23. There was no mention of a timetable for how long the previous TestFlight process would remain intact at testflightapp.com.

For those who distribute their pre-releases regularly through continuous integration, this is a significant concern. For starters, the Apple Review process largely limits how quickly builds can get into the hands of testers. Further, Apple has not made an API available to programmatically submit and distribute these apps — an omission as compared to the feature-set of the original TestFlight. Some developers have resorted to scripting against iTMSTransporter and creating an .itmsp metadata package, but there is simpler, lesser known tool that can be used, found deep within Xcode and Application Loader called altool.

$ /Applications/Xcode.app/Contents/Applications/Application\ Loader.app/Contents/Frameworks/ITunesSoftwareService.framework/Support/altool -h 
Copyright (c) 2009-2014, Apple Inc.  Version 1.0

Usage: altool -v -f file -u username -p password
       altool --upload-app -f file -u username -p password

 -f, --file                Filename.
 -u, --username            Username. Required to connect for validation and upload.
 -p, --password            Password. Required if username specified.

 -v, --validate-app        Validate an archived app. The username, password, and file path to app archive are required.
     --upload-app          Uploads the given app.  The username, password, and file path to app archive are required.

 -h, --help                Display this output.

It enables developers to programmatically upload an ipa to iTunes Connect in the following way:

$ altool --upload-app -f /path/to/app.ipa -u USERNAME -p PASSWORD

That said, it doesn’t automate the process of distributing apps to testers. There is still no means to populate app release notes or other required fields of the prerelease process. There is also no way to start the Apple Review process, or send an email to testers after the review is approved. Some are beginning to experiment with the internal API that the new iTunes AngularJS front-end uses, so perhaps it’s feasible to hack a complete solution together.

If you’re simply looking for a way to upload an ipa to iTunes Connect from your CI server though, altool is your friend.