Several weeks ago reading through the Apple guidelines it says apps should check for the reachability status before attempting to make a connection, and I’ve read of apps being rejected from the app store for not doing this.
However the reachability APIs can take up to 30 seconds (according to the Apple documentation, and also I’ve seen this myself happening sometimes) to determine if reachability is available or not. In this situation the API returns not reachable.
Therefore you can have the situation where you do actually have reachability but the APIs say you don’t and you won’t find out you do for 30 seconds or so.
Having to wait 30 seconds is unacceptably long – especially if the connection has been initiated by the user. Consider this scenario:
- User clicks some button that performs some internet related activity
- In accordance with the Apple guidelines the code uses the reachability API to check if there is reachability before attempting to make the connection.
- The Reachability API says there isn’t reachability (but actually there is) so the code tells the user there isn’t connectivity (confusing them in the process)
- 30 seconds later the Reachability API informs the code there now is reachability
- But its too late because the user has exited the app and gone elsewhere because they got fed up waiting.
By following Apple’s guidelines to first check reachability there is a real chance that an absolutely terrible user experience has resulted and the app didn’t contact the server when it could have done.
This seems ridiculous, surely I am missing something?
How can you follow Apple’s guidelines while still give a responsive app?
I’ve experiences these delays in the Reacability API and want to ditch it – because I’ve seen occasions when it says there isn’t reachability but if you try there is, therefore I want my app to try the connection anyway regardless of what the API says. But if I do this then there is a chance the app could be rejected?
Is there a solution to this dilemma?
I hesitate to answer this because it becomes a flame war. Answer – reachability doesnt work. The fact that it takes however long on a background thread simply doesnt matter.
The bigger problem with it isnt that it says you dont have reachability when you do, its that it says you do when in fact you dont. Which is the point.
Apple is not rejecting apps that dont use reachability. They are rejecting apps which cannot handle a network switchover from 3G to wifi and back and apps which cant handle losing connectivity properly.
Apps which do not properly ping a reliable backend taking into consideration timeouts and retries regardless of reachability and notify the user when connectivity has been lost will be rejected.
Apps which lock up when the plug is pulled on the network will be rejected.
Although apple has tried to be helpful and clear, the code they provide is not the code they use themselves, and its not sufficient.
You are left as an app developer to make it work for the rejection scenarios above.
Thats it. So forget reachability and simplePing from Apple.
Run your app, kill the network when a request is happening. Does it hang? Fail.
Pull the network when a request is NOT happening (but one might soon), do you notify the user?
Thats the whole of app rejection due to network issues.
Dont complain about stuff that has never worked. Although I would like this to be Apples problem,
its ours, and I worked too long on my code for this to give it away on StackOverflow.
Ask yourself this, am I pinging a reliable backend?
Am I doing it in a thread?
Am I timing that thread for timeouts?
Am I retrying before overreacting?
Its easy, but then again, its not.