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. 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.
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.
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.
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.