Building the app – What I wish I’d done differently

Are there some bits I wish I’d done differently? It’s looking back with 20/20 vision on a software project – of course there are!

The most obvious is that it doesn’t yet have all the latest bells and whistles Apple have added into their frameworks in the last couple of years. Things such as async / await and a greater use of Combine. This is due to a slightly conservative view towards new implementations. While I still retain a fondness for anything which simplifies and improves things I’ve had my fair share of working with ‘bleeding edge’ items in the past. The difference in this case is that as an indie I lose time and don’t get paid anything if it doesn’t provide the claimed benefits. That does introduce a touch of reticence and a willingness to let others charge in first. Sometimes it means you avoid going down a path which peters out; other times you realise it would have moved you along quicker.

By the time I’ve seen the stability and effectiveness of async / await I have an amount of working code where it’s not cost-effective to replace at this time. It’s something that will be done later as part of code refactoring once the version with the last of the milestone features has been released. It’s the same with Combine which I currently use mainly for processing web service responses. It will be used in more areas of the code as it becomes increasingly more closely tied in with the other frameworks.

Automated testing is one thing which is lacking. It was nowhere near as simple to implement when I first started the project as it is now. I did play around with the XCTest classes then but struggled with how best to implement the instantiate / teardown items. It also didn’t allow easy handling of cases where you have to wait for certain tasks of an indeterminate length to complete before validating your results. I think a fair bit of it also came from me not having a fully solidified design for a while and so didn’t know exactly what I was meant to be testing.

In the team-based projects I’ve worked in the past there is usually a defined set of requirements and you derive your design to fit within those constraints. The test cases can then be generated from those items before any code is even written. In my case it became an issue of available time resources once I’d finally inked in the design and so automated tests didn’t happen. They will start to be added while I’m adding the async / await and Combine modifications. Apart from validation and regression testing they also make it much easier to make the app display a specific screen with known data and screenshot it. That makes updating the App Store promotional images in different localisations trivially easy.

I also wish I could remember more of my French and German from classes in high school as that would make it simpler to generated the localisations for those languages.