PhoneGap, Apple Rejections & UI/UX Guidelines

I’ve recently encountered some grumblings from the development community that Apple has rejected their PhoneGap apps for not being “native enough”.  By itself, that doesn’t surprise me too much – Apple has very strict rules/guidelines on what they will and will not accept into the App Store.  What did surprise me is that people were blaming PhoneGap as the reason.  This accusation is not accurate, and in this post I’ll attempt to clear things up.

Apple & HTML

First, let’s talk about Apple & HTML.   Apple does not reject applications because their user interface is built using HTML.  In fact, many of Apple’s own apps or advertising platforms for iOS are entirely built with HTML/CSS/JS.  For instance, the Apple Store and iAd advertising platform, among others, use HTML as the primary content 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 these apps mentioned use PhoneGap, but they do use HTML for the UI.

Apple will reject applications that do not have a user experience that feels like an “app”, does not feel “at home” in the iOS ecosystem, or offers no advantage over a mobile web experience. This applies to all apps, not just apps developed using HTML for the UI. I don’t work for Apple, so I don’t know what their exact approval rules are (beyond these and these) but I can guarantee you that it largely comes down to how the user interacts with the app and how it “feels” on the device.

The iOS User Interface Guidelines from Apple have a very 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.

Here are some strategies that can help web developers create an iOS app:

Focus your app. Websites often greet visitors with a large number of tasks and options from which they can choose, but this type of experience does not translate well to iOS apps. iOS users expect an app to do what it advertises, and they want to see useful content immediately.

Make sure your app lets people do something. People might enjoy viewing marketing content in the websites they visit, but they expect to accomplish something in an app.

Design for touch. Don’t try to replicate web UI design paradigms in your iOS app. Instead, get familiar with the UI elements and patterns of iOS and use them to showcase your content. Web elements you’ll need to re-examine include menus, interactions initiated by hovering, and links.

Let people scroll. Most websites take care to display the most important information in the top half of the page where it is seen first (“above the fold”), because people sometimes leave a page when they don’t find what they’re looking for near the top. But on iOS-based devices, scrolling is an easy, expected part of the experience. If you reduce font size or squeeze controls to fit your content into the space of a single device screen, you’re likely to end up with unreadable content and an unusable layout.

Relocate the homepage icon. Websites often display an icon that links to the homepage at the top of every webpage. iOS apps don’t include homepages, so this behavior is unnecessary. In addition, iOS apps allow people to tap the status bar to quickly scroll back to the top of a long list. If you center a tappable home icon at the top of the screen, it’s very difficult for users to tap the status bar instead.

In addition to the iOS User Interface Guidelines, Apple’s App Store Review Guidelines have additional tips for getting your apps approved.  Many relate to HTML-based experiences, including:

  • 2.7: Apps that download code in any way or form will be rejected
  • 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 I mentioned earlier, I don’t know all of Apple’s rules, but I do know this:

  • If your app is just a web site wrapped in PhoneGap, it will probably get rejected. There are exceptions to this case, but don’t 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.
  • 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 very much subjective to the apps that are being evaluated.


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 and provides the ability to interact with native operating system functionality from JavaScript.  PhoneGap also provides the ability to package your application archive for App Store distribution.

PhoneGap does not make any attempt to build your UI for you. PhoneGap applications are not going to be immediately accepted because the user interface is built with web technologies. PhoneGap does not absolve you from following Apple’s rules/guidelines.

When you build PhoneGap applications, it is up to the designer or developer to build apps that correspond to the UI/UX guidelines for a particular platform/ecosystem.  There are many tools and frameworks that you can use to make your HTML experiences feel more native.   Here are just a few:

