‹ Back to Blog

A Tale of Two Apps: Parallel Native Development

February 27, 2015

GameStop

The future is now (sans flying cars) - mobile applications are ubiquitous, core components of most major products and services. Everyone and their grandpa has an “iPhone app” - but that’s not enough. Businesses increasingly need to provide products for multiple platforms, and releasing for iOS before or instead of Android can alienate or exclude large sections of the mobile market. At first glance, it appears that cross-platform solutions like Titanium/PhoneGap/Flex - which make lofty promises about reusable code - are a decent solution to this problem. However, at Ludomade we believe that parallel native app development is often a more robust solution. Using this approach, both iOS and Android applications are developed simultaneously. Feature sets are staggered between the platforms to gain efficiency by isolating issues in both design and development on one platform before they become a bottlenecks on another.

By applying this approach to GameStop’s iOS and Android applications, we were able to provide user experiences catered to the recommended interface guidelines on both iOS and Android while keeping the costs and timelines on-par with those offered by even the best cross-platform tools. Cross-platform development suites are quicker up to the point of producing something that amounts to a polished prototype, after which the efficiencies and user experience benefits of native development win out in a landslide.

Why Native?

  • Access to the latest features for each platform - many tools and services promise this, but very few deliver what they claim by consistently staying up to date with rapidly evolving mobile operating systems.
  • Full control over hardware, messaging, and personalization features - native mobile applications are the best choice for taking advantage of these core device capabilities.
  • Shorter dependency chains without excessive reliance on mobile middleware means a more stable app that is easier to maintain and improve, and has fewer points of failure.
  • Granular control over platform-specific look and feel to provide an experience tailored to each platform’s ecosystem - users are particularly unforgiving of applications that violate the interface standards and idioms of their host platform.
  • The end result of pure native development tends to be a small, fast binary. This is not a guarantee, but native development minimizes bloat and slowdown.

But it’s not all sunshine and rainbows:

  • Higher initial development cost than other approaches. The higher cost is only a drawback during the initial development phase. Maintenance and improvement costs are decreased thanks to some of the efficiencies described above, such as shorter dependency chains and closer access to the bare metal for supporting the latest platform versions.
  • It can be difficult to design multiple experiences while still maintaining feature parity - it requires serious multi-platform design talent, and bad design ports from iOS to Android need not apply.
  • Subject matter expertise required for maintenance and improvement - in other words, it is difficult to quickly fit someone without domain expertise into the role of a mobile developer. Native devs have a very particular set of skills - where’s my Liam Neeson emoji?

Weighing these pros and cons, GameStop ultimately decided to ditch their old app developed on Titanium and pursue parallel native development in order to provide their customers with the richest possible user experience on each target platform. We think they made the right decision, and users seem to agree:

Reviews

Project Planning

So, you’re sold - after making the choice to pursue native development, the planning phase begins. This phase is extremely important, because improper planning can make parallel native development into a logistical nightmare.

Most importantly, plan for time to communicate. Both structured and ad-hoc communication are vital: the staggered approach fails utterly without a strong feedback loop between developers on each platform.

Agile development hinges on the software engineering maxim “make it work, make it right, make it fast”. This is even more important when pursuing parallel native development; efficiencies are gained by locking down as much of the process as possible during development on one platform, then following up on others and taking advantage of the lessons previously learned. Executed properly, the essence of “make it work” and “make it right” can be captured on a single platform and duplicated on all others. Essentially, platforms stagger feature development, with one platform taking lead on a per-feature basis. Platforms can return to parity in time for major milestones, but still gain large efficiencies from this staggered approach.

Adapting To Change

Due to the standards of Agile development, as well as the rapid pace of the feedback loop between producers, designers and developers, it is crucial that all moving parts are close together.

Diagram

  • Allow developers to review early versions of the design
    • Discover technical limitations and false assumptions
  • Designers should review builds as frequently as possible
    • Consider implementing continuous integration so that designers will have immediate access to builds when they are released.
  • Do this tic-toc maneuver as many times as possible given the time constraints, but decide in advance how many cycles seem reasonable for a given sprint - too much feedback can lead to diminishing returns and wasted cycles.

This is best realized by meeting in person, discussing what went right and wrong, and welcoming changing requirements.

Integrating with Design

We approached the GameStop app with designs that established major patterns on iOS first. Android designs were then crafted based on the platform-agnostic flow established on iOS, but notably utilizing Android-specific design language, such as bleeding-edge Material Design. This is an efficient process which allows for a great deal of asset reuse while still resulting in an experience that uniquely represents each platform.

It is important to note that Android designs were not ported from iOS - a port is a shallow reuse of designs from one platform that accounts for neither the design language nor idioms of the target platform. Ports are ugly, and simply porting designs from one platform to another would severely undercut the benefits of parallel native development. The goal of the staggered design approach is clever reuse of high-level, platform-agnostic patterns. iOS usually takes the role of lead platform, not because Android is a second-class citizen with regards to design, but because one platform must lead in order to preserve efficiency and consistency. Involved business interests often favor iOS, though the process is not altered if another platform takes lead.

Wrap Up

When the process comes together, it results in apps that are consistent at a high level, yet uniquely representative of each target platform. Users respond well to these apps, and when users are happy, businesses are happy. That said, words are cheap - pictures are pretty:

Figure 1

Figure 1: The most significant differences between the platforms can be seen in the global navigation strategy. iOS (Right) retained the standard Tab Bar while Android (Left) utilized the new material inspired Toolbar.

Figure 2

Figure 2: Both apps shared a sliding Dashboard - on Android (Left) a Navigation Drawer. This functionality was one of a few design concepts taken from Android to iOS (Right), since both platforms support similar structures.

Figure 3

Figure 3: The search bar was moved into the Toolbar in Android (Left) in order to maximize screen real estate for map viewing. Ultimately, iOS (Right) couldn’t utilize this functionality because search and cart icons are persisted globally in the Navigation Bar.

Figure 4

Figure 4: Many of the screens, even those with complex editing and paging behavior, could be made consistent on both platforms with minimal UI modifications.

Figure 5

Figure 5: Here is an example of using the best native component for the specific task at hand. The Android Spinner (Left) and the iOS Segmented Control (Right) are used to select sorting options for product search.

a Ludomade article

Share on Facebook Share on Twitter