Chapter 11.Deploying Your Application
Now with your application fully tested, it is time to create the versions that can be submitted to the various app stores. Before we generate the release build of our app, we should remove any assets that should not be included in our production release.
For example, the Console plug-in was added when we first generated our Ionic application, so let’s remove it from our installed plug-ins. To do this, simply run:
$ ionic cordova plugin remove cordova-plugin-console
We also need to manually delete the reference to this plug-in in our_config.xml_file. Locate this line and delete it:
<
plugin name="cordova-plugin-console" spec="~1.0.4"/
>
Adjusting the config.xml File
Before generating your production build, you may also need to adjust the_config.xml_file with some additional settings. By default, the_config.xml_that is generated by Ionic is fairly bare bones. There are many additional settings you may wish to configure for your application, such as restricting the OS versions your app will run on. Other items within the_config.xml_that you may want to adjust can include the version number, restricting the domain access list, and replacing development API endpoints with production API endpoints.
For a summary of these settings, seeAppendix Bor the full documentation at theCordova website.
App Icons and Splash Screens
If you have not already replaced the stock icons and splash screens that are included when you use the Ionic templates, now would be the time. Rather than export the myriad of sizes required by each platform, we can use the Ionic CLI to generate them for us.
First, delete the existing icons and splash screens that were included. We have found that the CLI will not overwrite existing files; instead, they’ll fail silently.Next, include your base icon file within the resources folder. For the best results, this file should be 1,024 × 1,024 pixels in size. You should also not include any platform-specific effects, such as round corners or glossy overlays. Once you have your icon ready, name iticon.png. The CLI will accept Photoshop (PSD) files, but rather than worry about an incompatibility with a filter or some other technique you might use, we recommend sticking with a flattened PNG file as the source.
For the splash screen, you should have a file that is 2,208 × 2,208 pixels in size. Unlike icons, which are always square, splash screens are rectangular and can be oriented in both portrait and landscape mode. If your application is constrained to only run in a particular orientation, then you only need to supply the splash screens for that orientation. The Ionic team has provided atemplatewith guidelines about the safe zones for your artwork. Save your file assplash.png, also within the resources directory.
From the command line, run$ ionic cordova resources. This will upload the files to Ionic, generate the various icons and sizes, and then save them in the correct directories.
Building Your Android APK
Togenerate a release build for Android, we simply use the following CLI command:
$ ionic cordova build android --release -prod
If you have built Ionic 1 apps in the past, you might notice there is now an additional flag, the-prod. This tells the Ionic Build script to use the_main.prod.ts_file when building the_main.js_file. For those familiar with current Angular development, this file makes the call toenableProdMode().
Once the CLI is done working (hopefully with no errors), we can find our unsigned APK file inplatforms/android/build/outputs/apk/android-release-unsigned.apk. Now we need to sign the unsigned APK and run an alignment utility to optimize it and prepare it for the app store.
Generating the Signing Key
To generate the signing key, we need to use thekeytoolcommand that is installed with the JDK. Here is the basic command:
$ keytool -genkey -v -keystore my-release-key.keystore -alias alias_name
-keyalg RSA -keysize 2048 -validity 10000
The_alias_name_is your key alias. This is just a descriptive string that will identify your app. This can be letters, numbers, and underscores. Note that the key alias is case-sensitive. You can also change the_my-release-key.keystore_to something more descriptive.
The tool will prompt you to create a password for the keystore file and the key alias. It will then ask you a series of questions that will be used as part of the key generation process:
Enter keystore password:
Re-enter new password:
What is your first and last name?
[Unknown]: Chris Griffith
What is the name of your organizational unit?
[Unknown]: None
What is the name of your organization?
[Unknown]: AJ Software
What is the name of your City or Locality?
[Unknown]: San Diego
What is the name of your State or Province?
[Unknown]: CA
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=Chris Griffith, OU=None, O=AJ Software, L=San Diego, ST=CA, C=US correct?
[no]: y
After you provide this information, you will see this in the terminal:
Generating 2,048 bit RSA key pair and self-signed certificate (SHA256withRSA)
with a validity of 90 for: CN=Chris Griffith, OU=None, O=AJ Software,
L=San Diego, ST=CA, C=US
Enter key password for
<
my_alias_name
>
(RETURN if same as keystore password):
Once this is done, you will have a_my-release-key.keystore_file in the directory you ran the command from.
Make sure your store this file in a safe location. Once you sign and submit your application with this keystore, all updates to that app must be signed with the same keystore. There is no method to regenerate a replacement keystore file.
Next, we actually sign our APK with our keystore. To do this, we will use thejarsignertool that is also included with the JDK:
$ jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1
-keystore my-release-key.keystore android-release-unsigned.apk alias_name
This command will ask you for the password you used when you created the keystore, and then it will sign the application.
The final step is to run thezip aligntool (in/path/to/Android/sdk/build-tools/VERSION/zipalign) to optimize the APK:
$ zipalign -v 4 path/to/android-release-unsigned.apk MyApp.apk
With that, we will have our release-ready APK named_MyApp.apk_ready for submission to the Google Play Store.
Submitting to the Google Play Store
We will now cover the basic steps needed to actually submit your app to the Google Play Store. First, you will need to create aGoogle Developer account. This account requires a one-time fee of $25.
Once your developer account is active, you can sign in to the portal and begin the publishing process; it is fairly straightforward. However, the process is much easier if you have gathered all the supporting assets the actual Play Store listing needs, such as screenshots and marketing text (seeFigure 11-1).
Figure 11-1.Google Play Store App submission screen
After all the required elements are submitted, your application should be available for purchase within a few hours, if not sooner.
Building Your iOS App
Although it is possible to build development versions of your iOS application without enrolling intheApple Developer Program, if you wish to publish to the Apple App Store, you will need to pay the $99 yearly fee. Once you have completed your enrollment, we will need to next configure Xcode to use this account. Within Xcode, go to Preferences→Accounts, then fill in your Apple iOS developer account information.
Request a Distribution Certificate
With Xcode and your developer account linked, go to Preferences→Accounts, select your Apple ID, and then click the View Details button. You should see a pop up similar to the one inFigure 11-2.
Figure 11-2.Xcode pop up after pressing the View Details button
Click the Create button next to the iOS Distribution option, then choose Done to close the account details page.
Create a Distribution Provisioning Profile
The next step is to create a distribution provisioning profile that lets you submit your app to the App Store. This step is done on theMember Center page. On that page, choose the Certificates, Identifiers & Profiles link. Then find the Provisioning Profiles panel (Figure 11-3) and select the Distribution option.
Figure 11-3.Provisioning Profiles panel
On this page, click the [+] button to begin the process of generating a distribution profile (seeFigure 11-4).
Figure 11-4.Click the [+] button on the Provisioning Profiles panel
You will then be asked what kind of provisioning profile you need to generate. Hopefully, you recognize this screen from when you created your development profile. Instead of choosing iOS App Development, select the App Store option, then click the Continue button (Figure 11-5).
Figure 11-5.The provisioning options screen
On the Select App ID screen (Figure 11-6), we need to choose the App ID of your application. You should have already generated an App ID when you created your development certificate. If not, cancel out of this process, and use the App IDs link in the Identifiers pane to generate one. Once you have selected your App ID, click the Continue button to proceed to the next step.
Figure 11-6.App ID selection screen
Now we need to select the distribution certificate that you created earlier in Xcode (Figure 11-7), and then choose the Continue button.
Figure 11-7.Distribution certificate selection screen
On the next screen (seeFigure 11-8), you will need to name this profile, and then choose the Continue button.
Figure 11-8.Profile generation screen
The distribution certificate will be generated and it can be downloaded to your computer by clicking the Download button (Figure 11-9).
Figure 11-9.Provisioning downloading screen
Once you have downloaded the provisioning profile, simply double-click it to install it.
Creating the App Listing
Apple usesiTunes Connectto manage app submissions. After you sign in, you should see a screen similar to the one inFigure 11-10.
Figure 11-10.iTunes Connect portal
Choose the My Apps button, then select the [+] icon in the upper left. This will bring up the dialog inFigure 11-11.
Figure 11-11.New app dialog
Select the iOS platform, and then fill in the rest of the information. Once you have completed this form, click the Create button.
The App Information screen will now be shown (Figure 11-12). Although we can set some of the information, you will be returning to this screen later in the process. The reason for creating your placeholder app is that the Application Loader tool needs it to exist before it can upload your app.
Figure 11-12.Basic app information screen
Building the App for Production
With our app store stub created, we can turn back to the process of completing the distribution build. Return to your command prompt and run$ ionic cordova build ios --release -prod. After a few moments and a lot of output to the terminal, you should seeBUILD SUCCEEDEDoutput to the console. If not, scroll back through the output to identify the error.
Creating an Archive of the Application
To submit our application to iTunes Connect, we need to create an archive of the application. Return to Xcode and open your application’s Xcode project. This file can be found in theplatforms/iosdirectory.
On the project information screen, check that the bundle ID is correct, as well as the version and build numbers. The team option should be set to your Apple developer account. If you want to restrict which devices your app will run on, you can set that here as well.
Now select Product→Scheme→Edit Scheme to open the scheme editor. Then select Archive from the list. Make sure that Build Configuration is set to Release.
To create the actual archive, we need to make sure that we are targeting the Generic iOS Device from the device list in the toolbar. Then, select Product→Archive, and the Archive organizer will appear and display the new archive (Figure 11-13).
Figure 11-13.Product archive screen
Our application is now ready to be uploaded to iTunes Connect. Click the Upload to App Store button (Figure 11-14). Xcode will now sign our application, revalidate it, and upload to iTunes Connect. Once that process is complete, you should see the message inFigure 11-15.
Figure 11-14.App Store Archive Upload panel
Figure 11-15.Upload successful message
After a few moments, you should receive a confirmation email. We can return to our app listing on iTunes Connect portal and finish the submission process.
At this point you have two options with your submission: you can release your app to be reviewed and released to the public App Store, or you can release it to TestFlight for testing. Let’s briefly look at both of these options.
Using TestFlight Beta Testing
TestFlight Beta Testing is an Apple product that allows you to invite users to test your iOS apps before you release them into the App Store. With your iOS app uploaded to the iTunes Connect portal, simply select the TestFlight tab to begin the process. You will need to provide some basic information: an email for feedback, a marketing URL, and a privacy policy.
Next, you will need to answer a series of questions about encryption. Then your app will undergo a short review by Apple. Once it has been approved, you will be notified by email, and you can distribute it to both internal and external testers. Your testers will need to install the TestFlight app to access your app (Figure 11-16).
Figure 11-16.TestFlight app screens
Once you are ready to release the app for testing, your testers will receive an email with a link that will launch the TestFlight app on their iOS device and install the app. They then can use the app like any other app. One thing to note: these apps have an expiration date of 60 days once they are released, so this is not a long-term distribution solution. You are also limited to 2,000 testers at one time. When you are done with your testing, you can then move onto releasing the app to the public App Store.
Releasing to the App Store
With our iOS app uploaded and validated, we can complete the final steps to submit it to review by Apple. From the iTunes Connect portal, select the app you wish to release. Update or complete any app information you need to, and define the price of your app. Note that if you release your app for free, you can never charge for it.
Then click the Prepare for Submission link. This will bring up a long form where you can define the screenshots, store description, keywords, and app rating (Figure 11-17).
Figure 11-17.iTunes Connect app details screen
Once you have completed editing all these items, you can submit your app to be reviewed again by Apple. This process can take a few days or longer, depending on the backlog of reviews. Now you can turn to the hard work of promoting your new application!
Summary
You now know how to properly compile and submit your apps to both the Apple App Store and the Google Play Store. If you plan to release to the Windows Store, the Microsoft TACO team has agreat resourceto guide you through that process.