Think your app is ready for prime time? In this quick tutorial you'll work through a pre-publication checklist. Learn about the tasks you need to complete before your application is ready for the Android Market.
There are a number of hurdles—some mandatory, some optional—that developers must overcome before their apps are ready for users. Today we investigate some of the decision points that must be considered prior to uploading your application. Once you’ve addressed these issues, you’ll be ready to move on to publish at specific venues, like Android Market or the Amazon Appstore for Android.
Step 1: Start with a Solid Application
Really, if you ask any developer what their end-game is for app development, just about every mobile developer will tell you that they just want to create a killer app. But when you ask a developer what makes a killer app, you’ll get lots of different answers—awesome concept, well executed, unique, well marketed, etc.
We like to think killer apps are like fine cuisine. Lots of different techniques can be used to prepare and serve a tasty meal, just as there are many ways to achieve killer app fame. And as any good chef knows, you’ve got to start with good ingredients. With Android, this means that you’ve got to start with a solid app.
Solid apps have the following characteristics:
- Complete: the app has all the appropriate features implemented
- Secure: the app treats private user data appropriately (secure connections, etc.)
- Responsive: the app responds readily to the user, no matter the situation
- Efficient: the app’s performance is the best it can be
- Seamless: the app’s workflow is fluid and natural
- Highly Compatible: the app looks and behaves reasonably, regardless of the type, size, model of device, or country it will run in (within developer-determined goals)
- Thoroughly Tested: the app has been tested extensively and under a variety of real world conditions, on real target devices
- Live: the app is using live (not test/sandbox) servers, services, and certificates
Many of these characteristics have thresholds that must be set by your specific development team requirements. We’re certainly not saying you should hold off releasing your app because you have ideas for new features in the future, only that when you do release, you should ensure that you are providing the user with a whole package: a professional, high quality piece of software that stands on its own two feet. . .Well, this is Android, so I guess it should stand on its own two little green stumps!
Consideration #1: Collecting App Statistics
Consider what sorts of information would be helpful to collect once your app is released. Regardless of where you plan to publish, you will want to know some really basic information, such as how many people have installed your applications. Most Android publication sites will provide you with this sort of data, but not much else. Before you release your application, you may want to consider adding some statistics gathering hooks to find out about your users, as well as when, how, and where they are using your app.
For statistics gathering, you’ve got a number of options:
- [Easiest] Leverage an existing statistics-gathering service, like that provided with the Google Analytics SDK for Android. Biggest benefit: easy, well established. Biggest drawback: flexibility, and services like Google Analytics were initially designed for websites, not mobile apps
- [More Challenging] Roll-your-own statistics gathering solution and build it straight into your application. Biggest benefit: design flexibility, gather as much or as little information as you like. Biggest drawback: a tenuous trust relationship with your users that you must manage yourself
Consideration #2: Protecting Your Intellectual Property
Mobile apps are vulnerable to a variety of different enemies. Software piracy is a legitimate concern, so you’ll want to consider taking measures to make your app a not-so-easy target for these bad guy and girls. Here are some options you might consider for protection, all of which require some degree of code changes:
- [Easy] Enable ProGuard within your application project to obfuscate your code.
- [Easy] Keep your IP to yourself. Modify or obfuscate any generic code or algorithms used and make them uniquely yours. Remove any unused or unnecessary intellectual property from the app to limit your vulnerabilities.
- [Easy/Moderate] Perform a thorough security review of your application. This should include a review of any application servers or cloud services your app relies upon as well.
- [Moderate, Only Available for Paid Apps using the Android Market] Use the Android Market Licensing service to validate and enforce reasonable licensing policies with your application.
- [Moderate] Roll-your-own licensing service to validate and enforce reasonable licensing policies with your application.
Also, although not directly related to protecting your app, there have been some indications that have shown that applications which provide reasonable freeware or trial-ware versions are less likely to be hacked. Consider including a limited version of your application for users as a try-before-you-buy option. Along similar lines, you can make your application free, but use in-app billing APIs (available only on Android Market) or use alternate methods of collecting payment to enable features.
Consideration #3: How Are Users Going To Get Your App?
Most developers don’t decide how they’re going to publish their application as part of the design process—they just know they’ll publish eventually. Many think first of the Android Market, but there are certainly numerous publication opportunities out there. However, this decision needs to be considered before your final release build for a number of reasons, including:
- Each app store has its own policies and requirements in terms of content, etc. In order to conform to each app store’s policies, app code changes may be necessary. Note: This is certainly true of the Android Market, which uses Android manifest file filters to limit which devices your app will reach, amongst other requirements.
- If you’re planning to self-publish, you’ve got some extra legwork to do to determine how you are going to host and distribute your app (email, website, etc.)
Consideration #4: Where Are You Going to Publish Your App?
Just as developers often don’t decide how they’re going to publish, they also often don’t consider where they're going to publish. If you’re planning to publish your application internationally, here are some considerations before you do that final build:
- You should consider localizing your application by providing alternative resources to support different languages and dialects.
- Your app needs to be law-abiding. This means your app needs to comply with the rules in each country you publish in, and it needs to comply with international and export laws. Common problem areas in terms of the law involve encryption algorithms, inclusion of risqué content, financial information storage, and private user data transmission. It’s your responsibility, not the app store or publisher, to comply with law.
Consideration #5: Money Matters
Believe it or not, many developers don’t decide about whether or not their app will be free or paid until after it’s written. While this may work for some developers, it doesn’t work well for everyone. Here are some issues to consider:
- If you’re going to release a paid app, will you provide a limited freeware version as well? These applications will need to be managed separately.
- If you are planning to include ads in your app, then ad-based services require some extra coding on your part.
- Apps that want to leverage billing services like Android Market’s in-app billing framework will require moderate changes to the code.
- At this time, paid apps are only distributable to specific countries within the Android Market. If your app is a paid app, there’s less incentive to spend the valuable development time internationalizing your app for unreachable market sectors.
Consideration #6:Planning for the Future
Give a little thought to how you’re going to maintain and update your application. To some extent, this involves setting user expectations about your application. It also involves getting out your crystal ball and thinking ahead a bit.
- Is the app a beta or demo? If so, make this clear in the application and its marketing materials to set user’s expectations appropriately.
- Do you want users to be able to contact you directly with feedback? If so, include this as a feature in the app itself, or, at minimum, provide contact details.
- Review the areas of your application that are likely to change when upgrades occur. For example, review the version information of the application, as well as any underlying content provider or database versioning. You will also want to consider versioning any applications server or service protocols your application leverages, as these often change as time goes on.
- Finally, for your company’s sake, don’t forget to gather or produce all the appropriate documentation for your maintenance team (frequently, this won’t be you).
Bonus: Planning TutList
If you've been following along with all of our Android tutorials here on Mobiletuts+, you might be familiar with the tutorials that are working with the TutList application. How does it fit into the checklist for publication? Is it ready to publish? Over the next several tutorials using TutList, we will implement some of the solutions discussed in this tutorial for the TutList application.
There are a number of issues you need to address before your application is truly ready for publication. Successful releases start with a solid app. Then you must consider how you will distribute, manage, protect, and maintain that app. Once you’ve got a handle on these issues, you’ll be in a good position to “go live” and upload your application to the Android Market with the best chances of success.
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.Update me weekly
Envato Tuts+ tutorials are translated into other languages by our community members—you can be involved too!Translate this post