Several companies recently have stopped producing Apple Watch apps. The Apple Watch appkit provided for developers has some obvious inadequacies. Should Apple improve this interface significantly in Watch OS 5 so that better apps may be build more easily by developers?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Should Apple Improve the Developer Resources
- Thread starter Felix Bomar
- Start date
-
- Tags
- developer watch apps watchkit
- Sort by reaction score
How about supporting podcasts on the Watch? Seem slike the watch would be a very good platform for audio podcasts.
[doublepost=1520357466][/doublepost]Do you think the next watches will support better use of LTE for app installation and updating as well as during use of an app that needs to access new information?
[doublepost=1520357466][/doublepost]Do you think the next watches will support better use of LTE for app installation and updating as well as during use of an app that needs to access new information?
I think the developers go where the money is and there is little money to be gained writing apps for the Apple Watch. Does not seem to be a very large market of people willing to pay so the developers walk.
iOS App Dev here— here’s the issue
It comes down to 2 things: tool access & hardware limitations
1) tool access
When I write an app for iOS, macOS, and even tvOS, I’m using the same tools that Apple themselves use to develop system level apps for the platform. There are obviously rules about what I can and cannot use, but the API’s I’m accessing are identical to the ones used to build the device’s built-in apps. Apple will review my app to make sure I’m not breaking any of their rules for third party applications, but there is nothing actually stopping me from building the app to do whatever I want it to — it just won’t be available for App Store distribution if I try and use an undocumented or unsupported API or work outside the sandbox.
This is not true for WatchOS. To build apps for the Apple Watch, I need to use WatchKit— a proxy API with minimal control flexibility and specific features only. Apple’s built-in watchOS apps do not have this limitation — and as such are a lot more performant and functional than anything I could write for my watch.
WatchKit sucks. It’s buggy as all hell. There are a ton of things you just can’t do, and if agressively manages things like UI design, hardware usage, and watch-to-phone communication
2) hardware limits.
Apple does not trust devs to do a good job with WatchOS. Performance and battery life are been more important on this product on others to make a pleasureable, useful user experience (partially because of how the watch is used, and partially because of battery size and SoC limits that an incautious Dev could easily smash through), and Apple doesn’t want to give devs the ability to apps that, if not done to a certain quality standard, would severely cripple the Apple Watch as a whole. Apple imposes the WatchKit API knowing the performance & battery limits of the Apple Watch, and thus insures rush nobody will be able to write an app that will totally ruin a user’s device
To solve this issue, we’re left with 3 options:
1) Seriously improve WatchKit. WatchKit is to me a further example of Apple’s recently degrading software quality. It’s extremely buggy and very frustrating to use. As a developer, you have to ask yourself if writing a feature limited proxy app is really worth your time given how annoying it is to build. Apple doesn’t use WatchKit internally, so it’s unclear if they know how bad it actually is. It really is a pain.
2) Open up Apple Watch Cocoa UIs to third party developers. This would require a serious improvement in AW hardware or a very strict, rigorous and lengthy review process.
3) Nix third party apps on the watch all together. I honestly think this wouldn’t be so bad. A big party of dev’s Decision to abandon the AW has to do with the fact that people don’t really use third party apps on the watch. Maybe that’s WatchKit’s fault, but I don’t think so. I never use apps on my watch, and performance issues have nothing to do with it. But maybe that’s just my opinion.
I think third party devs certainly have a place in the future of WatchOS as a platform, but I’m not sure that future involves dedicated full UI app experiences. It’s clear that something has to done, but what exactly I don’tknow. I will say that I am not shipping a WatchOS counterpart on my next project.
It comes down to 2 things: tool access & hardware limitations
1) tool access
When I write an app for iOS, macOS, and even tvOS, I’m using the same tools that Apple themselves use to develop system level apps for the platform. There are obviously rules about what I can and cannot use, but the API’s I’m accessing are identical to the ones used to build the device’s built-in apps. Apple will review my app to make sure I’m not breaking any of their rules for third party applications, but there is nothing actually stopping me from building the app to do whatever I want it to — it just won’t be available for App Store distribution if I try and use an undocumented or unsupported API or work outside the sandbox.
This is not true for WatchOS. To build apps for the Apple Watch, I need to use WatchKit— a proxy API with minimal control flexibility and specific features only. Apple’s built-in watchOS apps do not have this limitation — and as such are a lot more performant and functional than anything I could write for my watch.
WatchKit sucks. It’s buggy as all hell. There are a ton of things you just can’t do, and if agressively manages things like UI design, hardware usage, and watch-to-phone communication
2) hardware limits.
Apple does not trust devs to do a good job with WatchOS. Performance and battery life are been more important on this product on others to make a pleasureable, useful user experience (partially because of how the watch is used, and partially because of battery size and SoC limits that an incautious Dev could easily smash through), and Apple doesn’t want to give devs the ability to apps that, if not done to a certain quality standard, would severely cripple the Apple Watch as a whole. Apple imposes the WatchKit API knowing the performance & battery limits of the Apple Watch, and thus insures rush nobody will be able to write an app that will totally ruin a user’s device
To solve this issue, we’re left with 3 options:
1) Seriously improve WatchKit. WatchKit is to me a further example of Apple’s recently degrading software quality. It’s extremely buggy and very frustrating to use. As a developer, you have to ask yourself if writing a feature limited proxy app is really worth your time given how annoying it is to build. Apple doesn’t use WatchKit internally, so it’s unclear if they know how bad it actually is. It really is a pain.
2) Open up Apple Watch Cocoa UIs to third party developers. This would require a serious improvement in AW hardware or a very strict, rigorous and lengthy review process.
3) Nix third party apps on the watch all together. I honestly think this wouldn’t be so bad. A big party of dev’s Decision to abandon the AW has to do with the fact that people don’t really use third party apps on the watch. Maybe that’s WatchKit’s fault, but I don’t think so. I never use apps on my watch, and performance issues have nothing to do with it. But maybe that’s just my opinion.
I think third party devs certainly have a place in the future of WatchOS as a platform, but I’m not sure that future involves dedicated full UI app experiences. It’s clear that something has to done, but what exactly I don’tknow. I will say that I am not shipping a WatchOS counterpart on my next project.
My impression is sleep monitoring apps and health apps beyond Apple's are quite popular on the watch. Additional categories of apps could become popular, if the specific apps were sufficiently compelling.
I think if Apple opened up some access to developers, we would see more quality apps, thus enhancing the usefulness of the watch. If Apple doesn't rethink their developer approach mindset with the watch, watch growth is going to eventually slow way down, as Apple isn't even coming up with several break-through apps of their own.
I developed a watch app the other day, I didn't run into any limitations or bugginess and it seemed pretty straightforward to me once I figured out my background options.
What limitations did you run into? What did you want to do that the API prevented?
I can’t imagine you were doing anything remotely complex without also running into a wall.
See the following:
https://www.macstories.net/linked/the-limitations-of-watchos-development/
https://marco.org/2018/02/26/watchkit-baby-apps
To me, the most frustrating limitations are lack of direct access to the view controller life cycle, the irritating way in which nsurlsession requests are handled, and the general extension like nature of the app bundle. But that’s just me. The limitations are too lengthy to list.
Last edited: