How Often Should You Update Your App?
Once the first version of an app has been built in anywhere from 4-6 months—possibly longer or shorter—the next step is to begin to maintain and support that app. The most popular apps on the app stores often see updates as frequently as weekly while other release cycles may happen once or twice a month. In this post, I'll break down how to approach app updates, balancing smaller and larger updates, and more generally accounting for different kinds of release cycles.
- Most successful apps release 1-4 updates a month.
- Update frequency will depend on user feedback, data, and team size.
- Most feature updates should be scoped to be no more than two weeks.
- Balance faster bug fixing updates with longer feature releases.
- Plan 2-4 updates in advance but keep attuned to market demands.
Why App Updates Matter
Although most don't know it, app updates are one of the best marketing tools app developers have at their disposal. With the number of apps people have installed on their devices today, regular updates can help an app get more mindshare relative to other apps on a device. Releasing regular updates keeps an app top of mind because it will show up in the updates list like the App Store or Google Play Store. Apple and Google also like to see app updates, especially with their major OS releases, which is why we recommend to have your app updated on major OS launch days.
App updates can also help build a loyal following, provided that the updates include relevant bug fixes and features that users are requesting. Frequent updates show you're committed to the app and that it's still being maintained. Having a loyal following for your app will help it spread on and offline. The most loyal users may even suggest your app as an option when people ask about alternatives to apps they are using now. This type of commitment could never be earned just through marketing alone.
Finally, app updates offer a way for a developer to speak with their userbase via release notes. While a smaller number of users likely will read the release notes, the ones who do are often the most technically savvy and engaged. Release notes should definitely not be overlooked.
App Updates Per Month
App stores do not reward the “ship it and prosper” mentality. As mentioned before, the most successful apps are updated upwards of weekly on the higher end. On the lower end, they usually get at least an update a month. If you don't feel you can be committed to updating your app at least once a month, seriously reconsider even building an app.
Your app store updates should be driven by qualitative user feedback, quantitative data, and an understanding of your market. Determining the right balance of these elements and the proper cadence of updates will take some time. Being more conservative with your release planning initially will ensure that updates will start making it to your users sooner.
There are some exceptions to the guidance of 1-4 app updates per month. If you have a larger number of apps in your portfolio, it may be challenging to update all of them each month. There's also the case where an app may just be in "maintenance mode" with little justification for continued investment; that's a topic for another time.
App Feature Release Updates
How frequently your app updates occur will mostly be driven by the types of features you try to tackle. The more features or the larger the feature, the longer it will take to get an update on to the devices of your users.
While feature length time will vary, our recommendation at Savvy Apps is to try to tackle features that take no longer than two weeks to build. If a feature on paper looks like it will take multiple months, try to figure out a scope that will instead fit it into two weeks. The reason is that even a two-week development cycle will then require multiple days to test and refine the update. Accounting for potential app store approval times, you're then already at three to four weeks in total, putting you just at the lower end of a threshold of a monthly update release cycle.
There are situations where a feature will be much more comprehensive, requiring multiple months of effort. These kinds of features are best suited for larger teams. Larger teams will have the resources to be working on multiple releases at once. One group of team members could be dedicated to working on an immediate bug fixing and maintenance app update. Another set of people may be working on an update that has a feature that is not slated to come out for 1-2 months in the future. If you're an independent developer or don't have multiple people working on your app at once, it's often best to stick with the maximum two-week feature building cycle.
App Bug Fixing Updates
Another type of app update is a bug fixing release. Although some releases will include features and bug fixes, it's also common just to focus on a release that helps make an app more stable. For example, Apple and Google's last major OS releases—iOS 9 and Android 6.0 respectively—were in many ways more about stability and bug fixes than new features.
For more mature apps that have significant marketshare, bug fixing updates are fairly common. These apps are mostly about improving and stabilizing experiences for their users because their features are largely solidified. They'll occasionally have longer feature building cycles happening in parallel for significant updates. Otherwise, their app store release notes often are as simple as "we bring updates regularly to make the app better for you." Bug fixing releases are the kinds of app store updates that can happen either weekly or every other week.
Major versus Minor App Updates
It's worth addressing version numbers briefly. Feature building releases are usually considered major app updates while bug fixing releases are thought of as minor ones. A major or feature release typically sees the second number of its version bumped while a minor one updates the last number in a three-digit sequence. For example, a feature update may see the app version go from v2.1 to v2.2 while a bug fixing update would go from v2.1 to v2.1.1.
The conventions for version numbers vary quite a bit in the industry and are continuing to evolve. For desktop software, with the speed of releases for browsers in particular, version numbers have become simplified and much higher. As it stands in January 2016, Google Chrome is now at version 47 and Mozilla Firefox version 43. For similar reasons, Facebook and Google in particular are beginning to adopt that kind of standard for mobile apps. Facebook's flagship app is now version 46 and each release bumps it a full number. This approach to version numbering is less helpful to users but may better represent the way release numbers work in the future.
Example App Roadmap and Release Schedule
By way of example, let's consider what an app roadmap and release schedule could look like right after a v1.0 app is shipped.
After an initial release, the next update really should be solely bug focused. Squash as many common issues as possible and don't even worry about adding any features that didn't make the v1.0 cut. This approach will lower your total support requests and give you the best chance to improve your app store ratings. It will also help with not having an update take multiple weeks. At Savvy Apps, we try to push a bug fixing release to an app store within days of a v1.0 app being launched. The first bug fixing update version number would be v1.0.1.
Thereafter, each release should include some bug fixes and refinements. Target a handful of each while beginning to move into the 1-2 week feature building release cycle. As called out earlier, hone a feature until it can fit within a 1-2 week design and development cycle unless you have a larger app team. The first major feature release would be labeled as v1.1. If two smaller updates were shipped thereafter, they would be versioned as v1.1.1 and v1.1.2 respectively.
As users provide feedback through your support system, the app store, social media and other places, keep track of the most requested items and bubble them to the top. Then begin moving these items into each of your releases. Use analytics, diagnostics like crash reports, and other hard data to also help prioritize items into your releases. Also continue to account for app store approval times as needed. Future feature releases would be labeled v1.2, v1.3, and so forth. A significant overhaul would then push the version number to v2.0.
It's generally a good approach to have 2-4 releases planned out as well as a broader overview for six or more months. None of your releases should be firmly solidified though. Keep them fluid and continue to triage them based on what you're seeing in the market.
While the number of app updates will generally be in the range of 1-4 per month, obviously where you fall on the spectrum will vary. Individuals or smaller teams may only be able to get out a quality release per month. Larger ones with more mature apps will usually be in that two, three, or even four updates range. Continue to balance adding features and stabilizing your app. Stay disciplined and avoid app scope creep. With this approach, you'll ultimately put yourself in the best position to have a healthy set of updates flowing to your userbase.
Join 20,000+ Other Readers
Sign up to be notified of new blog posts and be the first to receive helpful app goodies from Savvy.