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.

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.

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?

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.

Even if that's true, you are developing for one platform so the comparison is a bit disingenuous. Mobile development is made slower because of fragmentation, not the tools. Unless you've magically found a way to port your apps over to Android and Windows Mobile..

Windows Mobile is a bit player still, doesn't matter for startups (or non-startups).

That leaves you with Android and iOS. Most startups can start with iOS and add Android later -- there just aren't the sales numbers to prioritize Android development.

So we're back down to one platform, with native development providing definitively better results with less time.

Supporting differing platforms is not ideal, but somehow we built the entire PC industry on top of this concept, and it worked out. Maybe we should be looking at ways to bring ObjC code bases over to Android, or something that would let us re-use non-UI code.

But most startups aren't built around making money off direct app sales anyway so Android sales aren't the issue.

If you're an Instagram or Pinterest or Flipbook the Android userbase it way too big to ignore.

If you're an Instagram or Pinterest then you have more than enough money to target Android natively, and provide the best experience possible.

If you're not one of them, then there's more than enough of a userbase on iOS to start with.

I've been doing iOS for a year now and it's just painfully slow for anything involving a database or doing a lot of web service traffic, which seems to be most apps these days.

I'm actually looking into Monotouch now because C# is just so much easier for anything beyond snapping components together snd because every client wants an Android port now.

Parse.com :)

Parse is great but it doesn't help you talk to existing web services or deal with Core Data on the device.

Same experience here. I'd say iOS development is probably about %50 faster than web development for me. Maybe %100-%200 for complex apps.