The Step-by-Step Guide to Publishing a HTML5 Mobile Application on App Stores

The Step-by-Step Guide to Publishing a HTML5 Mobile Application on App Stores

Follow Josh Morony on

If you’re reading this you would probably know what an HTML5 mobile application is, but you might not know how to actually get one on the Apple App Store or Google Play.

You can submit an application built purely with web technology to both of these stores just like you would a native application (even if you don’t have a Mac), and for the majority of use cases it can look, feel and perform just as well as native applications (as long as the application is designed well).

There are a few steps between here and there, though. There are a few conceptual differences to understand when creating an HTML5 mobile application, and you can easily get stuck somewhere along the way.

I’ve created this simple step-by-step guide to point you in the right direction no matter where you are along your app store journey – this article should help give you the context you need.

1. Understand the Difference Between Native, Hybrid and Web Applications

Before you even get started, you should understand why you’re building a mobile application with HTML5 and what the difference is exactly between web and hybrid (if you’re submitting your app to app stores, you will be building a hybrid application) and native.

If you’re a little short on time, here’s a little infographic I made that explains the conceptual difference in a very simplified way. Please note that there are a lot of factors this infographic leaves out, and a hybrid approach is not always the best solution:

The Difference Between Native, Web and Hybrid Mobile Applications

Also, keep in mind that the purpose of this approach is to highlight the benefit of the hybrid approach, I’m not attempting to say “Look! Hybrid has 3/3 ticks in these areas and is, therefore, the best solution possible”.

It’s easy enough to understand what a native application is: an application that was coded using the native language of the platform. This means using Objective-C/Swift/XCode for iOS, or Java/Android Studio for Andoird. A native application has immediate access to everything that platform has to offer with no restrictions whatsoever. The downside to this approach is that separate applications need to be built for each platform.

A web application is an application that is powered by a browser through the Internet. A web application is typically built using HTML, CSS and JavaScript and can be served either through a desktop or mobile browser. A web application can be built to mimic the feel and behaviour of a normal native application, but instead just runs through a browser. Using this approach means you won’t have access to all the bells and whistles a native application does and you can’t distribute your application through most app stores. However, building Progressive Web Applications – which basically just means a modern/offline-capable mobile web application – is becoming a popular distribution method these days.

A hybrid application is a mix of the native and web approach that allows you to build the application once and submit it to multiple app stores. A hybrid application uses a native packager like PhoneGap/Cordova or Capacitor which essentially wraps up a browser web view into a native application and displays your web application through it. With this approach, users of the application will no longer be able to see the browser the app is being run through (so it will just appear like a normal native application to them), you have access to native functionality through PhoneGap/Cordova/Capacitor and you can distribute your application through app stores.

The most obvious question that might arise from this is:

If Hybrid applications are so great, why isn't everybody using them?

To drill down into all of the differences between a Hybrid and Native approach would take a blog post of its own. But in short, the main benefit of building native is that it offers the best possible performance and feature set. In most cases, the choice just comes down to personal preference, and the skills that are available – most requirement sets could be satisfied by either a native or hybrid approach. Whilst native applications have the potential for much higher performance, in most cases, it doesn’t make any noticeable difference (again, assuming that the application is designed well).

I often use the analogy of purchasing a high-performance supercar for city driving. If you’re never driving faster than 60km/ph it will hardly make a difference that your car could travel at 300km/ph. I’m sure car folk could easily poke all sorts of holes through that analogy, but hopefully, you get the idea.

I have elaborated on the difference between web, hybrid and native before if you want to check that out.

You will find a lot of opinions on what approach is the best for creating mobile applications between options like:

  • Native
  • Ionic
  • Native Script
  • React Native
  • Xamarin
  • Flutter

…and many more. Ultimately, all are perfectly capable of creating great applications in the right circumstances and with the right people. The only reasonable answer to which approach is the best is always “it depends”. This article is specifically about using a hybrid/HTML5 approach to building mobile applications, so I will be focusing more on that.

2. Design Your Application

Before committing to a particular approach, make sure you have your requirements defined and that your approach is going to meet those requirements.

