[JimDabell]

> This is a terrifying sentence to me, because what it implies but doesn't say outright, is that there's not a single person in the organization who actually fully knows what is being released. If there were, then they should already have this information!

It’s not the collection of the information that’s difficult, it’s delivering it to the user in an appropriate way when you use phased rollouts with feature flags.

The change log that the App Store presents to the user is static and identical for everybody. The changes that a user actually experiences are not. So you might have 0% of your users experiencing a certain feature when the release goes out, 10% a day later, 50% a day after that, and 100% at the end of the week. Or, if the metrics show a bad response, it might end up at maximum 10% seeing it, and then it dropping back down to 0% the next day.

Apple gives you a static text field to enter the change log information, with limited length. If you have ten different features to release, your users will all receive them at different times, and not all of them are guaranteed to make it out to everybody, how is a static text field supposed to deliver that information?

[Master_Odin]

"Begin rollout of feature <foo>" "We are rolling out <foo> in <timeframe> to ensure <x> about <y>, and rollback if <z>. You will notice you have <foo> when <bar>."

If you don't put anything about new features, don't be surprised when users don't use them (because why would they know) or complain what something "breaks" (or just changes on their workflow) because your changelog communicates nothing.

[JimDabell]

> "Begin rollout of feature <foo>" "We are rolling out <foo> in <timeframe> to ensure <x> about <y>, and rollback if <z>. You will notice you have <foo> when <bar>."

That’s a guaranteed way to get users complaining that they don’t have a new feature that you “promised” that they may never receive. It also isn’t appropriate for multivariate testing and just isn’t going to be understood by most users anyway.

There are way to do this in a decent way, but you have to do it within the application using your own logic. The change log provided by the platform is inadequate.

> If you don't put anything about new features, don't be surprised when users don't use them (because why would they know)

If you need to tell your users about new features in the App Store change log, then you’ve already failed because almost nobody sees it. Users know about new features because either a) it’s obvious when you use the application, or b) you tell them about the new features somewhere they will actually see it, at an appropriate time.

> or complain what something "breaks" (or just changes on their workflow) because your changelog communicates nothing.

A change log does not prevent this. You are attributing a lot of power to the platform change log that it simply does not have.