…… for the fastest apps
Development
App sales, In-app purchases, subscriptions, ad revenue, conversions, downloads and so on, are the language of business performance. To get the hyperconverting business performance described here, your apps also need technical performance.
For Freemium Apps, The Ideal Situation Arises When This happens
Here, all users who've downloaded your freemium ('upgrade to pro') app have ended up buying the upgrade or some of the other extra paid features i.e. 100% conversion. Imagine if you will, everyone who downloads buys! That's a bit hard to achieve, though it's always the ultimate goal.
Unfortunately, The Reality Is This
This is for apps that are doing really great. In fact there aren't many apps doing this 'well'. Generally once 2 to 5% conversion is achieved, everyone gets comfortable and accepts that's the best that can be done. This is the freemium/'upgrade to pro' business model that underpins the app business, or at least the In-app purchase side.
What if you could achieve this?
This kind of hyperconversion would revolutionize your business model. In b2b face to face selling it isn't that unusual (where 'Conversions' would be the closing rate of a sales pro meeting with qualified prospects). For freemium, once a user installs, they're qualified prospects.
How to Get Hyperconverting In-app Billing (IAB) App Sales
1. Implement a system that emulates real world face to face selling techniques, as much as possible. In real world selling, common sense comes as standard. For apps common sense is not included. Google just gives you an API for In-app Billing (In-app Purchases), but they don't tell you what to do with it. Sales training isn't part of the deal. Here are 3 basic In-app Billing optimization techniques that most apps ignore. There are a whole load of basic bootcamp techniques like this that when omitted, confine apps to zero revenue.
2. Make sure your use of the IAB API is flawless. If the user gets Play Store errors when they try to buy, you're done. Getting IAB tested and working perfectly can be trickly.
3. Implement a small AI expert system that:
- segments users by buying temperature
- closes the hottest ones
- warms up the rest
- repeats
- has some machine learning ability
Make it all fully autonomous, once the app goes out, that's it, fully automated algorithmic selling - and no cheating with remote control push notifications. IAB is just a tool, by itself it's not going to do any selling or make any money. That's why systems like this are needed.
Learn how your team can development a system like this for your Android app/project
4. If you've never used a system like this before, aim to close at least 1 in 5 users; a 20% conversion rate or higher. Much more is possible as you introduce more and more effective algorithmic selling methods. This is not 'new technology', it's just good software engineering that should be used a lot more in the app industry. Algorithmic trading of the financial markets has been around for ages, so why not for apps?
Get a superior ROI ('I' meaning development investment) and recoup or offset your development costs quickly. Learn how you can develop a system like this for your Android project.
Free Apps Using Hyperconversion Systems
Totally free apps (aka non paid apps), gain from hyperconversion too. As they can't offer the user In-app purchases, the data gathered from a hyperconversion system is used to intelligently alter the UX for all users to put each on the optimal path for your value generation strategy. Although many users may not be of much or any strategic value, all are on the optimal UX path for your end goal. That's the value. This approach avoids commoditized result apps, in which significant development costs may be incurred, but without significant benefits. Here are some of the main types of free apps you can get:
Vanity metrics apps produce a lot of social media signals, stats, reviewer comments and the like, but fail to produce any tangible business value.
Solid free apps that quickly find a position in their space, offering value to users and business benefit to owners. They could bring users to take up an offering on a site, be part of a wider user acquisition strategy for some other system, or have a totally different business model, but the main thing is, competent professionals have been involved at every stage, especially app promotion, app store optimization (ASO), user retention and overall strategy.
If not done the right way in synergy with your brand, including an ad delivery platform in a free app could have detrimental effects, but if used appropriately can generate revenue. All the industry data indicates that year in year out, app ad revenue is much much less than that of paid app or In-app purchase revenue, looking at the combined revenues of all the significant app stores together.
Many analytics platforms are vying for the privilege to be hooked up to your app. None of these systems influence the user in the moment that matters, because by the time you get to analyze the data, it's too late. It's like trying to influence the user's finger gestures by post. The benefit is small. Even using push notifications is too late.
A fully autonomous hyperconversion system is needed to get the maximum value from users.
Many companies, especially startups, are understandably averse to paid apps because of their limited user reach. That's a shame because paid is the top monetization method of all, if you look at gross app revenue for all app stores combined. Paid apps have 100% conversion in the diagram, in the sense that all users pay when installing.
Here's the solution to get the rock star reach of big name 'free' apps, with the fantastic pay up front revenue model of paid.
Create 2 apps, both with the same product name, but different Android package names, one is free to download and implements In-app purchases with an optional hyperconversion system and the other is fully paid. The paid app doesn't necessarily have to implement any extra functionality over the In-app purchase version, but should have all the functionality of the In-app purchase version enabled. The paid app will at least be able to offer code optimizations from excluding the In-app billing Java package.
As with professional service industries where the best clients pay more, your best users will gravitate to the paid version, and any hyperconversion system in the In-app purchase version will encourage them to do that. Gradually users become conditioned to paying for everything, but you can get the user reach investor appeal of household name apps like say, WhatsApp and at the same time demonstrate the credibility of immediate real revenue. Find out more about dual app Android revenue maximization strategy.
★Performance
To achieve this business performance very high technical performance is needed. Algorithms have to consider a lot of data points quickly; in the time it takes a user's finger to traverse a centimeter, a decision could be taken to switch the UX path to close a deal - an In-app purchase could be made.
Performance and UX
Without performance there is no user experience. Poor user perceived performance is a major reasons for uninstalls. That elegant minimal flow of interactive gestures, that's been the result of so much design effort, suddenly becomes academic if the user uninstalls. Unfortunately and unfairly, users may think your newly installed app is the cause of their Android system slow down, when in fact it's not, but you should eliminate the posssibility of your app being the cause.
Performance and App Engagement
An app that provides value and appears to do so instantly creates compelling engagement - IT IS engaging. There's lots of app engagement advice out there, but users may 'disengage' for any number of reasons beyond your control. It's worth focusing on what you can control - your app's performance.
You Get Great App Performance
… the same way you get it in other software development; by making it a design goal and part of your requirements specification at the beginning of a project. Conversely, the way not to achieve performance is to produce your app, see that it's slow and then say, "now let's make it faster" - which can be done, but it adds unnecessary development costs to a project. Java is considered the native development langage for Android, though somewhat confusingly the Native Development Kit (NDK), provides a C++ toolchain. Many server side performance considerations are now relevant to advanced Android development. Most of our client work is Java based, but where the solution requires it considerable advantage can often be gained from use of C++ on Android. Each situation needs careful consideration, as shifting out heavy lifting from Java to C++ is not always appropriate. When performance needs eclipse all other requirements and for the most computationally intensive or exacting embedded work, we can draw on ARM, Intel or MIPS assembly languages to squeeze everything possible from an Android device. The most effective techniques to gain peformance on Android involve multi-architecture binaries, vectorization and parallelization. Many entry level devices now have multiple cpu cores, but far more significant than that is the ability to install apps with architecture specific binaries and use vectorization in places to gain even more. Client apps can benefit from our own components based on these techniques. A successful project level approach should include a) designing for performance from the outset, not as an afterthought, b) discrimination between significant and insignificant gains, and c) the ability to measure.
Performance or lack of it can result from solutions in any programming language, so whatever language or language interfacing techniques are used, they must be used appropriately to achieve the desired results. Just using any particular language is not a guarantee of performance. On development languages for Andriod, there is now far more choice than ever, but it's important to not lose sight of the fact that the user doesn't care. Your design requirements and a considered view of the solution to be implemented will lead to an informed choice.
Get App Functional Advantage -
Porting Native Libraries
Making a great app and in particular something new, involves creating functionality. Your project must create it - or you must get it from somewhere else. To reduce this burden, Google gave Android a comprehensive Java API, specific to the platform, but at some point on complex projects, there comes a realization that this isn't enough to do the things you want and it's not viable to create what you need. That's when 'get it from somewhere else' becomes attractive.
There's a universe of open source code out there that can likely do what you need, but it's probably not Java. To do the best work that nobody else is doing, you have to take that stuff and port it to Android. Once you do this, your app gains a functional advantage, because your competition just has Android, but your app has something else as well.
Porting C/C++ libraries to Android really means you're extending the platform, but just for your app, with likely high performance and with total compatibility. This really empowers projects and whether you're following a hybrid model (HTML5, CSS and JavaScript), or are fully Java based, all the interfacing can be included to use this extra power from any language. This is how the stock Android Java API is provided, it's just a mapping to native code, with only the core Java API being written in Java itself.
The Android space is intensely competitive. The way things are right now, you can't expect to take over the world just using Google's stock API. To do something spectacular you will probably need this at some point. A lot of the big name apps do this and it's how the handset makers attach their own stuff to the platform.
Cost
Whether your budget is $5 or $1m a few things about Android development costs apply to all budgets:
Android is the platform with the widest reach, however the ubiquity should not be mistaken for meaning 'easy'. For the same functionality costs are usually more than for iOS. It's all too easy to get caught up in spending money on Android to receive only commoditized results, which may not be any less expensive than something more worthwhile.
Commoditized result apps, of which there many, are low net value propositions characterized by weak monetization methods, poor positioning and no strategy for improvement.
OS Fragmentation - the greater the level of Android OS backwards compatibility support, the greater the development effort and hence cost. This may not be significant, but it depends on the facilities your app uses from the stock API. The biggest name free apps go to some extremes to get every possible user, even if they're on 'old' devices, suporting Android Froyo 2.2 (API Level 8) and in some cases even earlier. We generally recommend supporting devices from Android Ice Cream Sandwich 4.0 (API Level 14) as a sensible level of backwards compatibility support, though it's best to decide this after considering your project goals.
UX/UI - adhering to a modern design language like Google Android Material Design is usually more expensive than 'design by developer', but you may not need Material Design and it's not the only way to a great looking result. Experienced developers produce UX/UI designs of equal merit as dedicated UX designers, in some cases. If you already have most of your graphic assets together including a vector of your launch icon this will also help costs.
Device fragmention - the main issue is form factor support. For phones vs tablets/phablets, it usually doesn't add too much to costs as good developers will know how to use
fragmentation support in the stock API to get optimal UI results on large and small form factor screens, but that doesn't include design for wearables. It's not an issue to distinguish phones/phablets from tablets, i.e. if the target device has GSM support.
In terms of Play Store integration, you should be clear about your monetization or value generation strategy and how you're going to get an ROI. Implementing a hyperconversion In-app billing strategy is an excellent way to quickly offset or profit over development costs after launch. It's a bit more expensive to build an app around Google's In-app billing API than to use the License Verification Library (LVL) used by fully paid apps. In-app billing in particular is critical to get right, as purchases are unlikely to be made if the user encounters even the slightest issue - IAB testing is not straightforward. Lastly on Play Store integration, give some thought to how hardened your crack protection has to be and how your business would be impacted if cracked versions of your paid app became available. Not all Android apps require Play Store or any kind of store integration, for example embedded projects do not typically need to cost for this.
Integration with your website back end doesn't impact costs if you have a well defined and designed API ready. It need not be a RESTful API, but the main thing is it works and we can test with it. If you need high performance multi-architecture network data processing, that may increase costs slightly.
An initial MVP release of your app is unlikely to be all you need, so you should budget for future phased releases of extra functionality, which would also help to bolster the effectiveness of your ASO and promotion effort. There are always exceptions; if you have a unique concept, one release with all core features may be all that's needed, but don't bank on it, as it takes time to spread awareness of your app and frequent update releases is a trusted method to do that.
Pilot/Proof of Concept (POC) apps always reduce total costs and improve plannning accuracy for larger projects and are highly recommended.
Hopefully these points have given you a few things to think about when planning your Android expenditure. With a proper approach there are tremendous rewards to be had and many ways to attain them.
Services
Android Development - It's No Longer Just Apps
It's gone way beyond that and requires planned execution in a multitude of areas that can exceed the capabilities of any organization - unless you've done it before.
Full Lifecycle Performance Based Android App Development
This is results based Android development, where in addition to producing an app, we take ownership of measurable performance metrics to get you the result you need. This is unlike commoditized Android development, whereby a client takes delivery of an app and then realizes that many other things are needed before a tangible return on their development investment can be realized and the success box can be ticked.
Android Background Service Implementation
Some apps have to do work outside the part the user sees. Often this is not done right and is a major cause of ANR (Application Not Responding) dialogs and other trouble that will sink your app's chance of success. We will be pleased to demonstrate our competence in this area and provide you with a high performance Android background service implementation to complement your UI.
Android App Store Optimization(ASO) and Management
Similar to website traffic, results don't just happen magically. The default outcome for any new app on Google Play and other stores is not very much, regardless of its merits in other respects. Fortunately the promotional services, strategies, methods and tools required to create great results are known and you can use them yourself or we can do it. Success here usually requires competitor analysis, engagement A/B testing, ASO and other monitoring. For top results ASO and management should be performed together with a continual app development push, which will reveal the direction of the most significant work needed to steer you towards success.
Android POC Pilot App Development/Risk Mitigation
For Android projects of scale, we always recommend a pilot development first. This risk mitigation exercise tests the validity of critical assumptions, both technical and other, before much more significant development costs are incurred. To learn more about why this is money well spent, get our PDF on HOW PILOT APPS REDUCE ANDROID DEVELOPMENT COSTS AND MITIGATE PROJECT RISK.
Android App Rescue
In circumstances where you've got a less than ideal Android app implementation, we can tell you what is needed to make it right and do it. You can't be a specialist in everything. Most of our Android re-development work is the result of digital agencies claimng to offer the highest level Android, iOS, Windows Phone and website results. If your current agency is doing that, at least make sure they're running separate development teams for each platform.
Straight up Android App Development
Like the title suggests, this is where you pay us money and we give you an app, LOL.
Android UX Design
We can work to a UX design you already have, or create one for you that's well adapted for Android. The best UX designs are collaborative, ensuring they can actually be built efficiently on the intended platform. Produce a design in any tool you like, some of the ones we've used include; InVision, Mockplus, Balsamiq Mockups, Fluid UI, Proto.io, Marvel, POP & Flinto (not to mention pics of your paper & pencil drawings!). Whether you want material design, flat design, bootstrap design, metro design, or just something that works, it's up to you.
Android Website & Backend Integration
Whether your website has a REST based API, it's SOAP, or you need integration with Firebase, Parse or another PaaS; whether authenticating via social media or email address; whether your data format is JSON, XML or ASN.1 - an optimal solution can be arranged. For demanding network data performance requirements there may be an opportunity to use our multi-architecture binary components.
