Hacker News Reader

Comment by bschwindHN | Hacker News Reader

Cross platform mobile games when you have C++ skills: Use C++ with OpenGL and share most of the code.

Cross platform mobile games when you need to ship faster and don't want to deal with C++: Unity

Cross platform traditional apps when you don't have a ton of developer resources: React Native (or better yet, Re-natal with ClojureScript)

Cross platform traditional apps when you have ample developer resources: A native app for each platform

Need to ship something quickly that will perform poorly, have weird UI quirks, janky scrolling, misbehaving touch events, and hard-to-debug canvas bugs that only occur on specific devices? Use one of those JS mobile frameworks.

View on HN

Phonegap has great scrolling, touch events work as they should and UI quirks are not a fault of the framework. Maybe just dont make games with it.

I have a successful phonegap weather app with over 200,000+ users in multiple countries. As a solo dev it certainly does the job I require of it and gives me very good return on effort as I can effectively deploy the app to most any platform I wish.

Keep the JS lightweight, use CSS for all your transitions and most people won't be able to tell it's a hybrid app.

Mind sharing a link to the app?

https://appsto.re/i6797pt

Im an Aussie, my 'flagship' version is specific to Australian weather. I have weather apps designed for other countries as well.

I can't argue with a successful app. If it gets users and the users are happy, then you've succeeded.

However, I disagree with with "Phonegap has great scrolling, touch events work as they should and UI quirks are not a fault of the framework"

I just downloaded your app on my Nexus 5 and easily broke the UI with just a bit of button pressing. I don't know if the map is ever supposed to be displayed in a tiny portion of the app at the bottom, but here is what it looked like after some quick button presses:

http://i.imgur.com/AoM5iKf.jpg

Additionally, the drawer list items don't scroll at 60FPS, and the scrolling acceleration is different from android's native acceleration.

The drawer that comes into view from the right (city detail?) also doesn't scroll at 60 FPS and actually prevents the last row of details from showing on the screen unless I drag it into view (at which point it will snap back down when I release):

http://imgur.com/JaZ9lMc.jpg

It's also quite easy to screw up the views with multitouch pinching (which users will notice when they try to interact with your map):

http://imgur.com/ojfcTV6.jpg

This isn't your fault, but it's very hard, if not impossible, to get all this stuff 100% correct compared to a native version. Obviously the majority of users don't notice this stuff, but I just don't think you can make the claims you do about Phonegap.

For new apps these days, if you have to go the hybrid app route, I don't see how someone would justify choosing Phonegap over React Native.

Hi, are you claiming say a re-natal app wouldn't have those quirks? Or at least fewer of them? Any writeups/experiences you'd like to share?

Yes, I believe so. I'm working on an app at the moment which uses ClojureScript on top of React Native. When I finish it I'll write something up. You can see an existing writeup on using React Native with JS here:

http://cmichel.io/lessons-from-building-first-react-native-a...

It basically works by running JS in a separate thread and doing the usual virtual DOM diffing algorithm to determine when to update and swap out native view components. The fact that it uses native UI components is what matters here. You don't have to recreate the behaviors in JS. It simply determines the tree of elements to display, it doesn't do the actual work of displaying them in a canvas. Then the underlying OS will take care of rendering from there.

And then you get the niceness of slicing up data and making network calls in JS or ClojureScript. And if you use re-natal in particular, you get a really simple but powerful application model. You can read about that model here:

https://github.com/Day8/re-frame

I'm sure I'll run into quirks and other weird behavior as I go, but I seriously doubt it will be anywhere near the magnitude of problems you see with JS-canvas frameworks.

Maybe save your judgement once you have successfully deployed your app on multiple platforms and dealt with myriad of issues that arise from your users.

Of course. But you can't deny there are classes of problems you completely dodge by using native UI components instead of a web view, especially when it comes to touch events and scroll accelerations.

I'll shut up now and write something up once I deploy an app to multiple platforms ;)

Sorry, didnt mean to be rude, it's easy to get defensive when talking about your work. I would like to read about your progress.

