I've been coding iOS apps for the past 6 months now (after coding web apps for years before that). If anything, I think iOS development is easier and faster than web development.
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.
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?
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.
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.
If you're an Instagram or Pinterest or Flipbook the Android userbase it way too big to ignore.
If you're not one of them, then there's more than enough of a userbase on iOS to start with.
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.