6 ms·

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

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.

calsy 10y ago
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.
- nachtigall 10y ago
  Mind sharing a link to the app?
  - calsy 10y ago
    https://appsto.re/i6797pt 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.
- bschwindHN 10y ago
  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 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 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 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.
  - sooheon 10y ago
    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?
    - bschwindHN 10y ago
      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-app/ 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 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.
      - calsy 10y ago
        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.
        bschwindHN 10y ago
        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 ;)
ryandrake 10y ago
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++.
- bschwindHN 10y ago
  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.
  - Capt-RogerOver 10y ago
    What is your opinion on Qt mobile?
    - bschwindHN 10y ago
      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.
- jventura 10y ago
  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 https://github.com/joaoventura/pybridge Performance is pretty good, and the UI is entirely native Android.
zerr 10y ago
What about Qt/QML, Xamarin.Forms and in fact Adobe Air/Flex?
- tluyben2 10y ago
  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.
  - zerr 10y ago
    For regular apps. For games there are actually a lot better and more choices.
ponytech 10y ago
> 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 https://itunes.apple.com/app/apple-store/id396101698?mt=8
tluyben2 10y ago
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.
- hn3000 10y ago
  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.
ekwogefee 10y ago
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 http://www.feem.io
- bschwindHN 10y ago
  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.
  - ekwogefee 10y ago
    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.
enlace01 10y ago
what do you think about libgdx?
- bschwindHN 10y ago
  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.

calsy 10y ago

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.

nachtigall 10y ago
Mind sharing a link to the app?
- calsy 10y ago
  https://appsto.re/i6797pt 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.
bschwindHN 10y ago
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 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 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 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.
- sooheon 10y ago
  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?
  - bschwindHN 10y ago
    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-app/ 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 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.
    - calsy 10y ago
      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.
      - bschwindHN 10y ago
        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 ;)

ryandrake 10y ago

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++.

bschwindHN 10y ago
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.
- Capt-RogerOver 10y ago
  What is your opinion on Qt mobile?
  - bschwindHN 10y ago
    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.
jventura 10y ago
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 https://github.com/joaoventura/pybridge Performance is pretty good, and the UI is entirely native Android.

zerr 10y ago

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

tluyben2 10y ago
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.
- zerr 10y ago
  For regular apps. For games there are actually a lot better and more choices.

ponytech 10y ago

> 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 https://itunes.apple.com/app/apple-store/id396101698?mt=8

tluyben2 10y ago

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.

hn3000 10y ago
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.

ekwogefee 10y ago

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 http://www.feem.io

bschwindHN 10y ago
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.
- ekwogefee 10y ago
  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.

enlace01 10y ago

what do you think about libgdx?

bschwindHN 10y ago
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.