Kudos for this, especially for generalizing from real apps. But I have criticisms.
Declarative approaches are appealing, but lack sufficient flexibility for general use. BTW arguably, browsers are native apps configured by html/css/js.
Html templates in json is unnecessarily confusing. It's unfamiliar and untooled.
Unfortunately, json paths are inadequate for api's in general. They can't extract data from within text, combine, compute, nor use complex sequential api queries to get the data you need. You could add all this, but coding in a data format is awful, compared with a designed syntax like javascript.
Still, it is appealing to have just "one json". Maybe people can live with html in json for that. If you also design the backend (or it's an isomorphic frontend to an existing api), data extraction by path should be OK.
I wouldn't say they're that hard, just awkward for the user. I'm not sure which part you mean, so I'll answer for both.
html templates in json: people accustomed to html have an extra layer between them and the result. It doesn't look like the result, making it that little bit more awkward to use. Tools don't know the json version of the html (e.g. editors with syntax highlighting; previewing the result; authoring tools).
Examples of extracting data: getting part of a date from a date string (or, eg date from date-time string). Also, first name out of a fullname string. Probably solve this class just with a regexp substitute function.
'Joins' are pretty common, where you get data from one part of an api (eg ID of a person), then use this to lookup other data. This could all be in a single json; or require different api calls - even between different api's.
Look, these features aren't hard to implement - and I wouldn't be surprised if you had them already. You could always accrete features as you go, like PHP did - ugly yet useful.
But my objection is that representing code in a data format (json) is very awkward to use. The worst examples are in XML (eg XSLT, ant java build system), but also applies to json.
If you can make it simple enough, for common cases, it's probably workable.
BTW have you seen jq? Gives a taste for features that end up being needed for handling json. And you could possibly just embed it, for arbitrary json processing... https://stedolan.github.io/jq/
BTW1 the role of this is not that different from early PHP - I wonder if embedding code in the template would work here too?
BTW2 Android already specifies UI's declaratively with a data format (XML), though it doesn't read api's etc, and it's IMHO awful to use.
Just to be clear, this is not HTML and has nothing to do with WebView. The JSON is used to directly manipulate native elements like UIStackView, UITableView, etc. and that's the whole point. Hope this makes sense...
Declarative approaches are appealing, but lack sufficient flexibility for general use. BTW arguably, browsers are native apps configured by html/css/js.
Html templates in json is unnecessarily confusing. It's unfamiliar and untooled.
Unfortunately, json paths are inadequate for api's in general. They can't extract data from within text, combine, compute, nor use complex sequential api queries to get the data you need. You could add all this, but coding in a data format is awful, compared with a designed syntax like javascript.
Still, it is appealing to have just "one json". Maybe people can live with html in json for that. If you also design the backend (or it's an isomorphic frontend to an existing api), data extraction by path should be OK.