I’m very squarely on the “Native is best” side. Obviously if you don’t have the funds/expertise to make a native app then you’ll choose web – but I would wager this is only viable if you don’t actually want to make money out of the app. Unless you have some amazingly compelling content (like pictures of naked people) that can not be got at by native means.

The thing is, I’m not really interested in arguing this any more as its a classic polarized debate like the Mac/PC or Linux/Windows ceaseless arguments. However most people in web development seem to be very anti-native, and as I’m often the outsider in such things, but also sometimes right, I need to set out my stall so that I can try to keep my mouth shut in any more such discussions!

Let’s get this straight. Web is the perfect platform for presenting documents. It is what it was designed for. Everything else has been a hack. We have many very clever and useful libraries such as jQuery to make web application development half-passable. However anybody who seriously thinks these are anything close to a great development platform is chugging on a crack pipe.

Or not an actual developer, but a web site designer who wants to cash in on making mobile apps.

Before you stop reading – I’m a web app dev of many years, and also did more than my fair share of mobile development.

The Web is no cure-all, it is an ugly hack of document rendering turned into interactive UI paradigm. The only selling point for it is that it is cross platform. But your experience – even on powerful desktops – varies widely based on CPU, RAM, and browser – it is simply impossible to make great cross platform apps because to do so is to ignore the native OS paradigms, or poorly mimick them.

Why is it that we are still amazed when someone creates some “fast” game in JS and CSS, or creates some amazing new visual trick like… and animated background or … 3D!

I means seriously, WTF people? We were doing this stuff on ATARI ST when I was a teenager (> 20 years ago), and this still gets a “wow” when somebody manages to make the godawful browser tech stack do the same using CSS and JS? That’s not progress, that’s a SHITTY PLATFORM FOR APPS. Its like we all became stupid and forgot everything that goes on in the rest of the tech world once the web hit.

We’re amazed when stuff like this is done because its so damned hard to do anything good in a web browser. That’s why designers and animators used Flash so much and cursed us for a decade. It is nothing more than triumph against adversity.

The native OS paradigms (visual or otherwise) issue is borne out in the great many “Cross platform” frameworks that have existed over the decades. If you don’t know the awfulness of J2ME, or Java desktop UIs (Swing), or Tcl/Tk and all the old C++ cross platform toolkits, you have no idea how bad things get. This is in part a reason why Java never took off even when delivered via the web and is also part of why Android and iOS are eating the lunch of all the other phone O/Ses whose only realistic entry point was J2ME.

Anybody reading this remember WAP? The mobile Internet that was, right on your phone, back in the early 2000s. What a crock of shit. Why? The UI had no personality, and no styling. It was slow and clunky, and admittedly ran on shitty phones with tiny screens.

WAP lost out to J2ME – a lesser of two evils – which you could consider a “native” app vs. WAP’s “web” approach. J2ME won that battle, even though people (like me) had to write sometimes 30+ different ports of the same application to handle different handsets. And we’re not talking just different graphics/screen size here, different data/game levels, different media, different code workarounds to handle bugs and resource limitations.

But still it was better than WAP. You had complete control (if you ignored all the J2ME horrible UI libraries) and could draw pixels. WAP… you could show stuff on screen badly, and maybe submit some forms.

Web on mobile is today’s WAP, in the same way that Native (Android/iOS/Windows Mobile/WebOS) is today’s J2ME. For compelling apps you need to use native stuff. What language you use to write that is less important. i.e. PhoneGap apps that use JS to glue together web UI and native features like location, camera etc are native apps. They are just slower, clunkier, non-native UI and feature-limited compared to true native apps.

The pace of development in mobile devices is now unlike anything we have seen before. 6-12 month refresh cycles of hardware and OS releases means the web will never catch up, not even close.

The ease of development used to be a USP of web sites, but this is most definitely not true for non-trivial web apps. For a start, for anything non-trivial you need a back-end server app and all that entails.

Web developers who think web apps can replace native apps ignore another major issue aside from native capabilities and integration – resources. When was the last time you, as a web developer, cared about how much memory visitors to your site had, or how fast their CPU was?

As a result performance of web applications varies immensely across clients and this matters even for simple forms or content display (layout complexity, images etc). On mobile this is a critical issue. You have to test your web app on every target device your users may be using.

Think about that.

You’re doing that right now for maybe 3-4 browsers across maybe 2-3 OSes (you are, aren’t you?).

Now extrapolate that level of work to every mobile device out there (especially the large number of Androids), as they all have difference browsers and vastly constrained resources, and different pixels-per-inch which affects usability of touch UIs.

Native development doesn’t skip this problem completely, but it gives you a feel for the size of the challenge that awaits you. Using native UI widgets you are at least nearly guaranteed some reasonable behaviour out of the box.

The point is that web development might get you somewhere, but it is unlikely to get you compelling revenue-generating apps unless your product is incredibly trivial and unique – unless you focus, like J2ME developers had to – on the devices that make up the largest market share – so iPhones and hopefully just a few of the Android handsets. Oh and maybe a HP device too, eh? Oh and Windows Phone.

If you are selling an “app” commercially you better be sure you can deliver it in working order to your end user. Make that a “paying” user. Not so many of those on the real web are there.

Many web developers fail to understand that mobile devices are “embedded systems”, it is not just your desktop web available in your hand. The user expectations are entirely different from desktops. Its so frustrating that people don’t seem to get that this is consumer electronics: where you push an ON button and stuff happens right there and then.

