Nope, it’s explicitly not because of the app version. (Although the feature would have a minimum version.) Google likes to lock updates behind a server-side check so they can gradually enable rollouts and see if it starts bricking phones or whatever (then completely ignore the issue for months if it does)
They’re using what’s called “feature flags” or “feature toggles.” It lets the software team work faster and safer: ship inactive code updates to clients, then gradually, remotely turn them on to make sure the changes work and be able to quickly go back without requiring another app update if something goes wrong.
They’re quite powerful and effective if used correctly. Very standard practice these days.
What the fuck? Few things are more obviously local-only or mostly-local than a clock app. Why is there a server involved in a basic UI feature?
I think they mean the updated app is rolling out gradually.
Nope, it’s explicitly not because of the app version. (Although the feature would have a minimum version.) Google likes to lock updates behind a server-side check so they can gradually enable rollouts and see if it starts bricking phones or whatever (then completely ignore the issue for months if it does)
Other than for getting the time, can’t see anything else.
They’re using what’s called “feature flags” or “feature toggles.” It lets the software team work faster and safer: ship inactive code updates to clients, then gradually, remotely turn them on to make sure the changes work and be able to quickly go back without requiring another app update if something goes wrong.
They’re quite powerful and effective if used correctly. Very standard practice these days.
https://en.wikipedia.org/wiki/Feature_toggle
I’ve used them in web apps. Using them in a clock app that’s entirely, or almost entirely local feels weird.