How to submit your app to app stores
Building and Publishing process
- You need a mechanism to sign your app for both platforms. For Android this is done with a keystore, and for iOS this is called a signing identity. But they both do the same thing in the end: they add a signature to the build file that can later be used to verify the author.
- Both platforms also require you to create a listing in their store. Let’s assume you’ve already done work to create the marketing material (screenshot images for the listing, description text, etc.), which will make it easier to create the listing. Having good marketing and app descriptions is vital for users to be able to determine if the app is for them or not.
- You must build and optimize the build file on both platforms. For Android, you upload the build file through the Google Play developer page, and for iOS, Xcode connects and uploads the file to your account.
Building icons and splash-screen assets
Icon at least 192px x 192px, recommend 1024px x 1024px
Icon & Splash Screen PSD: http://ionicframework.com/docs/cli/icon-splashscreen.html
iOS Icon design: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/AppIcons.html
Android Icon design: https://www.google.com/design/spec/style/icons.html
Auto create icon: ionic resources –icon (resources/icon.png)
Auto create splash screen: ionic resources –splash (resources/splash.png)
Preparing app for production
- Remove the Cordova Console plugin. This plugin is part of how Cordova allows you to debug your apps, but in production you don’t want this. Remove it from your app by running cordova plugin rm org.apache.cordova.console.
- Remove any unnecessary files. During app development you might install extra third-party libraries or create extra views that you don’t end up using. Remove them from the app so you save on file size.
- Remove unused library files. Ionic may have installed files in the www/lib directory of your app using Bower, and sometimes those library files also include the sources. You should delete any files that you’re not using.
- Compress your code. You can run your code through a JavaScript minification system to help optimize the file execution and reduce file size.
- Compress your graphics. Images are often what can cause app file size to grow. Try to compress your files and make sure they aren’t any larger than necessary.
Building Android apps and publishing to Google Play
How to use Android Studio: http://developer.android.com/tools/publishing/app-signing.html#studio
The Google Play Store is the primary place to publish your apps for Android. You’ll need to create or link an existing Google account with the Play Store Developer Console. Then you’ll be able to create a listing for your app that includes the title, description, images, and other details used to categorize and list the app. Once that’s done, you’ll upload the built Android app APK file you generated and submit the app for review.
Setting up for signing your apps
Read more about signing: http://developer.android.com/tools/publishing/app-signing.html#studio
To generate a new keystore, you’ll use a command-line utility keytool. You’ll replace know_your_brew with the name of your app (use underscores) in this command
$ keytool -genkey -v -keystore know_your_brew.keystore -alias know_your_brew -keyalg RSA -keysize 2048 -validity 10000
This generates a new file called, in this case, know_your_brew.keystore, and you can place it anywhere on your computer. Later you’ll need to know the location of the file, so make sure you can access it. You’ll reuse the same keystore for the entire life of the app, so you need to keep it for as long as you plan to support the app. You also need to keep it safe and private because it could be used by others for malicious purposes. Every version of the app must be signed with the same keystore or the updates will be rejected. If a team needed to sign an app, the same keystore would need to be used regardless of who builds the app. You should also generate a different keystore for every app you produce.
Build the release app file
$ cordova build --release android
This will generate a new APK file, which is the Android app file type, inside of platforms/android/ant-build/CordovaApp-release-unsigned.apk. The command line should report the exact file path to the APK file. This is an unsigned, release-ready version of your app.
Signing the APK file
Now you’re ready to use the keystore you created earlier to sign the unsigned version of the APK you just generated. Android comes with a tool called jarsigner that will help you with this task. You’ll need to know the file path to both the unsigned APK and the keystore from the previous two steps. I recommend moving them into the same directory so the command is easier to type. In the command you’ll replace know_your_brew with the same values you used to generate the keystore for your app, and update the name of the app if it’s something other than CordovaApp-release-unsigned.apk:
$ jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore know_your_brew.keystore CordovaApp-release-unsigned.apk know_your_brew
This takes just a moment, and it will prompt you for the password for the keystore and key. It will modify the APK in place. You can test that the app is now signed properly using jarsigner again, and replace the name with your app filename:
$ jarsigner -verify -verbose -certs CordovaApp-release-unsigned.apk
If you have any signing errors, you might want to rebuild the app using Cordova and try again to ensure you don’t have a lingering problem.
Optimize the APK
The last step is to optimize the APK file so that it reduces the amount of space and RAM required by the app on a device. The zipalign tool is the utility for the job: it will take your signed APK file and create a new optimized APK version that you’ll want to use for uploading. Under the hood, zipalign will optimize the bytes inside of the package for optimal reading by the operating system processes. The technical details can be found at http://android-developers.blogspot.com/2009/09/zipalign-easy-optimization.html
The zipalign tool just takes the name of the signed file (remember, you signed the file in place and haven’t changed the filename in this example) and the name of the file to generate. Change KnowYourBrew.apk to the name of your app:
$ zipalign -v 4 CordovaApp-release-unsigned.apk KnowYourBrew.apk
When the new file is generated, you now have a final version of your Android app that you can use to submit to any Android store. You’ve finished with the initial build, but let’s talk quickly about how to update your app.
Building an updated version of your app
Almost certainly you’ll eventually want to update your app with new features and bug fixes. The process to build an update to an existing app is the same as building the release, except you don’t need to create another keystore. A few details are worth emphasizing:
- You must use the same keystore to sign the app for every update; otherwise, the update will be rejected for not having the same signature and you’ll be required to create a new app listing.
- You must update the version and build number in the project config.xml file for the next release. If the numbers aren’t changed, then the app will not properly update on your users’ devices.
- If you build frequently, you might want to improve the steps by making the commands into a shell script that can be automated
Creating the app listing and uploading the app to the Play Store
The first step is to make sure you have access to the Developer Console for the Play Store. It requires a Google account. It’s recommended that you create a separate Google account for your apps from any personal accounts, so you avoid any situations where your personal account (and perhaps your name) becomes tied to your apps. You can create the Google account at https://play.google.com/apps/publish/ signup/.
There’s a one-time US $25 fee to update your account to a developer account. You’ll also have to agree to some terms and conditions as part of the registration process. You should walk through the steps and complete the account registration and payment before continuing.
Once you’re logged in to your developer account, you can begin the process of creating a listing. You’re able to start a listing and finish it later, which is handy when you’re trying to track down all of the details for the app. You can review the most up to-date details about the Google Play publish process at http://developer.android.com/distribute/tools/launch-checklist.html
In the process of creating the listing, you’ll need to provide the app name and default language, description, title, screenshots, and other metadata. Google Play requires several screenshots, an icon, and a feature graphic. You’ll need to use your preferred image editing program to design and size these images accordingly.
Once you’ve created the full listing, you can upload the app APK file. Google Play has alpha, beta, and production versions that you can use with your app. The alpha and beta versions allow you to push updates before they go into the public Play Store, and get feedback. This can be a great way to roll out updates first to alpha, then beta, and finally to production. Alpha and beta testing might not be very useful until you’ve gotten a loyal following or have users willing to help you out. But you could be the only member of the beta group so that you can test that your app updates correctly from the Play Store before pushing to production. You can see more details at http://developer.android.com/distribute/googleplay/developer-console.html#alpha-beta
You can also upload an app APK file directly to production mode. This means your app can go live in the Play Store, and anyone is able to find and download it without having to opt-in to the alpha/beta process.
After you have the listing filled in and APK file uploaded, your app should be ready for publishing. Once you’ve submitted the app, it will be reviewed through both automatic and some manual processes to verify the app doesn’t violate any store guidelines.
This can take hours or days, but if the app is rejected for any reason, you’ll be notified. If you violate any of the Google Play policies, you’ll be notified so you can resolve them and resubmit your app.
Updating the app listing or uploading a new version
You can modify the app listing details, such as the description, without having to submit a new APK file. For example, you don’t have to update the app APK file if you find a typo in your description.
When you update your app APK file, you must update the app version code (which is different from the version number) in the build itself. Cordova generates this value when you create the Android platform files based on the version number in config.xml. This number is built from the version number using this formula (unless you explicitly declare it): PATCH + MINOR * 100 + MAJOR * 10000. For example, version 2.3.6. (MAJOR.MINOR.PATCH) would be 6 + 3 * 100 + 2 * 10000 = 20306. Uploading a new APK file with an updated version code to production will trigger an update for users. The version number is just the value shown to users in the store. See http://developer.android.com/tools/publishing/versioning.html for full details about versioning.
Any changes from updating the app or metadata are usually available within a couple of hours on the Play Store. The status of the changes is shown in the Developer Console, in case you need to verify if the update is still pending or has completed.
Using alternative Android stores
There are other Android stores, such as the Amazon App Store, and the build process is the same regardless of which store you use. There may be different rules or guidelines that you need to adhere to for these stores.
But other stores aren’t inherently trusted like the Google Play Store. There is a setting on Android devices in Settings > Security > Unknown Sources that must be enabled to allow apps to be installed from outside of the Google Play Store. This is a major advantage that apps in the Google Play Store have over other stores.