I think our approach of the ‘virtual vehicle’, represented by a hash/set of metric->value, works well. We have been successful in providing common vehicle metrics for more than a dozen different types of electric vehicle, plus a bunch of other generic types. Overall, I think this is the correct approach, and lends itself very well to the IoT MQTT way of doing things.
Maintaining two separate Apps on two different platforms has been difficult, and the features and functionality are diverging too much.
The v2 protocol is too limiting (especially for new vehicle types, and custom metrics).
I like the idea of providing a ’templated’ approach to the displays in the Apps. We design templates to pick metrics, along with other assets, and display their current values updated in real time.
By leveraging the ‘virtual vehicle’ model, we can also introduce the concept of vehicle sources. At the moment, we are limited to just one vehicle data source - OVMS protocol v2, and to some extent the apps already convert the incoming v2 data into a hard-coded set of metrics, with hard-coded display layouts. The purpose of these vehicle sources is to login to a remote server, retrieve the vehicle data, and store it as the standardised metrics, in the standardised ‘virtual vehicle’. Example sources could be OVMS protocol v2, OVMS protocol v3 (MQTT), Tesla API, Carwings API, direct bluetooth to an OVMS module, etc. We could virtualise these protocols, with a common interface.

We develop a single universal App, coded in a ‘free’ open environment. I have looked at Xamarin and Phonegap (vue-js, and a bunch of alternatives in common use nowadays). My current preference is vue-js, as it seems that javascript and html lend themselves best to the templated display approach - it is trivial to dynamically load this content. That, plus the environment is truly free and well understood by a huge developer community. However, no decision has been made and I am open to suggestions.
The App implements a virtual protocol system. Each virtual protocol talks a particular backend API for a particular account. The virtual protocol then publishes vehicles for the user to choose from. Initially we would write an OVMS v2 protocol implementation, but others (as previously listed) should be relatively easy to implement.
The App implements a virtual vehicle system. Each virtual protocol converts the incoming vehicle data to the virtual vehicle metrics. We can base this simply on the OVMS v3 standardised metrics, but custom metrics also need to be supported. Commands to be sent to the vehicle can also be implemented in a similar way. The OVMS v3 MQTT protocol would be a 1-to-1 mapping here, for example.
The App displays are implemented via a templating system, with templates provided per vehicle type and per screen type (phone, tablet, desktop, etc). The user can customise these templates, using either named virtual vehicle metrics or other assets (pictures, buttons for commands, etc).
I feel that this approach provides an excellent balance. It allows for comprehensive support and flexibility of display for each vehicle type, without complicating the implementation. It also allows owners of more than one type of vehicle (perhaps not all supported by OVMS) to use a single App to monitor and control.