Not rude at all! I was a little aggressive with the app UI quirks I found.

If anything, your app is a great example that most users don't care or notice non native UIs as much as developers do. It shows the viability of using such a framework. So don't let me get you down, I just enjoy breaking software :)

I appreciate the feedback, always take that onboard.

1. The bug in your first screenshot is completely my fault and not the frameworks. Something I need to look into definitely.

2. While I would like the forecast to scroll at 60fps on low-end Android devices, I do not consider it a high priority. You might not agree, but the scroller works as it should albeit not at 60fps on lower end devices. iPhone5S onwards and later model Android devices run at the desired fps.

3. Multitouch is intentionally disabled on the map view, but if I was to include it I would use something like hammer.js which is a great js library for multitouch support.

I cant judge React Native as I have not had the time to dive into it. I will say phonegap was one of the easier frameworks I have worked with and it has definitely served me well with many users on multiple platforms.

There is no disputing there are many shoddy web apps wrapped up with phonegap and dumped on App Store/Google Play. They instantly leave a negative impression and do affect people's opinions on web apps. However, those web apps that are great, you dont even know they are web apps! They run so flawlessly that it doesn't register in your mind that it is infact a web app and not native.

Since when is a Nexus 5 a low end device?! It'll easily scroll anything in the os at 60fps and there are huge amount of people out there running significantly slower phones.

Again, the scroller works! It's not busted, the app doesn't crash on a large group of slower phones. Many of my users run slower Android devices.

The OP who has a general bias against JS centric frameworks stated that the scroller on his device did not run @ 60fps. I dont have any benchmark results to prove this to be so, so I can only take his word for it.

Now, when someone who has a bias against something, provides an answer to support his argument without evidence, is that reason enough to ditch a framework?

As I have mentioned, I have a large amount of users across multiple platforms and devices. That for me is good enough evidence that people enjoy using the app that is built on the phonegap platform. Are there limitations, YES... give me a framework that doesn't have them.

So enough about phonegap, show me a react native app running on multiple platforms built and managed by one person with large amount of users.

Cross-platform support was very important for my app, and I was the only developer. The app is an offline file sharing utility (1) with no servers involved. I wanted to support iOS, Android, Windows Phone, Windows Desktop, Mac OSX and Linux.

Initially, I built the offline file sharing app natively on each platform. That approach was tedious to build and maintain. It was scary adding new features because I had to do the same thing on every platform the app supports.

Then I did a major rewrite. I wanted at least 90% of the code to be shared across all platforms (desktop and mobile). Looking at React Native, it wouldn't have served my purpose. I ended up with C/C++ (for logic and network) and HTML/CSS/AngularJS (for the UI). Best decision ever.

The app needed a more advanced file browser for users to select files. The app's file browser performed very poorly when I tried implementing it with an HTML UI, and frankly would have required more work to optimize across all platforms. So I implemented the file browser natively on all platforms the app supports.

Overall, this approach has worked pretty well for me. And even though it is not as optimal as going native on each platform, I can fix bugs and implement new features much faster now.

(1) http://www.feem.io

That's fantastic! C++ is totally the right call for that situation, React Native is mostly focused on Android and iOS it seems.

Do you have any articles about your experience developing Feem? I have a project underway that also targets Android, iOS, Windows, Mac, and Linux and I'd be curious to hear how you have things set up in terms of build systems, what was the most painful platform to work with, etc.

Core - C++

UI - HTML/CSS/AngularJS (1.x)

Git - Separate repositories for UI and Core.

iOS - Cordova (just for the initial setup). Modified XCode project to include changes from the Core and UI git repositories. Added some native iOS code. Bridge between Core, Native and UI done with objective C++.

android - Cordova (just for the initial setup). Modified Android Studio project to include changes from the Core and UI git repositories. Added some native Android code. Bridge between Core, Native and UI done with NDK/JNI.

windows UWP - Cordova (just for the initial setup). Modified Visual Studio C++ project to include changes from the Core and UI git repositories. Added some native UWP code. Bridge between Core, Native and UI done with C++/CX.

