This year at WWDC Apple introduced watchOS 2 and the ability for apps to run natively on the watch. If you already created an app for Apple Watch then your work can be easily migrated to a native watch app. The user interface and interaction model are the same. The biggest consideration when migrating your app to watchOS 2 will be updating your communication system.
The key difference between inter-app communication on watchOS 1 and watchOS 2 is where your message is going after you send it. On watchOS 1 your message was being transferred to a shared container that was accessed by two processes running on the same device. All of this was handled via App Groups and Darwin Notification Center. On watchOS 2 your message is being transferred over a Bluetooth or WiFi connection between different devices. For some apps, that means it's important to rethink your overall strategy for how, when, and what you choose to transfer between the app running on an iPhone and the app that is now running on an Apple Watch.
Because your communication path now exists between two different devices, your communication architecture needs to make sure it takes latency and device availability into account. Complex apps will need to understand the tradeoffs between various communication mechanisms and how to use each one to achieve the best result. Now that the watch app runs on the watch itself, and the watch also has access to a WiFi network, you'll be using a combination of NSURLSession APIs as well as the new and extremely useful WatchConnectivity framework.
WatchConnectivity
The WatchConnectivity framework offers three core types of communication operations.
The Application Context is a shared data structure where you can store information that is synced in the background between the watch and phone. This is a huge deal for watch app developers because it gives you an opportunity to store information for the initial state of a watch app's UI that can be available on the watch before the user opens the app the first time. Anything that can be serialized as NSData or a Plist can be stored in the context. This is almost certainly going to be the centerpiece of your communication strategy for native apps on watchOS 2. It's a very elegant way to implement a basic View Model for configuring the UI of your Apple Watch app.
Here's an example of how you might use the Application Context. Lets say you are building an audio control Apple Watch app that can play a list of tracks on your iPhone. You could store an array of tracks and the currently playing track index in the Application Context. Any time that data changes on the phone, you can update the Application Context. The next time your Apple Watch app loads, it will have the latest information available to update its UI. The Application Context is a very easy to use API to achieve this result.
WatchConnectivity also supports background file transfers. This API should be used for longer running transfer operations. If your audio player app requires the presence of large media files on the watch, then this API will likely be the best fit for you. It affords you a much higher degree of control over the order and timing of file transfers than other communication tools do.
Interactive Operations most closely model the message passing system in MMWormhole. These operations are meant to send information between apps while both are running in real time. This operation might make sense to use for updating a playback indicator on the watch for audio playing on the phone. If the user is looking at their watch while your app is running on both devices, this API will be a great tool for keeping the two experiences in sync with each other. While this method is capable of waking up your iPhone app in the background, your communication system shouldn't rely on this too heavily because of how that will affect power usage on the user's iPhone.
As you can see from our audio player app example, there are very specific use cases for each of the APIs introduced in WatchConnectivity that come into play for our native app on watchOS 2. You'll want to think through all of your scenarios for sharing data between your iPhone and Apple Watch app to decide which one makes the most sense for each situation in your app.
MMWormhole
Many initial Apple Watch apps were built using MMWormhole, and we want to make it as easy as possible for those apps to migrate to watchOS 2. We are creating a new subclass of MMWormhole called MMWormholeSession that uses the WatchConnectivity framework. This means that if you were using MMWormhole to share information between your Phone and Watch apps then you can swap in MMWormholeSession and gain basic support for the WatchConnectivity framework in your native Apple Watch app.
The MMWormhole implementation of WatchConnectivity is based on the Application Context. The context provides a useful persistence mechanism for MMWormhole, as well as an opportunistic background syncing engine to make data available to your watch app before the next time it loads. The MMWormhole unique message identifier is used as the key for the application context, and the serialized data structure of the message is saved as its value. This way, you can pass messages to the wormhole without worrying about having an active connection between the phone and the watch. By the time the watch app activates in the future, the latest information will have been stored in the Application Context and will be available through MMWormhole's messageWithIdentifier API. This is a really nice feature for building more responsive native apps on watchOS 2.
Another popular feature of MMWormhole is real time message passing between an app and its extensions. The real time messaging operation of WCSession is a perfect fit here. The MMWormholeSession subclass uses this API for both sending messages and triggering listener blocks when a new message is received.
Conclusion
So, was MMWormhole "sherlocked"? Not exactly. The existing version of MMWormhole will continue to be supported and will be a great tool for sharing information between apps and extensions running on iOS and OS X. If you already have an Apple Watch app and have considered building a Today Extension, MMWormhole will still be a key component for your extension's communication system.
The new MMWormholeSession will be a useful tool for developers migrating to native apps on watchOS 2, but it is not a replacement for the WatchConnectivity framework. For instance, MMWormholeSession won't be a wrapper for the WCSession file transfer API, or handle message reply blocks. It will help make it easier to support watchOS 2 today, but developers will want to learn the WatchConnectivity APIs in order to build the best experience possible for their native app on watchOS 2.
We're going to keep iterating on MMWormhole throughout the iOS 9 and watchOS 2 beta process. If you have any feedback or want to help, check out the library on GitHub.