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.
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):
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):
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.
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.
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.
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.
I'll shut up now and write something up once I deploy an app to multiple platforms ;)
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 :)
Im an Aussie, my 'flagship' version is specific to Australian weather. I have weather apps designed for other countries as well.
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.
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.
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.
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
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++.
Performance is pretty good, and the UI is entirely native Android.
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.
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 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.
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.
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.