Why Native Apps Really are Doomed: Native Apps are Doomed pt 2
Eric Elliott
2.4K158

The author is focusing on revenue generation opportunities. Let me talk a bit about development costs (complexity, effort and duration).

My company was in a unique position to develop a native app along side the development of a Cordova hybrid app. Two teams were given the same specs and started on the same day. Both teams were new to the project and did not have any domain expertise advantage over the other.

The Hybrid team consisted of 5 members (4 javascript developers and 1 project manager).

The Native team consisted of 2 members (1 Android developer and 1 project manager).

Both teams shared the same designer and design assets (wireframes, mockups and scalable SVG assets)

Note: the goal was to release an Android app only for v1, then support both iOS and Android for v2.

SETUP

The Hybrid team had to defer development until the Cordova toolchain was prototyped and finalized. This consisted of picking the package manager, flux/react frameworks, CSS blueprints and build tools.

The Native team was able to start coding immediately with a well defined toolchain based on Android Studio.

DEVELOPMENT

The Hybrid team spent considerable time getting react/flux to work with local models and responding to server updates.

The Native team was able to leverage well-defined Android best practices for networking and local caching of data. While not built with a react pattern, the app business logic was implemented using content providers and utilize many OSS projects to achieve offline caching and data consistency throughout the app.

TESTING

They Hybrid team spent considerable time dealing with browser fragmentation (even from the same manufacturer and Android OS version on different devices). The same JS/CSS rendered differently between devices.

The Native team did experience fragmentation, but for the screen layouts and not for rendering of Android SDK controls. The layouts were made adaptive to support different screen aspect ratios and consistency was achieved pretty quickly.

As a result, QA effort for the hybrid app exceeded the effort of the native app.

EFFORT/DURATION

The project had a hard deadline of 6 weeks from start to MVP that satisfied 14 use cases.

The Hybrid team was able to complete 10 of the 14 use cases in 6 weeks. With the 4 person team working full-time, the team consumed 4 * 40 * 6= 960 man hours.

The Native team was able to complete 14 of the 14 use cases in 4 weeks. With the 2 person team working full-time, the team consumed 2 * 40 * 4 = 240 man hours.

The Hybrid team was asked to complete all use cases taking an additional 2 week consuming a new total of 4 * 40 * 8 = 1280 man hours.

OBSERVATION AND THOUGHTS

The Native team took 18.75% ((240/1280) * 100) of the time that the Hybrid team. Or said another way, Hybrid development took 5.3 times (530%) the effort of Native development.

But the Hybrid team was larger, resulting in more communication and coordintion! True on the surface, but the PMs and developers noted that overhead was minimal and did not significantly impact deliverables.

But the hybrid app was out-of-the-box ready to run on iOS from the same source. True and not so true. For the most part, non-UI hybrid code worked between Android and iOS. But there were enough differences between Mobile Chrome and Mobile Safari which required UI/UX specialized coding for each. Assuming HTML just works, especially considering scrolling and advanced animations, was not our experience.

Even if we doubled down on Native developers (1 iOS and 1 Android) resulting in 3 * 40 * 4 = 480 man hours. Hybrid development would then have taken 2.6 times (260%) the effort of Native.

Aren’t Hybrid (js/css) developers cheaper than Native developers, resulting in a lower cost? In our case, we had the same compensation for all resources. Both teams were filled with Sr. Engineers with years of experience in shipping products. On our projects, the price for rock star experience did not change based on specific technical skills. There is a benefit of being able to standardize on one skillset and re-use/reallocate those skills across multiple projects, but typically only large organizations, publishing a suite of apps, would benefit from multi-project resource allocations.

SUMMARY

Most companies assume that write once — publish many is more cost effective than write many — publish once. In our specific real-world test, this was not the case. Hybrid development takes 260% more effort man hours than Native development. You may have different experiences, but based on this unique test, Native was more time/cost effective than Hybrid.

Only looking at install friction and the resulting install base is but only 1 aspect of a profitable app business model. Taking into account development costs, marketing, discovery, engagement and perceived user value are the true factors that determines if an app has a viable business model.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.