Book Scanner 1.7.2 or why a simple change took one month
Book Scanner version 1.7.2 is finally completed and it’s the most awesome version of Book Scanner yet!
Book Scanner now works and looks good on all supported iOS devices and plays nicely with iOS 12.
Why did it take so long?
Even though this version took a whole month to complete, it contains no new features. Why did a simple point release without features take so long to finish? The reason is simple and contains a lesson for all of us:
The app had not been built for three and a half years.
But Runar, you ask, how can this be? You’re all about continuous, repeatable, automated processes, hates manual labor and coded your first CI pipeline before you even knew the singleton pattern.
Book Scanner was my first iOS app. I used it to learn both iOS-development and MonoTouch, the Xamarin-stack before Xamarin became Xamarin. Even NuGet-packages were brand new then.
Let’s think about what’s changed in the intervening years:
- iOS has changed from version 9 to 12 with a new permission model
- C# has gone through several language versions
- .Net has changed it’s entire mindset, project model and guidance
- Microsoft bought Xamarin
- Xamarin Components has been discontinued
- My analytics service of choice has been discontinued
- The App Store and iTunes Connect has changed massively
So in releasing this version I had to make a lot of small changes which would have been trivial if performed gradually over the years.
What lessons can be learned?
As a professional developer with a development team consisting of only me, how would I prevent this from happening again or in future projects?
By utilizing well-known techniques and tools improving software quality and ease of release and maintenance.
Automated tests
The only part of any app that is not covered by automated tests, is the part which can fail at any time without consequences. Book Scanner contains no such parts.
Therefore, basic stuff should be unit tested, service clients should have integration tests and important user scenarios should be UI-tested. In 2019 all of this is easy, and to be fair, it was easy in 2016 too!
Set up a CI pipeline from day 1
Then a CI pipeline which builds the app at least once a day is needed. The pipeline must build and test the app using the automated tests.
This would’ve alerted me when dependencies such as NuGet-packages or Xamarin components changed in a manner which breaks either the build or the functionality of the app.
Verify external services daily
If an app contains an external dependency, such as an analytics service, this dependency must be verified at least once a day. A service not vital to the operation of the app, should not break the CI-pipeline, but another build or repeatable automated process must alert you if something changes that break the way your app use the service. If the service forgets its backward compatibility, the CI-pipeline will fail. This is for the other cases, such as when a service is discontinued.
Become and remain an iOS expert
Follow the development of iOS closely. Install the betas after WWDC and check that the app still functions. Complete any necessary changes before the first full release. You’ll always how months to do this. And follow changes to the App Store or policies closely.
When iOS 12 made camera permissions mandatory, I failed to do this and my customers paid the price.
Beta-test major new features
Use a beta-test service or feature flags to verify new features on a subset of your user-base before releasing the to the general population. This makes sure that a major change is actually useful. Every new feature makes the other features of the app less discoverable, and the more features, the easier it is for bugs to hide.
Create a delivery pipeline
Finally, automate the actual publishing of the app. Including the way screenshots are taken, the signing of the app and actual upload to App Store Connect. This means that screenshots too need to be automated.
The only manual step needed to ship a new version should be the decision to actually ship.
None of these things are difficult, but they’re necessary for a carefree life in production.
I will document my preferred solutions to all of this in later posts. So for now, try the app, give me feedback, and I promise not to keep you waiting three and a half years again 😉