Know your apps from your apps
Having just been at Dreamforce 2013 with Desynit, we have all come away with bright, wide eyes, staggering forward repeating the word “app, app, app” like a mob of geeky zombies. Filling the “app gap” has been cited as our number one priority, and the new Salesforce1 Platform has basically been given to us as an incredible “free tonne of bricks” to start doing this.
But it appeared during discussions that this concept is starting to confuse a few people, and after a few whiteboard sessions explaining similar concepts over and over, I decided a blog post was in order on “what is the difference between an app, an app, and an app?”
It’s a good question actually, and typically we use a couple of pre-cursors to help us separate the types of app, and it’s important you know the difference before you go applying the term to your business.
The traditional, and predominant use of the term “app” is referring to what we technically call a “native app” and these are specifically (and expensively) written pieces of software designed to run on a certain type of device. Everything you download from the AppStore™ for your iPhone™ is ultimately a native app for your Apple™ devices.
These native apps are written in the appropriate programming language for the device they are intended to run on (ObjectiveC for Apple™ devices, Java for Android etc.etc.) and are typically fairly difficult to port between the different devices. They communicate with your Salesforce org via the various APIs sending data back and forth over secure external connections.
They are also written, compiled and released at a set moment in time, and do not change from that point (other than by lengthy update processes). This means if your underlying Salesforce data structure or business processes change, your expensive app might become redundant.
One worldwide example of a native app could be seen in downloading the Facebook app available to almost every mobile device in existence.
The second most common use of the term is referring to “web apps” these are slightly newer to the scene in their most popular format as it has taken longer for mobile and tablet devices to consistently come up to speed supporting the predominant technologies, HTML5 and CSS3.
The key to web apps is that they are not “downloaded” and stored on the mobile device, but are instead “accessed” – typically though the phones standard web browser – and are so cleverly written they provide a rich and functional experience. The actual compilation and markup is generated by the webservers, off on the internet, and the interfaces then rendered out by the phone. A lot of interesting libraries and technologies exist (such as Dojox.mobile and PhoneGap) that can detect the “type” of device being used and then make the web page mimic the native control’s appearances giving the user a very consistent experience, but in fact actually running almost no logical code on the device at all.
Some of the huge perks of these apps is that they quite simply run on any device that can access the internet. They can be seamlessly updated on the servers, and the user receives the updated version immediately, and because they are probably typically provided by, or hosted on the users core system, have unrivalled access to the company data.
An example of a web app can loosely be seen by accessing the facebook website on a mobile device (typically accessible on http://m.facebook.com) – you will receive a rich and integrated Facebook experience, but without a native app, purely through the browser.
The final kind of app a user might experience is called a “hybrid app” and you might not be surprised to hear that this is a mixture of the two app types mentioned above. Hybrid apps – such as the latest and greatest Salesforce 1 Platform typically have a native container, that the user downloads to their mobile device, but this then delivers rich web content through windows, or frames to the companies web service.
Hybrid apps, whilst therefore still limited to distribution through appstores on the relevant hardware (basically – sorry Blackberry users) can harness the full power of the devices features and hardware, whilst delivering an up-to-date web services.
In summary
The original interpretation of the term “app” being a native piece of software for a phone, is – in this developers opinion – possibly now one of the more restrictive and life-limited meanings. The huge cost and limited flexibility means that unless you directly intend to take advantage of the increased local processing power/storage and access to the device hardware it really isn’t the most sensible option any more. I am convinced that more and more apps will at the very least be naturally evolving into Hybrids, the incredible power demonstrated by Salesforce1 shows how you can be seamlessly passed between native and web services without any interruption or hassle for the end user.
This post originally appeared on Simon’s own blog, ‘The Simon Lawrence Application Development Blog’.
Thanks Simon. I certainly number myself as one of the confused when it comes to shades of app! What’s the difference between a web app and an online tool on a fully responsive website? Hope you can help. Sonja
That’s a really good question Sonja, and one that could probably spark a geeky debate lasting hours! I will save you from that though and give you the CliffsNotes on my opinion of the matter.
Technically, a well written, and responsive website could be described as being a “web app” yes. I personally think though, that the mobile experience of the web service should at least offer up some bespoke channels of appearance and functionality designed exclusively for mobile users – rather than just “being a website that works on a mobile device” (- contentious statement warning! -)
I suppose, in the blog post, I used “Facebook” as an example of a web app, and I do think this is a good example, because if you visit facebook.com on your phone, it will detect you are mobile, redirect you to m.facebook.com and from there you receive a completely different navigational structure, forms and their submissions are simplified for mobile users, and the whole look and feel is designed to mimic that of the native app (unless you’re on a bloomin’ Blackberry) – this to me is a true Web app. You can tap through to the “full site” which will take you back to http://www.facebook.com and display the full site, which will respond to your browser/screen size etc.etc. but although this then “works” and is indeed responsive, I don’t think it would/should be considered a web app in this form.
Crickey! Hopefully that helps and does not just confuse you more!! Please throw any more questions my way and I will answer them 🙂
My company currently offers a hybrid app for our customers to use. We have developed and will be releasing a native app to replace the hybrid but for a few months we will have both apps in the app stores. How can I name the new app so customers don’t get confused as to which one they should now use?
Hi Kara,
I suppose one way to differentiate the apps could be to put
“(iOS version)”
and
“(Android version)”
After the app name for the native versions on the appropriate app stores, and most people would probably figure that this is the specific download for their device. However, this does mean, as you move forward (and the hybrid app is deprecated) the apps will then have kind of funny looking names. Therefore, perhaps a better move is to keep the clean, core name of the app for the new native version and attach
“(web version)”
To the end of the older hybrid app. Though not strictly true – from my very own blog post above(!) – this might help people realise this version of the app is not going to be entirely encapsulated on their device (and indeed, when presented with “an app” and “an app (web version)” – I think you would find most people would choose the native download, which would help drive people onto the newer platform.
That is just a developers opinion though! Probably best to chat with your marketing department 😉
Hey nice blog simon, all points mentioned above are good, great tactical optimization techniques in fact. I would like to add some points which i think should not be missed. While talking about native, web and hybrid apps a big question arises which is the best mobile app development platform for developing an app which leads us to its pro’s and con’s. It depends on what your application is offering, what is the expectation of the users and what are your core development strengths. Hence, choosing the right platform for developing an app can therefore pose a significant challenge.
Right! Many costumers got confused between web application development and native application development but must say both platforms are very important for a business or any other product or social networking.
Thank you for sharing your article. This is very informative article to difference between native, web and hybrid mobile apps development.
Keep it up.