|
|
|
|
|
by amatecha
2119 days ago
|
|
IMO these walled-garden app stores that are supposed to be "so good for the users" should require quality release notes that describe the exact "performance improvements and bug fixes" that the respective apps apparently receive. |
|
1. Major apps often do phased rollouts of features in order to react to potential production issues, or to make certain features available to a limited subset of users or regions without having to do an emergency binary release if things go wrong.
2. The new build contains an A/B experiment, and you don't want to tell users that feature X was revamped because the experiment might not even go anywhere and only a small number of users will see it, anyways.
3. Your app is stable enough to have a regular release cadence e.g. monthly or biweekly, and you actually are just shipping whatever bugfixes made it into master since the last release with the major feature changes hidden behind feature flags until they are ready for 1. or 2.
4. The vast, vast, majority of users never read the update notes on the app store. They have automatic updates enabled, and your app updates at 3AM when their phone is plugged in on wifi and they are fast asleep.
5. Building on 4, if you actually want to advertise new features to users, it is better to build a native experience into the app either building a UI highlighting what has changed in the new version, or just popping up a dialog to show the patch notes (can be coupled with 1. and 2. to only show the dialog to users who have gotten the new feature enabled in the phased rollout or experiment). Discord is an example of an app that does this well.
6. Also building on 4., the changes are so minor that they are not worth paying a translation service to translate your patch notes if you are offering your app in multiple languages.