I wanted to write a general article about Apple Watch Development because I really needed to resume what I've learned so far. Having said that, in this article you will read an overview that can be very useful if you start with Apple Watch development. The article introduces the most important WatchKit concepts and provides links to external resources for topics that you may need to investigate in depth, providing a complete path that you can follow to learn how to write Apple Watch applications.
You can start a new Watch project in two ways: Create a brand new Watch application or add a new target for an already existing application. In booth cases, you must select the "WatchKit App" option under the WatchOS tab from the project wizard.
You will see two new root folders under the project hierarchy, one for the WatchKit app and the other for WatchKit Extension (we'll talk about these items later).
If you own a clock or not, I strongly suggest setting up a simulator. Bad news: As you will learn while developing your first Watch program, testing on a real device is a pain in your neck. Sometimes the program does not start and generally takes a long time to start (I refer to Xcode 7.2, I hope the situation will improve in the next Xcode releases).
As mentioned, to create a simulator just open the panel "Window-> Device" and click the "+" button in the lower right of the window and then select "Add simulator."
From the modal that appears, you can set the name of the new simulator and select your phone and watch models you prefer, the new device will appear in the list of available simulators.
WatchKit and WatchOS Application Architecture
Before writing any codes, we provide a quick overview of what a WatchOS application is and what you can build around.
WatchKit Extension and Watch App UI
A Watch App structure is based on 2 main features: WatchKit Extension and Watch App UI . The extension is where all logic takes place and where the user interface is up to date, App UI is obviously responsible for designing all App views and defining navigation through segues. These two elements are well separated into the project using the two folders we previously introduced. If you look at the expansion folder, you'll see some files and dedicated resources, while the Watch App folder only contains a storyboard and real estate directory.
WatchKit Extension is the core of your application, only from WatchOS 2.0, it has been moved from the Phone App system to the Watch App system that gives more power to the companion's Watch App. Thanks to this update, you can perform complex tasks directly on Watch (as network conversations), and generally, all the app will respond in response.
Communication between iPhone and Watch takes place through Connectivity Framework . We'll talk about it later, for now it's enough to say that thanks to this framework you can exchange data and messages between an iPhone and its paired watches. The WatchKit Extension is where all connection logs are located for the Watch page.
Watch App Parts
When working on a Watch App, you must know that you can create different items that users can run on their watch.
The main actor is obvious App itself, a user can run
You should have noticed that you create a new project that you can flag any options to include other items inside the app: Glance scene ]] Complication and Message scene .
Briefly, a Glance is a non-interactive single show where you can present important information from your app. The main role of Glances is to present simple and immediate data, this is not it correct the place to perform complex tasks or long network conversations then. This view is perfect for presenting time-based information or other previously stored data. A user is presented with the installed views that are set up on the Watch screen. This article by NatashaTheRobot explains in detail how to tickle a glance.
A Complication is a small item available in the clock quadrant which displays simple information such as date, battery level or next alarm. You can provide different formats of your complication (circular, modular and utilitarian, the forms you can choose from) and users can decide where to put the complication depending on available Watch Face Traces.
Complications are highly time-based and they are organized using a data source that responds to requests such as: "What information should I display at 14:00?". When the user activates time travel, moving the digital crown, complications are updated with the correct data for the selected time, so you should enter data for current, past and future dates (fear not time travel is limited to a 72-hour range). This is the best training on complication development so far, it's the stars from a general ClockKit explanation down through a detailed guide to coding for complications.
Really similar to iOS, a clock kit scene is defined by a view designed through a storyboard and an Interface Controller, responsible for updating content on the screen and handling requests like comes from the user interface. This item is an instance of the WKInterfaceController class. When you start typing the first interface check, you probably see the ViewDidLoad method and you will not find it The correct method for configuring your interface control is awakeWithContext: . The context is a useful way to send information through Interface Controllers. It is only a dictionary that you can pass during navigation that will be available to the presented controller through the awakeWithContext: method. You find this logic extremely useful, personally I would like something similar in iOS.
Other interesting methods exposed by the WKInterfaceController class are willActivate () and willDeactivate () which you can imagine being called when the controller is about to be presented, and when it is rejected.
Navigation through controls is extremely simple. In essence, you can present a new controller mode or use a page-based navigation. You will not use anything similar to the navigation control or tab manager, you only push or present the next controller using methods like pushControllerWithName: context: and
presentControllerWithName (_: context 🙂 . You may notice that these methods only receive the control unit name instead of requiring an instantiated controller. The name corresponds to the storyboard identifier.
This time I suggest you go through Apple Documentation. They have a very detailed overview of the interface control object and generally about the Watch App structure.
The starting point for a Watch App user interface is Storyboard. Here you can design views for interface controllers, eyes and dynamic messages. A WatchKit Storyboard works just like the iOS version; You can drag and drop items on the main dashboard and create segues between controls. The big differences you encounter are related to the layout system . Instead of AutoLayout, WatchKit is dependent on a very simple system that automatically defines the interface interface for you, which greatly simplifies how to design views.
Basically, you can place items on the user interface and define the size and position with simple rules. The size can be specified with fixed values, define values relative to the container size or customize the element content. To define the position of the item you have more restrictions; You can define the Preferred 2-axis Adjustment item using Left, Right, Top, Bottom and Center, the layout system automatically selects a position for the item relative to the other user interface elements. This article provides a very detailed explanation of how to handle the WatchKit layout system that creates the user interface for a single application.
You can select UI elements between an object object provided by WatchKit. You already know how some of these items work. You can create labels, buttons, switches, tables and pickers, but not all of these items work just like they work with iOS. Take the table as an example; You are used to setting up a data source and a delegate, but with WatchKit the whole stream is easier, you can set up the number of rows using the table.setNumberOfRows function and you manage different cell types using row controllers .
A comprehensive list of these sections is available on the Apple Human Interface Guide, while a detailed explanation of each component with sample code can be found on the documentation (see left menu).
Communication between Devices
Sending back and forth between clock and phone is an operation handled by Connectivity Framework . In essence, you can send information with direct messages in the background using a context or even share files and data.
Communication is controlled by a session and Depending on the type of message system you select, you must perform some controls on session mode (for example, make sure the device is available before sending the direct messages). You can read more about this topic on
this article. Remember that the connection frame has been introduced with WatchOS2, you can find some other articles that talk about communication with "Parent Application", do not waste your time with those articles since they are outdated. If you have some more time to use, check the WWDC session 713 Introduction of Watch Connectivity, also discuss how to adopt NSURLSession directly from a watch app.
I hope you have had this guided tour through Watch development. Notify me if it's something I've missed or it's worth mentioning. I would like to be happy to include all your suggestions in this article!