About Non-Native Tools


#1

So I was browsing some news
Ask HN: How are you building cross-platform (mobile and browser) apps?

I’ve been developing web apps for 5+ years and in my next project I’ve been tasked with building a mobile (iOS and Android) app that we can also run as a web app. I would obviously like to try keep a single code base for simplicity as we have limited resources. I’ve investigated writing a PWA but I’m put off by the arbritrary heuristics that Google are placing on whether or not the apps are presented as “installable”.
After that, it seems the only options are Ionic, or React Native + separate web app.

What is your experience writing apps for both mobile and browser?

to that question, here some interesting comments


https://news.ycombinator.com/item?id=17118657

I use React + React Native for https://www.jqbx.fm. As a 1 man project it seemed like the only sensible way to build mobile (android/iOS) and browser versions. I can share almost all of the code (where applicable) so one can move a lot faster and have a lot less mental overhead.

That being said React Native has stability and performance issues that are tricky and can hold up your app for a non-trivial amount of time. Also staying on top of updates requires diligence and can be a pain. But if you’re looking for the quickest path to market I would say look no further.

well … glad to see someone admit that there are stability and performance issues with React Native

the odd thing is that if you follow the link to the online app, you basically get stuck by a kind of “paywall”
eg. you can only log into the web app if you have a Spotify account
otherwise you can download either a macOS app or a mobile iOS or Android app

So much for the “web app”, I mean think about it, it’s on the web so you don’t don’t have to install anything but it can not be used “by default”, kind of defeating the purpose of publishing a web app.


Then someone mention 3 different tech in 3 different try
https://news.ycombinator.com/item?id=17118900

It’s the third time I have to build the whole stack (web+ios+android).
For the first time, I used a webapp and was hoping that the ios/android experience would be good enough. Unfortunately, It wasn’t and it was a big mistake. I’d only recommend this for quick mvp knowing that it’ll need to be rewritten or if your audience really understand what it means to have a mobile webapp compared to a native app. I.e. if there’s an IT department in place that can install it on the devices and understand the limitations.

For the second time, we went with ionic/phonegap. It was a huge improvement, but we hit too many limitations and scenarios where we wanted native tweaking for animations or handling the keyboard hiding fields or the topbar acting weird, etc. You don’t see those issues at first… but they start appearing as you start doing QA on more devices and with real users. And at that point, you’ve invested so much in trying to make it work that you can’t just go back, so you start piling weird hacks on top of weird hacks.

For the third time, we went with react-native. Overall it was a great experience and unlike ionic, it’s a real native app, not just a webview. We could reuse a big part of the code between web, ios and android. The issues we faced were often related to weird edge cases that are buggy within react-native itself such as input fields not working correctly when dictating or a “pull-to-refresh” supposed to be stateless but in practice being stateful and buggy if you call “refresh” on it twice within 30ms. However, it’s a good feeling to know that when we’ll have the time, we have the flexibility to either fix the library itself or re-write it (compared to ionic where we couldn’t do much and web apps where the solution to most our problems would be to “wait a few years until the browsers decide to improve it”.)

If I had to do it another time (a fourth time), I’d go with react-native again but I would make sure to stress test the libraries with real data on all the devices we’d want to support. Also, it’s popular in the javascript ecosystem to have libraries that depend of another library that depends of another library that wraps another library… in most cases, it’s just better to write a quick wrapper for your app and only include the inner-most library that does most of the work anyway. Otherwise you’re depending on too many authors and libraries quickly go out-of-sync and you’re stuck with old versions that aren’t compatible with new ones.

What I take from it is that a web app is not good enough, something like ionic/phonegap is better but can be hit with many limitations, and finally he mention react-native as a great experience and he’ll use it again.

So 2 comments on that, first if we were in the world were the Flash plugin was not about to get banned from all the major browsers out there I would argue that with the Flash tech it is easy to pull out a fast prototype or MVP and later on you don’t have to rewrite it or port it to another tech to make it into a “real app”.

And 2nd, all the following is quite true

Also, it’s popular in the javascript ecosystem to have libraries that depend of another library that depends of another library that wraps another library… in most cases, it’s just better to write a quick wrapper for your app and only include the inner-most library that does most of the work anyway. Otherwise you’re depending on too many authors and libraries quickly go out-of-sync and you’re stuck with old versions that aren’t compatible with new ones.

lol no kidding :smiley:

