You have 0 control over distribution though, which is pretty important to me.
> There are some amazing libraries for both platforms that you definitely don't want to miss.
I don't doubt that the platforms have good 3rd party support, but it's absolutely dwarfed by that of the web community, and that will only grow larger over time.
Simply having to wait a week to get approved for the iOS App Store (and less on Android) doesn't constitute 0 control over distribution. You can still release the app to the store when you want, if you plan ahead, and pull it whenever you like. Less control, yes, but not zero.
Also, how is this different from writing a non-native app? The same rules apply to distributing web apps if you want them to be in the store. True that you can release it as a website whenever you want, but that's not really the same thing.
You don't have control whether your app will be accepted into the store (like the recent bitcoin apps), you don't have control whether the content in your app will be allowed in the store (such as the many Comixology comics that where banned from being sold).
> Also, how is this different from writing a non-native app? The same rules apply to distributing web apps if you want them to be in the store.
But I don't have to put my web apps in the store at all, I just tell my users to visit a URL.
> I don't doubt that the platforms have good 3rd party support, but it's absolutely dwarfed by
> that of the web community, and that will only grow larger over time.
My take on this is that if you absolutely need the performance, go native and pick the platform you'll get the most customers on. If you're app is a glorified CRUD wrapper, though, HTML5 will probably suit your needs and you'll only have to code it up once.
If you have to enter / search / whatever information in an app which is horrible to use (a BIT of lag can ruin your day; you tap/swipe; because of the lag it just responds a bit late, the keyboard pops for the wrong field or you submit accidentally; plop seconds lost and so is your good mood) all day, you're not going to want to work with crap. It's not 'good enough' even though management might think so.
In both cases I still think you are better/easier/happier/cheaper off building it once and in case 1) giving your employees tablets/phones with the target OS and in case 2) just waiting till you have enough critical mass to warrant writing a version for the next OS.
Not to mention that, in most cases we have made HTML5 'hybrid' apps, we noticed that it takes more time making it uniform and smooth across the plethora of (especially Android) devices than just writing 2 native versions. And the HTML5 version will just never work well on a large amount of 'Alibaba $50' Android devices which surprisingly many people have. Resulting in TONS of bad reviews (if public) and/or very frustrated people.
this was going to be my comment on the original comment: it's not like you have to do only HTML5 or only native, or so i'm given to understand... i'd be interested to hear more about the hybrid approach if anyone has links/blog posts.
If your truly an expert at c# then learning objective-c isn't much of a challenge. At least learning the amount you need to build apps.
Put all the code in a good ui/codebehind separation framework like mvvm, and you are happier than ever.
And I can tell you, from my own experiences, your backend isn't going to be as cross platform as you dream of it being because everything from networking on down is done differently on Android and iOS. Which isn't to say that you can't front-end all of that with a shim in C# or C++ or whatevs, but on mobile, the bulk of the hard stuff is UI anyways and there is no cross-platform panacea as of this writing.
[0] Despite the many claims of "cross-platform UIs," we have many cases in our UI layer of doing different things on different platforms.
It is contentious on HN, but I implore you to draw your own conclusions.
It's actually a pretty cool technology. I gave a talk about it this month at Berlin CocoaHeads, and I'm gonna put some blog posts together about it soon!
First off I agree that native wins over some bundled HTML5 app anyday of the week.
But for many reasons companies still choose to use phone gap or another framework to compile HTML into a native app. The first and foremost reason is that a lot of organizations have plenty of web devs available with skills to build web apps.
Managers would rather leverage the skills they already possess. Believe me I do web dev as part of my job and I still try to make the case that Native is better for mobile. In the end it is cheaper to use developers they already have with tools the devs a familiar with (HTML/JS) than to hire several new devs to code against different mobile OS's.
Right or wrong Managers and Organizations like cheaper and faster.
First, you have the absolute most control you will ever have over your application. This may not be true when a particular tool becomes popular, say at the release of a new tool, but this definitely shows up as time progresses. Who knows what tools will keep up with the native frameworks terms of functionality?
Another reason that is more qualitative, is that you come into contact different design styles, code styles and paradigms. Objective-C, for instance, is a tricky beast sometimes, but it is an interesting language with a lot to learn both good and bad. The new things you learn will most definitely carry over into your web programming!
The third reason to code natively, and I cannot stress this enough, is third-party library support. Maven and cocoa pods may dependency management much better on the mobile platforms, and using a third-party tool will most likely render all those advancements useless. There are some amazing libraries for both platforms that you definitely don't want to miss. They were reduce the amount of time you spend coding and improve your baseline quality.