[emmett]

In every company I know where there is a capable web programmer and a capable iOS programmer adding the same features to their apps (supported by a shared backend), the web programmer is an order of magnitude faster. There's no peer reviewed studies on this subject but my anecdotal evidence (from advising dozens of startups through YC) is all on one side.

[randomdata]

Does that not come with a big "it depends"?

If you're trying to duplicate a document-centric interface on iOS (without using UIWebView), you are in for a lot of work. Similarly, if you are trying to duplicate an application-centric interface in the web browser, you are in for a lot of work.

There is overlap, of course. If your solution is document-centric you can simply use UIWebView on iOS. If your solution is application-centric, there are a number of Javascript frameworks that look a lot like UIKit in design. This should reduce the difference as the tools end up being similar, no matter what the target. Cappuccino even lets you use much of the Apple toolchain, including Interface Builder, while targeting the browser.

If each platform gets its own independent solution, it is going to largely depend on the complexity handed down by the designers. If the web version comes with less design complexity then it will naturally be easier to implement.

[markerdmann]

An order of magnitude? Do you really mean that you've seen iOS programmers spend 10x as long on something (e.g. 10 months vs. 1 month)?

Let's imagine a simple, specific example: you want to add a button that sends a message to the shared backend and displays an alert upon success. Let's walk through the code.

In your web app, you could add an HTML button, style it with CSS, and then use jQuery to send a request and define your success handler. Probably not more than 10 lines and a few minutes (depending on much time you spend with the CSS).

In your iOS app, you could add a button with Interface Builder, link it to a method on the relevant view controller that sends an NSUrlRequest, then add a delegate method that displays a UIAlertView when the response returns successfully. Again, not more than 10 lines. And no CSS, thank god. :-)

Where is the extra overhead that you're talking about coming from?

[emmett]

Perhaps a binary or ternary order of magnitude, rather than a decimal one. 10x is probably an exaggeration I would say typically it's more like 2-4x.

As I'm not an expert iOS programmer, I'm not exactly sure where the overhead comes from. Given the bugs that are usually present in iOS apps, the tricky bits appear to be:

- Handling screen reorientation

- Making scrolling smooth (it's easy to load either to lazily or too greedily)

- Making it feel "snappy"

- Not segfaulting when you have an error

The web executes on hardware far faster than mobile does so you have a lot more leeway to be sloppy. Ditto for the fact that web apps can't segfault, and it's hard to actually crash a browser.

Another really important point: Doing things on mobile is easy, almost as easy as the web. Doing things WELL on mobile is much harder comparatively because the platform is lower level and less powerful.