App Store Deployment
This is the fifth and final post of our five-part series on Android vs. iOS development from our microProduct Lead, Mark Oldytowski.
Now we’re in the home stretch: your app is finished and tested, so it’s time to get it out in the store. Of course, before you get to see your app out in the world, you’ll have to do a decent amount of prep work regardless of which platform you are releasing on. Both Android (Google Play) and iOS (iTunes) require you to sign up for an account and pay a yearly fee to be part of the developer network for distributing apps. Apple takes the account verification portion much more seriously, requiring a tax id number even if you aren’t selling the apps, and also vocal confirmation that you are who you say you are. All in all, it will take a day or two to complete the Apple developer account process due to the verification and getting your paperwork in order, while the Android store account is only a fraction of that due to its less stringent nature.
Speaking of stringency, one of the biggest differences between releasing an app for iOs vs. Android involves the review process for each release: In a nutshell, Apple has one, and Android does not. The Android Marketplace is the wild west of app stores, anything goes initially, and it isn’t until you do something really, really wrong (upload viruses, steal info, etc.) that they run you out of town. The advantage of this is that you can get new releases and patches out almost instantly, no need to wait on a review process or worry about your app being rejected (unless you fail the code validation process). The disadvantage of this is that there is also a lot of junk on the store, and users are less trusting of apps from unheard-of developers. On the Apple front, submitting your app puts it into a review queue, and it could be anywhere from one day to two weeks or more (average wait time seems to be about 8 days) for it to begin the review process depending on how busy Apple is, the type / size of the app, technologies used, data being shared, etc. This does provide a decent barrier to entry for keeping the junk apps out, but can be annoying if you have to get a critical release out or if Apple decides to reject your app due to a terms of service violation (which will happen eventually, they seem to change it every few weeks). Care must be taken on the Apple side to stay up to date with the rule changes to try to mitigate the app rejection scenario.
Another note about Apple changing the terms of service for the developer program: sporadically they can cause mysterious deployment errors and crashes within Xcode. There was an occasion where I was trying to deploy a build for release to iTunes, but during the verification process Xcode would hard crash with a segmentation fault and no additional information. I spent hours retracing all of my steps, checking out the build configuration to make sure I hadn’t changed anything, and then searched endlessly on the support forums to see what was going on. Turns out, Apple had updated their terms of service and required you to hit “Agree” in iTunes Connect (completely independent from Xcode) on the new policy. How anyone would know these two issues are related is beyond me, and it becomes a major problem when you are trying to hit a release deadline and these kinds of issues crop up.
Now to get back on topic, both Android and iOS will require you to create the app description page prior to submitting it to the store. These details are similarly straightforward on both services (name, description, cost, keywords, available regions, etc), with Apple just requiring a little more in the fact that you have to supply specific screenshots and icons for each device size you support while Android lets you get away with more generic sizes. On the Apple side, you will also have to provide information for the tester to use during the review process if it’s relevant to your app, such as account login information. Once the app listing is completed and the app is ready for submission, you will need to do a packaged release build within the IDE to submit it. For Android, simply generate a signed APK in Android Studio, upload it to Google Play, hit submit and your app is in the store within about an hour. Apple keeps this part fairly simple as well, but with the slight advantage of having Xcode integration with the app store so you can submit your build directly from there (assuming all of your certs and provisioning profile information is correct and the bundle identifiers match perfectly). Once you submit your build, just go back into iTunes Connect, select the build for release, press submit and then wait about a week to get it out into the store. Make sure everything on the Apple side is ready to go when you press submit, as re-submitting a new binary, even prior to review, will put you back to the end of the review line. Submitting patches apps on each system is very similar to new releases, so you will have the same week delay on the Apple side unless you can get them to expedite the review process (which doesn’t happen often). With each new version of iOS, there is a mad dash to submit app updates, often due to Apple changing framework features, so it’s best to be prepared with patches as far ahead of time as possible.
One final note on the store side: while Apple only has one app store available on its devices (jail-broken devices not included), the hands-off approach to Android has lead to multiple 3rd party stores popping up. The other big player on the Android market, Amazon, has it’s own app store for it’s Kindle devices, which requires a another account / submission process (and potentially new build) to become available on those devices. In addition, many smaller companies have started up unofficial app stores, which require the same. It’s nice to have the option out there to add some competition (leading to cheaper prices, etc.), but it becomes higher maintenance to keep track of the different stores and keep the release updated on all of them at the same time.
| Android | iOS |
| + Lack of review process gets apps and patches out quickly | + App reviews promote some quality level for apps, reducing junk apps |
| – Junk apps in the store cluttering things up for everyone else | + Single app store keeps things simple |
| – Segmented app stores cause higher maintenance | – Review process can be lengthy, especially for critical patches |
| – Constant terms of services updates cause rejections and odd issues. |
And Finally….
After that long, essay-like analysis between the two platforms, one feature sticks out in my mind as the reason I would pick one OS to develop on vs. the other: device segmentation. The IDEs and app stores are comparable, the frameworks have similar features, and language-wise, I can eventually get the same work done on both platforms, but what I can’t get past is the testing time involved in creating an Android app that actually works universally. It might be easy to get 95% there, or even 99%, but there will always be that oddball device out there that will cause you issues, and from a software engineer’s perspective, that is a tough issue to get past. Plus, with the terrible performance of the Android emulators, you would need physical devices for each screen size you test on, which will get pretty expensive. For all its problems, at least iOS is fairly consistent across all its available devices (for now). It has never taken more than a few hours to adjust for all of the available screen sizes, and performance for a run of the mill app is decent enough on all devices.
Read Part 1: Development Environment and Project Setup
Read Part 2: Language and Framework Features
Read Part 3: UI Design Tools and Controls
Read Part 4: Testing and Debugging
Download LMK
Download PubRally
Download Quack-a-pult