Facebook for example is releasing new versions every 2 weeks and every day I have updates for at least 6 of my apps. I also have built at least 10 apps for enterprise companies and provided you have decent CI have been able to turn around updates in less than a week. It is a different workflow that's for sure. As for Swift being a disaster well that's debatable.
Javascript and other Write Once, Run Anywhere approaches have always been shown to be flawed. They force the lowest common denominator. And on a platform like iOS where users are very picky about polish they will punish developers who have apps that don't feel right.
React Native isn't write once run everywhere - it's learn once run everywhere. And it interfaces with the real native widgets and has the javascript on it's own thread. That's anything but feeling right. It's more like Javascript bindings than a totally new paradigm.
That's nonsense. Javascript is certainly missing some features for mobile, but it's not because it is designed for "the lowest common denominator". It's because it's an open platform, and the standards committees and browser developers are really slow to keep up with all the devices that we have now.
Unity, on the other hand, works extremely well. Adobe AIR works well too. There are really awesome games made using both platforms, arguably the toughest kinds of applications to make "feel right". You can't just say the "Write Once, Run Anywhere" approaches are flawed when there are thousands of counter-examples on the app stores right now.
It once took me 24 hours to parse a JSON response into a Swift object. In ruby you can get a ruby object from JSON by calling JSON.parse(data)... that's it. It takes one second. In Swift it's a nightmare, it can take you a full day. Who the hell has time for that? Startups are all about speed, who wants to waste a day trying to parse JSON when it's a one-liner in literally every other language ever made.
I also hate using mutable objects for my data model. Swift allegedly solves this with Structs but they're really hard to use in practice. Want to pass a struct through a Notification? Too bad, needs to inherit from NSObject so guess you're stuck using mutable objects?
Swift might be a well designed language from an academic standpoint. I have no idea, I'm new to programming. But I can say for sure that it's horrible to use compared to other languages that I've used in production (Ruby, Clojure, Javascript). I would bet anything that being able to use any language/workflow of your choosing and compiling to iOS native through JS will be a better business decision than coupling yourself to XCode/Swift and whatever hacks you build to make the workflow less painful.
Have you tried using Objective C? The Xcode support is fine. The debugging experience is fantastic.
I'm comfortable with Objective C but I can certainly see the allure of Swift. Having said that, I'll bet that it's less XCode/Swift that is preventing newcomers from iterating quickly as much as the platform itself. Rather than really learn the platform, quite a few devs seem content treating it like browser and leaning on a webview.
I'm thrilled to see where React Native takes us but something tells me I'd have a hard time getting it past the lawyers based on some of the licensing comments I've read here.
Traditionally if you wanted to build an iOS app off the data model, you would need to hire an iOS developer who knows XCode/Objective-C to build a separate application that communicates with your backend through some REST/JSON combination. But with React Native I can just take the ClojureScript components that I'm already rendering on web and give them alternative renderings that target iOS native, because it's all just Javascript/React, and build my app that way. It's much easier for the person who created the initial domain model to build native components in the exact same workflow without missing a beat. iOS native is just a rendering target for your Javascript component just like web is, and you can code it in any language that can get to Javascript.
In a sense you're just building one application, and making it work natively anywhere, instead of building multiple decoupled applications. I am literally betting my future on this being a better way to build mobile applications, I'm sure that it is. The biggest barrier to making it work is the staggered release cycles you need because of the app store approval stop gates, but hopefully that will get cleaned up in the next couple years.
You'd be offloading your development and debugging to a third party tool that will always be staggered behind native development.
You'd be translating your code through a shitty javascript transpiler.
You'd end up hiring javascript programmers with little to no domain knowledge to make apps that feel less than native.
You'd end up having interface with the platform anyway, but through a JS shim.
You'd be putting all your eggs in one basket on a platform known for killing off its dependents. Apple doesn't like what React Native is doing to its ecosystem? You're shit out of luck when they pull you from their market.
Hire a competent person with the relevant experience instead of trying to shoehorn javascript into every problem domain. You'll end up hiring one anyway.
> Apps that download code in any way or form will be rejected
If the platform terms ban it, it doesn't matter if it can be executed technically.
It's crystal clear that using web tooling and compiling Javascript to native components is the way forward here. It's just that tools like PhoneGap, Titanium, Cordova ... were half-baked solutions and never really excited me. This is why React Native is such a game-changing technology. If a startup can get to iOS and quickly iterate without being held back by XCode/Swift it's a massive competitive advantage. Let other companies spend millions and 9 months hiring 'iOS only' developers, and struggling to get a V1 to market when you can take just your existing model layer which is already rendering JavaScript somewhere anyway, and have it target iOS native without missing a beat.
Really interested to see the fallout from React Native, especially once the Android library is released later this year.