All of their services that are network heavy (TV, iCloud, Apple Music, News, Safari Sync) are so slow and do huge full reloads of every bit of state, so you just constantly see loading spinners, or worse in iCloud, you see nothing and eventually it will pop all the new stuff in to view, with no way to force a refresh.
I get that CAP theorem exists, but other providers at least seems to understand opportunistic sync and do a job of making it work for the user, but Apple seems to think that inconsistent views over data can't be helped and that every user should understand eventual consistency.
Their SDKs for syncing data to iCloud have long been a joke in the developer community and I think there have been 3 attempts at getting CoreData -> iCloud working, with the last iteration NSPersistentCloudKitContainer often being used as the [butt of jokes, a case study on poor networking talent at Apple] among iOS developers.
Establishing popularity at a point in time requires a window of time.
If I had to guess, they pick a window of a few days because if you did it every minute or even every hour, there might be wild fluctuation in the long tail of apps, depending on whether 8 or 0 people happened to download it in that time.
You could fix this by making window size inversely proportional to short-term popularity and running every 15 min, but that's just more effort to reason about and code and debug. It seems like something they absolutely should do, but I can see why it would be pushed down the backlog.
[0] https://www.namecheap.com/support/knowledgebase/article.aspx...
They're omitting the detail that ISPs are violating the spec.
If you set your DNS TTL to 3600 seconds, a caching resolver should store both that and when they received the response. Then, when another client requests the same name in 30 seconds, it should pull the result out of the cache and send it to the client with a TTL of 3570 seconds. This way, once 3600 second pass from the authoritative query, all the cached data is expired everywhere. If you know you're about to make a change you can lower the TTL to 300 seconds an hour before you make the change, after which the change should only take 5 minutes to propagate.
Some ISPs ignore the TTL and tell all their clients that they can cache the result for 72 hours so the clients don't make as many queries to their DNS servers. If you find your ISP doing this, stop using their DNS servers (or stop using that ISP) because it can obviously cause you problems whenever anyone changes a DNS entry and your ISP is handing out a stale one for you to cache for days. Maybe just never use your ISP's DNS servers in general.
