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.
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’.
Our independent tech team has been servicing enterprise clients for over 15 years from our HQ in Bristol, UK. Let’s see how we can work together and get the most out of your Salesforce implementation.
