Published on: December, 2015
- Development •
- Mobile
If you’re up to the challenge of creating an Apple Watch App , here we will provide a simple guide outlining the basic steps. In case you have no experience working with iOS, I recommend you to take a look at the first part of our blog “Wearables War: Apple Watch vs. Android Wear”. There you will find information about the requirements to get started developing your first Apple Watch App.
One in six adults in the US already owns a smartwatch or fitness tracker. The smartwatch segment of the wearables market promises to be one of the most exciting — and a key part of market growth will be driven by the applications available for the devices. However building applications for smartwatches cannot simply be an exercise in taking existing applications and transferring them to a smaller screen. Rather, you’ll need a wholesale rethink of how your customers will engage with the application, and the specific use cases in which they’ll use it.
Therefore, to get into this next serious wave of growth in the wearables market you have two choices: have someone build a smartwatch app for you, or build one yourself.
The first step to create an Apple Watch App is to add a new target to the project.
File> New> Target
This action generates two folders: “Appname WatchKit Extension” and “Appname WatchKit App”
WatchKit app only includes the Storyboard and images resources. The logic will be written in the WatchKit Extension.
The two methods that you initially call before you see the UI (User Interface) are init and awakeWithContext. Even when you can prepare the UI elements in init, when there are too many elements it’s recommended to do it in awakeWithContext. If you use init, you have to call super first. Calling super creates the elements of the UI and assigns the properties we have declared.
The views are divided in a grid of 3×3. Everything is positioned according to a horizontal parameter (left, center, right) and a vertical parameter (top, center, and bottom). There is no concept of constraints, nor can you use coordinates to position anything.
Height and width can be set to a fixed value, related to the container or the content. This is similar to match_parent and wrap_content in Android.
Since WatchOS 2, communication can be done using WCSession.
To have simultaneous communication, both apps (iOS and WatchOS) need to create a WCSession instance and activate the session. Once both sessions are active, the apps can communicate between them instantly. If only one of those apps has the WCSession active, this one can keep sending actualizations and transferring files, but the actions will only happen in the background and follow iOS politics. This means that you cannot be sure when will they be done given that the OS will assign times and priorities based on its own criteria.
There are three ways of establishing background communication: it can be either through application context, user info transfer, or file transfer.
This method has pros and cons as only the last context transferred will be sent. Let’s see an example: in a case where only the iOS app has the session activated and sends a “message 1” to the smartwatch, this message will be delivered when the system thinks it’s right. If before that moment the iOS app sends a second message, “message 2”, it will overwrite “message 1”, then when the system decides it’s the right moment to deliver the message to the smartwatch, it will only deliver “message 2”.
This is very useful when we’re interested in only sending the most recent information, but it’s useless for any other scenario where the information sent is relevant.
To receive the message from the other side, we simply need to use the callback of the delegate.
This method is used when all the information that we send is important, and we don’t want every message overwriting the previous one. With this method, the messages are delivered following an order of FIFO (First In, First Out).
And to receive messages we use:
Basically, what we should use to transfer files between the devices is:
To check all the files that are waiting to be delivered you can access the property outstandingFileTransfers of the WCSession. To receive those files we use:
When we want the messages to be delivered instantly, we need the sessions activated in both devices. To check that, we need to look at the reachable state of the objective device.
iOS app: the paired Apple Watch must be connected by Bluetooth, and the watch’s app needs to be running in foreground.
Watch app: the paired smartphone must be connected by Bluetooth.
Once we have checked the state, we have two possible methods that we can call depending on what we want to pass (either is a NSDictionary or NSData).
To receive these messages we must consider if we want an answer or not. For NSDictionary we use session:didReceiveMessage: or session:didReceiveMessage:replyHandler:
For NSData we have the same choices depending if we want an answer or not. We can use session:didReceiveMessageData: or session:didReceiveMessage:replyHandler:
The above guide will help you get started developing applications for smartwatches. But remember the golden rule: a smartwatch is not a smartphone. The ways in which people will use your application on a smartwatch will be very different. Typically they will just want to glance at their watch for a few seconds, rather than using it for longer periods, as they would for a smartphone. However they will use their smartwatch with much greater frequency. Remember to keep this in mind as you develop your applications!