A Developer’s Guide To The Wild West Of App Discovery

Editor’s note: Raphael Ouzan is the founder CTO and head of product at BillGuard.
It’s hard to launch a consumer mobile app these days. Manage to build a stellar product that answers a true need? You can pretty much count on the Google/Apple duopoly and poor structure of both app stores to bury your work along with the overwhelming majority of apps wallowing on each platform.
With more than 80 percent of the 1.4 million App Store listings qualifying as “zombies” – not visible on any of Apple’s category lists – it’s really not so surprising that most iPhone owners don’t download even one new app a month.
So if you’re a consumer app company that’s staked its future on user growth, you have to find a way to address this challenge head on. When we were just beginning to research mobile, I turned to my friend Ouriel Ohayon for advice and will never forget his response: “Oh man, mobile discovery is the Wild, Wild West.” Ouriel was of course right, but like the American frontier in days of old, it’s not that no rules exist, but rather that those rules can be extremely hard to ascertain when you first trot into Dodge City.

As a sort of communal payback for Ouriel’s help, here’s our developer’s guide to the Wild West of app discovery.

Lean Development — Even on iOS

Once you’ve decided to start on iOS or Android, there are two important decisions you have to make ahead of launch: how to structure your builds and how to coordinate your launch.
BillGuard began as a web app; we started coding our first mobile app in early 2013, which was late in the game. At that point it was clear that iOS was the place to begin for the demographic we wanted to reach.
As our early iPhone app development progressed, we realized we were in a bind. Apple’s lengthy app-submission process (it still typically takes one to two weeks to get a new version approved) makes it very hard to develop in a quick, iterative, responsive way, listening closely to early users and continually applying fixes and improvements. That’s the lean development framework that most software teams like ours prefer to work in today. TestFlight wasn’t much help: only a limited number of testers make it through the complex setup.
So we decided to roll our own version of lean dev for iOS — a cowboy cigarette.

We formed a Facebook-based beta group for power users and quietly released to them no fewer than 11 versions of our app before our public launch day. We called it a private beta – though the app was actually public on the App Store as, frustratingly, there’s no formal beta testing on iOS as there is on Android. The feedback from this beta group proved invaluable toward a successful launch. 
To ensure we’d receive fresh opinions uncolored by our web app experience, we also bought some carefully targeted Facebook app install ads to draw new users and to begin to understand what marketing messaging worked well.
For example, in the ad creative, we floated a few different design alternatives to gain a signal on what drew consumers. That turned out to be very helpful in determining certain design elements like our app dashboard. 
It took about four months for our app’s quality to rise enough for a real launch. At that point, we pulled the app from the App Store so we could make a splash on our public launch.
Cowboy Tip #1: Stick to your developer’s guns – don’t let the rigid structure of the app store determine your software release cycle.

The All-Powerful App Store Feature

For launch day, we knew we had to generate a perfect storm. App Store rankings put a lot of emphasis on velocity of downloads and ratings. So as we saw it, we could either release an app that would get lost in the wasteland of the store, or we could push as hard as possible from many channels to propel it to the top at the start and trust that the product was good enough to stay there on its own merit.
The first and most important part of that plan was releasing a strong app to the world, which our lean dev hack helped to accomplish. We then needed to orchestrate two events: getting featured on the App Store and encouraging favorable press coverage.
Being featured or not can make or break an iPhone app. And there’s no way around it: to be featured by Apple on launch day, you need a relationship with someone in the Cupertino saloon.

Here’s where being well-networked in your own tech community helps. A friend and fellow consumer app developer offered us an intro to an App Store manager. We shared our app with that manager and, fortunately, he liked it enough to nominate it to Apple’s uber secret App Store editorial board for a featured slot.
We never would know who actually voted on the feature decision, but our Apple contact and our relationship with him proved invaluable. App stores are businesses, and like all businesses they want to display great products – but you have to find a way to knock on the right door to peddle your wares.
Cowboy Tip #2: Don’t be shy about asking for intros to people on the App Store and Google Play team. Then treat those contacts as users – if they love your app, they’ll work hard for you.

Press. Harder.

With this encouraging sign from Apple, we turned to our press contacts and offered them a sneak preview of the app, which we had to engineer. We left our App Store status in ‘Pending Developer Release’ and slipped journalists a promo code supplied by Apple. The writers fortunately also loved the app and enough committed to posting about it that we could report back to Apple that we expected strong press – which reinforced their tentative decision to promote it in the App Store. Turns out that even Apple seeks social proof.

Apple’s like a powerful uncle, a wizened patriarch who invites you to his table regularly for whisky, but never makes you feel entirely comfortable.

