Duncan's Blog

Delayed 3.1 Update

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.

There seems to have been a change on WatchOS (maybe other platforms as well for all I know) in how SwiftUI lays out views when it comes to sizing Text. I've been investigating why WWYS running on 6.1.2 seems to have odd places where the Font is so small it can't be read.... Its not everywhere and I can't work out the logic. The place I noticed it were: Text in Expenses Pay list rows Text in Welcome Screen beneath the Currency Picker OK Button in Filter screen Test In Change Currency Screen beneath Picker I'm sure there would be others. I downloaded the old OS for the simulator and it replicated what I see on the watch. Definitely related to which elements get preferred sizes. For now I've given up trying to work it out and will move the minimum supported version to 6.2 as I suspect this may be one of those early SwiftUI things Apple fixed without telling anyone (at least I can't find anything in the release notes). Its not totally satisfactory, but not worth adding complexity for multiple operating system versions support in a free App, unless I can get much more clarity on what has changed. So apologies to any users - you'll have to upgrade WatchOS if you see this issue.

This release has now been approved. I plan to take a break on feature development for now. I'll fix any bugs that get reported, but for what I want to do next I want to see what Apple release in WatchOS 7 at WWDC. Its likely that they may add APIs, that would make it much easier and I don't want to start and find that I've wasted effort. If anyone has feature requests or ideas, comments and even complaints let me know at wwyssupport@james-bell.net

The work on WWYS foreign expenses has gone very well. In the end I decided to add a setting to turn on foreign expenses and let you select a default currency. When the is switched on, WWYS does a daily attempt to get all the exchange rates against your home currency and caches them. A new page is added to Expense creation, which takes the amount entered assuming your default foreign currency and converts it to your home currency. If the is the intent then you can just swipe over to confirmation; but you could change to another currency or enter an explicit exchange rate from this screen. This seems to give an easy workflow for the intended use case; a trip abroad, where you can turn the feature on for the duration of the trip and get immediate translations to your most likely foreign currency, but could still switch it if for example you were offered a currency choice when making a card transaction, or made a border crossing etc. The design aim is to minimise the interaction needed to create an Expense and keep a simple fast interaction. Therefore I'm really pleased that this design has zero impact when foreign expenses is switched off; no change to the current Expense workflow, or data that has to be displayed on the limited screen real estate . The setting can be toggled or default foreign currency modified at any time. I'm currently testing out builds of 2.0, with foreign Expense support and quite a number of major bug fixes for problems uncovered in the redesign - this may take longer than usual because it's been a big architectural change, and also because I don't have the same opportunities for live testing under lockdown as previously. If anyone would like to volunteer as a beta tester please contact me at wwyssupport@james-bell.net.

I'm starting work on 2.0 of WWYS. This is a significant feature addition which was planned from the initial concept for WWYS. The concept is to add the ability to enter an Expense in a different currency to your home currency, and have the app get the exchange rate from the internet to give a rough value in your home currency. The CSV export would include the actual Expense in its native currency along with the exchange rate used and the converted value in the home currency. This would allow import to your main finance package, and the foreign Expense can then be identified and corrected against the actual exchange rate used by your bank etc. The idea is is that using the general exchange rate would give a good idea of what it has cost whist out and about, and provide enough data during reconciliation of the account to identify it correctly. The difficultly is adding this functionality to the watch without impacting the easy Expense workflow developed so far. To achieve this a new Setting will be added to identify a Travel Currency, which if activated will add a forth page to appear during the addition of an Expense, which will give the user to enter the transaction as either a home currency or travel currency Expense. If no Travel currency has been selected then this page will not appear. Once entered the travel currency value will be converted to your home currency using the rates advertised by the European Central Bank, using the latest data the watch was able to cache. (will try and update once per day, but will use whatever data it has available). The Expense List screen will indicate that a value id an estimation in the home currency, and full details will be available in the CSV export. One side impact of this change is that the selection of a home currency can't be allowed to change one selected without resetting the Expenses stored in the watch. I doubt this will be an issue because you would expect the home currency to be tied to the bank account being used, so any change would also align with a bank account move so resetting the Expenses would also make sense. This will mean removing the home currency setting and adding it to the Reset Expenses workflow and of course on initial installation. Please share your thoughts as a comment here or send to wwyssupport@james-bell.net. As I'm only just starting this feature, any comments or ideas are welcome and could be incorporated into the final solution!

WWYS is mainly written using SwiftUI. However there were quite a few gaps in SwiftUI when I started out. It was not clear how to get a set of Pages to work as SwiftUI doesn't provide a PageViewController. (I realise I could have written one, but that was slightly beyond me and not my focus when I started. Plus I still think it likely Apple will provide a standard control in the next version of WatchOS) Anyway the way I set it up was to use a WKHostingViewController around each "Page" view and launch a set of pages using the reloadRootPageControllers, which I put inside applicationDidBecomeActive(). At some point a realised that one of the stability issues I was having meant this should have been out a DispatchQueue.main.async block, and that's how its worked ever since.... Coming to todays issue I had been aware for a while that every time you leave WWYS, next time to go back to it you are forced back to the top level. Most of the time this would probably be correct behaviour; if the app is left for prolonged periods then starting at the opening screen is more than likely what the user desires and expects. But if you are in the middle of entering a new Expense it definitely is not. Unfortunately this happens quite frequently to me as I get a notification of a contactless payment shortly after its made and usually whilst I'm in the middle of creating the Expense in WWYS! I started work on looking at solving this problem by saving UI state so that on return the app could resume correctly. This turned out to be very complex as WatchOS doesn't provide the same framework as iOS and as I am using a mixture of SwiftUI and WatchKit, its much harder to roll your own solution. It was whilst I was tracing through the API calls of SwiftUI and WatchKit when you exit WWYS in every use case I could think of, that I noticed that of course applicationDidBecomeActive() is triggered EVERY time the app becomes active, even if the App has not been closed bu WatchOS. Hence all I had to do to solve the bug was move the reload out of this method...duh. I don't need to store UI state at all - just wish I could now get back the 4 evenings this week I've spent puzzling over this problem.