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?