4 ms·

The App Store has had a problem with cold starts for a few years now. I remember a few years ago when I worked on App Store search it was a known problem when a

by bradly 3y ago

The App Store has had a problem with cold starts for a few years now. I remember a few years ago when I worked on App Store search it was a known problem when apps like Disney+ were released and users were searching directly for a new app immediately.

calderwoodra 3y ago
Exactly this, it takes a few days before the app will be indexed.
- thomasahle 3y ago
  "Cold start" problems are usually not about the app being indexed, but about the recommendation/ranking system being based on what other users have clicked on or downloaded.
  - calderwoodra 3y ago
    Give it a try - deploy your iOS app with a totally unique name and let me know if you can find it. It won't show in search results, no matter how many pages you scroll through.
- ricardobayes 3y ago
  I wonder what on earth takes a few days, this is not a DNS record...
  - jdminhbg 3y ago
    The CAP theorem.
  - ugjka 3y ago
    DNS records don't take days
    - ricardobayes 3y ago
      yes, sorry. Meant the indexing by search engines
  - bloodyvalentine 3y ago
    DNS records take a minute or two to update
    - unreal37 3y ago
      DNS records take a minute to update and take 24-48 hours to propogate to all nodes globally due to caching. [0] https://www.namecheap.com/support/knowledgebase/article.aspx/9622/10/dns-propagation-explained/ https://www.namecheap.com/support/knowledgebase/article.aspx...
      - zrm 3y ago
        > ISPs have different cache refreshing intervals 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.
  - crazygringo 3y ago
    I wouldn't be surprised if it's tuned based on what people tap after a query, popularity stats generally, or other similar stats, and so they rebuild it only every few days after accumulating more stats. 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.
    - MichaelZuo 3y ago
      So it would be search of the app store a few days ago?
      - crazygringo 3y ago
        No, it would be a search of the app store string matches now, but ranked according to popularities from a few days ago.
  - AJRF 3y ago
    Apple + The Web is a match made in hell. 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.

by bradly 3y ago

calderwoodra 3y ago

Exactly this, it takes a few days before the app will be indexed.

thomasahle 3y ago
"Cold start" problems are usually not about the app being indexed, but about the recommendation/ranking system being based on what other users have clicked on or downloaded.
- calderwoodra 3y ago
  Give it a try - deploy your iOS app with a totally unique name and let me know if you can find it. It won't show in search results, no matter how many pages you scroll through.
ricardobayes 3y ago
I wonder what on earth takes a few days, this is not a DNS record...
- jdminhbg 3y ago
  The CAP theorem.
- ugjka 3y ago
  DNS records don't take days
  - ricardobayes 3y ago
    yes, sorry. Meant the indexing by search engines
- bloodyvalentine 3y ago
  DNS records take a minute or two to update
  - unreal37 3y ago
    DNS records take a minute to update and take 24-48 hours to propogate to all nodes globally due to caching. [0] https://www.namecheap.com/support/knowledgebase/article.aspx/9622/10/dns-propagation-explained/ https://www.namecheap.com/support/knowledgebase/article.aspx...
    - zrm 3y ago
      > ISPs have different cache refreshing intervals 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.
- crazygringo 3y ago
  I wouldn't be surprised if it's tuned based on what people tap after a query, popularity stats generally, or other similar stats, and so they rebuild it only every few days after accumulating more stats. 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.
  - MichaelZuo 3y ago
    So it would be search of the app store a few days ago?
    - crazygringo 3y ago
      No, it would be a search of the app store string matches now, but ranked according to popularities from a few days ago.
- AJRF 3y ago
  Apple + The Web is a match made in hell. 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.