So the other great thing about the Flash tech when it come to mobile and desktop app is the way you can extend them with native code eg. ActionScript Native Extension (ANE).

Sure, most dev use ANE as a service (they buy already made ANE) and depending on how they organise their app they can end up with compatibility problems etc (like you would with any 3rd party library).

But in the rare case where the dev develop themselves the ANE to support the app,
it’s where those extensions shine, literally the sky is the limit and so much reuse you would not believe.

Now, just a second to think, what if we could end up having something like Royale that take care of converting that flash tech to HTML-compatible tech (eg. without a plugin needed) and that web target would not be too much of a problem, even if limited, even if much less features, even with no extensions.


Which bring me to the following comment
https://news.ycombinator.com/item?id=17119300

Wow that app is exactly what me & my friends have been looking for. They even started hacking together an Android version of this. Looks really well done!
One question: Do you plan on writing a native desktop solution? I’m not a fan of having to keep my browser open just to run a single app.

oh let’s repeat that louder

I’m not a fan of having to keep my browser open just to run a single app

I’m like the next guy or gal, I love the web, and I do use a lot of web apps (even without noticing it) but there are some apps I would rather have as a desktop app because it is always open or among the first one I open when I reboot the whole damn thing.

That’s why you see me often saying that web app can be ignored (to a certain extend) and why Adobe AIR is still relevant only for mobile and desktop apps.

I mean, sure, if the browsers still allow me to run a Flash Player plugin I can put out there a “web app” where people can experience the app in their browser, but it does not change the fact that a mobile and/or desktop app will be able to do so much more.

In the end, without a choice, a simple video demo of the app (an HTML5 video that autoplay in your face for that matter) can be enough to show the user what it is to experience the app, and later a few hundred MegaBytes or less can allow that same user to have that app kicking and running on their OS (mobile or desktop).

So, unless the app can really benefit from being on the web (SEO, content discovery, etc.), picking a tech just to be able to produce a web app … well … that’s a lot of efforts for very few rewards and a hell lot of limitations.


Later on, finally someone mention Flash/AIR
https://news.ycombinator.com/item?id=17117661

Interestingly, Flash/Air seems most-popular cross-platform mobile toolkit for app dev (far ahead React Native):
https://blog.appfigures.com/wp-content/uploads/2018/03/11-Non-Native-SDKs@2x-1.png
(from https://blog.appfigures.com/ios-developers-ship-less-apps-for-first-time/ )

which point to the blog post
iOS Developers Ship 29% Fewer Apps in 2017, the First Ever Decline – And More Trends to Watch

After our report that the app economy is starting to mature last year, we started getting a lot of questions from members and friends about where the app economy is going. For this post we crunched through millions of new iOS and Android apps released over the years to look at 10 important questions and the data behind the answers.

This article conclude that non-native tools are not taking over, and look Adobe AIR is barely 10%, but look at those other figures

the specific problem on mobile: should you go iOS first or Android first?
and then later on you will have to port the app to the other OS

Adobe AIR cut through that BS right there as you can publish on both iOS and Android first
so yeah those 15% more effort you do at the beginning to test/publish on different OS/devices, they do payoff.

I would even say “don’t publish” if you really don’t want to, but at least test it,
go iOS first and publish only on iOS, but then you have the luxury to say
“hu ho let’s also publish on Android and make an announcement out of it”

which lead to that other graphic

eg.

According to our algorithm that maps apps cross platforms, roughly 450k apps are available for both iOS and Android. This is a fairly decent amount, but when we look at the bigger picture, it amounts to just 8.5%.

I wish there were another one that show the cross section of apps that are also published on Windows and macOS and that 450K number would shrink a lot

How many apps can argue they are published on those 4 platforms: iOS, Android, macOS, Windows ?

I would guess 3% to 5%

And I hear you complaining “but I can not publish a web app with Adobe AIR”

but did you think of those other cases

  • people being fed off by Apple iDevices and moving to Android
  • people being fed off by Google and moving to Apple devices
  • people who use your app on iOS but want to share it with their friends that use Android
  • people who use your app on Android but want to share it with their friends that use iOS
  • people who own an Apple iDevice but happen to have a Windows desktop/laptop
  • people who own an Android device but happen to have a macOS desktop/laptop
  • people who own both an Android device and Apple idevice
  • etc.

there is a strength in being able to publish quasi-native on all those different OS
the web may be the de facto lowest common denominator for cross-platform
but I say you get a better user experience by avoiding it (better UX, better perf, better extensions, etc.)