The OP was claiming that Apple's architecture is flawed and that once they realize the error of their ways, battery life will improve dramatically. That's just not true.
Your point is that the public SDK limits 3rd party developers from doing some stuff that Apple can do with the private SDK. That is, of course, absolutely true.
Letting the public SDK (or at least parts of it) lag behind the private SDK, while certainly frustrating to 3rd party developers, is the right thing to do. The situation is exactly the same on the iPhone, iPad, and Apple TV. Apple has employed that strategy from the beginning with iOS, and they believe it to be the correct strategy, so they will almost certainly stick with it.
I don't work at Apple any more (pushing toward launch on a startup!), but based on over 8 years of iOS history, I think it's safe to say that the public watch SDK will get more powerful over time, as private-only features are deemed ready to release to 3rd parties.
Yeah, OP's claims about battery life are manifestly silly. The HN headline makes it sound like the article is making claims about the Watch in general, but it isn't, just that one dev's app.
I understand and take your point about public APIs lagging behind private ones, but in this case it's not that the public SDK is lagging, it's a totally different beast.
The fundamental execution model is the same as watchos 1 -- you don't get to write code that runs in the app process, you write code that runs in a separate extension process and get to twiddle ui elements in the main process using a very limited API.
Which is why if you're trying to do anything dynamic, you have to resort to generating and beaming over images.
Besides this fundamental limitation, the management of app process vs extension process vs network daemons is still buggy (contributed to, probably, by the fact that apple isn't dogfooding), which means it's hard to impossible to make your app stable. I think this has been a huge contributor the general perception that 3rd party Watch apps are slow and buggy.
Obviously, I can only speculate about Apple's motives for going with WatchKit vs exposing native development, as on the iPhone.
My guess is they were very worried about an initial public perception of the watch being "battery life sucks," so they didn't want to open up 3rd party code to run on the Watch. Hence WatchKit and OS1.
Then there was a huge public negative perception about not having native apps, so they rushed out OS2, which has 'native' apps, but still following the (now nonsensical) 2-process model of WatchKit.
I do hope Apple opens up true native dev on the watch at some point.
It won't be "the public SDK getting more powerful over time," though, it will be making a qualitative change to the SDK itself.
P.S. If you haven't and are curious, I encourage you to take a look at WatchKit. I think you will be surprised at how limited it is.
P.P.S. I think Apple may have been better served by doing something akin to the original iPhone model -- just saying, "no 3rd party apps yet, but it's coming," rather than having a half-assed SDK on day 1.
Actually, thinking about it, they are doing something akin to the iPhone model -- initially iPhone development was supposed to be done as html+js web apps, and devs revolted, and then we got a real SDK.
WatchKit is the html+js of WatchOS development. OK, not that bad, but the situation is analogous.
I was going to reply to you and say the same thing: it's extremely similar to the initial iPhone 3rd party developer story, and for the same reasons. Apple is pretty predictable, really.
I know how WatchKit works, I was in on some of those meetings... Trust me, everyone at Apple had the same concerns you expressed and they still do. It will get better over time.
Also note that some built-in Apple apps do use WatchKit.
And I would still argue that allowing 3rd party code to run on the watch instead of in an extension on the phone would be just another example of an internal-only feature being opened up to the public. It's the same pattern. I realize that's a significant "feature", but so was the switch from html+js to native apps on the phone. And those significant advances go through the same decision process as smaller ones: do we feel comfortable opening up this feature to 3rd parties? what are the risks? have we used it enough internally to feel confident? has it iterated enough internally that we consider it stable enough to release (because it's hard to change after release)? etc.
The OP was claiming that Apple's architecture is flawed and that once they realize the error of their ways, battery life will improve dramatically. That's just not true.
Your point is that the public SDK limits 3rd party developers from doing some stuff that Apple can do with the private SDK. That is, of course, absolutely true.
Letting the public SDK (or at least parts of it) lag behind the private SDK, while certainly frustrating to 3rd party developers, is the right thing to do. The situation is exactly the same on the iPhone, iPad, and Apple TV. Apple has employed that strategy from the beginning with iOS, and they believe it to be the correct strategy, so they will almost certainly stick with it.
I don't work at Apple any more (pushing toward launch on a startup!), but based on over 8 years of iOS history, I think it's safe to say that the public watch SDK will get more powerful over time, as private-only features are deemed ready to release to 3rd parties.