Mac, Windows Desktop, Linux - Qt. Modified Qt Creator project to include code from the Core and UI git repositories. Added some "native" QT code. Bridge between Core, Native and UI done with Qt's C++.

Browser differences was a huge PITA. It was still worth it, though, compared to writing the same UI in different platforms and programming languages.

If you need more info on the build process, you can shoot me an email. My email is in my profile.

Thanks! Pretty clever to use Cordova to generate the initial project structures.

> Cross platform mobile games when you have C++ skills: Use C++ with OpenGL and share most of the code.

That's what we had done with our iOS game Dino Rush [1] back in 2010.

It was a lot of work to build our own engine, and the additional amount of work needed to port it to Android discourage us. Today even if you know C++ I will only recommend to use a commercial game engine like Unity, Unreal Engine, Lumberyard or Defold, to name a few. Build your own only if you have a lot of resources and very specific needs.

[1] https://itunes.apple.com/app/apple-store/id396101698?mt=8

I'd suggest:

Cross platform traditional apps when you have at least one poor soul who is willing to work with the Android NDK/JNI: shared C++ business logic + minimal platform-specific language for UI.

My view is that unless your app is trivial (say, less than 10K lines of code), it's never worthwhile to re-write the entire app for each platform. Share as much logic as you can with the "common" tongue, C++.

I've worked with the NDK/JNI and totally agree on the "poor soul" comment. If you're someone like Spotify who has enough money, supported platforms, and a complex enough app, then that method is likely a win.

But if you're only targeting Android and iOS, you'll likely get to market faster with something like React Native while still retaining native UIs. It'll certainly be better than Phonegap/Cordova/Ionic.

What is your opinion on Qt mobile?

I haven't personally used it so I don't have much to say. It looks like it requires a commercial license so that doesn't get me particularly excited about it.

I'm also not sure how hard Qt actually tries to give you UI components that look like what you would find in a typical app. If you have Qt experience then I'm sure you can make it work, I've heard good things from people who have used it.

I'm also guessing it has much more consistent and robust UI behavior compared to running things in a web view.

You'll have to find someone who has actually used it though to get a real opinion, I'm just speculating here.

I would go a little bit further and say that, depending on which language you have your code, you can even use C/C++ to make a bridge between Java and some language interpreter. I've done something like that for integrating a lot of existing python code on a Android app I've done. There's a working sample in my github: https://github.com/joaoventura/pybridge

Performance is pretty good, and the UI is entirely native Android.

For games when you want fast and cross platform with limited dev resources including browser; Haxe. Works well for producing fast and flexible code for games.

Would you be willing to elaborate on the reasons that make Haxe useable for games only?

I have been thinking about using it for some cross-platform UI components and would love to hear about the limitations that make it unsuitable for "normal" apps in your point of view.

What about Qt/QML, Xamarin.Forms and in fact Adobe Air/Flex?

For games? Or in general? I worked with both Qt and Xamarin (Forms ane Native) and both work well for apps as you get to know them. For games I would not use them although maybe just an OpenGL surface on either but that is not actually using them.

For regular apps. For games there are actually a lot better and more choices.

what do you think about libgdx?

I forgot about libgdx! It's a great framework and probably would have been perfect for the OP's use case. I'll add another clause to my list at the top.

EDIT: Nevermind, can't edit my root comment now so I'll just put it here:

Cross platform mobile games when you don't want to deal with C++, you don't need a full-blown engine + editor, and you're comfortable using lower-level APIs to get stuff done: libgdx

I view libgdx kind of the same as XNA, if anyone remembers that framework. It gives you the cross-platform abstractions you need (file system, audio, input, graphics) and even goes a little further by wrapping some popular 2D and 3D physics engines. Since it's Java, you can use it from your favorite language that runs on the JVM (looks like you can use Clojure, Scala, Kotlin, even python).

I've personally used it for a small game, and although I never finished it, developing with libgdx was a pleasant experience. You can develop it on desktop so you don't always have to deploy to a phone, and when you're ready it's easy to get it on a device.

Reply on news.ycombinator.com