The Tug of War Between Responsive and Native Design

Let me start by saying there will always be tension between native and responsive design. As long as native operating systems are pushing the bounds of what's possible on a specific device, there will be responsive apps trying to keep up with that functionality. However, deciding what's best for your business or project isn't so simple as picking the best technology. 

The decision should start with a close look at your goals for the project. What is it you're trying to achieve? Do you want to gently enter a world you've heretofore avoided? Or dive right in and make a stand? Moreover, what type of resources do you have to devote to the project? Are you going to be building it yourself, hiring a contract developer, or deploying a whole team to work on it?

These are important questions that should guide the development process. Let's look at the first one: You want to make an easy entrance into the mobile world. In this case, the simplest way to start is by building a responsive mobile site. This can be done with a relatively light web development effort. Unlikely native where you'd need to deploy a separate code base (often in a different language), this can be done with some additions to your HTML/CSS. It will be accessible to users across a wide span of devices. If they're on tablets, they can always opt for the desktop version if they prefer, and if they're on mobile it will be accessible on everything from Android to Windows Phone. It also saves you from having to decide between Android and iOS.

Now say you're in the second group: You want to make a splash on mobile. In this case, you're probably either building it yourself or deploying a team to work on it. Those are actually two groups, but regardless, you'll need to decide on Android or iOS. Where and how do you want to make a splash? Although Android and iOS are at parity in terms of market share - they both have about 45% of the market - there are big differences between the two.

First off, what does your app intend to do? Is it building some enhanced functionality to an OS or is it a simple app for a niche area (say racehorse stats). In cases like these, you're better off starting with Android. Google's OS features a substantially lower bar to being published, so it's easier for smaller efforts to go live quickly. Apple is known to reject apps that mimic other apps too closely, or that don't appeal to their sense of humor (think fart apps).

If your app is intended for a broader audience and you're looking for a more viral appeal, iOS is the way to go. For starters, name the last billion-dollar company that started on Android. While you're thinking, I'll mention the last two that started on iOS: Instagram and WhatsApp. (There's also Uber, but it's likely past the point of being acquired.) Mobile apps started with Apple, and empirically the best apps have started on iOS.

The best way to start is by figuring out the look and feel of your app. This is the starting point for both apps, and after that you'll need to segment development efforts since the two platforms use different languages and require different expertise. Remember, you went native so you could make a splash, so invest heavily in the look and feel of the app. It's the first thing a user will experience, and if it doesn't wow them they're not likely to return.

After you've settled on the design and UX, you can move on to actual development. The second major thing to think about is the backend. Do you want a shared backend or do you want to completely silo the apps? In some cases, like Snapchat, I'll never use the app on a different OS than the one I started with, or the web. Later on, however, you may want to consider a web presence, which you'll definitely want to interact with the data you have from the app.

In either case, a good solution is something like Parse or Firebase. These are great mobile backends that work for your app or site and are easily built into apps on either OS. What's better, once you're ready for the web it'll be as simple as tying in with your existing data stores on either service. 

At this point you're ready to submit the app. The first thing to look at is QA. Make sure you've done thorough testing and that every possible use case within the app is functional. There should be no broken links, no freezing, just completely useable. Have an area that's not quite ready for prime time? That's fine, remove it from the beta version. Just feature the fully baked aspects of the app. You'll want all the pieces in line so that the reviewers see you're serious about making a quality app.

That should be enough to get you started along the path. Feel free to reach out to me in the comments if you have any questions or comments!