One of the challenges with developing cross platform apps for iOS, Android, Windows, Web, Linux etc is that at some point you’re inevitably going to need to spend some time focusing on each individual platform. Optimising startup performance is one of those cases. In this post we’re going to start looking at the how and why of optimising the startup time of your app.
Let’s set the scene by understanding why startup time is important. There is an obvious answer here: Startup time is the time taken from when the user clicks on the app icon, to when the app is rendered and available for the user to interact with it. As such, reducing this time will clearly have a net benefit to the user and thus lower their frustration with using your app. There is a user expectation that apps will launch in sub-1 second time, allowing them to easily and quickly switch between apps. I’ve read that Apple recommends no longer than 400ms for iOS apps but can’t find an actual reference for this.
In order to optimise startup time, you of course have to have a way to measure it. Unfortunately, there’s no standard way to do this and definitely no consistent way to do it across all the platforms you may be targeting. Different platforms support different outputs that can be recorded and calibrated to give some gauge on how quickly our app launches. We’ll get into the specifics on how to measure startup time on various platforms in subsequent posts.
Once you have a measure for startup time you need to establish a benchmark – ideally you’d do this early in the app development lifecycle so that you can detect and address any notable changes during development. I’d also stress that whilst it can be informative to compare the startup time of your app to other apps in the market, don’t obsess over it (unless you’re getting negative reviews saying that your competitor launches quicker…. then you might want to target that feedback specifically).
The other thing that’s important about measuring startup time is that you do it consistently. By this I don’t just mean being consistent on the method for measuring startup time, I also mean being consistent about when you measure startup time. Ideally, you should be measuring it after every change to the app – if you can set this up as a step in your automated CI/CD process, you can detect and variance in startup time before you merge your changes.
One last point I’ll make is that you need to expect your benchmark to change with the course of your app. Sometimes you’ll need to prioritise feature development at the cost of a small change in startup time. Other times you’ll focus on improving startup time at the cost of slower feature development. The important thing is to document when your benchmark changes, what caused the change, and in the case of an increase in startup time, why it was permitted (and ideally a task to go back and look for ways to improve startup time again).