In a series of posts I will elaborate on how enterprise applications can embrace mobile devices.
Apps for end users
Just as there was a (fortunately long gone) time when company executives used to say We need a website there also has been a time when they wanted an app. There is certainly nothing wrong with this, besides the lack of focus. In this and a few following posts I am going to take a closer look at types of mobile apps (the word enterprise is missing on purpose). Talking about this usually leads quickly to a native vs. cross platform debate. While that decision certainly has to be made, I think it should not be the starting point. Other matters ought to be considered first.
The most important question is Who is going to use the app?. Who will be the target audience? As you shall see soon, its quite short answer end users/customers or employees has a significant impact on further decisions. End user apps can be divided into two broad groups:
- apps that solely run on the client (for example games, productivity apps, tools and media players)
- apps that connect the user to some service (for example Facebook or Twitter)
The difference lies in the decision if the app itself is the product (which undoubtedly is the case for games) or the service the app connects the user to. In other words: is the app published to make money or gain reputation, or is it put in the app store to promote the underlying service? The distinction between those two groups may not always be easy. For example, what happens if the game saves a highscore list on the publishers’ servers? Or if a writing app stores its files there? If the app is tied to the vendor, that is, the user is forced to create an account, the app probably belongs to category 2. If the save function is merely an add-on, the app belongs to the first category.
If the app itself is the product, it has to be as good as possible. What this means depends on its purpose. For example, games must be compelling, that is, graphics, sound and gameplay provide an awesome experience. Do not confuse this with the need to provide super-realistic hd pictures. An app that mimics retro style may be equally fascinating. The important point is that the underlying concept has to be convincing. Especially games are usually implemented as native apps. The decision is often based on the need for maximum performance. Other types of client-side apps may not have this restriction.
Apps that promote a service must do everything possible to make that service shine. Depending on its type, the app may need to integrate deeply into the client system. Here, too, a native app is often the right choice. In such a case, though, not the performance matters, but the need to communicate with other apps and components. For example, the client for a calendar service must make events and appointments available to the system-wide calendar. The same applies to contacts.
Apps of both categories may use wireless communications. Usually apps that solely run on the client will need less transfer capacity. If logins to a backend server are made, both groups have to ensure the security of the users’ data. How this can be done is subject to a future blogpost.
This is a (slightly updated) repost of a piece I published on my blog Tommi’s Blog. I deleted the blog in the wake of the GDPR, so the original version is no longer available, or only through the WayBack Machine of the Internet Archive. Please note: code usually has not been updated, so language feature reflect the time the original post was written.