We’ve been reading up on the main causes of app rejections in preparation for our game to be submitted and there seems to be a lot of mention of needing to check for wifi / net connectivity before launching browsers / websites from within the app.
We have an ‘about us’ page which we use Application.OpenURL to launch out to our website as well as a similar submit score function which opens a highscores web page and submits the score via url. As soon as you use this method the app closes and it tries to resolve the URL in safari whether or not the user is connected to the internet.
My concern is that if you run this on a standard iTouch without wifi connection it will close the app, launch safari and say something along the lines of ‘Safaru cannot open the page because it is not connected to the Internet’ etc… and that Apple will deem this unsatisfactory application behaviour .
Does anyone know if this kind of behaviour will cause an app to be rejected and if so, what kind of checks can be done prior to using Application.OpenURL to make sure the device has indeed got internet connectivity first. (we could hide / disable the link if this was the case)
You could use the WWW class to ping out to a specific page, and it’s return would tell your app whether or not you had an Internet connection. If true, OpenURL, if not, then just say, no internet connection found’, or display an ‘about’ in the app.
Interesting question. I had a friend submit an app (not a game) and was rejected for not checking for wifi / net connectivity before launching browsers / websites from within the app.
I’d would be sure to implement this before submitting your app. I’d tell you what he did if I knew how, but I’m very new to the iPhone SDK.
Thanks for the feedback guys. I have a feeling they are talking about apps which regularly poll the internet / wait for responses which are the cause for rejections when not checking for connectivity. For single fire-and-forget browser launching im hopeful this practice is acceptable. My main concern about ‘pinging’ a url using the WWW class is that it might not return with a response for a period of time / or at all if someone has a very slow / poor net connectivity. Its re-assuring to hear that other apps which have been approved have used the fire-and-forget OpenURL method without checking. Might just roll the dice on this one. Any other opinions would be much appreciated.
I think so, because like I said, I see it a lot. For my “real” connectivity, I do in fact check for availability, but I didn’t bother (or even think about it) for the WWW button. I mean, you’re just launching Safari and your app closes, so whatever happens then is out of your control anyway.
Thanks Eric, Unfortunately I suspect our score submission system will be the one that brings it down. Its borderline ‘real’ connectivity although it is still a fire-and-forget system. All the user rankings are on the internet / website and not being displayed within the game. We fire out with an encrypted set of URL parameters from within the game which will close the app, and show the list of highscores with your position highlighted in webpage format. We prefer this version of highscore system as we want to encourage users to visit the website and join the online community and we are planning on offering a regular set of prizes etc every few months for the best scores.
So the general consensus is, submit the app and hope for the best as is? When they say average 2 weeks approval time does this include rejections as well or are they typically more time consuming / lower priority?
