Things are way different than what they used to be when first apps ever appeared. Then, we didn’t really discuss about user experience, for instance.

Nowadays, there are various ways to see how your customers interact with the app. It is true that there is numerous analytics that can tell you details about your app’s performance, but the best parameter to tell you about performance is the crash rate.

What is crash rate?

The crash rate is a formula representing the number of app launches divided by the number of crashes in a given period.

You can see the result in different ways: from the total number of launches, how many have been a crash? (2 in 100); the percentage of crashes (2%); the percentage of successes (98%).

Choose the version that suits you best from time periods and results.

What is a good crash rate?

For Android apps, 2% (2 in 100) is a good rate. iOS apps usually have a 1.5% crash rate. It also depends on how competitive you are. For some, 2% is not a good crash rate.

There are various apps on the market. Some have 0.3% crash rate, others have 5% crash rate and yet they survive. But you must aim for the best experience you can offer to your customers.

One crash is acceptable, more can bring you trouble

Users are used to one crash. They get over it without batting an eye. But multiple crashes in a row mean they can’t use the app, so they will abandon it and will give bad reviews.

Your target should be to make these crashes improbable, and from our experience, paying attention to every little detail will help.

How can you lower your crashing rate?

Test the app during the development

People are in a hurry, so sometimes they test the final result, without looking at it during the process. Apps are created for users and they should be tested by them. In-house testing is not enough.

You will be surprised how many ways people find to hijack your app. Better hire a QA or a Tester to mess with the new app every day. This way, you won’t find trouble after releasing it.

Give it time

Don’t plan the release date in a short time. The more time you give to the app, the better it will get. We know it means more resources in time, money and developers, but an app developed with no pressure won’t need additional changes in the future (it doesn’t mean it won’t need new versions).

Postponing features, for example, for future releases can lead to expenses you didn’t plan and frustration for everybody. So give it time, don’t expect your app to be ready tomorrow (and not even in a year).

The fewer, the better

For an app, less is more for both its interface and the people who develop it. The fewer developers are involved in programming the app, the more decisions you can take. Everybody involved in the project should work as a team and the only goal should be to deliver the best version they can develop.

If you add feedback and testing as often as you can, you can’t go wrong.

Server for testing must match the server for production

Developing apps usually have some servers involved and it may happen that the testing environments won’t match the production ones.

This element is crucial because the app can work flawlessly in the testing stage, but it can massively crash in the production stage.

Conclusions

Crashing exists and we must deal with it, but we all should work harder to eliminate it. If something works, keep doing it, if it doesn’t work, fix it as soon as possible. And this way your users will acknowledge it.

If you need an app or you want to talk more about your existing app, do not hesitate to contact us!