That means the code is now executing on your watch instead of the phone. By reducing multiple times of data transfer between devices, this is going to make the app loads a lot quicker and responds in a shorter period of waiting time.
WatchKit Extension runs on the phone and the Watch App is more like a display console for your app.
WatchKit Extension now runs on the watch, you don’t have to run a watch app with the phone connected actively.
Spentable: our first app on the watch
Spentable is a handy, in-your-pocket app that helps you to track your expenses and make purchasing decisions. Now you can even track you daily expense via the watch App without taking out your phone.
In this post, we will talk about the experience on building an app for watchOS 2.
Since the watch app is now running on the watch as a native extension, there are situation we need to handle data sync between the phone and the watch. For example, we wish expense input via the watch will be reflected on the phone instantly.
Get connected to the phone: Watch Connectivity Framework
In watchOS 1, the watch app must be connected to the iPhone app (we call it the main app) to work. We often call
[openParentApplication:reply:] to send a message to the iPhone app. However, now the connections in watchOS2 are handled by the Watch Connectivity Framework.
The Watch Connectivity Framework provides a seamless background connection between iPhone and iWatch. It helps doing all the synchronization work between the main app and the watch app. When the watch app handles a user input say, a new expense item, it has to notify the main app and get the record updated. The could be easily done via the Watch Connectivity Framework.
This allows Device-to-device communication more freely (such as transferring files, user infos and application context around ). There are serval APIs to transfer particular data for different use cases.
So how do we choose between them?