You got an idea, which you are really excited about and believe in. After initial market research to validate the idea, understanding target users and developing business strategy, you get around to decide the Tech stack. With whole world going “mobile first“, you decide to make Android version followed by iOS. This article is majorly focussed for indie developers and startups with low market budgets, might not be fully suitable for ‘big-fish-in-the-pond’ companies, having thousands of dollars for development.
This posts deals with following proper practices during App development . If the foundation is strong, the building is strong and does not shake. Below are some of the pointers to be taken care of while developing app . I have learnt them by faulting at them myself, delaying app launches and development cycle. Don’t want others to do the same mistake I did. Following proper practices builds your confidence and sense of pride in your own product. This will help you go ahead and pitch your product to users and investors with head held high. #Be-Your-Products-No1-Promoter. I will explain this in detail in part 3 of the article why this is important.
1) Do Testing. Period.
- Cannot stress this enough. A major reason reason for force close and ANR is lack of proper testing. Test-driven-development is advisable even if you are working alone/ Hackaton mode. Agreed, takes more time and you could have built some other feature in that time. But get over this irritation and write tests.
- Uses : Test makes the code modular and results in better code maintenance, readability, cleanup and refactoring. Also, it helps to add new features faster and with confidence. Keeps the development cycle fast and helps in updating. Force close is something which we cannot afford to have.
- preferably use dependency injection. Roboguice is supposedly the best.
- Combination of roboguise + mockito + roboelectric
- For all the developers out there. Respect design. Its a major part of app, something which will make or break the game and put you above the rest of the apps.
- Follow android design guidelines more or less, few tweeks here and there are fine till you can justify them .Try innovative gestures.
- Make sure your design is awesome. I am not a designer so cannot go into details . Its better to get in-house designers that to put it off on a designing firm, who give limited number of iterations and give you more BS than doing real work.
3) App Permissions
- Only use permission which are required. Never have shady permissions like “retrieve running apps” ,” phone identity ” etc in app till user can either see clear use of it. Dont forget to explain on the market if any out of line permission is being used otherwise it leads to bad ratings.
4) Project Development Tricks
- Soft Launch app with different name and publisher account .
“Matt Brezina, Founder of Sincerely
This is a great observation Andrew. One thing we did was launch 2-3 versions of our product under a different apple account, without our personal names on the app, before we launched Postagram. When we did a PR launch the product was basically just a branded version of our work from the past 4 months; we knew it would function well and we knew users would love it. Since then we’ve never spent more than 4 weeks developing a release. And we particularly use Android for quick experiments – the apple 1 week app approval delay can really slow down the iteration cycles – that, and the difficulty in doing a/b tests are my least favorite things about the current mobile development environment.”
- use Android to prototype since the updates are easier.
“Kenton Kivestu Senior PM, Mobile Poker at Zynga
Part of the solution is to develop / test features on Android where you don’t face the rigor or delay of the Apple approval process. Also, I think Kieran’s point is valid as well. Apple may have a high quality standard but there is no inherent reason that you need to spend 6 months developing something to get Apple approval. The 6 month development time is probably more indicative of feature creep, broad scope, testing too many things, over-polishing, etc.”
- Test your app initially in another geography so that you can get things right. That might be Canada or New Zealand, where you have high smartphone penetration and an English-speaking audience that’s similar to the US.
- Strong, iterative product management
When we push daily on the web then why not for mobile? Try and have daily pushes and weekly releases.
- Minimal Viable Product
What is enough? This might require another post, but one thing I can clearly agree with Andrew Chen – “Simple but polished v1 app.”
source of above quotes on mobile project management are from Andrew Chen’s blog post .
5)Understand market/user better doing the ‘real’ launch to improve app
- A/B testing
with new functionality in play store developer console to release update to only a set of users before launching .
Use TestFlight for distributing and beta testing before launching app in the market for real.
- Event tracking to understand user – Several easy to integrate tools can help with this, including Flurry (free and recommended for its UI), Mixpanel, and Google’s event tracking (free). Measure the engagement levels, average sessions, clicks to identify hot areas.
- Feedback mail – Ensure that there exists mechanism for users to give feedback. This can lead to great insights, ideas for new features etc.
6) Advertisment – Don’t be intrusive
- True, user is not paying you for using app, but don’t make it sin of his life by bombarding him with advertisements at wrong places like near buttons or sudden full screen pop ups.
- If you are using admob, don’t try to be smart with them and follow guidelines or your account might get banned. Been there :P Took almost 15 days to revoke it back resulting in lots of loss. In most cases, they never revoke it back.
7)Maintain Single APK for all devices – avoid fragmentation
- Play Store uses total number of downloads as important metric in ranking algorithm. Also, having different versions of apk for different android devices of density and size(fragmentation) reduces the count of downloads. Ensuring your app is available on as many devices as possible, serving all devices from the same APK file.
- Code should recognize on what kind of device the app is installed and dynamically handle changes to the layout/structure.
- There is tradeoff between development time to support backward compatibility. If your app say india focussed where considerable people are still on 2.2 and 2.3, you will have to support it otherwise if say its USA focussed you can still do fine supporting 4.x. Note your decisions will have effect on number of downloads app will have which effects ranking.
- Make all hardware declarations in your manifest optional using android:required=“false”. Just don’t forget to have your code handle the device not having that function.