Fuck, We’re a Native App Company

Imagine you were an astronaut, and you’ve been trained to colonize mars.

To prepare, you’d obtain a suit that would protect you for an average of minus 80 fahrenheit and dust storms that could last for days. Radiation from space would also be a concern because of the thin atmosphere, so your suit should be designed to keep the gammas out. Wouldn’t you know it, gravity is about 38% of earth, so just getting around would take some getting used to.

Now let’s say one day you’ve become acclimated to Life on Mars (editor’s nod to Bowie) and your superiors call you and tell you they’re sending you to Venus.

You immediately freak out because you realize your spacesuit isn’t designed for Venus’s atmosphere. You’d have to get a new suit that would protect you from surface temperatures that are hot enough to melt lead (about 870 degrees fahrenheit). Beyond the suit, you’d need to deal with a serious jam up: the atmospheric pressure would feel like you’re 3,000 feet down into the ocean. And if that’s not enough, active volcanoes would be rampant — so you’d need some boots that would allow your feet to sweat a bit.

In short, while both Mars and Venus are planets; while they’re both round; while they both exist in our solar system; while they orbit the sun…they are most definitely entirely different.

Now apply this same conundrum to building technology products: specifically the difference between Native Apps — designed specifically to operate on your mobile device — and websites, designed to operate on computers. In short:

Apps are from Mars, the Web is from Venus

This is never more apparent than when trying to shift a business from one medium to another. Moving a web business to a native app business (or a native app business to a web business) requires a complete change of planet. The way you create product, the tools you use, how you measure results, the relationships you build — all will be completely different.

At Mylestoned, we’ve recently begun this shift because it’s right for the customers and right for our product. While I’ve run web companies that have had native apps before, I’ve never focused solely on the native app side of things so deeply.

We’re digesting tons of data, and we’re lucky to have a few friends with successful native app businesses — Jason Jacobs, Mike Oliver, and Jon Gilman from Runkeeper, Giuseppe Stuto from Smackhigh , ❖ Aaron White — but haven’t stumbled across a clear roadmap for making this shift (anyone? bueller?). So here’s what we’ve learned (so far):

9 tips for moving from a web product to a native app product:

1. Technical Build: With web development, you’re building for one platform (the web). Building a native app requires you to consider builds for iOS (apple) and Android (google). Your first decision is which platform — or which one first. “Both” is irrational, so just stop that right now.
2. & Iterating. To a tee, everyone says developing for a native app means a slowdown in your technical process compared to the web. Most apps are built in Swift or C, but the code isn’t the problem — it’s the sheer number of permutations (OSs, screen size, etc. with Android) and the damn approval process with Apple and iOS. Apparently if you’re coding in React Native, you skip the Apple process for updates. True? This seems very non-Apple to me.
3. Hybrid vs. Full Native. Due to native app development challenges, everyone naturally falls back to suggesting a Hybrid app. Basically it looks like a native app, but you’re really forcing users to open a web browser in the app framework. Well that should make coding it easier — except it’s harder to tap into GPS, the camera, notifications and the contact list, which is why you decided to go native anyway. Everyone has some tale of some 7-pronged Unicorn that did this (“Uber is native”), which will then be debunked (“no, they were native once but not anymore”) and how they know (“you can tell by the millisecond response time”).
4. Testing and Beta Plan. Start with test flight, so your buddies and coworkers can tell you all the places you screwed up. Then slowly release access to all of those people who you baited onto your waitlist. (For Betas, everyone will reference their favorite “crushed it” release, like Robin Hood. You can only hope you’ll have hundreds of thousands on your waitlist. No, I mean that. You’re just hoping, pal. Have fun slowly letting in the 64 people who signed up for early release).
5. App. Store Positioning. Before developing a product people even want, you’ll need to put some ridiculous cycles into positioning in the app store. Beyond what to name the app (255 characters for iOS though they recommend 23 or less for optimal viewing on all devices. 30 for Android), creating a tagline and a description, there are a ton of variables. Appbot’s “Secrets of the App Store” sheds light on the requirement to micro-analyze, geek out, and statistically multi-variate the crap out of everything from number of screen shots, to complexity of logo to whether fuchsia will drive more traffic than periwinkle blue. We’re particularly attuned to category choice — is it cosmically weird to have a “death” app live in the lifestyle category?
6. App. Approval. Notably for iOS you’re going to have to jump through some hoops to get your app into the app store. Much has been written about the approval process: it could take a week, but apparently it’s now shorter. You also should expect rejections — certainly for your first submission, and likely for a variety of items from bugs to something apple is competing with to — obviously —amateur porn. Everyone says you need a “relationship” at apple and google to ensure smooth sailing for your app. I never needed a relationship to launch my website…
7. Ecosystem tools. Are you using Sensor tower? What about AppAnnie? Crashlytics is a go to, as is Localytics. “But we used to use Mode and Intercom and” you say. You might have loved them once, but time to break up and move on. It wasn’t them, it’s now you. Get ready to swipe left, because once you move into native app environment, you’re going to have to pick a whole new set of tools and vendors to work with.
8. Friggin’ Installs. In the traditional web world, you’re focused on driving traffic to your website where you want people to take an action. With native web, you have one major hurdle in the way of that: the install. Installs is a classic vanity metric, but one that has to be serviced nevertheless. Sure installs can be paid for ($1-$2 per install, driven by those who want free internet access in India) and 20% of installs never even open the app (they got distracted or only wanted internet access). Yes, once you’re on someone’s device they’re captive — but now the real efforts begin as you aim to nurture users beyond 1x usage, and hope to avoid the dreaded uninstall.
9. mylestoned.com. Oh wait, what the hell do we do with our website and the technology we developed there. Yeah that thing we spent 8 months, 18 hours a day working on? How about we just put up a splash page and forget it ever existed.

As it relates to planetary shifts, this feels as seismic of one I’ve been through. We’re retrofitting the spacesuit now, launch sequence to commence shortly. [and if you have any insights, please please please reach out to me, I’m all ears].

People, if you got this far, please hit the ❤ below. It’s karmically sound.