When the user wants an "App" but they need a webapp ?
March 8, 2015 7:48 PM
I would like to understand more about giving a webapp a Play Store/App Store "App" .
(Asking for a friend)
You have a web-app which works perfectly well on a range of mobiles / tablets but it's been decided that the same functionality needs to be exposed as an "App" via Play Store/App Store.
In a rational world you wouldn't do this ... but it's not a rational world.
What the business want is to able to say "Yes" when asked "is there an app ?", what the devs want is to not add to their existing workload.
So on the surface this isn't very difficult, you commision an App for each platform which is essentially a chromeless browser; all the app does is fetch the logon page of the "Foo" web-app and then act as a browser; configure it to be your "Foo App" and submit it to Play/App Store gatekeepers.
Only I understand that said gatekeepers, at least App Store and possibly Play Store, won't accept such an App because "an app needs to be more than a website" (it's not clear to me how much the term website and webapp intersects in the gatekeepers thinking)
What I'd like to hear about is
* is the belief that such an app is unacceptable correct ?
* if "Foo App" would be unacceptable what would make it acceptable ? I've failed to find the criteria written down . Just hypothetically if the data was pulled as JSON and rendered into HTML within "Foo App" ... does that pass the test ?
Would really appreciate references which discuss to what degree this sort of stuff can/has been done.
And by the way I do appreciate Phonegap is very useful but really want to use the web-app as is; also that React Native looks great but clearly bleeding edge (particularly for Android).
(Asking for a friend)
You have a web-app which works perfectly well on a range of mobiles / tablets but it's been decided that the same functionality needs to be exposed as an "App" via Play Store/App Store.
In a rational world you wouldn't do this ... but it's not a rational world.
What the business want is to able to say "Yes" when asked "is there an app ?", what the devs want is to not add to their existing workload.
So on the surface this isn't very difficult, you commision an App for each platform which is essentially a chromeless browser; all the app does is fetch the logon page of the "Foo" web-app and then act as a browser; configure it to be your "Foo App" and submit it to Play/App Store gatekeepers.
Only I understand that said gatekeepers, at least App Store and possibly Play Store, won't accept such an App because "an app needs to be more than a website" (it's not clear to me how much the term website and webapp intersects in the gatekeepers thinking)
What I'd like to hear about is
* is the belief that such an app is unacceptable correct ?
* if "Foo App" would be unacceptable what would make it acceptable ? I've failed to find the criteria written down . Just hypothetically if the data was pulled as JSON and rendered into HTML within "Foo App" ... does that pass the test ?
Would really appreciate references which discuss to what degree this sort of stuff can/has been done.
And by the way I do appreciate Phonegap is very useful but really want to use the web-app as is; also that React Native looks great but clearly bleeding edge (particularly for Android).
At least for the Apple App Store, the sad truth is that like many of the rules, a lot of it is in the hands of the individual reviewing it. It's entirely possible that the same app could be accepted by one reviewer and rejected by another. But I think the spirit of the rule is that if it feels like a web app/web browser, it's not going to be accepted. Native navigation, native controls, using hardware features, etc. all help. But the bottom line is what it feels like. I have seen Cordova apps rejected for feeling too "webby."
BTW, while you may believe that it's irrational for someone to want a native app rather than just a web site, there are legitimate reasons. One of the biggest is that native controls often provide better experiences than web controls. I know many webapp developers who object to this, but all I can say is that I strenuously disagree. And without jeopardizing my pseudo-anonymity here, I'll say that I have worked on an extremely popular iOS app, which had a team of insanely talented software engineers behind it. Industry leading experts in Javascript, CSS, and native iOS development, among other things. After years of messing with it, we abandoned our strategy of trying to do everything in HTML, and went back to making a lot of stuff native, because the experience is just better. And we were wasting a huge amount of time trying to get HTML to behave like a native app. You may recall a few high profile apps that have done this...
Secondly, there is a real value to having your app show up in the app store when people search your company name. This may seem like fluffy marketing stuff to engineers, but it makes a difference.
posted by primethyme at 8:41 AM on March 9, 2015
BTW, while you may believe that it's irrational for someone to want a native app rather than just a web site, there are legitimate reasons. One of the biggest is that native controls often provide better experiences than web controls. I know many webapp developers who object to this, but all I can say is that I strenuously disagree. And without jeopardizing my pseudo-anonymity here, I'll say that I have worked on an extremely popular iOS app, which had a team of insanely talented software engineers behind it. Industry leading experts in Javascript, CSS, and native iOS development, among other things. After years of messing with it, we abandoned our strategy of trying to do everything in HTML, and went back to making a lot of stuff native, because the experience is just better. And we were wasting a huge amount of time trying to get HTML to behave like a native app. You may recall a few high profile apps that have done this...
Secondly, there is a real value to having your app show up in the app store when people search your company name. This may seem like fluffy marketing stuff to engineers, but it makes a difference.
posted by primethyme at 8:41 AM on March 9, 2015
a "hybrid app" is what you describe where you have a chromeless browser frame that runs as a native app, and it loads the app code (typically HTML5, CSS3, and Javascript) from a server and then the user interacts with it.
The HTML5, CSS, and Javascript can also be stored inside the app, with no access to the outside server necessary. I think that's the more common case. In a sense, it is a native app; it just happens to be written in Javascript rather than ObjC or Java.
What dtl describes -- a chromeless web view that accesses a predefined URL -- is more likely to get rejected by Apple as "not really an app".
I agree with primethyme that there are perfectly good reasons for wanting a presence in the App Store, even if the functionality is the same as what's available on the web. If it's truly identical then Apple might reject it, but they might not. I also agree that you can get a better experience with a native app, but if you all agree that your web functionality is sufficient, it is certainly much much less work to package up what you have than to create a new app from scratch.
posted by alms at 9:10 AM on March 9, 2015
The HTML5, CSS, and Javascript can also be stored inside the app, with no access to the outside server necessary. I think that's the more common case. In a sense, it is a native app; it just happens to be written in Javascript rather than ObjC or Java.
What dtl describes -- a chromeless web view that accesses a predefined URL -- is more likely to get rejected by Apple as "not really an app".
I agree with primethyme that there are perfectly good reasons for wanting a presence in the App Store, even if the functionality is the same as what's available on the web. If it's truly identical then Apple might reject it, but they might not. I also agree that you can get a better experience with a native app, but if you all agree that your web functionality is sufficient, it is certainly much much less work to package up what you have than to create a new app from scratch.
posted by alms at 9:10 AM on March 9, 2015
This thread is closed to new comments.
- a "web app" is basically just a website that you access from a browser. "App" just implies that the website does something (looks stuff up in a database, etc). But I don't think there's a universal agreement on what makes it a web "app".
- a "hybrid app" is what you describe where you have a chromeless browser frame that runs as a native app, and it loads the app code (typically HTML5, CSS3, and Javascript) from a server and then the user interacts with it. Typically the native browser frame will have hooks to various features of the mobile device, so you can (for instance) snap a photograph via a Javascript call.
- a "native app" is an app that's been coded in Objective C or Swift (for iOS) or Java (for Android)(and yadda yadda for Windows phones and Blackberries etc). A native app will have full access to the mobile device - okay, full access to whatever the SDK allows.
You can actually do quite a lot with just a hybrid app - a lot of business apps are fancy forms that don't take much advantage of the mobile device's graphics or DSP capabilities. Phonegap (which I believe is now called Cordova) is a set of components for building hybrid apps. IBM's Worklight IDE is an Eclipse plug-in (plus lots of other stuff) that is based on Phonegap/Cordova.
In theory, the hybrid approach should allow you to develop an app that runs on any mobile device, with only a single source code tree of HTML5, CSS3, and Javascript. In practice, it's not uncommon for the Android UI to be different than the iOS UI. But still, it might be significantly cheaper to develop and maintain this kind of app.
Natch, if your app is doing anything sophisticated with audio or video etc, you'll want to "go native". It's typically a lot more work to support multiple platforms, though.
Okay, all that aside, you wanted to know how the people at the App Store decided if you really had an actual app, or if it was just a website in disguise. Honestly, I don't know - but I suspect that if you're using an accepted hybrid framework (like Phonegap/Cordova/Worklight), that would count toward it being acceptable to the App Store. If it's using any device features - like the camera - that would probably count, too - I'm pretty sure you can't load a page into mobile Safari and have it take a picture. And in the case of Worklight, for instance, most apps talk to a Worklight server, which will handle certain things beyond the realm of a mere web app, such as allowing the user to upgrade their app if a more current version is available, handling user tokens and app security, JSON helper functions, and so on, via "adapters".
I hope this helps a little. Sorry it's so long, but I didn't know where to even start without definitions of web, hybrid, and native apps.
posted by doctor tough love at 10:29 PM on March 8, 2015