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.
"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:
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
* 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!
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.
"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."
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"
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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?
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.
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.