WatchKit | Hacker News Reader

WatchKit

developer.apple.com

396 pointsuptown85 comments

Open articleView on HN

There are actually 4 different types of Apple Watch apps:

1. Glances

2. Actionable notifications

3. Extension WatchKit apps (extension runs on iPhone, view runs on watch)

4. Fully native apps

It appears 1, 2, and 3 will be available for the initial launch, while #4 will be available later next year, probably starting with a beta released at WWDC.

hey orand, thanks for the summary.

You mentioned #4 will be available later next year, probably starting with a beta released at WWDC.

Is Apple actually saying this? If so, can you please share the source? I mean from Apple not macrumors.

They actually said this in their September 9th press release, although most people missed it:

http://www.apple.com/pr/library/2014/09/09Apple-Unveils-Appl...

"With Apple Watch, developers can create WatchKit apps with actionable notifications and Glances that provide timely information. Starting later next year, developers will be able to create fully native apps for Apple Watch."

Someone from Apple also essentially reconfirmed this earlier today on the WatchKit developer forum.

Edit: here's the source that first tipped me off to this detail hidden away in the press release:

http://david-smith.org/blog/2014/11/06/expectations-for-watc...

Appreciate orand.

I wonder what fully app for watch means though. I am intrigued on the touch event support. There is something new called Force Touch.

Apple mentioned Force Touch during the unveiling demo, and there is a blurb in their documentation as well:

"Force Touch. A small screen can only accommodate so many controls. That’s why Apple Watch introduces an entirely new interaction model: Force Touch. As well as sensing touch, the Retina display also senses force. Force Touch interactions display the context menu (if any) associated with the current screen. Apps use this menu to display actions relevant to the current content." [1]

I've heard people compare this to a long press, but its subtlety different. Force touch can bring up a context menu faster, because you don't have to wait to determine if a touch is "long" or not

[1]- https://developer.apple.com/library/prerelease/ios/documenta...

Thanks for the info Billy.

I think there has to be more touch events available than Force Touch. Seems a fairly trivial interaction.

Given the features page I assume the API should support more events. Digital Touch "implies" touch down-move-up:

http://www.apple.com/watch/features/

* Section 6-left, a heart drawn on the watch with the name Jamie.

"You don’t even have to use words. The Digital Touch features on Apple Watch give you fun, spontaneous ways to connect with other Apple Watch wearers, wrist to wrist."

* Below, a flower drawn on the watch with the name Eliza.

"Sketch. Use your finger to draw something quickly. Your friend on the other end can watch your drawing animate, then respond with a custom creation for you."

Hopefully is already there or else we might have to wait and see the touch API public for WWDC. Eager to play with it, if anybody has more information please share. Thanks!

Update: on the developer forum an Apple employee provided a more accurate breakdown:

1. Watch App

2. Watch App with Glance

3. Watch App with Actionable Notifications

4. Watch App with Glance and Actionable Notifications

5. "Fully Native Apps"

In other words, you can't have glances or actionable notifications without a Watch app.

Particularly interesting are the Human Interface Guidelines for Apple Watch: https://developer.apple.com/library/prerelease/ios/documenta...

They feature various previously unknown details about the watch, for example that the two sizes have different display resolutions, 340px and 390px respectively.

It's particularly interesting to see which UI elements has made it to the small screen of the apple watch. Not much else than switches, buttons and sliders are featured in the guidelines. Looking forward to see what developers eventually will come up with for these devices.

Am I groking this right? The Watchkit app actually runs on the iPhone as an extension, and just the UI component runs on the watch hardware?

Edit: better direct link: https://developer.apple.com/library/prerelease/ios/documenta...

"The Watch app resides on the user’s Apple Watch and contains only storyboard and resource files; it does not contain any code. The WatchKit extension resides on the user’s iPhone (inside your containing iOS app) and contains the code and resource files for managing your Watch app’s interface."

Yup, still MVC but the view is the only part running on the watch.

What's more, you can't get the current properties of the interface objects (e.g. the position on screen, or text content). You can only write to them: https://developer.apple.com/library/prerelease/ios/documenta....

Does that matter? If you need to know those values, you can just store them locally when you set them.

Wait, then how do you get user input at all? Just buttons? That sounds like a pain.

