New iPhone App
Duncan James-Bell • February 12, 2021
Delayed 3.1 Update
After completing the WatchOS changes over xmas, I had intended to release the Apple Watch version with multiple accounts and iCloud sync as a standalone release before starting work on the iPhone App. However in reconfiguring the project to start working on the iPhone App I then found I could no longer release Watch apps without the iPhone App....probably because of my lack of understanding of Xcode configuration; but in the end I needed to complete the bare bones of an iPhone App before finally getting this release done.
Duncan's Blog
After the disappointment of any better messaging API this year, I've been experimenting with better ways to export the data from the watch. In the end I decided the best way forwards was to bite the bullet and sync data to iCloud and write a dedicated iPhone App. The move to iCloud data storage has taken quite a lot of work because changing the data schema in the future becomes harder, so I first of all had to bring forward other features such as multiple account support that impact the data schema. So I am going to do this in two stages. Firstly the next version will come with multiple account support and iCloud data sync, then at a later data an iPhone App to improve data export. I've just completed my first beta version for WatchOS, but its such a big change that I will need to road test it for a few weeks before getting ready to release. I also need to update all the instructions on this web site as its a big change to the overall structure and flow for quite a few use cases. If anyone wants to help out with beta testing please get in touch!
WWDC has been a mixed bag in relation to WWYS. I had really hoped for more message API support on the Apple Watch so I could improve export to use iMessage or email, but unfortunately I can't find anything that might assist. On the other hand SwiftUI has made some big improvements on what is possible. This leaves a dilemma; WWYS was always intended to be based on SwiftUI as being the best way to have a good WatchOS only app, the the reality of the current implementation is that quite a bit of the "Outer Shell" had to be built with WatckKit. In the new WatchOS 7 this would no longer be the case, but removing and porting to full SwiftUI would make it very hard to be backwards compatible with Watch OS 6. Having given it some thought I've decided that my approach will be to first update the current App so that it better aligns with WatchOS 7 during the beta period, using its current architecture in a WatchOS 6 backwards compatible way. This is to support anyone on the beta program and ensure WWYS keeps working. In parallel a WatchOS 7 only port will take place to release as shortly after the official WatchOS 7 release as possible. At this point I will drop WatchOS 6 compatibility and so users will need to upgrade to keep up to date with new versions. However, this will be preceded by a final WatchOS 6 release that is backwards compatible.
I've been working on improved complication support for WWYS. Apples logic behind these complications is incomprehensible. For those who have never looked into this, different watch faces support different complications. Some look almost identical on the watch in size and shape, but vary in what data can be added to them. I was trying to mainly provide the daily spend directly on the complication, but was unable to make this work in all cases. Some complications allow text or images, others support some kind of gauge, and even though they may look the same shape not all can be used on every watch face - there seems to be no specific logic, almost as if Apple just a a new type every time they get a new idea and add it it the faces they are working on at present! Anyway the results will be in the next update. I'm not really happy with them, but its the best I can do without finding way to add a gauge of some kind ;-> I did wonder about adding a weekly/daily spend target just so I could do this, but it just seems so artificial. After all I've put the totals on the main screen so if you can't work from that adding a little bar doesn't seem to do much other than look pretty and add complication - which I have tried to avoid as the functional path being simple is the most important aspect of the app.
