I've been reading through the documentation on the WatchKit connectivity framework to try and figure out if I can delegate all of the intensive processing needs over to my parent iOS app. All of the code already exists in the parent app for doing the required processing and it seems significantly more efficient for it to do so, rather than the Apple Watch app duplicating the code and attempting it itself.
My question is whether this is possible if the app on the iOS device isn't active at the time the watch kit app makes the request? Will it just queue up the request until it's next opened or can it be configured to process it immediately? I would want the watch to always get some form of response or have a timeout on the request.
UPDATE:
I found that my particular issue was related to calling the reply handler from a background thread after executing a separate request. When I was doing this I didn't get a response back from the iOS device to the apple watch. This initially made me think the iOS device was ignoring the requests until it was active.
The solution for me was to do the following so that the reply handler is always called from the main thread. This seems to be a critical piece of the communication that I must have missed out in the documentation (or maybe it was missing :o). Long story, short, after making the update shown below I successfully got responses back every time.
dispatch_async(dispatch_get_main_queue(), { () -> Void in
replyHandler(myResponse) // Always call from main thread!
})
WCSession's sendMessage APIs enable the WatchKit extension to wake the iOS app up in the background as long as reachable is true. Here is a nice step-by-step tutorial on using sendMessage.