If you’re creating a pure web application (an HTML5 mobile application that does not require native APIs or to be submitted to app stores), then you only have access to features that are available to the browser. Make sure all of the functionality you require is available here. Don’t worry if you later decide to include native functionality, it’s extremely easy to convert your HTML5 mobile web app to a hybrid app.

If you want access to some native API’s or want to submit your application to app stores (or both) then a hybrid approach is going to be your best bet. We’ll talk more about integrating PhoneGap/Cordova/Capacitor to access native API’s and wrap your application later, but make sure the functionality you require is available as a Plugin API in Cordova or Capacitor, or that there is a 3rd party Cordova/Capacitor plugin available that provides the functionality you need (anybody can create their own Cordova/Capacitor plugin that accesses native functionality).

When designing your application keep in mind the iOS Human Interface Guidelines and Android Design guidelines. Keep in mind that some of the information in these guidelines will be specific to native applications, so don’t worry too much about it. Just make sure you follow good design principles that are prevalent in most mobile applications.

If you’re building an application to be distributed through the Apple and Google Play app stores, you need to play by their rules. Make sure you comply with the Apple App Store Review Guidelines and the Google Play Developer Program Policies. This is where the benefit of distributing your application as a Progressive Web Application comes in – using the open web means we don’t need to jump through somebody else’s hoops.

Apple especially can be a bit fickle with their application of the guidelines, but if you break any of them (sometimes even if you don’t) your application may be rejected and you will have to fix the problem and resubmit. Here are a few gotchas to watch out for that might see your application be rejected:

  • Your app is more like a web page than a mobile application
  • You don’t handle online/offline states
  • Your app is slow or unresponsive
  • Your application doesn’t make use of native features (i.e. there isn’t really a reason for it to be distributed as a native app instead of a website)

Apple is much more strict than Google in the review process, for more information check out my other blog post on the Apple review process.

3. Build your application using an HTML5 mobile framework

HTML5 mobile frameworks are the corner stone of developing HTML5 mobile apps. They fulfill a role similar to that of jQuery and Bootstrap in normal websites.

On a website jQuery allows you to easily create animations, show and hide things, and so on. Frameworks like Bootstrap provide pre-built user interface components. When building an HTML5 mobile application, frameworks like Ionic allow you to easily create typical mobile interface elements like scrolling lists, buttons and screen transitions.

HTML5 mobile frameworks are not strictly just for creating the user interface though, most also have ways to store and manage data (data that would populate a scrolling list for example) and handle application state.

If you were to try and recreate the behaviour of a native smooth scrolling list with acceleration and deceleration in plain old JavaScript you would likely not achieve a good result without an enormous amount of effort – and there is a good chance your application may end up getting rejected. In Ionic, though, you can just do something like this:

        Item 1
        Item 2
        Item 20
        Item 21

and it’s done:

Ionic List Example

See this page in the Ionic documentation for an interactive demonstration.

These frameworks implement advanced techniques like recycling DOM elements in the list that are off screen to improve performance, so I highly recommend that you use one. Getting the same level of performance as a native application is a difficult challenge, and it’s something these frameworks have done very well through years of optimisation.

There are other frameworks available, but I would recommend Ionic to anybody who is just getting started as it is a powerful framework that can be easily used with Angular, but it can also be used with any other framework or completely on its own. Also it’s completely free to use.

4. Test Your Application Through the Browser

The great thing about developing mobile applications with HTML5 is that you can test it right through your browser.

Different frameworks may be run in different ways but typically you will be able to access your application through a local web server by going to:


in your browser. If you’re using Chrome Dev Tools you can even emulate the device you are designing for by clicking the mobile icon in the top left:

Chrome Dev Tools

From here you can debug your application to your heart’s content using the Console, Network, Timeline etc.

If you’re building a web application, then once you’ve finished this stage your app is all good and ready to go. But if you want to create a hybrid application that can access native API’s and be submitted to app stores, it’s now time to package the application.

5. Package Your Application

You can use a technology like PhoneGap/Cordova or Capacitor to wrap your web application in a native wrapper and act as a bridge between your application and the native APIs of the device.

