|
|
|
|
|
by markerdmann
5096 days ago
|
|
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? |
|
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.