In the original 2007 iPhone introduction, Steve Jobs famously derided other smartphones at the time for running “baby” software and the “baby” internet. He was right.
Developers weren’t given access to make native apps until the iPhone’s second year. Before the native development kit was ready, Apple tried to pass off web apps as a “sweet solution” for third-party apps, but nobody was fooled.
Apple wasn’t using web apps for their own built-in iPhone apps — they were using native code and frameworks to make real apps.1 Developers like me did our best with web apps, but they sucked. We simply couldn’t make great apps without access to the real frameworks.
Apps were terrible, and didn’t take off, until we had access to the same native tools that Apple used.
* * *
Developing Apple Watch apps is extremely frustrating and limited for one big reason: unlike on iOS, Apple doesn’t give app developers access to the same watchOS frameworks that they use on Apple Watch.
Instead, we’re only allowed to use WatchKit, a baby UI framework that would’ve seemed rudimentary to developers even in the 1990s. But unlike the iPhone’s web apps, WatchKit doesn’t appear to be a stopgap — it seems to be Apple’s long-term solution to third-party app development on the Apple Watch.
The separation of Apple’s internally-used frameworks from WatchKit has two huge problems:
- Apple doesn’t feel WatchKit’s limitations. Since they’re not using it, it’s too easy for Apple’s developers and evangelists to forget or never know what’s possible, what isn’t, what’s easy, and what’s hard. The bugs and limitations I report to them are usually met with shock and surprise — they have no idea.
- WatchKit is buggy as hell. Since Apple doesn’t use it and there are relatively few third-party Watch apps of value, WatchKit is far more buggy, and seems far less tested, than any other Apple API I’ve ever worked with.2
Apple will never have a very good idea of where WatchKit needs to improve if they’re not using it. But this sweet solution is the only choice anyone else has to make Apple Watch apps.
WatchKit only lets us create “baby” apps. That’s all it will ever let us create.
WatchKit needs to be discontinued and replaced.
No focus on quality or expansion of WatchKit will fix this. There are only two ways to meaningfully improve Watch apps, spur third-party innovation, and unlock the true potential of the Apple Watch.
One solution is for Apple to reimplement all of its own Watch apps with WatchKit instead of their internal frameworks, which will force them to fix WatchKit’s many bugs and dramatically expand it.
The much better solution, and the one I hope they take, is for Apple to expose its real watchOS UI and media frameworks to third-party developers, as it has done on iOS.
* * *
I also made this argument in podcast form in Under The Radar 114.
Defensive web developers who object to my “real” classification, remember this was 2007 hardware with 2007 cellular speeds and 2007 browser capabilities. You don’t realize how good you have it today. (But most apps should still be native.) ↩︎
Here’s one from today for
WKAudioFilePlayer, an abysmal, demoralizing API that I lost weeks of my life battling that feels like it had literally zero testing at Apple. I’d bet money that nobody at Apple has ever tried to build an app with it. ↩︎