Well, lets see, I use Droidlight but that's by Motorola LLC, so maybe ColorLights. ConnectBot (ssh client). Barcode Scanner (I'm not actually sure if this qualifies as 100% native -- but I think it does). Open Camera. K9 (email - there are others, with different strength/use cases). ChatSecure.
Now, these are all Android apps, and few (if any) have iOS versions. But they all have iOS equivalents -- and I don't think most of them would've been as good, as non-native apps.
Note the absence of stuff that works well as a website, like facebook or twitter. For games, I think the choice between native/html should probably be governed by the answer to:"Is it as much fun as html/webview?". This is a good yardstick for other "apps" as well.
For eg hn, there's no need for an app, but of course hn is a pretty terrible web page. There are a number of easy fixes that would make it more usable, especially on small screens, but the maintainers don't care. And that's fine -- it's not accidentally bad, it's intentionally bad.
One could make a similar site that didn't break voting, threading, screenlayout on small screens quite easily. And it should probably be a web site.
One can make a "web app" to schedule meetings (see doodle.com) -- and one could augment that with something native[1]. Or one could make native apps like the ones mentioned above.
Could one make a web-rtc proxy for ssh and allow logging in to edit firewall rules via web browser? Absolutely. I'm not sure I'd want that though. Not as long as web browser security refuses to learn from office macros: unsigned js code, all or nothing execution etc.
There is some middleground, as google docs demonstrates. Personally I prefer content creation/editing to be local, possible to do off-line (with sync) -- and I'd like competing apps to be able to easily share data (via eg: the file system).
Now, that twitter can't be bothered to make a decent web-site isn't really an argument against web-sites. It's an argument against poor web-sites.
Now, these are all Android apps, and few (if any) have iOS versions. But they all have iOS equivalents -- and I don't think most of them would've been as good, as non-native apps.
Note the absence of stuff that works well as a website, like facebook or twitter. For games, I think the choice between native/html should probably be governed by the answer to:"Is it as much fun as html/webview?". This is a good yardstick for other "apps" as well.
For eg hn, there's no need for an app, but of course hn is a pretty terrible web page. There are a number of easy fixes that would make it more usable, especially on small screens, but the maintainers don't care. And that's fine -- it's not accidentally bad, it's intentionally bad.
One could make a similar site that didn't break voting, threading, screenlayout on small screens quite easily. And it should probably be a web site.
One can make a "web app" to schedule meetings (see doodle.com) -- and one could augment that with something native[1]. Or one could make native apps like the ones mentioned above.
Could one make a web-rtc proxy for ssh and allow logging in to edit firewall rules via web browser? Absolutely. I'm not sure I'd want that though. Not as long as web browser security refuses to learn from office macros: unsigned js code, all or nothing execution etc.
There is some middleground, as google docs demonstrates. Personally I prefer content creation/editing to be local, possible to do off-line (with sync) -- and I'd like competing apps to be able to easily share data (via eg: the file system).
Now, that twitter can't be bothered to make a decent web-site isn't really an argument against web-sites. It's an argument against poor web-sites.
[1] http://9to5mac.com/2015/05/14/sunrise-meet-keyboard/