Good luck Frank. If you get stuck, then I'd be happy to help out (e.g. sample code). I'm retired and currently stuck at home in a COVID lockdown, so I've plenty of time on my hands :)

I’d prefer to post working code on here: I understand your requirement and the code will be short enough to fit in a reply, but without the Coredata part. What version of Xcode, iOS & WatchOS do you use and do you use SwiftUI? If you use SwiftUI, do you generate apps with or without an AppDelegate? These days I prefer “pure” SwiftUI apps, I.e. without the app delegate. I can probably make a start tomorrow morning (12 hours time) if you want, and you get those answers to me. The watch connectivity sample code you refer to (above) contains far more than you need, so it’s not a good starting point.

Sorry for the delay Arsene: I've been otherwise occupied the last few days. Perhaps you've already tried on the watch, but it should work just the same as on the phone. You might need to change the ContentView's HStack to deal with the watch's smaller screen, but that's all. Cheers, Michaela

And thank you also M: the exploration was helpful to me too. I'm classifying COVID exposure sites (usually sparse information, e.g. entity name) so as to generate a risk profile by label and time period, e.g. Supermarket exposure risk by hour of day.

Ah, OK. Good luck 🙂

Using @StateObject in the App view, with appropriate.environmentObject call, creates a singleton for access by all child views. However, personally I prefer the DataModel.shared & @ObservedObject method (as per your suggestion).

Oops, I posted my answer at 7am and wasn't wide awake. When using a singleton **static let shared = DataModel() ** in the data model instead of using @StateObject in the root view, you refer to it (and get state changes) by using @ObservedObject var dataModel = DataModel.shared in the view where you are handing the @Published vars (e.g. arrayInt). Apologies, Michaela

A @StateObject var is like a @State var, except that @State only applies to the View where it's defined whereas a @StateObject var applies (with the right conventions) across all views. Here, State refers toSwiftUI, not CoreData. This is important where 2 or more views need access to the data model, because if you use @State var dataModel = DataModel() in both (all) views then separate and different versions of dataModel are created - i.e. they don't "talk" to each other. So, in the example I gave you, you will need to put @StateObject var ... in the App view - as per my earlier comment. Regards, Michaela

Also, don’t forget to instantiate BLEManager in your View hierarchy, as a Singleton or via @StateObject var bleManager = BLEManager() in the App View (plus a .environmentObject call on ContentView() in the App view)

You're welcome Kenn. I'm retired and currently stuck at home in a COVID lockdown, so it was good to exercise my mind. Also, I'm not sure if you're familiar with @StateObject. When Xcode created your project, it probably created a View named somethingApp. Putting @StateObect into this View allows a single instance of DataModel to be passed to all subsequent views: @StateObject var dataModel = DataModel(). then use .environmentObject(dataModel) after the ContentView() line The @EnvironmentObject var dataModel: DataModel line in my sample code picks up this reference from the @StateObject in the App view. Cheers, Michaela

Sorry, I should've been more explicit, beyond saying that the the Identifiable and var id weren't needed. Making something Identifiable means that it must have a property called "id". You can also use the id: parameter with List() in SwiftUI, but be aware that having a List in a ScrollView doesn't work - presumably because List is also a ScrollView. I'm happy to help out: I'm retired (in my seventies) and write apps for my own needs and to keep my mind active, so giving back is good for me. Best wishes, Michaela

For some reason inline code is not working in Comments (Monterey Beta issue?). The code that works on the very first launch of the app is .onAppear(perform: {             MKMapView.appearance().mapType = mapStyle             MKMapView.appearance().showsScale = true             MKMapView.appearance().showsCompass = true         }) Thereafter, until the app is killed and relaunched, the options are reset to default. My understanding is that many features (such as mapType, showsScale, showsCompass) are unavailable in Map() and any solution, other than an official enhancement, will be a fudge that's prone to future breakage.

That’s OK and thanks for your interest anyway. Yes, I’ve done a different project that switches maptype using UIVewRepresentable. What I don’t understand with my partial solution is why the very first setting of mapType in onAppear works, and thereafter doesn’t.

No, it's better that you create your own project in whatever version of Xcode that you have, adapting accordingly. I think (from memory) that Xcode 12 onwards creates SwiftUI apps by default, so you would only need to create your new project and then: Create a Swift file called DataModel and add the code I've given; Modify your new project's App file to add the @StateObject and .environmentObject lines I've given; Modify ContentView to be as I've described; Add your Plist entry as described.