Building Native Apps

July 27, 2017

A native app can be a great solution for your clients, but there’s a lot to consider before you get started.

In part 2 of our Cross Platform App Development series, we provide in-depth guidance around the benefits and drawbacks of building a native app. 


A tale of two phones.

As we discussed in our introduction to cross platform app development, there are several approaches to consider to get your app deployed across multiple platforms. The most straightforward approach—although not necessarily the easiest—is to develop one app, with its own codebase and resources, for each platform you wish to target. Generally, this entails using the language and frameworks provided by the operating system developers. For iOS, this means Objective-C or Swift for the language, Apple frameworks like UIKit and CoreGraphics, and the Xcode development environment (or IDE). Android development, meanwhile, is performed in Java (or Kotlin) using the Android Studio IDE. We call these kinds of apps native apps.

There are a lot of upsides to this approach when we contrast it with app development using third-party tools that can target multiple platforms. There are also a few drawbacks, which we’ll consider later. Let’s start with the positives.

Native app development provides the best opportunities for a seamless user experience.

The frameworks provided by mobile operating system makers have, for the most part, enormous overlap in functionality and high-level conceptual design, and this has only become truer as mobile ecosystems have matured. But the devil is in the details, and the expectations of users of Android, iOS, or mobile Windows devices are all slightly different. The most reliable way to make sure that you’re doing things in the sanctioned, user-expected manner for a platform is to do it exactly as the platform recommends, without worrying about whether that approach is compatible with the approaches adopted on other platforms. Gestures, animations, particular input controls- these are areas where a one-size-fits-all approach will result in user friction. And the newer a UI feature is to the mobile world, the less likely it is that its implementation across platforms will be very similar. If your goal is that users will feel maximally comfortable within the app, you will want to carefully consider a native approach.

There are other advantages in your ability to polish your app to a truly fine shine, taking advantage of the fact that you have fewer layers of code: Your ability to optimize for performance is greater, because you’re not wading through translation layers or generated code, and you’re far less likely to encounter framework bugs. If you do manage that level of polish, a native app has a much better chance of being featured in a platform store. This can make an enormous impact on the reach of your app.

Native app development provides the deepest pools for talent and support.

Because you’re doing things the conventional way, you’re maximizing your exposure to standard practices. You’ll have the most access to subject-matter experts and the best chance of finding solutions to your bugs with a quick search query. And perhaps most importantly, you don’t have to worry about your codebase going through a sudden and accelerated aging process when the cross platform community finds that a new toolset is more effective, or when your third-party cross platform vendor decides to stop developing the toolset. These are real concerns and can represent a hidden multiplier on effort and inputs to your app.

You’ll also have access to the widest variety of open-source and third-party libraries and tools, as well as documentation and deep resources in online communities like Stack Overflow and a wide variety of conferences like WWDC and Google I/O.

Now, the pitfalls.

Your upfront costs are likely to be higher when developing multiple native apps in parallel.

You will need to find design, dev, and QA resources for what are effectively multiple teams building the same product. You will need to make decisions about where your apps will deviate across platforms, and those decisions can be challenging. Overall, your primary costs could be higher than with cross platform solutions. To some extent, though, you can expect returns on this investment over time, in the form of a more plentiful labor pool, fewer layers of code for bugs to be introduced, and lower effort required to update apps to incorporate new and compelling native features.

Multiple implementations of the same logic means multiple opportunities to create bugs.

Of course, writing the same code twice means two opportunities to make simple logic or coding errors. It can also be tough to spec products in a way that guarantees identical implementations of business logic across platform, so you may have bugs in the form of inconsistencies. If your business logic is deep, complicated, or requires exacting implementations, it may make sense to look into cross platform toolsets that allow you to avoid code duplication.

Tooling and user expectations trump platform considerations in some cases.

This is not exactly a drawback, but sometimes the tools used to develop an app draw you away from native UX models, and this can be a reasonable outcome. This is particularly true in the case of 3D games, where users are accustomed to fully-customized interfaces. It may also be true for apps deployed in settings where the device and OS are not a central part of the experience (kiosks, for instance) or where seamlessness of user experience is at a premium because users are expected to change devices frequently (such as a video-streaming service deployed to tablets, phones, browsers, and televisions).

As you contemplate the approach you will take, setting your priorities and understanding your goals is crucial to navigating the sometimes murky waters of your development plan. There are no universal solutions, but it is likely that some of the approaches we are discussing in this series will be more suitable for your needs than others.

Next week, we will dive into consideration of two of the major candidates for true cross platform development: Xamarin and React Native.

Read part 1 of our cross platform app development series: Building Cross Platform Apps.

Seamus Campbell

Seamus Campbell, L4 Solutions Architect, is a seven-year veteran iOS developer, as well as a Certified Cicerone and beer author. His professional interests include strategies for effective code review and mentoring, and when he’s not thinking about code he can often be found around Portland, OR, with a bicycle, a guitar, or both.

BLOG ARCHIVE
Droidcon 2017: A History of Android, and a Look Ahead
Eric Ries Needs a Better Editor.
Metrics that Matter
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • August 2017
  • July 2017
  • June 2017
  • May 2017
  • Contact L4