The phone apps end up having to keep up with the underlying android+ios stacks' ever changing details, but even worse are the cloud services that help make the app -> router connection seamless, with the need to keep up with the ever-ongoing churn required to run binaries on Google's servers (aka "in Production").
To give an idea of how much churn is required to run binaries "in Production", there is a 6 month build horizon enforced across the company to ensure that all teams keep up with the underlying churn (changes to security, rpc, filesystems, monitoring, libc, etc). Running binaries older than that is verboten. The reasoning is that teams building the underlying components would never get a chance to upgrade / turndown down-versions/ down-compatibility.
Supporting these products means requiring staffing the role of keeping these services running from both dev+ops perspectives.
It sounds crazy but the system is designed to build "at scale" rather than to be built "sustainably". Dealing with this ever ongoing churn is the typical life of a Google engineer building "in prod". The model works well with a healthy CI/CD (albeit still a waste of time to deal with mandated churn), but falls apart quickly when staffing is removed.
