Having a regular schedule of updates helps get individual big fixes or features out faster. You may not notice a difference because you may not experience the bugs that are being fixed. There may be slight changes to features that you don’t use enough to notice. There could even be features that are disabled until they’re remotely enabled. Mobile apps often run A/B tests for changes to see how those changes affect user behavior, so you might be in the “no change” test cohort when you don’t see changes, those changes may never activate on your installation if the test doesn’t pan out.

I recently convinced my team to adopt this practice so I’ve been brushing up on it. When done right it can mean a more stable app and quicker response to issues since it relies heavily on monitoring app performance, bug reports, and user reviews. Communication to users is hard since you don’t want to have every update be “fixed bugs” but it’s also unnecessary to say “fixed an issue where a batch upload job didn’t handle individual errors by retrying” for each change that may not actually impact you as a user but which impacts the business that builds the app.