There seems to be some kind of dictation-based input

So if the phone is dead the watch won't even show the time?

Does this setup significant improve battery performance?

It looks like there are native Apple apps on the watch: they noted in the intro video that clicking on an image of a map opens up the Apple Watch's "Maps App"

You can add a map to your own app as well

You can add a non-interactive snapshot of a map.

The watch is independently able to show the time.

It also has built-in time-display capabilities in the SDK to limit the amount of traffic going between watch and phone (i.e., you don't have to manually update a timer or clock display from your own code, the watch does so locally).

Seems like all of this is meant to reduce processing on the watch side, and also to minimize the amount of data moving between watch and phone.

> Does this setup significant improve battery performance?

Not for your phone.

It's been said that an updated SDK with support for "native apps" (maybe that also means untethered?) will be released some time in 2015. http://www.macrumors.com/2014/11/18/apple-watchkit-ios-8-2/

This first version is probably just a very early beginning of how the runtime will evolve, to put something out there before launch.

This has been confirmed by Apple

Reminds me of how the original iPhone only supported web apps, and they later came out with a full SDK.

An interesting tidbit from the HIG (https://developer.apple.com/library/prerelease/ios/documenta...):

Create prerendered animations using a sequence of static images. Store canned animations in your Watch app bundle so that they can be presented quickly to the user. Canned animations also let you deliver high frame rates and smoother animations. Creating animations dynamically from your WatchKit extension and transferring them to Apple Watch adds a delay before playback can begin.

This is not a good sign as to the power of the watch, unless I'm drastically misinterpreting things.

This is referring to the delay in the transmission between your phone and the watch. By storing the static, pre rendered animations on the watch itself, they're ready to play immediately. By rendering them on your phone (where the WatchKit extension lives) and then transferring the view over bluetooth low energy links to the watch to display them would add a delay.

The main problem is the battery life. All this seems to indicate that the device is deisgned to maximize it. A matter of trade-offs, really.

I also found this interesting: "(Dates & Timers) ... Does not need to be updated by your WatchKit extension". Makes me think of timer coalescing in OSX. Now they're just sidestepping the whole issue altogether.

Not necessarily timer coalescing and probably more of a radio optimization. All 3rd party code will run on the phone and not the watch, so any updates to the UI made via code will have to necessarily travel over Bluetooth.

Apple wants to limit the frequency of these updates, so the most frequently updated UI bits (clocks, timers) will be done on the device itself without the persistent BT use.

If you're talking about the use of pre-rendered animation - you may be right, but given the graphic effects when you're drawing in Digital Touch, it's probably got enough power for animations rendered on the fly. May be a matter of baby steps, and they'll eventually open up more of the hardware in a way that doesn't completely kill the battery.

From a quick glance at the docs I tend to agree with you. Seems like we're going to be working in a pretty restrained environment on the watch since Apple seems to prefer you do the heavy work on the phone & not the watch Here's to hoping that this is good news for the Apple Watch's battery life!

Based on development with the Pebble, processing doesn't seem to have much noticeable impact on watch battery life. Updating the screen, writing to flash, or doing communications use so much more battery than almost anything you can do on the CPU.

What is probably more constrained is the memory and storage available on the watch. By moving as much of the application to the phone as possible, they decrease the demands on the limited resources of the watch.

That reminds me of the cheap "MP4" players popular a few years ago (many of them iPod Nano clones...) that could play low-res video and had UI animations too - the animations were just a series of bitmaps and the video was basically MJPEG. The processor was a 24MHz Z80 with a few hundred KB (kilobytes) of RAM.

It takes very little processing power to stream images from memory onto a display. An even more dramatic demonstration of that is http://trixter.oldskool.org/2014/06/19/8088-domination-post-...

That sounds like it tries to use Bluetooth low power when possible, lowering the bandwidth. Even full bluetooth is something like 2MB/minute.

I would buy this watch, but I'm completely convinced that Android Wear is more spot-on for the watch UX with their card based user interface. It does have all these features, the glaces, the actionable notification, extension apps, but from UI standpoint it is just a card. Also, the UI on Android Wear is prettier. I'm not sure why Apple is using black ugly buttons that remind me on very first Nokia multimedia color phones.

I agree; I think for a wearable to be successful it has to be passive and useful. Apple's watch seems too interactive to me but it does look nice and I think it'll have enough passive features to be good.

They say the HIG that the black background is to create the illusion of a bezel-less display, which I guess it does pretty well. Not the best solution but it's not a problem for me.

I was under the impression it was for battery life.

It does use an OLED display and we know black uses less power.

I'm not ranting about the black background. I'm ranting about the buttons and the way they look:

https://developer.apple.com/library/prerelease/ios/documenta...

Moreover, there is no way this watch is pulling over 24 hours battery life. They said that they expect you to charge it everyday. In that sense, the power should not be much of an issue as big as the comments here presume. LG G Watch easily lasts 24 hours, and Moto 360 easily goes 16-20 hours. So unless this watch lasts 2 days or more, screwing up the UI makes little sense, you'd be charging it every night anyway.

I don't get the watch-craze at all, as it adds 0 things you couldn't do before. However, i m looking forward to Android Auto, something that i wanted for a long time.

> as it adds 0 things you couldn't do before

That's your opinion. For me it has been life-changing.

Would you mind elaborating on this? I'm in the same boat as return0 -- I just can't imagine what utility I'd get out of a touchscreen on my wrist.

Personally, I really enjoy the automatic sleep/activity tracking that my Pebble provides (via Misfit app)

Besides that, I mainly use it for "watch" stuff.

That said, it is really nice to be able to get notifications without taking my phone out in certain contexts—bicycling, walking, in a pool, phone charging in other room, etc.

How so? I say this as a Pebble user that was thoroughly underwhelmed. There was the marginal benefit of receiving notifications on my wrist, but it was never worth having yet another device to charge and worry about. My watch now sits in my desk drawer.

There's a lot of groaning about the constraints of the platform (battery life, available interface components, etc), but I for one am excited by these constraints. It can be a really fun and interesting challenge to design within constraints, and in this respect the watch reminds me of the early days of mobile computing. Those tiny little battery-limited devices forced one to think differently about what a UI is, compared to the gargantuan desktop computers and their nearly cinematic display resolution.

> It can be a really fun and interesting challenge to design within constraints

It'll be fun as a technical exercise and to satisfy one's intellectual curiosity, but not as much fun once you've identified the workarounds for all the constraints and you're just trying to ship.

Based on the typography guidelines, the DIN-like font used on the Apple Watch is named "San Francisco": https://developer.apple.com/library/prerelease/ios/documenta...

Here's hoping it will replace Helvetica on iDevices and Macs as well...

It's included in their resource pack if you want to try it out :) along with a punch of .psd templates.

San Francisco? That font is over 30 years old (http://en.m.wikipedia.org/wiki/San_Francisco_(typeface))

If only they had gone with the "classic" San Francisco font you linked -- the Watch's whimsical level would be off the charts!

It's a graphical illustration of the San Francisco of Armistead Maupin vs. that of Jony Ive.

Update: wikipedia no longer has http://en.m.wikipedia.org/wiki/San_Francisco_(typeface), but now has http://en.m.wikipedia.org/wiki/San_Francisco_(1984_typeface) and http://en.m.wikipedia.org/wiki/San_Francisco_(2014_typeface)

I sure hope so! ;-)

http://en.wikipedia.org/wiki/San_Francisco_(typeface)

If you try to download the resources, you have to accept a license agreement for the San Francisco font, which contains this line:

IMPORTANT NOTE: THE APPLE SAN FRANCISCO FONT IS TO BE USED SOLELY FOR PURPOSES OF DESIGN AND DEVELOPMENT OF APPLICATIONS FOR APPLE WATCH.

A quick scan makes it look like you don't have direct access to create your own UI elements, you are stuck to the prebuilt stuff.

This definitely is designed to maximize battery life

Yeah, and you can't create UX elements on the fly, they have to be contained in the bundle pushed to the phone. So, less to install/push/change over the phone/watch network connection.

Following that link consistently makes my Firefox crash. Anybody else experiencing this?

Working fine for me in Firefox 35.

Same thing for me.

Crashing firefox here too. I had it crashing multiple times until I realized it was this tab that was causing it.

I think they've gone about this the wrong way, architecturally. I would have streamed draw commands to the watch and received touch events back, with the watch hardware essentially being a display client with no compute power of it's own. That would cut silicon real estate, remove the need for local wifi, etc - and placed the development focus on a super low latency wireless command stream. That way, the watch, as a product, would last much longer between upgrades, and your UI complexity would be bound by the host phone, not the little SoC.

See wiremine's post here:

"The Watch app resides on the user’s Apple Watch and contains only storyboard and resource files; it does not contain any code. "

With regards to the WatchKit apps - I'm sure I read they were static resources - essentially a GUI library that can run on the watch. That's subtly different to being able to render any command in a draw stream, say, from CoreAnimation. The former gives a storyboarded GUI from a resource set (sliders, buttons, etc), with static animated images (!), the latter is more flexible and I think would be less resource intensive watch-side (render display commands vs local GUI library)

If you wanted to go super-minimal, you could even probably stream a compressed bitmap to a screen that resolution over a wireless protocol, moving all rendering phone-side.

There's also still the issue of the native watch apps coming in 2015.

This would introduce lag in user interactions, which is unacceptable to Apple and its users.

It would also make it impossible to untether the watch from the phone in future revisions, which seems likely to be the plan for the longer term, once technology improves enough to allow adding cellular connectivity without unacceptable size and battery life compromises. Here's someone's take on it:

http://stratechery.com/2014/now-apple-watch/

Yay! This will keep me busy next weekend I'm sure. Quickly glanced through the catalog of objects available and it doesn't seem to be borrowing UI from iPhone the way iPad did. Some similar UI elements but judging by the names they are different implementations and not just differently scaled/laid out.

Do you think we will be able to build custom watch faces at some point?

"Watch this spot!"

Doesn't look like there is any support for drawing on the fly. You could create the watch face as static image, but I don't see a way of drawing the hands and keeping them moving once a minute. Maybe create a series of static images with the hands, and stream them once a minute from the phone? Anybody have any thoughts?

Seems like this is the type of thing that might be possible once the "fully native watch app" sdk is released.

Anyone have a link to available APIs?

you can start here, but you might need to be a registered dev to get to the content:

https://developer.apple.com/library/prerelease/ios/documenta...

Thanks! I am a dev, but was mainly curious if they were opening up the heart rate sensor to apps directly or if we would have to go through HealthKit.

It looks like mostly interface related things, for now. https://developer.apple.com/library/prerelease/ios/documenta...

If you log into the developer center, there is an iOS 8.2 beta available with a new version of Xcode and WatchKit.

I downloaded it, there is no option to create such a project in the xcode 6.2 beta, as of 1pm EST (Nov.18)

Edit: You cannot create an Apple Watch project. You create a standard iOS project, then add the Apple Watch storyboard/methods

Are they allowing access to the sensor data from the watch? I'm particularly interested in heart rate.

A brief scan of the documentation didn't show anything obvious.

My guess would be that you access the heart rate data from HealthKit.

Nope. Check the dev forums @ Apple.

You can cache images on the watch using WKInterfaceDevice.currentDevice() but there is no way to check if an image has been cached, lol.

Can store up to 20 mb.

Also https://news.ycombinator.com/item?id=8625526.

Looked like there were a lot of motion detectors on the Apple Watch. Any guesses on whether they'll expose that in the SDK soon?

I'm happy to see new products and a competitive landscape but frustrated to see Apple (and others) using different development processes. It's already painful to write apps that work on all 3 major mobile OSes, but now watch app developers have a huge set of watches they need to develop for too.

Frustratating to see products each trying to compete using their own closed ecosystem, because it hurts developers and it hurts innovation.

I understand your frustration, but I don't think products trying to compete with closed ecosystems hurts innovation. The smartphone race ushered a new era for software development. The new development process made it mandatory (in order to stay competitive) to reconsider your software for the specific hardware, which promoted some very good redesigns and innovation that would not have happened otherwise.

The only real way that could have happened is if a third party released a great smartwatch that was independent of the phone platform. Something like Pebble but higher-end. Unfortunately with Android Wear existing, I doubt there is still an opportunity for that.

Reply on news.ycombinator.com