CONTACT

Why brands should develop mobile apps in native code, not frameworks

Punchkick Interactive
  • Punchkick Interactive
  • July 11, 2016
Why brands should develop mobile apps in native code, not frameworks

For many brands, the modern mobile landscape is a balance between offering top-notch user experiences and identifying cost-effective technologies that will facilitate that experience. When deciding how to build an app, it’s important to consider what methods will lead to the best balance for both your users and development teams. There are many options available to deliver products and experiences to a mobile user, each with their own strengths, weaknesses, and trade-offs. However, there are a number prevailing methods for mobile app development that have become popular over the years, and we’ve examined each of their benefits and challenges.

Native Development

Developing a native application means that the app is written in the language specific to the native operating system of a particular device. Objective-C and Swift are languages that are used to develop apps for Apple’s iOS, while Java is used for Google’s Android. Applications developed in these languages are specialized for the intended platform, and their codebases cannot be installed on other platforms, so native applications for distinct operating systems are often developed simultaneously to ensure that the product is available on both platforms.

Building applications in native code for iOS and Android ensures that they are fully compatible with and able to take advantage of the best features of the operating systems from day one. As Apple and Google introduce new frameworks and APIs to their software over time—including things like Apple Watch support, interactive notifications in iOS 10, and direct access to new Siri APIs—apps written in native code will immediately be able to take advantage. Apps build though other means, like those outlined below, will likely take longer to jump on board, because they depend on third-party framework developers to make their own updates.

“Write-Once” Platform Development

Using non–native code to deliver a digital product to your mobile users can be appealing because there’s a perceived efficiency in development—there a multitude of options to leverage in a “write-once–deploy-anywhere” development model. These options are meant to solve for the issues of individual development efforts for each platform. Some of the more popular options include:

MOBILE WEB
Some products are best fit as a mobile-specific or responsive website that is accessible via a web browser on the user’s device. While native operating systems were still in their infancy, developing a mobile-specific website was the standard for a company’s mobile presence. Mobile-specific and responsive websites do not live locally on the device, but can offer a lightweight and easily consumed option for a mobile presence. Mobile-optimized websites will be available on every mobile device that has an internet connection and a browser that supports HTML5—which is every device in recent history.

However, developing websites specifically for mobile users (also known as “adaptive” or “m-dot” web development) introduces a number of complications for web developers and content generators. Updating content or functionality across two distinct sites for desktop and mobile can be cumbersome, and sharing links can sometimes mean users see the wrong experience for their device. (This is why Punchkick recommends responsive web development.)

Mobile web experiences are also significantly less responsive than native code, and fail to leverage many of the native APIs that make iOS and Android apps so powerful and engaging. Mobile web apps can’t access many device capabilities or APIs, can’t build widgets or extensions, and can’t store certain types of data locally to use between sessions. These aren’t a replacement for native apps, but can compliment native apps as an option for users who may not want to download a full-fledged app or might discover your brand via Google.

WEB-BASED WRAPPERS AND PLATFORMS
A middle ground between purely mobile web and native solutions is to leverage an external platform such as Adobe PhoneGap or Ionic, which offer the development team a chance to develop in web languages such as HTML5, CSS, and JavaScript. Developers can then wrap their web code in a native wrapper (like the Apache Cordova framework), which offers the web product access to native-specific features like cameras, accelerometers, and geo-location through JavaScript API calls. Using a wrapper allows the development team to develop a core set of features in the app and then deploy them for each specific OS.

These apps have all of the failings of mobile web applications, combined with challenges of indirect communication with native APIs. By putting JavaScript API calls in between the application code and the operating system, the connection between your app and the frameworks and APIs it relies upon is incredibly brittle—meaning that when Apple or Google changes their APIs for iOS and Android app development, your app will break.

Beyond compatibility weigh the operating system, apps built with web-based wrappers won’t be able to take advantage of the security best practices on either iOS or Android—because their application code is based on web technologies, they are susceptible to the same security vulnerabilities and exploits that webpages need to contend with.

HYBRID APPS
The last iteration of an app development method that invokes HTML5 and web-technologies is the Hybrid app. Much like web-based platforms, this method employs web languages as the write-once piece of the development process, and then leverages non-native languages like Ruby and C# for business logic and needs. These apps built in non-native require specific native code to implement the UI on each specific platform. There are multiple tools that can be used accomplish this method, including Ruby Motion and Xamarin.

Hybrid apps, like web-based wrapper apps and others, fail to leverage the interface paradigms and tools built into the mobile operating systems, like UIKit on iOS and Material Design on Android. Hybrid apps take a one-size-fits-all approach to interface design that in practice equates to “lowest common denominator” for UI and UX design. Ultimately, this approach yields apps that don’t look or feel at home on their native operating system, providing a sub-par experience for users.

On the whole, write-once development platforms simplify development in the short term but complicate support and iteration in the long term.

Ultimately, the surest way to build the optimal user experience on iOS and Android apps is to build for the platforms themselves, rather than finding some workaround that will simplify development in the short term but complicate support and iteration in the long term. Getting an app to market quickly and efficiently on both the iOS and Android platforms is valuable—but not at the expense of the core technologies that facilitate your users’ experience with the app.

An emerging trend of FORTUNE-level brands replatforming their apps to be fully native has been accelerating for the last several years—brands that invested in platforms like Kony and PhoneGap are transitioning away from the platforms to fully native iOS and Android code. Legacy write-once platforms like Adobe Flex are becoming enormous headaches for the brands that once relied on them. Since Adobe discontinued Flex, dozens of massive brands have had to reinvest in mobile to start their apps entirely from scratch.

While new platforms emerge frequently, like Xamarin, the wisest and most future-proof mobile development strategy is to build the app right the first time, versus using a write-once development platform and having to start from scratch in 12 months. Native code is future-proof: while Xamarin and platforms like it might be acquired and sold multiple times, with unsure development futures and iteration plans, Apple and Google aren’t going anywhere. By building apps the way Apple and Google recommend, brands will never need to start from scratch.

Connect

Let’s Build Together

Thanks for reaching out!

We will be in touch shortly.