Fixing Mobile Platforms
I wrote an article recently on why mobile app-first companies are doomed to fail due to their inability to close viral loops and retain users effectively. I pivoted my own company’s new product Origami to focus on the web and build mobile as a companion. The article centers on data regarding onboarding and our inability to optimize onboarding in a timely manner. I’d like to propose a couple changes for Apple and Google to consider that I believe would make mobile a viable platform for startups going forward. I’ve ordered these from most plausible to least plausible.
1. Ability to pass parameters from a download URL to an app
“I have no idea why people are downloading my app, or how they found out about it” is the response given by most app developers when asked where their mobile downloads are coming from. This is a huge problem and there is an easy and powerful fix.
On the web, there are a number of ways to track a user from page to page:
Referrer header that tells you what page someone clicked to get to the current page.
Cookies so that a website can, for example, store a bit of information about a user to keep them logged in even if they close their browser.
URI parameters that trigger predictable actions on a page (i.e. google.com/?query=soup will always show you a search for soup).
All of these methods let the developer maintain state for the user, as well as potentially actionable insights on where your users come from and what they are doing.
If a user transitions from the mobile web to the App Store, the chain is broken and we’ve lost all information about the user. We can’t maintain state and we no longer reliably understand where the download came from.
The solution is simple: let developers pass arbitrary parameters from the web through to a download.
Currently, the download link to our app is a static URL:
If we could pass parameters, it might look like this:
Apple or Google would then make these parameters available to the developer from the native app. The link above would allow us to keep the user logged in from web to download, as well as know where our new user came from.
I believe this single feature alone would spawn an ecosystem of startups. Developers could instantly personalize app downloads and ad companies could sell real performance-based install campaigns. And we’d finally be able to answer the question of where downloads came from.
2. Show search terms from App Store/Google Play in developer portals
Related to the ability to pass parameters is a simple dashboard that the developer portals should include, with a Google Analytics-like view of how users discovered their app organically in the App Store or Google Play. It would show a list of keywords used to get to your app and their frequency. This doesn’t seem that hard to do, and it would provide an enormous increase in visibility into where users are coming from.
In addition, if the user came from a featuring or from a particular category or Top X chart, that information would also be valuable to share with the developer, either afterwards in a dashboard or even better, on the user’s first app open.
If we had this information available to us, it would help us optimize our app descriptions as well as give us insights into what users are looking for. We’d save a lot of development time if we knew people came to Everyme primarily because they typed in “Group Messaging” or “Private Social Network" in terms of prioritizing features and marketing campaigns.
3. Removing the app price floor, allowing paid upgrades, and adding the ability to generate coupons
I believe that the $0.99 floor on app pricing and the inability to charge for an upgrade degrades the quality of apps and has had a negative economic effect on developers as well.
- App developers who shouldn’t be making $0.99 off of terrible apps make a profit on every random person that downloads one, and thus they have an incentive to flood the store with low-quality apps at a guaranteed profit margin. App discovery is very difficult on mobile so quality apps get buried under the load.
- App developers who should be making a lot more than $0.99 per app end up pricing their apps at $0.99. Mobile consumers seem to be extremely price sensitive - probably from the pricing floor. Great app developers end up making less money than they should. In addition, since developers can’t charge for app upgrades, they have little incentive to continually improve their product. This is passed on to the consumer in the form of higher expectations for 1.0 apps.
- Startups that know that they can’t make a long term, sustainable business selling apps at $0.99 give away their apps for free instead. Eventually they will turn to advertising or virtual goods. But users of a free product are not very sticky, and why should they be – they haven’t invested anything and don’t expect a return.
The solution to me is simple: Remove pricing constraints. No minimum pricing, ability to shift pricing in real-time, paid upgrades, and also couponing. Coupons are a great way to incentivize people to download your app. They let you test price sensitivity of your target market as well as create artificial demand. I’m sure there will be a flood of $0.01 apps, but that’s great because all of the bad apps will trend towards free and the good apps will have the opportunity to find their equilibrium price.
4. Programmatic app submission and developer APIs
As has been pointed out many times before, the ability to deploy fixes and new features on the fly has been a huge boon to the web and we need a similar system for mobile. It doesn’t need to be complicated – just a REST endpoint to upload a new Android APK or iOS binary along with metadata – version number, changelog, etc. will do. Coupled with automated build systems like Jenkins, developers will be able to fix bugs faster and test features in real-time with something as simple as a Git commit.
I think a corollary feature to programmatic app submission is more APIs for developers surrounding the app details. Adjusting the icon, screenshots, pricing, search tags, and your app description via APIs would save developers time, money, and would give us more success factors that we can algorithmically control.
5. Load a native app immediately by hitting a website/URL
Allowing developers to load a native app via the mobile web would solve 95% of the problems with mobile. Here is what I mean by this:
- User reads about Everyme in their mobile Twitter client or sees an ad.
- User visits Everyme.com.
- Mobile web browser encounters a new HTML header tag:
<meta name="associated-ios-app-url" content="https://everyme.com/Everyme.app" />
- Mobile browser kicks the user to a black screen and loads the app located at https://everyme.com/Everyme.app.
- If the user wants to go back or reveal the address bar, he or she swipes down from the top (currently loads notifications) and the address bar shows everyme.com as being loaded, along with standard browser navigation controls.
Other cool things you can do with this:
- User searches on Google for a soup recipe.
- Clicks result to https://recipesite.com/recipes/soup.
- Browser encounters HTML header tag:
<meta name="associated-android-app-url" content="https:// recipesite.com/Recipes.apk?recipe=Soup" />
- Soup recipe is loaded in a beautiful native app.
The main complaint I’ve heard with this is that mobile apps are huge downloads. That’s true – but the average size of a website has increased greatly over time, in addition to our network bandwidth. I suspect that app developers would also adjust their code to load less heavy resources synchronously. We would figure it out as a community.
6. Allow an app to set itself as the default handler for files, calls, texts, etc.
What I really mean by this is that we need more power over the core functionality of the phone. Android has embraced this but iOS hasn’t, and we need buy-in from both systems, especially for apps that have a social component. We need the ability to ask the user if it’s ok for our app to handle certain phone events and files by default.
This hurt our company a lot when we realized we could never create an address book app better than Apple’s because we weren’t able to capture phone calls, texts, or the recent calls log. We ended up creating our own call log internally, but it was a significantly degraded experience from the default address book.
I am hopeful that in the next couple years, at least some of these changes will be implemented. At that time, I think it will make a lot of sense to reconsider a mobile app-first strategy. For now, I still recommend that you build mobile apps to engage and retain users alongside the web, but not necessarily to acquire new ones.
Follow me on Twitter