Phonegap app store approval

First, let's talk about Apple and HTML. Apple does not reject an application because the user interface is built using HTML. In fact, many Apple apps or advertising platforms for iOS are entirely built with HTML, CSS, and JavaScript. For instance, the Apple Store and iAd advertising platform, among others, use HTML as the primary medium for the user interface. Outside of Apple there are many successful apps that have user interfaces built with HTML, including LinkedIn,Wikipedia, the BBC Olympics, and many, many others. Note: Not all of these apps mentioned use PhoneGap, but they do use HTML for the UI.
Apple rejects applications that do not:

• have a user experience that feels like an "app"
• feel "at home" in the iOS ecosystem
• offer a differentiation from a mobile web experience

This applies to all apps, not just apps developed using HTML for the UI. Adobe is not Apple, so we do not know the exact approval rules beyond the "App Review Guidelines" and "App Store Review Guidelines" provided by Apple. However, it is clear that approval largely comes down to the user experience: how the user interacts with the app and how it "feels" on the device.
The "iOS User Interface Guidelines"  from Apple has a large amount of information about what is and what is not acceptable for Apple's ecosystem. In these UI Guidelines, Apple specifically addresses "web-based designs": "Reconsider Web-Based Designs If you're coming from the web, you need to make sure that you give people an iOS app experience, not a web experience. Remember, people can visit your website on their iOS-based devices using Safari on iOS."
Be sure to read the full iOS User Interface Guidelines for tips on creating a great “app” experience using HTML and related technologies.
In addition to the iOS User Interface Guidelines, Apple's "App Store Review Guidelines" has additional tips for getting your apps approved. Many relate to HTML-based experiences, including the following tips:
 

• "2.12: Apps that are not very useful, unique, are simply web sites bundled as Apps, or do not provide any lasting entertainment value may be rejected"
• "10.3: Apps that do not use system provided items, such as buttons and icons, correctly and as described in the Apple iOS Human Interface Guidelines may be rejected"
• "10.6: Apple and our customers place a high value on simple, refined, creative, well thought through interfaces. They take more work but are worth it. Apple sets a high bar. If your user interface is complex or less than very good, it may be rejected"
• "12.3: Apps that are simply web clippings, content aggregators, or a collection of links, may be rejected"

As mentioned earlier, Adobe does not know all of Apple's rules or processes, but the following indicators can result in rejections:

• If your app is just a web site wrapped in PhoneGap, it will likely get rejected. There are exceptions to this case, but do not expect that wrapping a web site in a web view will get you into the App Store.
• If your app requires the user to pinch/zoom/pan to view content (like a web site), it will probably get rejected.  Your apps need to feel like apps and be immediately intuitive.  Don't make the user work to find how the app functions, and don't make them navigate past navigational content just to get to something useful.
• If your app just looks like text on a page with hyperlinks, and has no native-like styles, it will probably get rejected.

App store approval often seems like a blurry line and is particular to the individual apps that are being evaluated. Each app is considered on its own merit, functionality, and user experience. The iOS User Interface Guidelines and App Store Review Guidelines are also living documents – they may change as new OS versions are released or new app designs bring up new issues. Be sure to review the guidelines periodically.

Now, let's examine what PhoneGap is exactly, and how it fits into this context. From the PhoneGap FAQ: "PhoneGap is an open source solution for building cross-platform mobile apps with standards-based Web technologies like HTML, JavaScript, CSS." For a much more detailed description of PhoneGap, see my previous post "PhoneGap Explained Visually." PhoneGap acts as a container for user interface elements built with HTML, CSS, and JavaScript. It wraps your HTML experience. Then your app can interact with native operating system functionality using JavaScript. PhoneGap also provides the ability to package your application for App Store distribution.
Using PhoneGap does not absolve you from following Apple's rules/guidelines. PhoneGap applications are not going to be immediately accepted because the user interface is built with web technologies.
PhoneGap does not attempt to build your UI for you or to conform it to Apple's arbitrary guidelines. When building PhoneGap applications, the designer or developer controls the UI/UX and ensures it corresponds to guidelines for a particular platform or ecosystem. As you design and develop your PhoneGap applications, consider what makes an application “feel like an app” or “feel native.” Many of these considerations fall into one of the following categories.

First, consider the following questions with respect to your application:

• Does the app follow user interface paradigms that are consistent with the platform?
• How does the application appear visually?
• Does the application resemble an HTML page, or does it have visual “controls” and touch-optimized interface elements?

