I'm using the beta Stack Exchange app version 1.4.2 with iOS 9.1. When I have a fast internet connection, it works as expected. However, when the connection is extremely slow (sometimes unusable), the app freezes for around 20 seconds and then crashes. This is worse than having no connection at all, since with no connection the app opens with an error message.

I found that under slow connections (GPRS1 in this case), the app freezes with this screen and after around 20 seconds, it crashes:

Slow Connection

With no connection at all, the app opens and errors as expected:

No connection

This is probably because the SE app tries (and fails) to connect to the servers when it finds a connection. I've noticed that when my wifi is a bit slower, the app takes a few more seconds to open.

1 Although this (GPRS) is a type of internet connection, I couldn't manage to open any web page with it.

  • Is it crashing or just hanging on this screen? Commented Dec 14, 2015 at 17:20
  • @BrianNickel It hangs for around 20 seconds and then crashes Commented Dec 14, 2015 at 17:20
  • Hmm... Not seeing any crash logs for 1.4.2. Could you go into Settings.app, turn on "Disable Analytics", kill the app and see if you can reproduce the crash? I have a bit of a theory. Commented Dec 14, 2015 at 17:39
  • @BrianNickel It still crashes. Neither Disable Analytics nor Return to Feed seem to help. Can you still get the logs if the app runs out of memory? I suspect that may be the cause of the crash, since it takes a few seconds to open multitasking after I double click the home button. Commented Dec 14, 2015 at 17:53
  • @BrianNickel I have found this crash log in my phone: pastebin.com/Ezznm8kz Commented Dec 14, 2015 at 19:02
  • I see what's happening. It's blocking on a request to refresh the site list in the feed. Going to investigate. Commented Dec 14, 2015 at 19:49

1 Answer 1


This will be fixed in the next beta build.

The app depends on the site list (/sites) for many things it does. As such:

  1. it gets loaded before the first login. It is subsequently loaded once every 24 hours but continues returning old values until the new version loads.
  2. we have a synchronous method on the site cache to resolve sites by host name or API site parameter. We're relatively certain the site should be there when the request is made.

Because some cases could arise that we call the synchronous siteForApiSiteParameter: and the site list isn't up to date, the method's default action is to try loading the cache and block until completion. This of course assumes that this will be a rare case and that the /sites API call should complete in a timely fashion.

You, however, have reached a state where this call is being made every time you load the app and the request is so slow the device's watchdog timer is killing the app because it still hasn't finished launching after 20 seconds.

My theory:

  1. You opened the app. It may have kicked off the call to refresh /sites. This took a long time or failed.
  2. The feed loaded, including a hot question from a site that was not in the app's site cache. The feed loading process blocked on the call to /sites.
  3. You got sick of waiting and left the app. The app saved the contents of the feed to disk.
  4. The app was terminated in the background without completing the call to /sites.

Now, every time you return to the app the feed prepares to render its saved contents, gets to the unknown site, and blocks on the call to /sites. Since you're on GPRS the app hangs and you get caught by the watchdog.


My solution has been to defer or eliminate calls to the /sites when rendering the sites.

The particular code you got caught on was for evaluating whether or not to display a site icon on a feed icon based on whether or not the preceding item was on the same site. There was no reason to even resolve the site here because the site parameters we had was good enough.

Similarly, the feed would pass the resolved site to the cell when rendering the site icon(s), meaning it would block when configuring the cell. Now the feed just passes the site parameters to the view and it either renders the known site or displays a placeholder background and asynchronously reloads /sites to display the icon when available.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .