Experience Introduction: Glow App Develops Apple Watch App

Previously, I worked with two colleagues to develop an Apple Watch app for our Glow App in our spare time. This article is written to introduce the development of Apple Watch and list some pitfalls encountered during the development process. Although Watch OS 2 has been released and we developed it with WatchKit, many contents are also applicable to Watch OS 2. I hope this article is helpful to everyone.

Introduction

• Design
• WatchKit App Architecture
• Data Communication
• Provisioning Profiles and Entitlements
• Tips

Design

Essentially, you can use Apple Watch as an extended screen of iPhone. You don't need to take out your phone. You can get information or do some simple operations by just raising your wrist. In fact, when you develop Watch App, you will find that the Watch simulator is implemented as an external display of iPhone simulator.

However, Apple Watch presents a new way of human-computer interaction, and the design interaction guidelines of iOS App are not applicable to Watch. Therefore, before designing and developing Watch App, it is necessary to understand its interaction and basic UI elements.

First, let’s talk about interaction. In addition to the familiar gesture interaction, Apple Watch provides 3 new ways of interaction:

• Force Touch

  The Apple Watch display can sense pressure as well as user clicks, and a "hard press" can display a context menu with up to four actions.

• The Digital Crown

  Like traditional watches, the crown is the most commonly used interaction. But on the Apple Watch, the crown is not used to adjust the time and date, or wind the watch. By turning the Digital Crown, you can accurately zoom, scroll, or select data without blocking your view. It also serves as a button to return. Press it to return to the home screen, and press it twice to return to the clock interface.

  It sounds great, but the crown API is not yet open, and the system automatically does the scrolling for you:[

• Side Button

  A long button below the crown. Pressing it takes you to the Friends interface. Here, you can call or text the 12 contacts you've selected, or use the new ways the Watch communicates, such as tapping them, drawing a doodle, or sending a heartbeat.

Well, the relevant API is not open yet. Considering its contact function, it is estimated that it will not be opened in the future.

Apple Watch Human-Computer Interaction Guide

Watchkit App Architecture

When you add a new Watchkit App target, you will find that Xcode actually adds two new executables and compiles them together with your iOS App.

The dependency relationship between them is shown in the figure below. Watch App depends on Watchkit Extension, and Watchkit Extension depends on iOS App. As you can see from the two figures above and below, there are only Storyboard and ImageAssets in Watch App. That's right, in Watch OS 1, Watch App only contains some static things, and Extension is where the code is actually executed. Extension is responsible for obtaining data from iOS App and controlling what to display on the Watch App interface. The operation of Watch App is also initiated by Extension to iOS App. Watch App does not communicate directly with iOS App.

Each page of the Watch App needs to have a corresponding subclass of WKInterfaceController, such as InterfaceController and GlanceInterfaceController in the Extension folder in the figure above. In addition to init, WKInterfaceController has 3 methods related to the life cycle:

 // Called after init, you can configure the elements on the interface in this method  
 - ( void )awakeWithContext:(id)context;
 // Called when this page is about to be displayed to the user  
 - ( void )willActivate;
 // Called when this page is no longer displayed  
 - ( void )didDeactivate;

Data Communication

As mentioned earlier, the Watch App itself only contains some static content. It does not save data by itself and cannot send network requests. It can only interact with the iOS App through the Extension. Therefore, data transmission between the Watch App and the iOS App is the key and the main development work of most Watch Apps. There are five main methods of data transmission. The first is to use the openParentApplication:reply provided by WKInterfaceController, and then implement application:handleWatchKitExtensionRequest:reply on the iOS side to handle the request from the Watch Extension. The third is Wormhole, a third-party library that sends messages and data through the Dawrin notification center. The middle three methods all pass data in independent shared sandboxes through App Group.

• WKInterfaceController openParentApplication:reply
• NSUserDefaults
• Core Data
• NSFileManager
• Dawrin notification center - MMWormhole

WKInterfaceController openParentApplication:reply

This method is very intuitive and is the most real-time and reliable of the several data transmission methods. You can use Enum to define several request types, and then pass the request type when sending the request, so that when the iOS App receives the request, it will know what to do. The iOS App uses the reply callback to pass back the request result.

In this way, the iOS App can be called up even in the background. However, the iOS App cannot actively call up the Watch Extension.

 NSDictionary *request = @{kRequestType: @(requestType)};
 [InterfaceController openParentApplication:request
                    reply:^(NSDictionary *replyInfo, NSError *error) {
 }];

 - ( void )application:(UIApplication *)application
 handleWatchKitExtensionRequest:(NSDictionary *)userInfo
                         reply:( void (^)(NSDictionary *))reply
 {
    RequestType requestType = userInfo[kRequestType];
 if (requestType == RequestTypeRefreshWatchData) {
 //  
 }
 }

The three methods in the middle are very similar. They all store data in an independent shared sandbox. The difference is how they store data. When the iOS App or Watch App needs data, it will look for it in the sandbox. It's like a secret mailbox. Only the two parties know where it is. So this is also an asynchronous transmission method. The two parties do not communicate directly. See the following code for specific usage.

NSUserDefaults

Using NSUserDefaults is the simplest, but there is a limit on the data size.

 NSString *appGroupName = @ "group.com.yourcompnay.shared" ;
 NSUserDefaults *defaults = [[NSUserDefaults alloc] initWithSuiteName:appGroupName];
 [defaults setObject:user.name forKey:@ "userName" ];

Core Data

If your iOS App has already put Core Data in a shared sandbox, you can consider this approach.

 NSString *appGroupName = @ "group.com.yourcompnay.shared" ;
 NSURL *storeURL = [[NSFileManager defaultManager]
    containerURLForSecurityApplicationGroupIdentifier:appGroupName];
 storeURL = [storeURL URLByAppendingPathComponent:@ "glow.sqlite" ];
 [self.persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
                                              configuration: nil
                                                        URL:storeURL
                                                        options:nil
                                                        error:&error]

NSFileManager && NSFileCoordinator

File reading and writing inevitably involve multi-threading issues, but don't worry, just use NSFileCoordinator.

 - coordinateReadingItemAtURL:options:error:byAccessor:
 - coordinateWritingItemAtURL:options:error:byAccessor:
 [coordinator coordinateWritingItemAtURL:fileURL
                                options:nil
                                  error:nil
                             byAccessor:^(NSURL* writingURL) {
   [dataToSave writeToURL:newURL atomically: true ];
 }];

NSFilePresenter

You can also listen for file changes by implementing the NSFilePresenter protocol, and get real-time updates for free without having to implement a refresh mechanism yourself.

 - presentedItemDidChange

Dawrin notification - MMWormhole

The first one is also very convenient to use. Watch Extension and iOS App send messages and listen for messages. Another big advantage is that Wormhole will save the data transmitted last time, so when Watch App wakes up, it can use the data in Wormhole first, and then update the interface when iOS App sends the latest data.

 // init  
 self.wormhole = [[MMWormhole alloc] initWithApplicationGroupIdentifier:kApplicationGroupIdentifier
                                               optionalDirectory:kWormholeDirectory];
 // iOS app  
 NSDictionary *message = [self makeWatchData];
 [self.wormhole passMessageObject:message identifier:kWormholeWatchData];
 // WatchKit Extension  
 NSDictionary *message = [self.wormhole messageWithIdentifier:kWormholeWatchData];
 // do something with message  
 [self.wormhole listenForMessageWithIdentifier:kWormholeWatchData
                               listener:^(id messageObject) {
    NSLog(@ "Received data from wormhole." );
 }];

This is also the method I used at the beginning. But in the process of using it, I found that if the iOS App is in background mode, it cannot receive messages from the WatchKit Extension in real time. Therefore, we choose to mix openParentApplication:reply and Wormhole. When the Watch App wakes up, use the data in Wormhole to ensure the response speed of the Watch App, and use openParentApplication:reply to request the latest update from iOS.

Provisioning Profiles and Entitlements

At the beginning of development, the most troublesome things may be Code Signing, Provisioning and entitlements.

Each target must have its own App ID. So we need three in total:

• yourAppID
• yourAppID.watchkitextension
• yourAppID.watchkitapp

You also need to create an associated Provisioning Profile for each App ID. If you use Xcode to automatically create a Provisioning Profile, it will only create the first two for you. You need to manually create them in the developer center.

In addition, you also need to make sure that your three Entitlements are correct. Version Number, Build Number, and App Groups (if used) must be the same, otherwise the compilation will not pass.

Tips

Debug

Sometimes, you may need to debug both iOS App and Watch App at the same time. However, Xcode only allows you to specify one target to run. You can either debug the iOS App code or the Watch App code. However, you can debug both at the same time by using Xcode's Attach to Process. The specific steps are as follows:

• Run the WatchKit App
• Open your iOS app in Simulator
• In Xcode’s menu bar, select Debug -> Attach to Process, select your iOS App, and you can debug both iOS and WatchKit app at the same time.

App Icons and iTunes Connect

If you encounter an Invalid Binary error when uploading your app to iTunes Connect, it is likely because your Watch App icon has a transparent layer or alpha channel. A more convenient solution is to open the image with Preview, select Export, and then uncheck the Alpha option at the bottom and confirm.

End