1. 12

  2. 12

    This is a great writeup of many options. In my opinion, it misses one, though: writing a core application library in a runtime-less language like C/C++ (or Rust) and then a UI on top.

    I’ve seen that happening multiple time to various degrees, one even going as far as having their own “views”, which basically served the data in use for the application views to the frontend.

    1. 8

      […] core application library in a runtime-less language like C/C++ (or Rust) and then a UI on top.

      That’s what we do at work.

      The non-UI parts are implemented as a cross-platform C++ library, while each platform gets native UI adhering to platform conventions.

      It works reasonably well, and I think we deliver solid products to our 100M+ users.

      one even going as far as having their own “views”

      We’ve been moving more of this logic to the backend, with what we call “view aggregation services.” So instead of clients requesting the pieces of data they need to assemble a screenful of stuff, the backend takes care of most of it, and the clients just need to display it with appropriate UI components, almost like specialized web browsers.

    2. 2

      I have spent most of my career working on native software, on different platforms, and have used the “native provides native experience” argument (from the article: “Different platforms are different”) before. Now I find myself questioning it.

      Why does each platform provide a distinct experience? We know that it can’t be because the target audiences are different and require different experiences, because all of the platforms under discussion here are mass-market platforms and sold to the same groups of people. Presumably the reason is part market differentiation, and part IP differentiation following the “look and feel” lawsuits.

      What we also know, based on this plurality of different experiences, is that if it is possible to use psychology and HCI principles to define “an” objectively ideal user experience for some interaction mode, then at most one of the competing platforms implements that ideal so mostly following the UI guidelines would mean doing something suboptimal. This is both spatial (at least one of iOS and Android is suboptimal) and temporal (at least one of iOS <7 and iOS >7 is suboptimal).

      Further, we know that the people who created the interaction guidelines were either considering their apps or all apps, not my apps. In the real world, talking to my friend, opening a bank account and writing a diary entry are three different interactions with three different processes to engage with: people manage to navigate all three without confusion. For an iOS user, we are saying that they should have similar interactions, but that those interactions should be different from those for an Android user completing the same tasks.