I'm leading a small team in building an ionic app right now.
The edge that cordova/phonegap/ionic will retain is the HTML and CSS part. As well as, at least for a little while, a more robust plugin ecosystem. Though that second one will change VERY rapidly.
The other developers on my team are very much frontend & CSS types.
I would be too much of a bottleneck if I were the only developer able to write the code for the app.
If xamarin were free when I started, I may have given it more time in evaluation, but at the end of the day, I think that the choice would have remained ionic.
Even react-native isn't ready yet if you're a windows based shop. But maybe that's come along in the last couple months too.
> Even react-native isn't ready yet if you're a windows based shop.
Don't forget, Facebook's annual developer conference F8 is coming up next (April 12th 2016). They will surely have some new announcements in a few weeks.
I'm practically in the exact same boat as you and also using Ionic. The only thing I can think of to make me consider migrating is performance. Cordova/Ionic can be slow to handle complicated screens, animations and transitions.
Getting native performance would be a big differentiator. Hopefully, Ionic/Angular 2.0 will go a long way to improving performance.
One database trick I used was to pre-select queries in the background and cache the results. It creates some code overhead for updating/inserting that has to keep the cache in sync. However, it simplified the logic in the rest of the code because I didn't need a promise for a select, I just read the cached object. That allows me to outsource the controllers for screens to developers who don't have to work with promise overload. They access my wrapper service for the content using synchronized code.
My database is also very simple. If you have a complicated schema with lots of joins, it'll be tough to cache things and keep it in sync with the db.
Feel free to email me, if you want more details on this concept.
I wonder if today though, with the licenses costing nothing, if they still would have done IL2CPP. I think there are benefits of it especially on iOS where they need to be sure there aren't future cases where development is blocked. But it was a massive undertaking and almost made Unity unusable/unstable for a good portion of 2015. They appear to have weathered the storm even though they had to recreate AOT compilation in C++ (which spawns massive amounts of files).
Unity was going to go C++ back in the day when Flash/Non-AOT code was being blocked in iOS 3.3.1. [1] I actually wish pure C++ was an option for Unity. Being C++ at build allows Unity to control it's destiny a little more and I am sure the 3.3.1 thing with Apple influenced that.
One interesting aspect is that they make use of C++ inline declarations when doing the JavaScript vs C++ examples, without explaining that there are semantic differences between writing the code like that or .h/.cpp files.
Honestly Cordova is good for beginners. It won't fade away but look for more of a pivot to something like React Native or like Xamarin where it'll compile to native code. Their current approach of running in a web view is great for people tranistioning from traditional web development to app development. However as I've experienced, once you begin adding lots of plugins, things get really hacky or incompatible with each other. That's where Cordova platforms like Phonegap and Ionic lose out.
> - Having an open source alternative like this will be a blow to Phonegap's/Apache Cordova's use for new apps.
Really? Do you think Zuckerberg is now shaking in his boots thinking Facebook will have to pull out of React Native?
> - Let's not forget Microsoft now owns RoboVM. I wonder what this event implies for it.
Thank you for noting this. It is potentially interesting to Clojurians since Clojure targets the JVM (would be cool if Clojure could be used for cross platform native app development with RoboVM, as an alternative to a convoluted mess of trying to use ClojureScript with React Native).
Projects such as Ionic Framework that build upon Cordova will still remain popular becuase they appeal to front-end web developers with Javascript skills. However, Xamarin is a great fit for Windows web developers that already work with C#.
.NET proper has been OSS for a year and a half now (in the form of .NET Core), and .NET Micro Framework, which was specifically created to target resource-constrained devices, has been available under Apache 2.0 since 2009. Since parts of Mono have been available under MIT all along, even if Unity had some reason to favor Mono over the others, then they could have replaced the GPL/LGPL bits on their own.
It's likely that Unity hasn't done any of these things because they need support. This might help, but I'd be unsurprised if the Unity situation stayed the same as it has been for the last few years.
Actually, in my experience phonegap/Cordova was only good untill you have something like background geolocation updates... A lot of hassle and never got it to work. For just basic apps, it's great / easy though
I've built a very simple app in Cordova and I'm now re-building that same app in Swift and animation/transition-wise/UI I don't really feel too much of a difference. I am however having issues with some bluetooth iBeacons and local notifications in the Cordova one so that's why I'm going (and learning) full native. (Swift is great, I really like it.. well at least compared to Obj-C and coming from the JS world)
Why Unity wasn't just able to take LGPLv2-licensed Mono and use it? LGPL doesn't impose any requirements on the linked code (be it Unity libraries or third-party code or anything), it's basically "link with anything you wish but keep this particular library free, please". What was the issue here?
It's not Apple's terms of use. It's how iOS binaries are created. On iOS all the libs must be statically linked. This means the LGPL code becomes the integral part of the app so all of the app must be released under LGPL. If you are fine with this you can have LGPL code in your app. This is one of the reasons if you want to use QT for iOS development you need to purchase commercial version.
It's well possible to statically link LGPL library and non-free proprietary code. You just have to provide end-users a way relink with their own builds of said LGPL library (i.e. give them an .a file with all your proprietary bits, and, if you're nice, a linker invocation command). Yes, this is some significant hassle to set up two-step linking (unless you don't really care about not revealing the internal structure - if you don't, you can just throw a bunch of .objs), but not a complete game-stopper.
Here what FSF says about this:
> If you statically link against an LGPL'd library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application
Cordova is still useful for android, you have api's like web midi that don't exist on native android but can be accessed through the chrome web view on android 5.0+.
- Having an open source alternative like this will be a blow to Phonegap's/Apache Cordova's use for new apps.
- The change in Mono's licensing means Unity may finally upgrade to a newer version of Mono.
- Let's not forget Microsoft now owns RoboVM. I wonder what this event implies for it.