I never understand how someone can write an article about their very first foray into something and then, at the end, assert that they know more than the experts already.

> In the end of the day, the watch battery is there just to shuffle these .PNGs around. When Apple realizes how to avoid that, the watch will last for a week instead of hours.

Drawing every frame using CoreGraphics is a terrible idea, on any iOS device. Just like any platform, you have to understand at least the basics of the underlying architecture if you want to write efficient code.

I happened to make the built-in Stopwatch app on the watch, which displays an animated graph very similar to his. Suffice it to say, I did not use a CADisplayLink and CoreGraphics at 60fps. Especially considering my graph is horizontally scrollable by the user.

Even if WatchKit still doesn't provide a more efficient way to do this (I don't know; I've never used WatchKit), rest assured that Apple's apps certainly don't use this method, so the week-long battery life claim is just a dream, unfortunately.

> Constants are defined via let, and variable are allowed to vary through a var. Though constants are lame, as only the binding itself is constant and you can change everything inside them as usual.

That is at best misleading, as it is not true for collections. From the Swift docs:

> If you create an array, a set, or a dictionary, and assign it to a variable, the collection that is created will be mutable. This means that you can change (or mutate) the collection after it is created by adding, removing, or changing items in the collection. If you assign an array, a set, or a dictionary to a constant, that collection is immutable, and its size and contents cannot be changed.

Swift is the only language that I've seen that actually does make a distinction depending on the keyword used.

> When Apple realizes how to avoid that, the watch will last for a week instead of hours.

In order for this statement to be true, the CPU would have to be using 85% of the entire watch's power consumption just to shuffle PNGs. I bet the entire CPU doesn't use nearly that much power, once you include the display.

This is for 3rd party apps -- despite the "native" 2.0 SDK, where all your code runs on the watch, it's still split clumsily into app (which you can only control by providing interface templates) and extension, which is where your code runs. The extension can control the app only through a very limited SDK that has to do IPC to effect changes in the main app.

Apple's own apps don't have this restriction, and I can't see a good one for 3rd party apps to have it, either -- hopefully they'll open up a full API in the future.

Would you rather they use uncompressed bitmaps instead?

I remember the little MP3/MP4 players which were very popular around a decade ago(https://en.wikipedia.org/wiki/S1_MP3_player ) used a similar strategy of making all the UIs bitmaps. The LCD had the windowing functionality built into its controller so it was easy to define a rectangular window and then just stream the appropriate pixels into it. They only had a 24MHz Z80 and 384KB of RAM, but hundreds of MB or more of secondary storage, so it made sense to tradeoff size for speed that way.

You can see an example of that here:

http://www.mympxplayer.org/pafiledb/images/screenshots/12088...

PNG is not cheap on the compression side, due to the lossless coder. It's a little better to decompress:

Some benchmarks on iPhone 6 are here: https://browser.primatelabs.com/geekbench3/4423501

e.g., JPEG is 15x faster to compress and 2.5x faster to decompress.

I think I'm more impressed that LiveJournal is still around 10 years after it first came out.

The big take-away:

  In the end of the day, the watch battery is 
  there just to shuffle these .PNGs around. When 
  Apple realizes how to avoid that, the watch 
  will last for a week instead of hours.