If you are up to the challenge of creating an Apple Watch App, here we will provide a simple guide outlining the necessary steps.
One in six adults in the U.S. already owns a smartwatch or fitness tracker. The smartwatch section of the wearables market promises to be one of the most exciting — and a crucial part of market growth will be driven by the applications available for the devices. However, building applications for smartwatches cannot merely be an exercise in taking existing applications and transferring them to a smaller screen. Instead, you will need a wholesale rethink of how your customers will engage with the form, and the specific use cases in which they will use it.
Therefore, to get into this severe next wave of growth in the wearables market, you have two options: have someone build a smartwatch app for you, or make one yourself.
Firstly to create an Apple Watch App is to add a new target to the project.
File> New> Target
This action creates two folders: “App name WatchKit Extension” and “App name WatchKit App.”
WatchKit app only involves the Storyboard and images resources. The logic will be addressed in the WatchKit Extension.
The two methods that you originally call before you see the User Interface (UI) init and awakeWithContext. Even when you can make the UI elements in init, when there are too many elements, it is suggested to do it in awakeWithContext. If you utilise init, you have to call super first. Calling super creates the details of the UI and assigns the properties we have declared.
The views are divided into a grid of 3×3. Everything is placed according to a horizontal parameter (left, centre, right) and a vertical parameter (top, centre, and bottom). There is no concept of constraints, neither can you apply coordinates to position anything.
Height and width can be set to a fixed value, associated to the container or the content. This is related to match_parent and wrap_content in Android.
Since WatchOS 2, communication can be made using WCSession.
To have concurrent communication, both apps (WatchOS and iOS) need to form a WCSession instance and activate the session. Once both sessions are ready, the apps can communicate among them instantly. If only one of the apps has the WCSession active, this one can continue transferring files and sending actualizations, but the actions will only occur in the background and follow iOS politics. This indicates that you can’t be sure when will they be made given that the OS will assign times and preferences based on its criteria.
There are three ways of setting background communication: it can be either through application context, user info transfer, or file transfer.
This one has pros and cons as only the last context transferred will be sent. Let us see an instance: in a case where only the iOS application has the session activated and sends a “message x” to the smartwatch, this message will be passed when the system thinks it is right. If before that time the iOS app sends a second message, “message y”, it will overwrite “message x”, then when the system decides it is the right moment to deliver the message to the smartwatch, it will only give “message y”.
This is very useful when we are interested in only sending the most recent information, but it is useless for any other scenario where the information submitted is relevant.
To receive the message from the another side, we need to utilise the callback of the delegate.
This method is done when all the information that we send is essential, and we do not want every message overwriting the previous one. With this process, the messages are delivered following order of FIFO (First In, First Out).
And to receive messages we use:
What we should apply to transfer files between the devices is:
To check all the data that are waiting to be delivered, you can obtain the property outstandingFileTransfers of the WCSession. To get those files we use:
When we require the messages to be delivered immediately, we need the sessions activated in both devices. To check that, we require to look at the reachable state of the external device.
iOS app: Bluetooth must connect the paired Apple Watch, and the watch’s app needs to be running in the foreground.
Watch app: Bluetooth must connect the paired smartphone.
Once we have reviewed the state, we have two feasible methods that we can call depending on what we need to pass (either is an NSDictionary or NSData).
To receive those messages, we must consider if we want an answer or not. For NSDictionary we use session:didReceiveMessage:replyHandler: or session:didReceiveMessage:
For NSData, we have the same options depending on if we want an answer or not. We can use session:didReceiveMessage:replyHandler: or session:didReceiveMessageData:
The above guide will assist you get begun developing applications for smartwatches. But master the golden rule: a smartwatch is not a smartphone. How people will use your application on a smartwatch will be very different. Typically they will want to glance at their watch for a some seconds, rather than using it for longer periods, since they would for a smartphone. Though, they will use their smartwatch with much higher frequency. Remember to have this in mind as you develop your applications!