We've seen wrapped websites get rejected before. I don't think I've seen/heard of a hybrid app that uses Cordova to access device hardware/sensors ever get rejected. I think if you're not going to be using something on the device whether location, camera, etc then it's important to ask if that particular project needs to be an app or can it just be a mobile website accessible by URL and browser.
We need to provide an iOS app and the current plan is to build a hybrid, as we already have a browser based version of the product.
Although you should be able to reuse a lot of your components, I would suggest keeping as much code as possible local to the device. This simplifies network connectivity a bit (since there's always code present to handle the condition), and Apple will look at this more favorably. (They do reject "wrapper-style" apps.)
I've been trying to understand the black art of how apps get accepted/rejected from the App Store, but there seems to be no clear guidelines regarding hybrid apps.
It's really a matter of who at Apple actually reviews your app. Some reviewers are pickier than others, and all have slightly different interpretations of the HIG. Thankfully, I've had no real issues with any of the reviewers I've encountered, and as long as you treat them kindly with respect, even if you do have an issue, they'll usually do their best to help.
From what I can make out, as long as you're not just wrapping a desktop website up in an app, you should be fine.
This is true, but also a few other "guidelines" are applicable, in my experience:
- Don't wrap a website (as you just mentioned)
- Obey the HIG where applicable. Apple is fairly accommodating wrt user interfaces -- e.g., Google's apps that use Material design and look consistent across Android and iOS. Games get much more leeway, of course.
- Handling the lack of network connectivity is a big deal -- If your app requires a network connection and there is none, you must generate a user-friendly error message. If you can subsist off a cache or provide offline data, that's even better (along with some indication to the user that they are offline and data will be synced later). Provide as much functionality as possible without a network connection -- unless your entire app requires network access, there's little reason to lock it behind a "this app requires the internet" gateway.
- Be very careful how you store data. Apple pays close attention to how much data is synced via iCloud, and if they see caches and such getting backed up, they'll complain and reject the app.
- Likewise, be careful how much data you download, especially on a cellular connection. If your app plays movies, for example, you must reduce quality while streaming on a cellular connection.
- Apps that use device functionality are looked upon far more favorably. This can be something as simple as using the SQLite plugin for persistent storage or the GPS or even popping up an email composer as a sharing mechanism.
- Avoid the soft keyboard. If a control becomes unreachable because the keyboard obscures it, Apple will reject. It is your responsibility to avoid the keyboard. I've got an example that mimics native keyboard avoidance here: GitHub - kerrishotts/cordova-keyboard-example: Simple keyboard avoidance example for Cordova and iOS
- Your app's appearance should appear as if some thought has been applied to it -- that is, align your elements, avoid fuzzy images and icons, etc.
- Honor system settings if possible. A good example is respecting the system font size. (See: GitHub - phonegap/phonegap-mobile-accessibility: PhoneGap plugin to expose mobile accessibility APIs. )
- If your user requires authentication, be sure to provide the reviewer an appropriate test account. Whether or not Apple will use it depends on the reviewer, but apps can be rejected solely for not supplying a login.
- There is a section when submitting your app that allows you to leave notes to the reviewer. This is a good place to leave tips & notes about your app. Keep in mind that although you know your app inside and out, the reviewer does not. Just respect your reviewer and they will usually do everything they can to help.
i.e. if the site is responsive enough to deal with small screens in the first place, you can probably get away with just using that as your UI.
Being responsive is critical, of course, but acceptance will depend largely upon your UI. Your app can be as responsive as it can be, but if the UI looks like you're wrapping a web page, you're apt to get rejected. The simplest way I've found to boil all this down is this: don't give the Apple reviewer any reason to suspect that your app isn't native. Appear native even with a nonstandard but polished UI (like material design or a game UI), and you're probably going to be accepted. If your UI is unpolished and looks like a webpage, well, all bets are off and depend upon your reviewer.
Has anyone had anything similar rejected before?
I'll give you a couple of examples of my experiences:
- Remote database CRUD app. Network access is obviously critical, but the app would handle it gracefully by storing data locally and synchronizing when it could. It would retry sync attempts should a network be present and the server be somehow unreachable (or generating an error). All of the app would work just fine in a desktop browser, but relied upon the SQLite plugin for local persistent storage, which was sufficient to pass review. UI wasn't perfectly standard, but was polished.
- Dictionary app. Content is local, except for external web links. User data is stored in a SQLite database using the SQLite plugin (and so uses some device functionality). Even so, the app itself works perfectly well in a desktop browser (uses IndexedDB/WebSQL in that case), but the UI appears polished and material-like.
- Museum app. I didn't code the original app -- I was just there to upgrade to a more modern version of Cordova. This app's UI is not terribly polished, and does appear like a website. However, a lot of code is local, it properly handles lack of network connectivity, AND uses device functionality for several features. Apple approved without issue, even though it did scream "non-native". I suspect it is the use of device features in this app that tipped the reviewer over to acceptance.
I hope that helps, and best of luck with your app!
Thanks for the quick and very helpful responses. You've put my mind at ease now, and I'm fairly happy we can do what we want without fear of getting a rejection.
Many thanks again