I badly wanted to write a generic article about Apple Watch development because I really needed to resume what I’ve learned so far. That being said, in this article you’ll read an overview that might be really useful if you are starting with Apple Watch development. The article introduces the main WatchKit concepts and provides links to external resources to topics that you might need to examine in depth, giving a full path that you can follow to learn how to write Apple Watch applications.
You can start a new Watch project in two ways: Creating a completely new Watch application or adding a new target to an already existing application. In booth cases you have to choose the option “WatchKit App” under the WatchOS tab from the project wizard.
About Apple watch app development
All watchOS apps must have an extension delegate that you can use to respond to your app’s life cycle events. You can also use the delegate to manage background tasks, extended runtime sessions, Siri intents, workout sessions, or Handoff activity from other devices.
The WatchKit framework performs other support tasks, such as accessing device-specific information about the Apple Watch running your app, registering for remote notifications, and creating custom interfaces for local and remote notifications.
An Apple watch needs the presence of an iPhone to run third party Apps. To build Third-party apps a developer will need to separate sets: A WatchKit App (runs on Apple Watch) & A WatchKit Extension (run on paired iPhone) When you decide to launch your App on Apple Watch, the WatchKit Extension on your iPhone runs in the background to upgrade the user interface and be responsive to user interactions. There are total three opportunities that WatchKit provides to extend your iPhone app to Apple Watch.
Designing for the Apple Watch
The Apple Watch requires you to think about the constraints of the device you’re designing for with even more pedantry and attention to detail than is required for the iPhone and iPad. You need to keep the following in mind when designing Apple Watch apps:
- The Apple Watch has an absolutely, ridiculously minuscule screen—it’s tiny!
- The screen is not visible most of the time
- Nobody wants to spend any more than five seconds, if that, looking at it
- The watch is a separate computer (more on this later)
- It has no keyboard, so the only text input available is via voice dictation
- It has a very, very small storage capacity—less than 8 GB, and only a tiny fraction of that is available for you to use
In general, as long as you’re careful—and pay attention to the design constraints of the watch—you’ll probably be fine if you follow the same general approach that is taken for iOS development. That said, it’s easy to forget that every single thing that your Apple Watch app does relies on an often unreliable Bluetooth connection to an iPhone. It’s especially easy to forget this when you’re using the simulator to test things, because the Watch simulator doesn’t have to deal with talking over the radio to its simulated counterpart iPhone. This means that the simulator will be significantly faster than a real Apple Watch will be.
How the Apple Watch Works
watchOS apps are embedded inside iOS apps. When you download and install an iOS app that contains a watchOS app inside it, that app is automatically transferred over the Bluetooth link to the watch. If the watch isn’t in Bluetooth range of the iPhone at the time, it’s installed later.
watchOS apps are independent applications that run entirely on the watch: they do their own processing, manage their own memory, and can store files on the watch. However, watchOS apps rely on the parent iPhone for access to any of the user’s data that’s stored on the device.
- When the user explicitly launches your app from the watch home screen
- When the user interacts with notifications from your app on the watch
- When the user interacts with a glance provided by your app
- When the watch face needs to update a complication on the watch face provided by your app