This is not an exhaustive or complete list in any way.  If you are aware of other tools or frameworks that I’ve missed, or have more questions on this subject, please leave a comment below.

  • Enric Valencia


    I definitely agree. I indeed published a couple apps in apple store (went through revision at first attempt) and they are built on Phonegap. And I am not even using any of the mentioned UI frameworks! Just pure HTML/CSS/JS.

    I think that the way to success is more based on concept than on specific implementation.


  • Ronald K

    I’ve submitted several Phonegap apps to the store in the past few years, and none of them has been rejected. Just stick to Apple’s guidelines and you’ll be fine, IMHO.

    But then, I don’t use jQuery Mobile as it is way too slow for mobile apps 🙂

    jQTouch used to be a nice framework. Unfortunately maintenance and development seem to have ceased to exist.

  • BrianMB

    “or offers no advantage over a mobile web experience”

    This implies that an App Store app always offers a better experience as a matter of fact, which just isn’t true.

    • Andrew

      BrianMB, Actually, no, that is not what I am implying. Some mobile web experiences are better than native, and some native experiences are better than mobile web. This is very subjective to the applications in question. When I refer to “No advantage over a mobile web experience”, this may or may not be related to UX. If the experience does not differentiate itself from a mobile web experience, then it will probably get rejected. This may be UI related like touch optimization, styling, or layout. Or, it may be related to functionality like offline scenarios, local asset or data storage, or integration with the underlying operating system. If it is just a mobile-styled web site, served from a server, wrapped in a web view, then there is no advantage over a mobile web experience, and it will get rejected.

  • Carlos Santana

    Very useful article and thanks for the clarification
    Dojotoolkit mobile is very useful franework also

    • Andrew

      Carlos, Thanks! I know I forgot a bunch of tools. I’ll add it to the list.

  • BrianMB

    @Andrew: It could be a mobile-styled website, wrapped in a web view, that has great touch optimization, full offline capability, and makes use of all the underlying OS capabilities that iOS exposes to its web engine (which are numerous).

    I completely agree that, if an app doesn’t satisfy these criteria, it probably isn’t a very good one anyway. But the two worlds are not mutually exclusive, not a bit.

  • Head Data Zombie

    jQT isn’t quite dead. The main repo was recently updated to allow native scrolling on iOS 6. I’m in the process of rewriting my fork to be compatible with Zepto and adding new features.

  • Roy Smith

    You also missed jqMobi – a mobile-first JS framework that delivers a native feeling UI that works identically on iOS and Android.

    • Andrew

      Thanks Roy

  • Michael

    Can people give examples of their PhonGap apps that have been approved? I think this might be helpful for those of us fighting the 10.6 rejections being handed out by Apple.

    I use TabBar and NavigationBar plugin, open Apple maps for directions, and use push notifications. Still I am just not iOS enough. Our users don’t want to play games or log into Facebook. They want information and resources at their fingertips.

    • Andrew

      There are many phonegap apps that have been approved at

  • Saša Radovanović

    With (mobile) websites getting richer and richer, more app like, it will be a question how a mobile application can stand out vs. a (mobile) site.
    This mainly in regard to the following point:
    “If your app is just a web site wrapped in PhoneGap, it will probably get rejected. There are exceptions to this case, but don’t expect that wrapping a web site in a web view will get you into the App Store.”
    Having build many business applications, we see that a mobile application isn’t per definition an improved (richer) version of a site.

    It strange to see the rejections mainly based on website like reasons, instead of also focusing on the non-usage of app features like Contact, Files, Media and such.
    (Still we also see more and more features becoming available to browsers, so this point will get weaker with time)

    At the moment we are working on a mobile application which could have been a mobile (rich) site, but due to native calendar access we have made the move to Phonegap and native extensions. Together with the rich app experience, this addition can be a tipping point.

    So depending on the type of project it can be a gamble or educated guess if Apple will have anything against it…

  • Head Data Zombie

    HTML 4 & 5: The Complete Reference by O’Reilly Media, Inc.

    • Andrew

      Thanks “Head Data Zombie”, a great example!

  • Pingback: Some Guidelines on Getting Your PhoneGap App Approved by Apple | Tiggzi: Cloud-based Mobile App Platform()

  • Matias

    Have you tried Zepto.js?

    It should be included in the list too!

  • Mobile application development

    Thanks for sharing this blog