There is an article floating around the web today, warning against “Shell Apps” and tools like PhoneGap. The logic in this article has a few arguments that are misleading, and I’d like to introduce some counter arguments as they relate to PhoneGap and HTML experiences for comparison.
The “Silver Bullet”
First, the “Silver Bullet” argument… I have never seen it stated anywhere that PhoneGap is a “Silver Bullet” that will solve every problem for every application developer. PhoneGap is a tool for developing applications. It enables developers to build applications in situations where they may not have otherwise, including:
No knowledge of native development
Existing web development skills
Reuse of assets across platforms or leverage existing code/assets
Lower barrier of entry in the mobile app world
PhoneGap isn’t a “magical” solution to end all other solutions. It is a toolset that enables you to build & bundle natively installed applications using web technologies. For more detail on what exactly PhoneGap is, see this post “PhoneGap Explained Visually“. If you’d like to understand the motivations behind PhoneGap/Cordova, then look no further than the PhoneGap blog.
If you were building a house, would you use a butter knife to drive nails? Or, would you use a sledgehammer for finishing touches? If you needed lumber for your house, would you go cut down a tree, cut some beams out of it for use in your house frame? No, You wouldn’t do any of these. You would use the right tool for the job, and you would use raw materials that you already have available or are easily accessible.
Chances are, if you are building an app, you would do the same thing. There are cases where PhoneGap is not the best choice, but that does not mean there aren’t a huge number of cases where PhoneGap is a great choice (if not the best). It does not make sense to have to rebuild everything from the ground up, or have to learn completely new skills just to build apps for a mobile platform.
Increasing Complexity
The article also makes claim that HTML/JS based apps are more complicated than native apps:
At first things are easy. For simple screens, using a webview might be faster than writing a native implementation. As you add functionality to the webview, the complexity increases until you give up and write everything native.
This is far from the truth. There are 2 facts that are completely overlooked in this statement:
You can write a “bad” or overly-complex application in any langauge. Native development is not a silver bullet that prevents you from building “Bad” apps.
Native applications can also be extremely complicated – they are not inherently more simple.
Regardless of the underlying technology, the more features, views, data models, and components that you have within an application will add to the overall complexity of that application. This is precisely why people apply model-view-controller (MVC) development paradigms and software design patterns.
PhoneGap and hybrid/web development techniques are no exception to this rule. You can create really simple apps very quickly without a high degree of computer programming skill, but creating complex applications requires real software development processes. MVC, abstraction, encapsulation, separation of concerns, etc… all apply. You can absolutely build complex applications with web technologies, but you must approach them in a structured manner – just as you would approach an enterprise-quality native application. If you do not approach a complex problem with proven software design principles from the beginning, you risk setting yourself up for failure regardless of the underlying technology.
I have significant experience in developing native applications, interactive development, HTML/JS, as well as developing with cross platform technologies. Based on my own experience, I am far more productive with HTML & JS/PhoneGap than I am with native development, and I can create applications that are just as complex.
That does not mean everyone will be the same as me. A developer who comes from either the Objective-C or Java worlds and does not know HTML will likely be more productive with native development – once they learn the libraries and paradigms for native mobile development. Likewise, developers who are already proficient with interactive development for the web will be more productive using web technologies. One cannot make generalizations about a software tool or productivity when the use cases and developer skills are so widely varied.
The Framework Tax
The article makes the claim that you end up paying a “tax” by using frameworks such as PhoneGap:
You could use an open source shell-app framework like PhoneGap, but that leaves you at the mercy of their schedule. If the native platform introduces a new API, or you run into an edge case that requires extending the shell framework, it could be months before you can implement your own app’s functionality.
Again, this is not entirely accurate. The goal of PhoneGap is not to recreate & mirror every native API on every platform. Rather, to provide a consistent API for building your applications across multiple platforms, using familiar web development skills, and to push the web forward. There are certainly APIs on all platforms that it does not support.
Luckily, PhoneGap is built on top of an extensible architecture, so that if you wanted to take advantage of a new API, you can create your own native plugins (yes, in native code) to expose that functionality for use within your PhoneGap applications. If you do not want to wait on the PhoneGap/Cordova open source initiative, then you can build it yourself without delay. You do not need to fork the framework for this, rather you extend it within your own projects. There’s also a good chance that someone has already written a native plugin and posted it on github that you can reuse.
Browser Fragmentation
Well, you have a point there… to a point. There are definite browser fragmentation issues. Webkit on iOS != Webkit on Android != Webkit on BlackBerry != IE/Trident on Win Phone, etc… However, this is generally related to presentation styles, not core browser functionality. It is important to use tools like caniuse.com when you are evaluating your development strategy and modernizr during implementation phases (for graceful degradation). While there are variations in the browsers, it doesn’t mean that your architectural patterns, your business logic, or your data model are going to be different.
Different browsers on different platforms also have different performance metrics, and you need to build your application experience based on what you are trying to create. Do not try to force a slow browser to be fast; that will never work.
Versioning
The versioning argument in that article sates “hybrid apps allow you to update” is not entirely true:
Shell app let you update content without requiring a full app release by serving your pages off a server. In the process, you lose release atomicity, the assurance that whatever you ship to clients comes in one complete, unchanging bundle.
Yes, you can serve web pages, and if you have native content around the web content, then it could be mismatched. However, it is important to understand that you can’t create apps with HTML technologies that update their own code withinin the local app bundle on the device based off of code downloaded from a server.
If you build an app that bypasses Apple’s App Store and updates itself automatically, it will get rejected. You may be able to pull down data/content or images and cache them locally, but a “full app release” is not possible. The Apple Developer Agreement explicitly says in section 2.7:
“Apps that download code in any way or form will be rejected“
Likewise, “Users may wait weeks or months to update apps” applies to native development as well. If your users don’t update, then they don’t update. In this case the mobile branding may not match the website branding. This happens regardless of technology choice.
The Uncanny Valley
There is merit to the uncanny valley argument (html based apps don’t always feel “right”), but that does not mean it is impossible to build native-feeling applications using HTML and JavaScript. The trick is that you must design these apps to feel like applications, not like web pages. Here are a few apps that are built using HTML-based technology: Apple Store, Facebook, LinkedIn, Wikipedia, Mafia Wars, US Census Browser, Bit Timer, Untappd, and even the “revolutionary” iAd advertising experience from Apple are all built on top of HTML. (This is by no means a definitive list of all HTML-based apps either.)
Some of these apps you might already use on a daily basis. The “uncanny valley” argument really comes down to UX design, and giving your HTML application a first-rate experience. If you do not invest in your user experience, it will not feel right. Some of these apps show up in Apple’s recommendation lists… would Apple recommend bad apps to us in the “walled garden” that they have worked so hard to curate?
Performance
Again, this is a question of using the right tool for the right job. You would likely not build a 3D modelling application using HTML/JS, but you could easily build a word game experience, an enterprise data reporting front-end client, or content-centric experience using HTML & JavaScript. There are things that you need to do to make sure your HTML-based experiences perform well, such as using touch events instead of mouse events (mouse events in web views can have an OS lag up to 3-400 MS, where touch events do not). Or, using CSS3 translate3D transforms to enable GPU-rendering on DOM content. Perception of an application boils down to creating a proper user experience. You can absolutely create a great user experience with HTML & related technologies, but I wouldn’t use it for super-computing tasks.
If your app requires intense data crunching for a computationally intensive task, you can always drop down to a PhoneGap native plugin to perform the heavy lifting for you.
Write Once, Run Everywhere
When was the last time you saw a computer or device that could not render HTML content? I have several devices at my disposal for work: 3 Android devices, 2 iOS devices, 1 Windows Phone, 1 Blackberry, and a Macbook. None of these devices is incapable of rendering web content. HTML is the most widely distributed and pervasive means of presenting digital information in a visual manner, and it has been around for decades.
The Right Tool
As mentioned in the original post, use the right tool for the job. Don’t force a solution that doesn’t fit, but also don’t over-generalize your technology decisions based upon incorrect assumptions. I can build a responsive layout with dynamic content far easier in HTML than I can in native Objective-C, but building a triple-A quality game isn’t even close to achievable in HTML. It all depends on context:
What are you trying to build?
Who are you building it for?
What are the UX requirements?
Who is building it, and what are their skills?
What is your budget?
There is no doubt or question in my mind – You can absolutely build incredible app experiences that truly feel like apps using web based technologies.
Adobe Shadow has been out for over a month now, and I’ve finally had a chance to start integrating it into my development workflow. Shadow is a new tool that provides you with a synchronized desktop & mobile browsing experience, and it even lets you inspect & modify the HTML DOM on the remote devices. Basically, you just connect the devices, then navigate your content on any of the connected devices for a synchronized browsing experience. Fellow Adobe employee Christian Cantrell has a great video overview of Adobe Shadow on his blog, if you’d like to learn more.
I’ve been focusing on multi-platform HTML-based solutions, especially with the app-UI framework/library. Shadow has become very handy when testing features on multiple devices. App-UI is a free & open source collection of reusable “application container” user interface components that may be helpful to web and mobile developers for creating interactive applications using HTML and JavaScript.
Basically, I just point the desktop Chrome browser at the page I want to test on my devices, and all devices will navigate to that particular page. Quick, easy, and to the point. Check out the video below where you can see the synchronized browsing experience in action.
In my examples that have browser history integration you can even see that selecting an item in the list causes all devices to navigate to the selected item (starting at 25 seconds into the video). It does not yet necessarily solve every issue around button clicks and scrolling, but it certainly helps streamline the testing of a single page/experience on multiple devices.
Ready for the new era in multi-screen development?
Available now on labs.adobe.com, Adobe Shadow is a new, free tool that enables synchronized browsing and remote inspection across desktop and mobile experiences, in real time.
Rather than having me try to describe it, check out this video from Adobe TV…
Adobe® Shadow is a new inspection and preview tool that allows front-end web developers and designers to work faster and more efficiently by streamlining the preview process, making it easier to customize websites for mobile devices.
Shadow will be updated regularly to stay ahead of web standards, web browser updates and support for new mobile devices entering the market, while incorporating user feedback to provide the best functionality and experience possible.
This version of Shadow focuses primarily on the following:
Device pairing
Synchronized browsing and refreshing in sync with your computer
Perform remote inspection and debugging so you can see HTML/CSS/JavaScript changes instantly on your device.
Be sure to keep up with the latest and greatest information on Adobe Shadow:
Here’s a quick preview of my new HTML5/PhoneGap data vizualization app. Once released, this will be available on multiple platforms, in multiple app stores, AND it will be completely open source. Just waiting on app store approvals…
You can expect a full writeup on how this was built after it is released.
In this series, I’d like to highlight Adobe’s mobile offerings, and the variety of platforms that can be supported from a single codebase. I wrote a simple URL Monitoring utility application that will check the status of various HTTP endpoints using the AIR URLMonitor class. I now have that application running on 3 OS platforms, in 4 ecosystems (5th coming soon), supporting phone and tablet interfaces, and all with a single codebase
Many Apps, One Platform
Here’s the official app description that I’ve been using:
URL Monitor is a simple diagnostic application that will allow you to quickly and easily monitor the status of various URL endpoints. Simply enter a URL into the text box and add it to the list. A polling HTTP request will be made every 10 seconds to determine the availability of a given endpoint. HTTP codes 200, 202, 204, 205 and 206 will be identified as a success with a green check. All other HTTP codes will indicate a problem as a red ‘X’. To remove a listing, simply perform a horizontal swipe on a given row to reveal a delete button. All monitoring is paused when the application is in the background.
This application is currently available in the following ecosystems:
You may be wondering, “How did you get a single codebase into so many markets?”… Well, you’re in luck. Here’s detailed instructions how to get from Flash Builder into each Ecosystem:
Flex/AIR on Devices: From Flash Builder to BlackBerry App World (coming soon)
What’s really interesting about this is the activity that I have seen on each market. The application is free on each market, and became available over the last few weeks. I have done absolutely no promotion of it… This is the first announcement that I have made.
As of 9/15/2011, the application has been live in Apple’s store for 3 weeks, and has had 554 downloads; it has been live in the Google Android Market for 3 weeks, and has had 20 installes (only 11 active); it has been in the Amazon market for 2 weeks, with 0 installs (yes, that is a zero); and surprisingly, it has been on the Nook store since Sept 1, and has had 816 downloads! Now, that was unexpected.
With the default settings, the Flash Builder (and the Android SDK) will not be able to detect you nook device as an Android tablet. In order to be able to deploy via USB, you must first register as a nook developer at https://nookdeveloper.barnesandnoble.com/, and also be sure to download the Android SDK from http://developer.android.com/sdk/index.html.
Once you are a registered developer, you will have access to tools that enable you to put your apps onto a nook device. First, you must download and install the Nook SDK add-on to the Android SDK.
Nook SDK Setup
This will download and install the Nook SDK. Once installed, the installation process will need to restart ADB. Click “YES” and allow it to proceed through the restart process.
Nook SDK Setup - Complete
Once you are a registered developer, you will have tools accessible to enable “Developer Mode” on your device, which allows you to provision the device for development. Go to the “Developer Mode” section of the nook developer portal and enter the device names and serial numbers for your dev devices. From here you will be able to download a provisioning file.
Nook Developer Provisioning
The provisioning file will allow you to deploy applications directly to the nook via USB. Attach the Nook Color device to your computer via a USB connection. The Nook Color device will show up as a device in Finder. Copy the provision.cmd file that you downloaded from the “Developer Mode” provisioning portal directly into the root of the Nook Color device.
Nook Provisioning File
Next, eject/unmount the Nook Color device. Now, use the tools within the Android SDK to restart ADB (Android Debug Bridge):
./adb kill-server
./adb start-server
Once ADB has restarted, use the “adb devices” command to list all connected Android devices (The Nook Color device must still be connect via USB, even though it has been unmounted).
./adb devices
You should see your device listed in the output:
ADB - View Device
Now that you are able to view your Nook Color device using ADB, Flash Builder will also be able to deploy to it. You will be able to Run/Debug directly from Flash Builder and launch applications on the Nook Color device. This follows the normal Flash Builder debug process.
However, there is one trick… you may notice that if you go to the “apps” menu on the Nook color, you won’t see any of your applications deployed via USB. Don’t fret… they actually are on your device. There is just a trick to view them. From the “apps” menu, click on the “archived” button. A popup will be displayed here. Now, press and hold the “volume up” button. When the speaker appears on the screen (continue holding the volume button), tap on the speaker. When you tap on the speaker, the “extras” screen is displayed. (You can release the volume button now.) The “extras” screen will list all of your manually installed applications, and you will be able to re-launch your installed apps.
From here, you can generate your release-build APK as you normally would from Flash Builder. Once you have your APK generated and tested, you’re ready to prepare it for the Nook Store. Sign into the Nook Developer Portal, and go to the “Applications” section. Click on the “Add New Application” button.
First, you will need to enter the primary metadata for the application (name, type, price, version, etc…).
Nook Portal - New Application
Once you have completed the basic information, click on “Save and Continue”, and you will be redirected to the “Description & EULA” tab. Enter an application description and an optional license agreement (I left this blank b/c I do not have any special terms for my app).
Nook Portal - App Description
When ready, click “Save and Continue” to enter the “Keywords and Category” tab. On this screen, enter descriptive keywords and categories to help categorize your application within the Nook store.
Nook Portal - Keywords & Category
When you have your categorical information all set, click “Save and Continue” to proceed to the “Icons & Screenshots” screen. Here you will need to set the application icon and add application screenshots.
Nook Portal - Media & Images
Now this is where the application approval process is a little different from other app stores. You need to click “Send for Application Approval”, and the application metadata must be approved before you can upload a binary APK file.
Once the application metadata is approved (this took about a week for my app), you will be able to upload the APK binary.
Nook Portal - Upload Binary
After you have uploaded and submitted the binary APK file, the binary file will need to be approved before it is actually available within the Nook store. The binary approval took another week+, so the overall approval process took over 2 weeks. Once approved, your application will appear in the nook store, and will be ready for public consumption!
First, navigate to https://developer.amazon.com/ and click on the “Amazon Appstore for Android” link. Once there, you will need to walk through the full registration process to create your account.
Amazon Appstore Landing Page
Once you click on the “Get Started” button, you will be guided through the Appstore registration process. Once that is complete, you will be directed to the Appstore developer portal home page. From here, just click on “Add a New App”.
Amazon Appstore Home
Next, you will being the App upload wizard. First, you will need to enter primary metadata for the application, including a title, form factor, supported languages, and contact information. Once you have entered this information, click on the “Save” button.
Amazon Appstore App Metadata
Next, you need to enter merchandising information. This includes the app category, keywords, a description, price, and release/availability dates. Once you have completed all of your merchandising information, click on the “Save” button to proceed.
Amazon Appstore App Merchandising Info
Next, you will have to specify content rating information. Just fill out the information about your content, and click on the “Save” button to proceed. I didn’t run into any content rating issues in the Amazon Appstore, like I did with the iOS App Store.
Amazon Appstore App Content Ratings
Next, upload multimedia that will be associated with the application. This includes application icons (note: they must match, event though this screenshot doesn’t show it – I was rejected b/c of this), and actual screenshots of the application.
Amazon Appstore App Multimedia
Scroll down to see more of the “Multimedia Content” form. You will also be able to enter promotional images and promotional video assets for your application. Once you have uploaded all necessary multimedia, click the “Done” button.
Amazon Appstore App Promotional Media
Now you are ready to upload your APK Binary. Follow the instructions for uploading an APK file. Once it is uploaded you will see information about the file that was uploaded.
Amazon Appstore App Binary
Finally, click on the “Submit App” button to submit your application for approval. There is an approval process for the Amazon Appstore similar to Apple’s, and my application was live in less than a week from submission.
First, navigate to market.android.com/publish/signup to register for an Android Market account. Once there, you will need to walk through the full registration process to create your account.
Android Market Registration
Once you are fully registered, you will be directed to the Android Market publishing home page/dashboard. From here, just click on “Upload Application” to start the process of uploading your application’s APK binary file.
Android Market Dashboard
Once you have successfully uploaded the application APK, you will be prompted with the details about your application. Click “Save” to being entering application metadata information.
Android Market APK Uploaded
You will need to upload at least 2 screenshots of your application, as well as an application icon for use within the Android Market.
Android Market APK Metadata
Next, scroll down to the “Listing Details” area and begin entering metadata for your application. This includes an application title and description, as well as release notes, classifications, and promotional text.
Android Market APK Metadata - Description
Next, scroll down to the “Publishing Options” screen, where you can configure copy protection settings, content ratings, pricing, and available markets.
Android Market APK Metadata - Pricing and Markets
Finally, enter your support/contact information and check the consent checkboxes.
Android Market APK Metadata - Contact and Consent
Once you have completed the form in its entirety, scroll back up to the top of the page and click on the “Save” button to save content, or “Publish” to save and publish the application to the Android Market. Once you have successfully published it, your application will show up in your home dashboard, as shown below.
Android Market APK App Ready
Thats it! The Android Market makes it extremely easy to publish your application. My application started showing up in the market after about 30 minutes from pressing the “Submit” button.
You can check it out live in the Google Android Market at:
In this post, we will cover the workflow for delivering a solution from development in Flash Builder through packaging for various Android ecosystems. In subsequent posts, this will be followed up with detail for delivering to each individual ecosystem.
You can start developing apps for Android using the debugging simulator built into Flash Builder. However, a critical step in your development process is that you must test and evaluate your applications on a physical device (preferably before you try to ship it). Luckily for all of us, that is really easy with Flash Builder.
First, develop your mobile application. When you are ready to test it on a device, simply go to the “Debug” menu and select “Debug Configurations”.
Debug Mobile Application
Next, create a new debug profile, select the platform “Google Android”, and select the “on device” debugging option with “debug via USB” selected.
Debug Configuration
Make sure that your test device(s) are plugged in via USB, and then hit the “Debug” button. Using this approach, you can deploy to any Android device that has USB Debugging enabled. This applies to phones and tablets… to enable USB debugging, you just need to go to Settings -> Applications -> Development, and then select the checkbox to enable USB debugging. You can also use this method to debug on a Nook Color device, however you must have it unlocked already via your Nook developer account.
Once you have developed and debugged your application, you are ready to export it for real world consumption. The first thing you need to do is specify you applicaiton name, version and id in your app.xml file. Be sure that these are the final values, as the application id will be the unique identifier for your application in all marketplaces and if you distribute the APK manually.
Application XML Configuration
Once your application configuration is finalized, you will be ready to actually export the project. Right-click on your project in the package explorer and go to the “Export…” option. You can also perform the same action by going to the File -> Export menu.
Export Menu Options
Next, select the “Release Build” export option, and click “Next”.
Export Release Build
Set your export folder, and a base filename for the output file(s), be sure to select the target platform “Google Android”, and export as “Signed packages for each target platform”. Click “Next” to setup your platform signing options.
Export Release Build Options
For Android, you can use a purchased signing certificate, or use a self-signed certificate. Just use the browser button to locate your signing certificate, or click “Create” to crate a certificate.
Export Release Build - Platform Signing Options
If you create your own certificate, the following window will be displayed. Just enter a publisher name (your name), a password, and a file location. Next click “OK” and the certificate will be created and you will return to the Platform Signing Options screen.
Self Signed Certificate
Next, click “Finish” and your APK file will be generated.
Export Release Build - Platform Options
Now that you’ve generated your APK binary file, you are ready to push to the various app stores… Let’s take a look at this process for each ecosystem:
In this post, we will cover the workflow for delivering a solution from development in Flash Builder through publishing in Apple’s App Store.
You can start developing apps for iOS without an Apple developer account by using the debugging simulator built into Flash Builder. However, a critical step in your development process is that you must test and evaluate your applications on a physical device (preferably before you try to ship it).
To get from Flash Builder onto an iOS device, the first thing that you will need to do is create a developer account with Apple and setup your signing certificates and mobile provisioning profiles. To register for a developer account, visit developer.apple.com and walk through the registration process. Note: You can register for free, but you can’t access any of the iOS deployment tools without the paid enrollment into the iOS developer program.
After you have an active iOS developer account, you will need to create a signing certificate and distribution profiles. From the iOS developer center’s home page, click on the “iOS Provisioning Portal” link as shown below.
iOS Developer Home
Next, click on the “Certificates” link on the left side of the screen, as shown in the next screen capture. This will direct you to the certificate management area.
iOS Provisioning Portal
If you are only concerned about developing and not about distribution (or if you are not the iOS account team agent and can’t access distribution profiles), then you simply follow the steps for creating a development certificate.
If you will be distributing your application in the app store, via the enterprise distribution model (if you qualify for the enterprise program), or if you will be using ad-hoc distribution, then you will have a “Distribution” tab, as shown in the screen below. Distribution certificates are required for distribution profiles. Go ahead and click on the “Distribution” tab and follow the instructions for setting up a certificate. You will need to create a certificate signing request through Keychain Access, and then you will need to submit it through the Apple developer portal.
iOS Provisioning Certificates
Once you have successfully created a certificate, it will display under your “Current Distribution Certificate” heading within the “Distribution Certificates” tab, as shown below.
iOS Provisioning Certificates - With Certificate
Download the certificate and either drag or import the “distribution_identity.cer” file into the Keychain Access application. Once you have imported it, you should see the profile listed. In the next screenshot, you can see that I have selected my “iPhone Distribution” certificate. You will need to export the certificate to a .p12 file so that it can be used by Flash Builder. Just select the certificate at the root level (be sure to not just select the key). Next, go to the file menu and click “Export Items” and save the certificate to a file.
iOS Provisioning Certificates - With Certificate
Obviously, I’m showing these steps on a mac. To create a certificate on Windows, follow the instructions available here.
Once you have created your signing certificate, you’ll next need to obtain your provisioning profile from Apple, in order to be able to actually deploy on any iOS devices. If you are only using your registered iOS devices for local development and do not plan to distribute your application yet, then you can go to the Provisioning section of the iOS developer portal and download the development “Team Provisioning Profile”. Click on the download link and save you .mobileprovision file locally, and then proceed on to setting up your debugging environment.
Download Development Profile
If you will be distributing your application, then you will need to first create an application ID. All distribution provisioning requires an application ID. Within the iOS Provisioning Portal, click on the “App IDs” navigation on the left sidebar, and then click on the “New App ID” button on the right side of the screen.
Create Application ID
From here, you need to create the actually application ID. You need to enter a description (what you commonly refer to the app as), and enter a bundle identifier. For the description on my application, I entered “URL Monitor” for my description , and the bundle identifier is “com.tricedesigns.URLMonitor”. The bundle identifier is the unique reference to your application.
Create Application ID
Once you’ve create an App ID, next you will need to create a distribution provisioning profile. Click on the “Provisioning” navigation item on the left sidebar, and then click on the “Distribution” tab across the top. To create a new distribution profile, click on the “New Profile” button on the right side of the screen.
New Distribution Profile
Next, select your distribution type. For most of us, this will only contain “App Store” and “Ad Hoc”. For developers who have access to the enterprise developer program, there will be a third “Enterprise” option. Note: “Ad Hoc” distribution means that you can only distribute to a limited number of devices; all of which need to be registered within your developer account. Give your distribution profile a name (I called mine “URL Monitor App Store”), and select the application ID that you just created. Once you click submit, the distribution profile will be created.
Create New Distribution Profile
Once created, download and save the .mobileprovision file for future use.
Download Distribution Profile
Debugging:
First things first, let’s cover debugging. I mean, c’mon… you can’t distribute an app if you haven’t debugged it first… right? To debug, go the the debug menu and select the “Debug Configurations…” option to create a new device configuration.
New Debug Configuration
Select the target platform “Apple iOS”, and then select the “on device” launch method.
Debug Configuration
From that same screen, cick on the “Configure packaging settings” link to show iOS signing options. In the screen shown below, select the .p12 certificate file that you created earlier, and select the debug .mobileprovision provisioning file that you also just downloaded.
Apple Debug Settings
Click “Apply” to save these settings, then click “OK” to close this dialog. You will be returned to the “Debug Configurations” dialog, and you can now click “Debug” to actually debug your application on your iOS device. Flash Builder will not automatically deploy to your device. It will create an IPA file, which you will need to drag into iTunes, and then synch your device to deploy it. However, you can still actively debug your application over the local network, directly within Flash Builder.
Deployment Packaging:
First things first, setup your application’s metadata within your app.xml file. In particular, you will need to specify an application name, version number, and ID. The ID MUST match the bundle identifier that you specified when creating the App ID through the iOS Provisioning Portal, and the version number must be a valid number.
Flex Project App.xml
Next, right click on your project and select the “Export” menu option, as shown below:
Export
Select the “Release Build” option, and continue the wizard steps:
Export Release Build
Next, you will need to specify the export location (“export to folder”) and enter a filename. Also, be sure to have the “Signed packages for each target platform” option selected.
iOS Export
Next, you will need to configure your distribution options. Specify your certificate (.p12) file location, your provisioning file (.mobileprovision) location, and select the correct package type. If you use an App Store or Enterprise provisioning profile, select the “Final release package for Apple App Store” option. If you use an Ad-Hoc provisioning profile, select the “Ad hoc package for limited distribution” option. Keep in mind that you must provision specific devices in the Apple App Store before creating the build. Next, click “Finish”, and out will come an IPA file ready for distribution. Note: If you are using a developer certificate, you will not be able to distribute an IPa file.
iOS Export IPA
Distribution:
If you are using Ad Hoc distribution, you can now simply send the IPA file to your users, and they will be able to deploy the application to any provisioned devices. If you are using the enterprise provisioning option, you can just send the IPA without worrying about specific device IDs. However, keep in mind that you can only distribute those files according to Apple’s rules surrounding the Enterprise deployment model.
If you’ve be “chomping at the bit” to upload your application to Apple’s app store, then this next section is for you. First things first, you must go to iTunes Connect to setup your application with the App Store. Simply navigate to itunesconnect.apple.com and l0g in using the same credentials that you used for the iOS Portal. iTunes connect allows you to manage and monitor your applications, including sales trends, #downloads, etc…
To get started,click on the “Manage Your Applications” link shown in the screenshot below:
iTunes Connect - Home
You will be brought to the “manage” screen; from which you can edit metadata for all of your applications. To create a new application, click on the blue “Add New App” button in the top left corner.
iTunes Connect - Manage Apps
iTunes connect will now walk you through a series of questions that will provide appropriate metadata for your application. First, select your language, and enter your company name. If you are submitting as an individual (not a company), just put your name.
iTunes Connect - New Application
Next, you need to create the primary metadata about you application: The application name, the sku number (stock keeping unit), and select the bundle identifier. Make sure you select the bundle ID that matches your App Store provisioning profile. DOUBLE-CHECK THIS SCREEN TO MAKE SURE IT IS CORRECT! Once submitted, the bundle ID information cannot be changed. When you’re absoultely sure it is correct, click on “Continue” to proceed.
iTunes Connect - App Information
Next, enter the availability date and pricing for your application. Keep in mind that the availability date only applies after the application has been approved by Apple. If you back-date this, it will not speed up your time into the app store. When ready, click “Continue” to proceed.
iTunes Connect - Availability and Pricing
Now, enter the primary metadata that describes your application. This includes the version number (try to keep this in synch with your app.xml in your Flex project for organization purposes – although not required to match), description, primary and secondary categories, keywords, contact information, and review notes (for the team at Apple that will review your application).
iTunes Connect - Primary Metadata
Next, rate the content within your application. Apple will verify your app against these ratings, and if they do not match, your app will not make it into the app store. Mine was actually rejected for this… No, I do not have crude content in this case. For example, if you provide unrestricted access to the internet, such as allowing a user to type in any URL, and you show that content via a stageWebView, then you are rated 17+. No “ifs”, “ands”, or “buts”. My only options were to remove the unrestricted access (remove stageWebView), or to have the app rated 17+. I chose 17+. Don’t be confused by this though; If you use StageWebView, that doesn’t mean your app will always be rejected – this is only b/c I had unrestricted access to the StageWebView control. In my app, you can enter any URL, and click on the “view” button to view the content of that URL.
iTunes Connect - Content Ratings
Next, upload your application images. The large icon is 512×512, and the phone screenshots should match actual device resolutions. Note: Your main “large icon” must match the one embedded in your application – I also got rejected b/c it didn’t match initially, as shown in the screenshot below.
Image requirements from Apple:
iPhone and iPod touch Screenshots must be .jpeg, .jpg, .tif, .tiff, or .png file that is 960×640, 960×600, 640×960, 640×920, 480×320, 480×300, 320×480 or 320×460 pixels, at least 72 DPI, and in the RGB color space.
iTunes Connect - Images
Hit “Continue” to save all of your changes, and now you are ready to start uploading your application binary. Click on one of the “Ready To Upload Binary” buttons on either the top of bottom of the screen to move the process along…
iOS Distribution - Ready to Upload
Once you click on the “Ready to Upload” button, you will walk through several questions around export compliance and encryption. Answer these questions, then hit “Save” to proceed.
iOS Distribution - Export Compliance
Once you have completed all of the questions, your application will now be ready to upload. After this point, we will be leaving iTunes Connect, and jumping to the OSX desktop to actually upload the application.
iOS Distribution - Application Ready to Upload
Now, we are ready to upload the application. In OSX, launch the “Application Uploader” program, which is a part of the XCode developer tools. When the application loads, you will need to sign in using your iOS developer credentials.
iOS Provisioning Certificates - With Certificate
Upon login, the Application Loader tool will allow you to chose which application you want to upload a new build for. Choose the desired application, and then click on the “Next” button.
iOS Provisioning Certificates - With Certificate
The Application Loader tool will display metadata about the application that you have selected, and you will need to choose an IPA file from your local filesystem for distribution. Be sure to select your release-compiled, App Store provisioned IPA, or else the upload process will fail.
iOS Provisioning Certificates - With Certificate
Once you’ve selected the IPA file, click “Send” to being the upload process.
iOS Provisioning Certificates - With Certificate
After the upload process is complete, there will be a verification step, and then you will receive a message “Uploaded package to iTunes Store”.
iOS Provisioning Certificates - With Certificate
Click “Next”, and you will be presented with a “Thank You” message, and the upload process is done.
iOS Provisioning Certificates - With Certificate
Now, comes the Apple approval process. Generally, this takes about a week for new applications, and only a few days for application updates. However, there are not guaranteed timelines. Once the application is approved, it can be ready for immediate consumption within Apple’s App Store.
You can check it out live in Apple’s App store at:
Recent Comments