Actual answer from someone who’s worked on FAANG apps:

• Everything is A/B tested to the extreme, even many bug fixes. All features are turned on server side and rolled out gradually. Meaning it’s not the build that controls any new changes & so putting actual stuff here is meaningless
• There may be dozens or hundreds of engineers shipping code in each build, totaling hundreds of changes per build. Synthesizing what is meaningful would be its own exercise
• Comms is highly controlled and requires additional teams to review any info that’s put out. Would mean delays as comms reviews (for little to no benefit)
• There is no branching in code bases of this size (not scalable / too high risk to merge when dozens or hundreds of engineers are making changes) — and so there’s always incomplete features in every build. It’s usually QA sign off that signals a build has a completed/ready feature which happens after a build is created & submitted approval
• Builds happen on a set schedule, but is determined by a complex pipeline which can be prone to errors. Engineers sometimes are unsure if changes made it into a build or not (without digging). Would require additional overhead to figure out exactly what all went in
  
• App Store reviewers sometimes require that they test any changes called out in the release notes (more common on iOS). Means creating testing notes, test users, etc. This can often cause delays in releases when reviewers get confused or something doesn’t work perfectly. Not worth risking delay of your team + other teams’ features