Let's examine two application views, both taken from Fresh Food Finder, an open source PhoneGap application that is live in the App Store.

Both of these images captured by the PhoneGap emulator were captured from the exact same application. The image on the left has HTML content but no CSS style sheet attached. If you compare the visual experience, the application on the left looks like web page content. There are no styles to give it the appearance that is expected of an application experience. Alternatively, the image on the right looks like an app: it has a header area that contains navigational elements, it has a scrollable content area, and each list item has UI elements that prompt the user to proceed through an experience or workflow.

Figure 2. A blog formatted as a web page.

First, it is just a web site (my weblog) wrapped in a web view. Apple frowns upon the practice of wrapping web sites with a native shell. The wrapper is an empty shell that contains no logic, just a reference to the remote web site. It will fail in offline scenarios. And there is no differentiation from a mobile web experience or added value to offset this failure.
Secondly, the user interface has not been optimized for a mobile experience. The user must perform a pinch/zoom gesture to read any content. Additionally, there is no touch-friendly navigation, there is no discrete differentiation between navigation and content, and the overall experience does not have an app-like feel.
Develop your applications such that they feel “at home” when placed next to a native application. You don't have to mimic every single native UI style, however user interaction paradigms should be similar. Make the user interface intuitive and clean. When considering what is meant by an app-like experience, look at other apps that are already out in the public and examine designs that have already been approved by Apple. Numerous resources on the web compare existing app user interfaces including:

• Mobile Patterns
• Inspired UI
• pttrns

Also many tools and frameworks help you make your HTML experiences feel more native. Here are just a few to get you started:

• Twitter Bootstrap
• iUI
• jQuery Mobile
• Sencha Touch
• Kendo UI
• app-UI
• Zurb Foundation
• Moobile
• Chocolate Chip UI
• Dojo Toolkit
• jqMobi

This is not an exhaustive or complete list in any way. A lot of frameworks mimic a native-like experience. Or create your own interactive experience without using any frameworks.

If the user must click an HTML link to load a separate page, and there is a disjointed transition between the views, you will likely need to optimize the experience. Apple seems to prefer applications that have a unified feel and continuous experience. If the user performs an action within the app that gives the impression that the current “page” is unloaded and a new page is being loaded, then you take steps to make this transition more seamless. Try  introducing single-page architectures with asynchronous loading of data and dynamically updating the content. Or try to make the transition between pages lighter and faster, with less of an interruption to the user experience.
Optimize the processes and experience of getting data in and out of your application. First, minimize your data transaction overhead by only sending data as it is needed, in a lightweight format. This optimization reduces latency and generally makes your app “feel faster” by reducing total time from requesting data to displaying it on the screen.
Pay particular attention to all transitions and animations within your application. These activities include transitioning from one view screen to another or animating elements within your HTML experience. If your app stutters, flickers, or provides a less-than optimal experience, revisit how you move app elements around the screen. Look into techniques to force GPU rendering of HTML DOM elements using just CSS styles. In many cases, these techniques can improve overall application performance.
Additionally, add simple nuances like indeterminate progress bars or animated spinners to provide status during make time-intensive processes, like transactions with the server. These UI indicators go a long way to helping the application feel faster and more “native.”
Last, but by no means least, pay attention to response times within your application. These response times can relate to processing user activity or response times from the server. Apple generally does not like slow or unresponsive applications. If data takes a long time to load from a server and be usable, then Apple may reject the app. Likewise, if the user clicks a button, and nothing happens for a few seconds, this sluggish behavior could be grounds for rejection. You application needs to provide some level of interactivity and feedback to the user, even when operations are happening in the background.

In conclusion, pay attention to your user experience. Apple's approval process varies depending upon what your app does and how it does it. Do not assume that the use of PhoneGap means that you don't have to abide the App Review Guidelines and App Store Review Guidelines from Apple. In general, Apple pays close attention to the quality and overall user experience of an application. If it does not perform well, is buggy, is aesthetically displeasing, or if it offers no differentiation from a mobile web experience, then it is likely a candidate for rejection from the App Store. Apple has set the bar very high for the quality of applications it accepts within their ecosystem. The more you focus on a quality user experience, the more your chances of success improve.
For more examples of how to improve the experience of your application to make it feel more native, Greg Avola, the creator of the popular Untappd application, has an article on the ADC, "Creating apps with PhoneGap: Lessons learned."