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.
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.