If you want to build iOS applications but don’t have a Mac you can use the PhoneGap Build service, or Ionic’s own Package service. To build for iOS you need the appropriate SDKs installed on your machine, and you need a Mac for that, however, if you didn’t want to use one of these build services you could also do something fancy like setting up a virtual machine.

The basic role that Cordova/PhoneGap/Capacitor performs is this:

  • Cordova/PhoneGap/Capacitor creates a native application that contains a web view
  • All of the resources for your application are stored inside of this native application
  • Cordova/PhoneGap/Capacitor loads your HTML5 application into the web view (the web view cannot be seen by the user)
  • The web view displays your application to the user

Our application is really still just a web application since it is being powered by the browser, but now we also have access to the device through Cordova/Capacitor, and it can be installed like a normal native application.

Enjoying learning about hybrid apps? Consider retweeting to share with others 😀

6. Access Native APIs (optional)

You can just use Cordova/Capacitor to package your application so that it can be submitted to app stores, but why stop there? We have access to all this magical native functionality now!

With Cordova or Capacitor, we can access just about everything that a native application can. Rather than interacting with the device directly, we could use Cordova to pass messages between the device and our application.

HTML5 app interacting with the device

Typically, the native functionality will be available through some global Javascript object. We will use the Camera API as an example. To trigger the camera all we need to do is run the following bit of JavaScript:, onFail, { quality: 50,
    destinationType: Camera.DestinationType.DATA_URL

function onSuccess(imageData) {
    var image = document.getElementById('myImage');
    image.src = "data:image/jpeg;base64," + imageData;

function onFail(message) {
    alert('Failed because: ' + message);

This tells Cordova to tell the device to launch the camera, and then we can grab the resulting image data from the onSuccess function. In this case the functionality is available through the camera **object which can be found at ** Sometimes though, like in the case of the AdMob plugin, the functionality will be available directly through an object that is available globally like:


If you are using Ionic, and I highly recommend that you do, using native functionality will look a little different because Ionic has some built-in support for doing this. This video may help to give you more context.

Also, more recently, the Ionic team have released Capacitor. This fulfills a similar role to Cordova but includes some improvements that the Ionic team wanted to see.

7. Test Your Application on a Device

I mentioned before that one of the great things about HTML5 applications is that you can test them through your browser. Once you start integrating Cordova/PhoneGap/Capacitor and native API’s though testing through the browser isn’t so great.

To test an application that is accessing native API’s you will need to run the application on an actual device. But how do you debug without your browser debugging tools? Don’t fret! You can still debug directly on your device and access the same browser debugging tools, you can check out the videos below for more information on how exactly to do that:

It’s an important step, in any case, to test on a device, whether you’re using native functionality or not. The behaviour on an actual device can be different than when it is viewed through a desktop browser.

8. Sign Your Application

To distribute your applications on app stores you will need to “sign” your application, and in the case of iOS you need to sign your application before you can even install it on a device.

For an iOS application you will need to create a .p12 personal information file and a provisioning profile. You can more easily sign an iOS application if you have a Mac and XCode but it is also possible to sign an iOS application without a Mac (the article I linked above describes how to do that).

To sign an Android application, you simply need to create a single keystore file. The Ionic documentation has some examples of how to get through the signing process.

9. Distribute Your Application

Assuming that you want to distribute your application in the native app stores, you’ll need to sign up for the iOS Developer Program (in fact, you’ll have to do this to create your provisioning profile and such anyway) and as a Google Play Developer.

If you want to publish your application as a Progressive Web Application, you do not need to do this (and you don’t need to worry about signing your application either).

You will need to prepare your app store listings for both platforms and provide some details about your application. To submit to Google Play you will simply be able to upload your .apk **file through the developer console. To submit to the Apple App Store without a Mac though you will need to use the **Application Loader **program, **which is only available on Macs. You can use a service like to get around this, though.


I hope that this article has been able to give you some context around the path to building and deploying an HTML5 mobile application to app stores. There are a lot of steps in between, of course, and this has just been a very high-level overview.

For a complete walkthrough of creating an application from scratch (including learning Ionic itself) and submitting it to app stores, you may be interested in taking a look at Building Mobile Apps with Ionic.

Check out my latest videos: