Help with first watch app

I helped with a similar question a few months ago in this post https://developer.apple.com/forums/thread/689484?answerId=686982022#686982022

If your iPhone app is in SwiftUI, the sample code I provided should form a workable basis for your use case. Note that the phone app and watch app both use a Data Model (i.e. standalone class, not a SwiftUI View) for communicating with each other and processing the data. The models also provide and collect data from their respective SwiftUI Views, i.e the user presses a button or enters data on the device in a SwiftUI view, which then gets collected by the Data Model and processed and/or transmitted to the other device.

In my sample code (above) the user wanted to transmit count data from the watch: in your case you (presumably) want to transmit a command to the phone. You can do this by having a common struct e.g named Command, in each Data Model, that describes the command that you're passing. Then in the transferUserInfo (i.e. send) and didReceiveUserInfo (receive) functions you use an instance of Command to send/receive your navigation instructions. Having received the Command from the watch, your iPhone Data Model would then send the appropriate instructions to the BLE autopilot.

My original post is a very simplified version of watch connectivity and there are circumstances where things can get more complicated. I therefore advise that, at some point, you read the documentation link I provided earlier.

I hope that this helps. Regards, Michaela

PS - it's also possible for the watch to communicate directly with your BLE navigation device, using the same code as on the iPhone (except for the UI, given the watch's small screen): but maybe that's another question/answer for another day.

Second PS - depending on how the iPhone app and device are configured, the phone app might not on-send the command to the autopilot immediately - which could be problematic!!! My suggestion therefore is that your watch app communicates directly with the autopilot, as per the phone app.

Well, I've got one way communication now, but only when I run on the actual devices. running from the simulator I still get the pairingID issue.

I can send from the watch to the phone, but the other direction, I have the following issue when updating my watch View from the ViewModel...

Publishing changes from background threads is not allowed; make sure to publish values from the main thread (via operators like receive(on:)) on model updates.

I'm getting closer, but time to pack it in for the night.

I just added "DispatchQueue.main.async { self.rcvMsg = msgStr }" where recvMsg is my published variable, and I now have two way communication working! Thanks again for your time.

I integrated the approach gleaned from the test app into my autopilot app, and I can now control the autopilot from my watch. The watch sends messages to the Bluetooth manager on the phone, and those messages are forwarded to the Bluetooth peripheral in the autopilot. Works like a champ!

There are 4 methods for phone/watch communication under Watch Connectivity, each related to the amount/type of data and the required immediacy of transfer. Now that I better understand what you're doing, my perception is that your use-case needs the sendMessage method, which you seem to have done, rather than transferUserInfo (which is simpler to implement and more reliable, but less immediate).

However there are some potential issues with sendMessage from the watch to the phone if the phone is not reachable or not active, as reported here (as recently as 3 months ago). Advances in iOS over the last year or two have improved the ability for background processing (in essence, when the app is not active on screen) - but I haven't had cause to delve into it and so can't offer advice. I suggest, if you haven't already done so, that you test your watch/phone/autopilot communication with your phone (phone app) in various states - to ensure that the watch's commands to the autopilot are reliably implemented.

Best wishes and regards, Michaela

I was surprised to find that the phone app continued to pass my commands through to the autopilot even after locking it. I would have been perfectly happy to have kept it on while using the autopilot, so the functionality to continue while locked was an unexpected bonus.

The HW autopilot’s only function is to maintain a heading. Anything else will be features I add in the phone app. I plan on implementing a route tracking feature once I verify the HW autopilot is doing its job. That and a few others would be tedious if not impossible to implement on the watch, so my plan is to have the phone be the brains of the operation.