This is a great opportunity to stand out by doing something different with an app that is concieved with the Apple Watch in mind.
This will lead to a lot of very similar Apple Watch extensions. Existing apps will focus on their exising functionality and extending it to the watch as Apple recommends. But that doesn’t mean you should throw in the towel just because you don’t have an existing app that fits this mold. Don’t make it this easy for your competitors to win over customers.Īpp developers with existing apps defintiely have an advantage in bringing Apple Watch extensions to market, since they can focus on just the Apple Watch extension part of development. Imagine if an Apple Watch owner is choosing between your app and a competitor’s, and the latter supports Apple Watch but you don’t. Just like supporting the different screen sizes of the iPhone is necessary for high quality apps, adding Apple Watch support will soon be too. If the iPod touch will be supported is an open question.) So if you have an existing iPhone app that could benefit from displaying small and time relevant pieces of information on a watch, then you should definitely consider adding this fuctionality. In terms of everyday use of the Apple Watch, that makes perfect sense. (I’m intentionally specifying iPhone here as it does not appear that the Apple Watch will pair with an iPad. WatchKit as it stands today is clearly geared towards creating extensions to existing iPhone apps.
#APPCODE WATCHKIT TABLE HOW TO#
It still behoves you to follow Apple’s conventions in your own apps so that your customers will know how to use them. Of course Apple is building on the knowledge that watch owners already have acquired from their iPhones. Many of them would be difficult to discover you just have to know them. Nilay Patel at The Verge counted 15 different ways to interact with an Apple Watch. Nothing earthshattering, just more new API:s to learn. But tables work in a totally different way from UITableView, for example. Some things like labels and buttons have some resemblance to our dear friends UILabel and UIButton. I just wish the new system didn’t bring back those old memories from Java Swing…
But I’m guessing the reality of battery life won the argument in favor of something much simpler. The Apple Watch seemed like a great test for this paradigm with its much smaller screen.
Apple has pushed auto layout hard for several years as a solution to dealing with different screen sizes. To further reduce the amount of communication needed between the watch and the iPhone, all your UI elements are packaged up in the watch app extension and sent to the watch when the app is deployed. This is a really clever way to limit the power consumed by the app on the watch.
#APPCODE WATCHKIT TABLE UPDATE#
The watch basically acts like a remote terminal: the code on the iPhone sends commands to update the display and receives back messages of the user’s actions. All your code runs on the iPhone and not on the watch hardware.However, as far as I know in Xcode 6.1 it was not possible to create Swift frameworks for use in extensions. Apple recommends that you use frameworks to share code between your container app and extensions. You can use both Objective-C and Swift to develop apps for Apple Watch.That said, this release was more capable than we dared hope for.
#APPCODE WATCHKIT TABLE FULL#
The initial release of WatchKit was expected to be more limited in capability with full native apps only being possible later in 2015.
0 kommentar(er)
