SwiftUI rewrite for the watch app.

[vincentneo]

Well, this is going to be a big change, if I do make it happen.

The current watch app is built with WatchKit. WatchKit storyboards are deprecated since watchOS 7, and there is basically no updates for that anymore. No one knows if a future watchOS release will drop support for WatchKit apps. Moving forward, I believe it is wise to move the watch app to be a SwiftUI app, both for long term practicality and the features it brings.

SwiftUI also supports display of maps on the watch, which are (1) interactive unlike the one in WatchKit, (2) watchOS 10 will allow for poly lines (https://developer.apple.com/documentation/mapkit/mappolyline) from what I can see in the documentations right now, (3) better align the experience between the watch and iOS app of this project.

The cons of this, is that, deployment os will have to be raised. Some features like the map improvement are only available on watchOS 10, so what should the minimum os be, would be a question of its own.

(Then there's the other problem which is if I have the time to do this, but at least lets get some feedback, thoughts from users too, anyways)

@merlos, any thoughts on this?

[merlos]

Hey Vincent!

These days, that I had to work again in the code, it also came to my mind moving to Swift UI, but I was thinking to do it for v2.0, some kind of new start.

I was only not thinking only on a porting of the existing UI, but also in improving the "backend" of the app. For example, right now we are keeping three copies of the data (in the map, in memory using CoreGPX and in CoreData which makes it a bit hard to keep the state synced and even understand the code (I feel it is somewhat scattered). So, I was wondering how we could we do it in a more simpler or structured way.... but have to think more about it. Do you feel the same, do you have any idea on how to implement it?

With regards of the watch and adding the Map, I'm fine with it. I am wondering if there is a way we can keep the battery consumption... do you think that if we use horizontal pagination (similar to exercise app) would it be better for the battery consumption? Also, I was thinking that it would be great to have some of the figures we display larger. While running or riding a bike they are hard to read...

I'm preparing a certification for the next months, so I am not sure how much I'll be able to work already on this...

[vincentneo]

Do you feel the same, do you have any idea on how to implement it?

Yes, that is something that I have thought of before. I bet that right now there's probably some edge case bug still occurring, and that is precisely on point with how there's too many copies of the data.

No real idea of it yet, but I think CoreGPX should only be used for the decode and encode, rather than basing the backend off of it. So basically the the app has a data structure of its own, and only when user wants to open a file or save to a file, then CoreGPX is used. What do you think?

On the current recoverable feature built upon Core Data, I have no ideas on that yet.

I am wondering if there is a way we can keep the battery consumption... do you think that if we use horizontal pagination (similar to exercise app)

That needs research, since I am not sure if it is still being kept running even when user isn't actively viewing it. Anyways I am planning for the watch interface to be mostly different from now, since to add a map on such a small screen means much re-thinking of the UI is necessary, in my opinion.

I'm preparing a certification for the next months, so I am not sure how much I'll be able to work already on this...

And that's alright. The case has always been that we work on this project only when we have the time to do so.