6 ms·

I built my first mobile app this year (iOS) and I was appalled at how bad the tooling and development workflow for mobile was. Swift is a disaster, the app stor

I built my first mobile app this year (iOS) and I was appalled at how bad the tooling and development workflow for mobile was. Swift is a disaster, the app store approval process feels like going back 10 years in a time machine, debugging XCode is like trying to solve the riddle of the Sphinx, testing is hard, a reloaded dev workflow is non-existent... It's no wonder startups can't get out the door and quickly iterate on mobile. 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.

woah 11y ago
Also, with react native you can push software updates over the wire without Apple even knowing.
- kranner 11y ago
  App Store Review Guidelines 2.7 states: > 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.
  - sportanova 11y ago
    It's allowed - there's an explicit exception for downloading code and executing it via WebKit http://info.meteor.com/blog/apple-hot-code-push-mobile http://info.meteor.com/blog/apple-hot-code-push-mobile
    - kranner 11y ago
      Thank you, I didn't know this.
      - sportanova 11y ago
        Yeah, it's a big deal! Hot swapping!
threeseed 11y ago
I don't really buy this. 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.
- swsieber 11y ago
  Except they don't really force the lowest common denominator. It's not too hard to write a plugin for cordova. Additionally, 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.
- fragsworth 11y ago
  > Javascript and other Write Once, Run Anywhere approaches have always been shown to be flawed. They force the lowest common denominator. 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.
- tlinton 11y ago
  You can access the native objects and interact with them in javascript using Tint (essentially node.js + native-bridge + ease-of-use-wrapper). A little different then "run-in-a-webkit-with-C++-callbacks" mentality (e.g., phonegap, node-webkit), or facebook's "branded-programming" with react native.
kranner 11y ago
You seem to be lumping Xcode with Swift. Have you tried using Objective C? The Xcode support is fine. The debugging experience is fantastic.
- nerraga 11y ago
  I think the debugging experience is the same as just about any other platform that I've worked on. It's not significantly better or worse (I work mostly in C++/VS/Win have recently started work on a mobile project that required me to get acquainted with Xcode). 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.
bottled_poe 11y ago
I agree that the app release process is very poor. I learned recently that the app store review process does not necessarily include a human test. This was a very annoying discovery as it resulted in a dreaded 'release-only' critical bug.
shams93 11y ago
This is so true on both android and ios tooling is a nightmare lately I switched to meteor/cordova but still ios requires an expensive Mac to build which I can't afford.
- irishcoffee 11y ago
  My ignorance may be showing here: can you just run the OS in a VM and compile that way?
  - NeutronBoy 11y ago
    OSX is only licensed to be run on Apple hardware.
    - irishcoffee 11y ago
      Ah I did not know that, thank you.
task_queue 11y ago
You had a point with your first paragraph but fell flat with sentence one of your second paragraph.
- AlwaysBCoding 11y ago
  JS->iOS is the way of the future, beacuse increasingly you can get to Javascript from any language. So for example, if your backend data system is built in Clojure you can get to Javascript via ClojureScript which is a Clojure->Javascript compiler. If you wanted to build a web application off your data model you could use your Clojure data model on the front-end, the final HTML produced is just some web rendering of that data model. 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.
  - task_queue 11y ago
    I don't buy it. This is the same argument I've heard from Node.js proponents. 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.
jaegerpicker 11y ago
I agree about React Native, it basically makes JS a first class language on the platform. I was a native only guy for as long as the platforms have been around. But the chrome dev tools debugging, ability to quickly and easily share code between the web and mobile, and the quick dev cycle is really powerful. I really disagree that swift is a disaster, for the most part it's a extremely well designed language. Great functional tools, great performance, and playgrounds plus a useable repl were all huge steps for the iOS platform.
- AlwaysBCoding 11y ago
  Swift is awful to use in practice. 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.

woah 11y ago

Also, with react native you can push software updates over the wire without Apple even knowing.

kranner 11y ago
App Store Review Guidelines 2.7 states: > 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.
- sportanova 11y ago
  It's allowed - there's an explicit exception for downloading code and executing it via WebKit http://info.meteor.com/blog/apple-hot-code-push-mobile http://info.meteor.com/blog/apple-hot-code-push-mobile
  - kranner 11y ago
    Thank you, I didn't know this.
    - sportanova 11y ago
      Yeah, it's a big deal! Hot swapping!

threeseed 11y ago

I don't really buy this. 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.

swsieber 11y ago
Except they don't really force the lowest common denominator. It's not too hard to write a plugin for cordova. Additionally, 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.
fragsworth 11y ago
> Javascript and other Write Once, Run Anywhere approaches have always been shown to be flawed. They force the lowest common denominator. 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.
tlinton 11y ago
You can access the native objects and interact with them in javascript using Tint (essentially node.js + native-bridge + ease-of-use-wrapper). A little different then "run-in-a-webkit-with-C++-callbacks" mentality (e.g., phonegap, node-webkit), or facebook's "branded-programming" with react native.

kranner 11y ago

You seem to be lumping Xcode with Swift. Have you tried using Objective C? The Xcode support is fine. The debugging experience is fantastic.

nerraga 11y ago
I think the debugging experience is the same as just about any other platform that I've worked on. It's not significantly better or worse (I work mostly in C++/VS/Win have recently started work on a mobile project that required me to get acquainted with Xcode). 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.

bottled_poe 11y ago

I agree that the app release process is very poor. I learned recently that the app store review process does not necessarily include a human test. This was a very annoying discovery as it resulted in a dreaded 'release-only' critical bug.

shams93 11y ago

This is so true on both android and ios tooling is a nightmare lately I switched to meteor/cordova but still ios requires an expensive Mac to build which I can't afford.

irishcoffee 11y ago
My ignorance may be showing here: can you just run the OS in a VM and compile that way?
- NeutronBoy 11y ago
  OSX is only licensed to be run on Apple hardware.
  - irishcoffee 11y ago
    Ah I did not know that, thank you.

task_queue 11y ago

You had a point with your first paragraph but fell flat with sentence one of your second paragraph.

AlwaysBCoding 11y ago
JS->iOS is the way of the future, beacuse increasingly you can get to Javascript from any language. So for example, if your backend data system is built in Clojure you can get to Javascript via ClojureScript which is a Clojure->Javascript compiler. If you wanted to build a web application off your data model you could use your Clojure data model on the front-end, the final HTML produced is just some web rendering of that data model. 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.
- task_queue 11y ago
  I don't buy it. This is the same argument I've heard from Node.js proponents. 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.

jaegerpicker 11y ago

I agree about React Native, it basically makes JS a first class language on the platform. I was a native only guy for as long as the platforms have been around. But the chrome dev tools debugging, ability to quickly and easily share code between the web and mobile, and the quick dev cycle is really powerful. I really disagree that swift is a disaster, for the most part it's a extremely well designed language. Great functional tools, great performance, and playgrounds plus a useable repl were all huge steps for the iOS platform.

AlwaysBCoding 11y ago
Swift is awful to use in practice. 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.