Whoops, here’s something we’d overlooked in our latest app effort — good thing we stumbled across this before submitting it! — if your application is network dependent, apparently Apple requires that you detect network availability proactively, spinning helplessly in its absence is not sufficient. From this top 11 list of rejection reasons:
6. Popup for network detection If your app requires the use of the Internet, you must detect when the network is unavailable and provide a pop-up message informing the user. Just having the spinning busy icon display and a message saying “trying to connect” is not sufficient. Apple will reject your app if you don’t provide a message informing the user that they need a network connection.
Ah, OK then. No worries, we’ll just grab the Reachability sample … wait, what?
7. False claims of a missing network On a related note, make sure you don’t have any false positives in your network detection. There’s a bug in the “reachability” functions provided by Apple. If you don’t first try to perform a network connection but instead just do a reachability test, the code will always report the network is unavailable. Apple will reject your app if they discover you have this false positive case.
Actually, it looks like what I presume is the “bug” referred to above in Reachability is indeed not such … not exactly, anyways. The trick is, you want your first status check of your target host name’s reachability to be made synchronously. Because, until it completes the check, well, it’s not connected, is it now? Quite logical, really. And once that initial check is sorted, then your updates should properly be asynchronous. So in Reachability’s appDelegate where it has
|
1 2 3 4 5 6 7 |
[[Reachability sharedReachability] setHostName:[self hostName]]; // The Reachability class is capable of notifying your application when the network // status changes. By default, those notifications are not enabled. // Uncomment the following line to enable them: //[[Reachability sharedReachability] setNetworkStatusNotificationsEnabled:YES]; ... [self updateStatus]; |
that’ll always return false for your target host reachability in -updateStatus if you follow the given instructions. Whoops! To fix that, simply do a synchronous then an asynchronous query
|
1 2 3 4 |
[[Reachability sharedReachability] setHostName:[self hostName]]; [self updateStatus]; [[Reachability sharedReachability] setNetworkStatusNotificationsEnabled:YES]; [self updateStatus]; |
… and you’re all good.
It would be more clear that the first host reachability check failing was a foreseeable occurrence if -setNetworkStatusNotificationsEnabled was actually labelled -setStatusResultsAsynchronous. Or, even better,
-callThisToMakeTheSampleFailHaHaSucka. But Apple very rarely labels sample code quite that honestly!
Comments (8)