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.

Sorry, in my previous answer I didn't explicitly answer your question about the Watch providing complete data for heartbeats for thousands of seconds. Some time ago I looked at the heartbeat data in the Health repository on the phone (as reported from the Watch) and more recently at heartbeat data in workouts on the phone: there appears to be no "complete" dataset, only periodic (every few seconds) data points. This perhaps is understandable given that for an hour's exercise there could be 5-10 thousand heartbeats, requiring a lot of storage and processing on the Watch. This lack of complete data, and my observed inaccuracies in the Watch's heart rate reports, is why I can't reply on the watch data and must use a third-party heart monitor chest strap. In my case, with arrhythmia issues, my phone app, using realtime input from the chest strap, can alert me during a run when arrhythmia stars to occur and/or when my safe heart rate maximum has been exceeded. I'm also able to then share the data with my medical advisors. Once again, best wishes and regards, Michaela PS - I gather that you're in Europe (Czech Republic?): in which case I wish you well in these troubled times.

I'm working with a number of multi-platform apps that have local packages, and sometimes have your problem because I'd forgotten key steps. For each Target (platform), build the Library (package) before building the main product of that target (e.g. MacOS). You will probably have to rebuild the Library (package) after any Clean Build Folder. For each target, at the General tab of the Target explorer, make sure you've included the library (package output) in the Frameworks, Libraries and Embedded Content. Each target needs to have the Library specified, not just once at the project level. I've had problems with local packages when I've included the source(s) in my app's project, rather than having the package in a separate directory and included in the app project. Best wishes and regards, Michaela

Heart rate data from my Apple Watch Series 4 are very inaccurate, as was the case on my earlier watches. For a while now I've been using the Watch's Workout app while running and comparing that with workout data from an iPhone app that uses a Polar H10 heart monitor strap. For example, on yesterday's run the Watch recorded an average heart rate of 148 bpm, whereas the Polar device data was for 123 - which is almost certainly accurate (I'm 72 with heart issues so don't go very fast). I have several years' worth of data from monitor straps (starting with Garmin), so I know what my heart rate should look like: it's understandably declined over the years as I've aged. Most heart monitor straps record every heartbeat and transmit its time interval as milliseconds, along with the current heart rate (actually a moving average of the intervals in bpm) to a tethered smart device. Most modern straps use Bluetooth LE and therefore can be read by the Watch Workout app, your app and/or an iPhone app. Best wishes and regards, Michaela

CloudKit records from CoreData integration are stored in a special zone (com.apple.coredata.zone) not in _defaultZone, which the CloudKit dashboard shows by default. Also, the dashboard is set by default to view the public database. So, make sure you've selected the correct database (public/private) and zone in order to view records. The "out-of-the-box" implementation of CoreData / CloudKit sync does not, and will not, store any records in the Public database. Also, CoreData record types (entities) and fields (attributes) in CloudKit have their CoreData model names preceded by CD_, e.g. a CoreData entity called Period with startTime and endTime attributes would appear in CloudKit's CoreData zone as CD_Period with CD_startTime and CD_endTime. I'm not sure what you mean with the iCloud account vs Development account. I find that running an app in debug mode in Xcode and accessing the CloudKit console also from Xcode (in "Signing & Capabilities") ensures that I'm looking at the correct CloudKit database. I hope this helps. Regards, Michaela

I looked at the same sort of app related to COVID case alerts here in NSW, but decided to do it only for myself. Most websites have restrictions on the use/reuse of data - especially for commercial purposes. You would need to check each website that you use (or intent to) for their terms of use: such information is often hard to find and usually legally complex, e.g. in relation to jurisdictional coverage. I imagine that Apple would be cautious about allowing any app that could, or does, contravene copyright or data licensing agreements, otherwise they might face joint liability. Even if Apple were to approve your app, you would be wise to conduct a legal risk analysis of the data collection and aggregation process. Best wishes and regards, Michaela (PS, I spent 30 years as an IT Procurement and Contract Management specialist and had to deal with intellectual property and licensing issues many times).

It's still happening with latest betas (Xcode 13E5095K and Mac OS 21E5212f). Also, I still haven't got NSClickGestureRecognizer to work, so it does seem related to the log messages or their underlying problem.

It's still happening with Xcode Version 13.3 beta (13E5086k) and Monterey 12.3 Beta (21E5196i), both the latest available as of today (4 Feb 2022). Regards, Michaela

Have you found solutions for this question? I suggest using SectionedFetchRequest for the hour grouping and a Shape struct for creating the bar chart. If you need help, then respond to this comment. Regards, Michaela

I'm a tad tired after a long day's work (it's evening here in Oz) so I haven't really digested what you're doing. However, my first thought is whether you've created a @StateObject to allow your Environment managed object to respond to changes. I normally put the @StateObject in my SwiftUI app's main (App) scene, and then pass .environment(.managedObjectContext.... to whatever view(s) thereafter need it. This way the resulting views respond immediately to changes in the Managed Object, provided you've used the correct @Environment statement in those views (which you seem to have done). Good luck and best wishes, Michaela