You pick up a phone to do something, it has to do it quickly, cleanly and reliably. The user does not see a mobile device as a mobile desktop (though more powerful than PCs we used not too long ago) where its OK to spend 15s loading, bombard them with some pointless screens, download a ton of crap off the web.

Even a great deal of native apps fail horribly at this. They take too long to load, the UX is poor due to excessive navigation etc. I have some laughably bad iOS apps installed on my devices – which occurs because there is no try before you buy / returns policy, a major flaw that needs to be rectified. And if it does get rectified, you better fear for your app-store hosted web apps.

The fact is mobile devices are now so desirable as a platform precisely because of Apple’s iPhone and the native iOS. Web developers may see these as sexy devices they’d like to do stuff on, but everybody else sees these as great things that work better and faster than their old computer, with less fuss and (so far) no viruses – and nobody thinks of these as being like web apps but packaged up. Web applications pull it back to the sluggish land of the desktop. Response time is everything in touch interfaces.

As for native OS integration, whether using HTML5 features (still not fully standardized) or custom JS APIs á la PhoneGap, the features available will always lag behind native apps, and will usually lag behind in performance. HTML standards processes are inordinately slow and protracted. Never, ever expect and quick turnaround innovation from HTML. Just forget it.

“But my app is not performance dependent”. Yes it bloody is. If the user taps or drags stuff and it doesn’t happen in smooth realtime like native apps, you stick out like a shit on the arctic tundra. Remember that your app is competing UX wise with all the great default apps shipped on the device (well at least as far as iOS goes).

“But I don’t need native integration or true native UI”. Yes you do – as soon as you have any form of native competition. And if you are pursuing a market that actually generates decent income, you can bet people will come with native equivalents.

Some people point to WebOS – it’s web based technology. However it is effectively native, another proprietary platform. Its yet another OS to port to. Are people seriously saying that, even if performance issues don’t emerge from this, that they’d like to use all this hacked together HTML/CSS/JS crud we’ve amassed over the last 10-15 years to write apps for a tiny device that can have a perfectly good, fast, tightly integrated app written using the well-documented libraries provided in a native language? It’s a little like writing scalable web app back ends using BASIC. You could do it but… its the wrong tool for the job.

An interesting blip here is Symbian. This was a native OS platform on all the big Nokia devices. However it failed – the crown went to the UX-inferior J2ME platform present on the same handsets. Why? Presumably because there was no commercial marketplace of any worth for the apps (the handsets always featured low in app sales, a very small % of total market), and the devices it ran on were the horrible Nokia bricks that cursed us for the last 10 years, cost a fortune and had bad battery life.

In a nutshell the Web is a pile of cobbled together crap – from an application development point of view.

We can put up with this for true web applications/services as we can’t face writing native Windows, Linux and Mac OS X clients for our apps – it makes us gush when a tool like jQuery reduces the pain level by another 10%. Our users are accustomed to this paradigm, and for many of our apps we don’t need any whizzbangs that require really obscene hacks like Flash for camera access etc. Because their PCs/Macs are a bit of a hassle to maintain they appreciate not having to install apps. They also don’t expect always-on connectivity so settle for “just while I’m sitting at the computer”.

Even with tablets, there is no point making a web-based app for them. Just make your normal site work well on tablets. Desktop users will likely appreciate the improvements too. I can see the attraction of making a tablet-optimized “app” because its reasonably quick and cheap, but really, put that work into your regular web UI. For a Rolls Royce experience for your tablet users, give them a native app if it is commercially sound to do so.

The User expectations of mobile, including tablets are completely different. The device is a tool to get stuff done. In contrast to “I’m now sitting at my computer doing a bunch of stuff”.

Let’s not even talk about battery usage…

Bottom line: Mobile development is really hard work, involves lots of time and testing, the likes of which desktop web app developers have little idea about. Browser wars are nothing compared to real cross platform dev where the end product is high quality.

If you’re going to do it properly, do it native.

Now, please let him fade away gracefully Apple. Perhaps this is happening, what with him not giving the Macworld Expo talk.

Doubts about his health are too damaging to the company and it is really obvious actually that the whole management team at Apple is really on the ball – but this is not widely understood and as a result Apple’s stocks are suffering at every twist and turn of public appearances (separately from the general market problems).

People need to see – gradually, and this seems to be Apple’s plan – that life goes on without Steve and great stuff continues to come from Apple. After all he’s got them to a pretty amazing place. Killer proprietary OS, killer phones, computers people actually want to own as objects, not just as tools.

I hope you’re well Steve.

After much pain and messing around, the problems I had with getting the network of the guest O/S working were related to VMWare and the guest O/S’s fixed IP address.

Even if you set VMWare to NAT mode, it will not notice the fixed IP that the guest O/S is using. What you have to do is change the DHCP and NAT settings of DHCP to use the correct subnet you want, and the correct IP address. You do this by changing the “/Library/Application Support/VMWare Fusion/vmnet8/dhcpd.conf” and “/Library/Application Support/VMWare Fusion/vmnet8/nat.conf” files, so that there is a single IP address in the DHCP range (end of range MUST be start+1).

You then ALSO have to edit the file “/Library/Application Support/VMWare Fusion/locations”  to change the value of – wait for it – VMNET_HOSTONLY_HOSTADDR to the IP subnet you want the “static” IP to be on.

This last step took me a long time to work out, not least because the variable name makes no sense with using NAT mode.