Why we went native…

By Ben Hinman, Software Architect, Marval

 “I think subconsciously people are remarkably discerning. I think that they can sense care.”
- Jony Ive

When we began building our enhanced MSM Mobile app, we were committed to building it as a progressive web app. We believe that progressive web apps are the future of mobile and we wanted to skate to where puck was going to be. However, we quickly realised that this was going to be very difficult given the current state of mobile web browser support for web components. In addition, we found that scrolling, animations and gestures just “felt wrong” in mobile web browsers. For some apps this would be OK — an acceptable trade-off for a single codebase, use of an existing skill set and overall speed of development. However, much like Jony Ive, we believe that our customers can sense the care we invest and we wanted to honour that with a first-class user experience.

Why not cross-platform?

Once you decide to “go native”, you need to decide on whether you are going to write separate apps for all your target platforms, or write a cross-platform app using development tools such as Xamarin or React Native. We decided to write separate apps.

At a conceptual level, our app is primarily concerned with communicating with a RESTful web service, based on the Avalon+JSON media type. The Avalon+JSON media type allows our RESTful web service to drive our user interface. This means that apart from the user interface components, we have very few code-sharing opportunities.

Sharing user interface component code is hard. Whilst you can do this with tools such as Xamarin.Forms, we ultimately decided that we didn’t want to base our user interface on an additional abstraction. Taking on a dependency carries risk. Base libraries often have bugs that require workarounds and adding an additional abstraction would not only have made these harder to work around, it would have likely brought its own bugs that we would have had to work around as well.

Why not hybrid?

We could have written a native app that wraps a web view. Some apps try to mimic the look and feel of native controls using HTML and CSS, whilst others simply use web views to display content. Trying to mimic the look and feel of native controls is hard and apps that do so often “feel wrong”. Given that our app’s user interface is primarily concerned with navigation and forms, we didn’t see any additional value in adopting a content-only hybrid architecture at this time.

But you’re not using any native capabilities!

Not yet, but by writing native apps we have kept our options open. We have big plans for MSM Mobile and hope to share these with you soon.

Final Thoughts

“Sometimes you make the right decision, sometimes you make the decision right.”
- Phil McGraw

Only time will tell if we made the right decision.

Web component support in mobile web browsers has improved dramatically since we started development and we still believe that progressive web apps are the future of mobile. However, we were able to deliver a first-class user experience to our customers much faster by going native.

Ultimately, we believe we made the decision right.