On launch day, we went live with a TV appearance, received a bunch of other great press that we had embargoed, and received the promised featured slot from Apple. We managed to pull this launch off despite numerous formal barriers that Apple itself constructs. In truth, as we’ve continued to develop on iOS over the past couple years, our relationship with Apple hasn’t become any easier. But having a champion in Cupertino continues to make a big difference.
Cowboy Tip 3: Take PR seriously – and use any media success as a lever with Apple and Google to get featured on the App Store or Play Store. And remember – the App Store refreshes on Thursdays. Time your launch accordingly.

From Uncle Apple to Cousin Google

As an app developer, Apple’s like a powerful uncle, a wizened patriarch who invites you to his table regularly for whisky, but never makes you feel entirely comfortable. His rules are strict, he’s mercurial and slow-moving. But he also commands everyone’s respect – and it’s a whole lot easier to get things done if you win his support.

Google, we found, is more like your cool older cousin who understands where you’re coming from and enjoys a heart-to-heart over beers. He encourages you ship in quick release cycles, provides in-depth feedback on how you’re doing, and talks your language at your level. But, alas, we came to discover that also cousin Google has social baggage to deal with.

Pragmatically, starting and iterating on Android is much better and faster. Yes, device fragmentation makes Android QA much harder, and the animation engine is much better on iPhone, but all in all Android is a much more dev friendly environment to work in.

To Port or Rebuild?

Before we reached out to Google regarding our app, we began designing and coding it. Many developers structure their second platform app according to the same exact UI and design principles of their original app – porting it over – but we chose not to do that. We didn’t think the consistency of user experience on the two platforms really mattered. So we designed BillGuard for Android with a couple large UI changes from our iPhone app.
The downside of this approach is that when you learn something about user behavior on your new app, you don’t know whether it’s due to the platform switch or due to that particular feature. That’s a huge disadvantage — enough to make it the wrong decision for most apps — but in our particular case I don’t regret it. 
Cowboy Tip 4: Understand the advantages of each mobile platform and how you can improve your app on one platform based on the experience on the other.

Hit over the Head with a Tablet 

We developed a strong contact at Google who helped us through the Android launch process – a biz dev head in New York and his Google Play team, whom we met at SXSW.
We met personally with our New York contact every month, and as our app progressed the Google Play editorial team gave us a ton of detailed feedback, most of which we implemented.
Some of the feedback, however, seemed just wrong to us, and we pushed back. Google’s team actually accepted our position in some cases, which demonstrated that this was a real peer-like relationship – far from our Apple experience. Later, the Google editorial team even advised us on when and how to launch.

This was like telling a new sports car maker immediately before it goes to market that it can only open a showroom if it simultaneously releases a pickup truck.

Everything seemed to be going well until one day, late in our development process, our Google contact informed us that if we wanted to be considered for a Play Store featured slot we had to release not only a phone app but also a tablet app. Google wanted to bolster its overall tablet app quality, so it was only featuring new apps that launched on both phone and tablet screen sizes.
This… really sucked. Our entire product development had focused on phone screens, and now if we wanted to be featured and avoid Android obscurity, we had to also build for a very different user experience for tablets. This was like telling a new sports car maker immediately before it goes to market that it can only open a showroom if it simultaneously releases a pickup truck. It felt absurd, out of character from the Google dev relations we had come to appreciate. But it showed how business considerations can force the hand of even the most dev-friendly Googlers.
We decided to comply, despite the additional time it demanded. And in the end, following some extraordinary help from our contact, Google did feature our app on launch day. As with Apple, setting up press coverage ahead of time — and letting Google know about it — certainly helped to get featured on the Play Store. 
We’ve found that attending Google I/O has been important to expanding our relationship with Google. While there, we’ve participated in a few, refreshing ‘reverse panels’ where Google folks ask us about the experience of building for Android. 
Cowboy Tip 5: Understand and align yourself with the strategic goals of Google and Apple – even if you don’t share them.

The House Rules

Our apps are now well-established on both the App Store and Play Store, and our launches were key to that. But in retrospect, we feel that the success of our launches had way too much to do with identifying and negotiating technical hurdles: Apple’s and Google’s frameworks, guidelines and secondary business interests.
Hopefully the day will soon dawn when app discovery improves such that the mere quality of a service determines visibility. Maybe Product Hunt will cross the chasm and become such a tool, or maybe Apple’s new App Analytics signals a commitment from Apple to enhance transparency for both developers and users.
Until then, we’re all subject to Apple and Google’s Wild West house rules, most of which aren’t posted at the saloon door.