alphalist Blog

Creating a Mobile Version of an Ecommerce Web App: Native vs. Containerised SPA

Share

Based On Podcast Featuring:
Aron Spohr // CTO at FlaschenpostAron Spohr // CTO at Flaschenpost

Aron Spohr // CTO at Flaschenpost

Episode #63

If you run an eCommerce web application and are tasked with creating a mobile version  - you have 2 options - either have a separate Mobile team code and maintain a natively written mobile app OR containerize your web application so you can continue to use just one application. Aron Spohr, the CTO of Flaschenpost, runs a flourishing grocery delivery service in Germany, and in a recent alphalist CTO podcast he discussed why Flaschenpost runs their mobile app in a hybrid way instead of employing a separate Mobile team to code it natively.

Table of Contents
  • The background
  • Does an all-in-one descriptive language exist?
  • The Inefficiencies of having both a native mobile app and a web app
    • A/B Testing Among Different Teams
    • Quick Fixes
  • Do you need a Native app for ECommerce?
  • Behind our Hybrid setup (Native + Web App SPA)
  • Case by Case Basis: Facebook's HTML5 > Native experience

The background

Ideally, if I was starting from scratch I would start with mobile-first - 100% native apps. Flaschenpost started with a desktop version and the desktop version continues to be popular - especially in offices. We anyways need to maintain a web app version. Should we create a team dedicated to mobile as well?

Does an all-in-one descriptive language exist?

It would be fun to dream up with developers a kind of descriptive language that allows one to render it natively and also on the web. But then if you take that two steps further, you end up with HTML.

The Inefficiencies of having both a native mobile app and a web app

A/B Testing Among Different Teams

We tried having a 100% native mobile app.  But the problem was that since we were doing so many AB tests  - experimenting with e.g. the way we present the items, how we present the prices, etc.- it was a lot of work for the app team actually to catch up with what was happening in the other teams with the webshop. We realised that because the Mobile team always needed to reimplement the same stuff the Web team was doing - they were always behind. Therefore we decided to let us use the same web app. I think mobile is just another way of representing or generating a view of the same stuff.  So from a technical point of view, I find it very fair, and if I was tasked with creating a mobile app when I already was maintaining a desktop version - I would definitely just use a containerized web app. 

Quick Fixes

Using just one web app gives us a lot of flexibility and agility - particularly when it comes to quick fixes. For example, recently PayPal’s Express CheckOut was offline for 6-8 hours. It is something we use so we couldn’t wait for them to fix it. We had to make a workaround.  What did we do? We created something in Google Tag Manager which would phase out the PayPal button and would explain to our customers,”Hey, PayPal has some problems, please don't click here, use some of the other payment methods.”. This was implemented in approximately 10 minutes with Google Tag anager and was visible in the app and on the webshop right away.  This is one of those great advantages you have if you have that on one platform. With a web application, you can just hack that with some JavaScript but with a  native app, it would have been a totally different story.  We would have needed to change the codebase, and have the update reviewed by the app store before we could release it. That is if it didn’t break. 

Do you need a Native app for ECommerce?

I agree with what Tobias Schlottke said on the podcast. In most cases, an eCommerce store is about rendering - delivering information, and showing items. A web application does rendering quite well. Therefore in most cases, a web app is enough for an eCommerce service. There are great frameworks for mobile and AP tools you may be missing, but having two separate teams for web view and a natively built app often means implementing the same thing twice (or even three times if you consider iOS and Android). 

Behind our Hybrid setup (native + Web App SPA)

Flaschenpost currently has native apps for iOS and for Android, but they are utilizing our single-page application (SPA) we have. It's a mix - a container in a way. A hybrid setup in which some features are native and some actually from the Web View. It works for us. Though to be honest, it was tricky to find a way to communicate between the native app and the containerized web app. We might even have some small bugs because of it.  But the most important thing is that our users experience it as a mobile app. 

Case by Case Basis: Facebook's HTML5 > Native experience

It's not a one-size-fits-all approach. As Tobias cited, 10 years ago Mark Zuckerberg said that building Facebook on HTML5 and not focusing on mobile-first Native apps was a billion-dollar mistake. It made a lot of sense for a company like Facebook to code their app natively due to the nature of their business and the technology available at the time. Every company would need to decide what makes sense given the cost of maintaining 2 teams.

Conclusion: If you already have an eCommerce web app and want to release a mobile app, it is much easier and sustainable to just containerize the web app SPA. This way you don’t have 2 teams doing the same work and you can make changes that affect both.