Icenium v1.1 Now Available

Today I am proud to announce the first update to Icenium since our v1 launch a month and a half ago. As a cloud-based solution, we have always planned for a regular cadence of product and service updates – continuous delivery of value, if you will. This v1.1 release represents our first step toward establishing a regular cadence of updates that include new features, improvements in existing features and fixes for any issues discovered (thank you for reporting them to us in our forums). As we continue to develop Icenium, we expect to deliver updates on a regular schedule, starting at about every 6-10 weeks, and eventually accelerating to where we can deliver product and service updates at high frequency.

With this release we have added a few new features, updated support for Apache Cordova and fixed some bugs reported by you. To summarize this release, I will categorize the changes into four buckets:

  • General – Changes and updates to the back-end services, or changes that apply to all client tools.
  • Icenium Graphite – Changes and updates to the installed client for Windows.
  • Icenium Mist – Changes and updates to the browser-based client for all platforms.
  • Icenium Ion – Changes and updates to the iOS development and testing utility.

The complete release notes can be found here.

General

Apache Cordova v2.2

All Icenium projects may now use Apache Cordova 2.2. All new projects will be created using Cordova 2.2 by default. Existing projects can be upgraded to the new version in by opening the Properties settings for a project.

ChildBrowser Plugin

The ChildBrowser plugin has been updated to version 4.0. This version is compatible with Apache Cordova 2.2.

Kendo UI Mobile

The new project template (Kendo UI) has been updated to use Kendo UI Mobile v2012.3.1114.

jQuery Mobile

The new project template (jQuery) has been updated to use jQuery Mobile v1.2.0.

Android Hardware Acceleration

In the project properties you may now select to enable or disable Android hardware acceleration. Hardware acceleration will improve the rendering of UI animations.

OS Version Support in Device Simulator.

OS version selector has been added to the simulators. Changing the OS version can affect behavior of the app.

image

Icenium Graphite

Cut/Copy/Paste/Select All

Cut, Copy, Paste, and Select All commands have been added to Code Editor’s context menu.

image

Reload Project in Simulator

New ‘Reload’ button in the device simulator reloads the current project.

Reorder Open Documents

You can reorder open documents by dragging and dropping the tabs in the order you prefer,

Icenium Mist

Version Control

The version control capabilities of Mist have been improved to parity with Icenium Graphite, including the ability to Clone projects from a URL-based Git repository, such as GitHub, and push and pull changes to and from the parent repository.

image

Find Function

A keyboard shortcut (CTRL+F) will open a Find dialog enabling you to search code files for specifies text. Additional shortcuts have been enabled during Find operations – Find Next (Enter or F3), Find Previous (SHIFT+Enter or SHIFT+F3).

Case-sensitive search and search with RegEx are supported. When RegEx search is enabled case-sensitive search is disabled.

Device Simulator Improvements

Status bar and orientation properties have been added to the device simulator.

Reload Project

New ‘Reload’ button in the device simulator reloads the current project.

CORS Requests

When a CORS request is executed via the device simulator an information message is displayed letting you know what is happening.

Icenium Ion

Ion works with Cordova 2.2 only. A warning message is displayed when attempting to use older versions.

Mobile MeetUp at the Movies

Last night I had the great pleasure of introducing a few hundred mobile app developers to Icenium, and then treating them to a pre-release private screening of The Hobbit: An Unexpected Journey in High Frame Rate 3D. I have to say, I had a blast. The energy level was high, I meet a lot of very cool, developers, and learned a lot about some of the start-ups in the area.

Hobbit Splash - Telerick

I want to thank the organizers and members of some of the Seattle area MeetUp groups for coming to the event, and generally being pretty awesome:

From talking to lots of you as you were coming out of the theater, it sounds like the movie was great – especially in HFR 3D (Sony was onsite ensuring the 4k projectors were in top shape!). Thanks again for attending – see you next time!

IMG_0034

2012-12-13 19.22.39

2012-12-13 19.30.19

IMG_0040

Configuring Icenium LiveSync with the SGS3

Icenium LiveSync enables you to easily deploy an app in development to one or more devices and see changes made–in real-time in both the integrated device simulator and across all connected devices–without having to recompile. In order for LiveSync to work, your development environment must be able to communicate with the device. For Android devices this requires communication using the Android Debug Bridge (ADB). This video shows you how to set up your development environment to enable LiveSync between Graphite and the Samsung Galaxy S III.

This video shows you all the steps outlined in this blog post.

What to Do

The steps outlined in the video are simple and easy to complete.

  1. Install the Samsung Android USB Driver for Windows
  2. Enable Debug Mode on the Device
  3. Optionally Verify with ADB

Install the Samsung Android USB Driver for Windows

This is pretty straight forward. Go here and download the Samsung Android USB Driver for Windows. This is the driver package for many of the Samsung devices, including the SGS3 and other smartphones and tablets in the Galaxy product line.

Enable Debug Mode on the Device

For any device that will be communicating over the ADB, you must enable USB Debugging. On the SGS3 this is in Settings > Developer Options. Check the box for USB Debugging so that there is a green check mark in the box.

Optionally Verify with ADB

When you installed Icenium Graphite part of the installation package included the Android Debug Bridge, which is used for LiveSync communication between Graphite and the devices. You can use ADB in a command line to verify that your SGS3 is visible to ADB (this isn’t necessary, but can be useful if you are troubleshooting any device connection issues).

  1. Open a command line end enter:
    cd %USERPROFILE%\AppData\Local\Temp\ADB
  2. Enter:
    adb devices

You should see a device ID for your SGS3 (for example, in the video mine is 4df1d84539005ffd).

That’s it – you are all set. When you create or open a project in Icenium and your SGS3 is connected, you should see it in the Device list.

Setting Up the Kindle Fire HD 7 for Icenium LiveSync

Since we released Icenium a couple weeks ago, a few folks have asked me if it could be used to build apps for the new Kindle Fire HD. The simple answer is “Yes.” The Fire HD is an Android Ice Cream Sandwich (v4.0.x) device, and Android (v2.2 and greater) is a supported operating system for Icenium projects.

In order for Icenium to communicate with devices over USB, and deploy and update apps, the device drives for those devices have to be installed and configured on the PC. For Apple iOS devices, the device drivers are included in iTunes. For Samsung devices, most of these are in Samsung Kies. For HTC devices, these are in HTC SyncManager. You get it.

But what about Amazon? They don’t have a utility like this.

Setting up the Kindle Fire (1st Generation) to work with Icenium LiveSync was pretty straight forward – download the USB driver, update an INI file and wham-o, it works. Then Amazon released the Kindle Fire HD, which included an updated operating system (the original Kindle was based on Android Gingerbread – v2.3.4) and it was proclaimed to be unhackable. This meant that for developers it was going to be a challenge to work with it as a development device in any way not prescribed by Amazon. Of course the official guidance is to use the Android SDK, platform tools and Eclipse as your development environment. Yuck.

When you plug in a Fire HD, it installs a driver that enables you to copy media files to and from the device, but it doesn’t enable the Android Debug Bridge (ADB) to access the device to install apps. Icenium LiveSync uses ADB for the communication to Android devices to enable deployment and updates on devices (don’t worry, you don’t need the Android SDK for this, ADB is installed in C:\Users\<usernmae>\AppData\Local\Temp\ when Icenium Graphite is installed).

I bought a Kindle Fire HD 7” and began following the unofficial steps to connect to it as a development device. Turns out it was very troublesome, especially if I refused to download the Android SDK. I found a few blog posts that all pointed back to a forum post on how to root the Fire HD, so I gave it a shot. Unfortunately for me when I followed the steps it didn’t work. No matter what I tried, the correct driver would get installed, and the Fire HD wouldn’t show up in the ADB device list.

image

Rather than get discouraged, I experimented and got it to work. The steps in the forum post may work for you, but they didn’t work for me right away. The only ADB driver that I could get to install was the Android ADB Interface (not the Android Composite ADB Interface driver as outlined in the forum post). I had to manually install a different driver (a generic USB Composite Device driver), and then the Kindle Fire HD was recognized by ADB.

image

After that, I connected the Kindle Fire (1st Gen) that I previously had working, and the Android Composite ADB Interface driver magically appeared. I disconnected both Kindle devices and reconnected them and both of updated to the Android Composite ADB Interface driver.

image

Now both the Kindle Fire 1st Gen and the Kindle Fire HD were visible to ADB…

image

…which meant that both devices are ready to by used by Icenium LiveSync.

image

Now when I click on “Run on Device” the app is compiled in the cloud for Android using the Icenium Compiler Service and pushed through Icenium Graphite and over ADB to the devices.

image

That’s it. Now you can test your Icenium project on either a Kindle Fire or Kindle Fire HD. As soon as the Fire HD 8.9” arrives, I’ll give that a test.

And stay tuned for a video series on Icenium LiveSync called “Getting to 50’ where I will add various devices to see if we can successfully support simultaneous LiveSync to 50 devices.

D7

What About Windows Phone?

In the past couple of days since I announced the release of Icenium, I’ve had a number of people asking me if it supports Windows Phone in addition to Apple iOS and Google Android. I suppose that is because nearly all other Telerik products are dedicated to the Microsoft technology stack, so it would be almost expected that Icenium would get on the band-wagon.

Its All About the Data

Allow me to let data do the speaking: 

Image

In the past year Apple and Google have grown in market share by nearly 17% (Source: comScore, U.S. Mobile Subscriber Market Share). In that same period, Microsoft dropped nearly 2% – meaning Apple and Google are outpacing Microsoft by nearly 20%. In fact, Apple and Google are the only two mobile platform providers that have been consistently growing in market share during that period.

So I decided to focus our efforts on Apple and Google. Microsoft will have to wait.

What Will Windows Phone Do?

I used to be a Windows Phone user. I loved my Windows Phone (I missed a lot of the apps from my old iPhone, but I LOVED the operating system and the Live Tiles). In the last year I have regularly switched phones every month or two, trying out several Android devices in addition to the iPhone 4/4S and now iPhone 5. I’m a believer in Windows Phone – I think it is a great operating system. That is completely separate from the business decisions I make.

With Windows Phone 7 already on death row, and the success of Windows Phone 8 nothing more than speculation (like this and this), I didn’t feel like WIndows Phone warranted our time…yet. I am bullish on Windows Phone. Like I said, I love the OS and the new hardware is looking pretty good.

I have maintained a wait-and-see stance on adding Windows Phone support to Icenium.

We’re Not Waiting Idle

Of course, Telerik has a lot of knowledge in Windows Phone, which means we’ve already done some research. We’ve done a proof-of-concept to learn more about what it would take to support Windows Phone, and we know what we need in order to give Windows Phone the Icenium treatment. We’ve already engaged Microsoft to work out some of the details, in the event we decide to move forward.

Over the next few weeks we’ll be watching the early adoption of Windows Phone to see what the consumer reaction is, and use that to make some decisions about how we prioritize our backlog for the remainder of the year, and early 2013.

OK, What About Windows 8?

Having worked on Windows 8 tooling before I left Microsoft, I feel like I know the app-type Formerly Known as Metro (FKM) pretty well. I’m curious to see how consumers and enterprises react to both the app-type and the new hardware. Clearly Windows 8 will be successful in the PC market – although I’m not sure how well PC users will take to the FKM style apps.

ImageFor the mobile device market, the success of the Surface with Windows RT (Surface RT) and the OEM tablet form factors will have a huge impact on the success of FKM apps on devices. If the hardware isn’t sexy, the Windows 8 tablet will suffer the same fate as Windows Phone 7.

If the Surface RT and its cousins do well with consumers (and even in the enterprise), then the FKM app-type has a shot, and it would make sense for Icenium to support it. The advantage we have is that FKM apps can be built with HTML and JavaScript, which work through a projection layer into the Windows Runtime (WinRT) – basically the exact same way Apache Cordova works (in concept), making adding FMK app support to Icenium very achievable.

Like WIndows Phone 8, I am bullish on Windows 8, and the Surface RT – I’d say I am even more bullish on Windows 8 than Windows Phone 8. I’ve already pre-ordered my Surface RT and a Windows 8 Ultrabook with a touchscreen.

Keep Your Fingers Crossed (and Buy a Surface RT)

I hope that helps you understand some of the decision making process I used for deciding what platforms to support in the initial offering of Icenium. We have aspirations to support all relevant platforms – and right now that definition excludes Windows 8 and Windows Phone 8. Let’s hope that changes.

I’d love to see a three-horse race in the mobile market.

Hybrid or Native?

In their recent Developer Economics 2012 report, VisionMobile calls out (on page 29) the question of Hybrid or Native. What is the right technology choice when considering the development of a new application? Which is better, HTML5 (mobile web or hybrid) applications, or native applications. Clearly each have their advantages and disadvantages, right? According to VisionMobile, this is the wrong question.
In the report, VisionMobile identifies three decision criteria that must be evaluated in order to make the choice between HTML and native.

  1. Existing assets: Which languages does your development team know? What languages are your legacy content assets coded in?
  2. Depth vs. breadth of experience: Do you need to deliver deep experiences and code directly to the platform? Or is breadth of experience more important, which would lead you to leverage cross-platform tools/hybrid solutions?
  3. Distribution channel and monetization: Are you a major brand with existing customer accounts, or do you need app stores to reach and bill customers.

Personally I like the way VisionMobile looks at this decision tree. The fact is, there is no universal truth – hybrid is not always better than native and native is not always better than hybrid. The technology decision has to be made while considering all of these factors.

Recently I was at a technology trade show where we were demo’ing Icenium non-stop for several days. Every demo I did I would ask the person I was speaking with about their interest in mobile app development and their background. My anecdotal findings are that the majority of the people I engaged with were coming from a web development background and either approaching mobile because of the opportunity it provides (reaching millions of people) or because they are being directed to by their boss (e.g. how can they mobilize their existing web assets). In either case, the person I was speaking with and the development team they were representing had existing skills in HTML and JavaScript, and were somewhat intimidated by Objective-C and Java (or at least frustrated that they were going to have to learn anther set of skills to solve this problem).

In either case, if these people used the decision tree presented by VisionMobile, in many of their cases they would choose Hybrid as the right solution for them – the have skills and content assets in HTML & JavaScript (#1), in almost all cases they were looking for a breadth experience over a depth experience (#2), and either wanted in-house enterprise distribution or AppStore distribution.

The fact of the matter is that Hybrid apps are a perfectly good technology choice in many cases (possibly more so than native). They are easily approachable because they use languages and technologies that the majority of developers are familiar with, which drives down the cost of development, and they can reach multiple platforms with a relatively low cost of development per platform (another huge plus for the people I spoke with).

Hybrid apps may not be the right technology choice all of the time….but I am betting hybrid is the best choice 80% of the time. What do you think?

Should You Go Hybrid?

Over the past week, since we released the first beta of Icenium, I’ve been talking with lots of web and mobile web developers who are either starting to develop apps for mobile devices, or who are going to be starting soon. These folks, who are new to building apps that run on devices, have lots of questions about the options available to them, and lots of confusion over native-vs-mobile web-vs-hybrid.

For the purposes of this conversation, I’ll use the following definitions:

  • Native apps are built for a specific platform with the platform SDK, tools and languages, typically provided by the platform vendor (e.g. xCode/Objective-C for iOS, Eclipse/Java for Android, Visual Studio/C# for Widnows Phone).
  • Mobile Web apps are server-side apps, built with any server-side technology (PHP, Node.js, ASP.NET) that render HTML that has been styled so that it renders well on a device form factor.
  • Hybrid apps, like native apps, run on the device, and are written with web technologies (HTML5, CSS and JavaScript). Hybrid apps run inside a native container, and leverage the device’s browser engine (but not the browser) to render the HTML and process the JavaScript locally. A web-to-native abstraction layer enables access to device capabilities that are not accessible in Mobile Web applications, such as the accelerometer, camera and local storage.

What Should I Choose?

One of the most common concerns for web developers new to the mobile app world is the learning curve required to build native apps, or the lack of education on what a hybrid app is. My advice is, before committing down a single path, consider the user experience and what each option provides you. Native apps will always provide the fastest performance, at the cost of being more complex to code when compared to a hybrid app, while a hybrid app will be easier to build, using HTML5 and JavaScript, at the cost of giving up a little bit of speed. If the user experience you want to create is a Need for Speed style game, chances are you’ll want to use native technology to implement the app for each mobile platform you’re targeting in order to get the best graphics performance. If you want to build the next Foursquare, using geolocation and providing a means for displaying data and updating data, a hybrid app is a perfect solution and enables you to build it once, publish it through app stores, and have it work on several platforms.

Like any other technology choice, deciding between native and hybrid requires you to look at the user experience and decide on the level of investment you need to make to achieve the goal. Native apps will always require more investment because they are written with more complex languages, designs and structures. They also need to be written/rewritten for each mobile platform you are targeting. Hybrid apps will always enable you to build for more platforms faster, if you are willing to sacrifice small amounts of performance (e.g. game-level responsiveness).

What is a Hybrid App?

Hybrid, by definition is anything derived from heterogeneous sources, or composed of elements of different or incongruous kinds. A hybrid app is one that is written with the same technology used for websites and mobile web implementations, and that is hosted or runs inside a native container on a mobile device. It is the marriage of web technology and native execution.

Hybrid apps use a web view control (UIWebView on iOS, WebView on Android and others) to present the HTML and JavaScript files in a full-screen format, using the native browser rendering engine (not the browser itself). WebKit is the browser rendering engine that is used on iOS, Android, Blackberry and others. That means that the HTML and JavaScript used to construct a hybrid app is rendered/processed by the WebKit rendering engine (for you Windows 8 folks, this is what the IE10 engine does for Metro style apps that use WinJS) and displayed to the user in a full-screen web view control, not in a browser. No longer are you constrained to using HTML and JavaScript for only in-browser implementations on mobile devices.

The real secret sauce of hybrid apps is the implementation of an abstraction layer that exposes the device capabilities (read: native APIs) to the hybrid app as a JavaScript API. This is something not possible with Mobile Web implementations because of the security boundary between the browser and the device APIs. Apache Cordova (formerly PhoneGap) is an example of a JavaScript abstraction layer over native APIs (for you Windows 8 folks, WinJS is another example of a JavaScript abstraction layer on top of native APIs). Through this abstraction layer a common set of APIs is exposed in JavaScript, and these JavaScript APIs work on any device supported by the framework (for WinJS that’s only Windows 8, but for Cordova that is seven mobile platforms including iOS, Android, Blackberry and Windows Phone 7). When the native wrapper is compiled around the HTML, CSS and JavaScript resources, there is an interop layer added that connects the JavaScript APIs with the platform specific APIs.

What this really means is that, for example if I build a mobile app with Apache Cordova, I can use JavaScript to access a native API, like the camera, using a single API call regardless of what platform the app will run on.

navigator.camera.getPicture (onCameraSuccess, onCameraError, { quality: 50,
    destinationType: Camera.DestinationType.DATA_URL
});

function onCameraSuccess (imageData) {
    var image = document.getElementById('myImage');
    image.src = "data:image/jpeg;base64," + imageData;
}

function onCameraError (message) {
    alert('Failed because: ' + message);
}

Under the covers the JavaScript is making an interop call that access the native API for the camera. That means that on an iOS device this JavaScript is calling into the native layer to instantiate a  UIImagePickerController and on Android it creates an Intent to use MediaStore.ACTION_IMAGE_CAPTURE to take a picture. When developing a hybrid app you don’t need to worry about this level of detail. All you need to do is call the JavaScript function (navigator.camera.getPicture() in this case), and respond to the outcome (the imageData passed to the onCameraSuccess call back function in this case).

Summary

Hybrid apps are a great option for you if you:

  1. Want to target multiple mobile platforms
  2. Want to take advantage of device capabilities like geolocation, accelerometer or the camera
  3. Want the app to be useable when the device is offline
  4. Don’t need the advanced graphics performance that you can only get from a native app.

Hybrid apps are built with web technologies which means there are millions of web developers who already have the base skill set to build mobile apps.

Here is a graph that highlights the differences in native, hybrid and mobile web applications.

We Need Developer Tools, Not Platform Development Tools

It’s been almost a year since I left my role at Microsoft as Director of Product Management for Visual Studio. Ever since I left, I’ve had lots of people asking what I am working on now, and I’ve been pretty quiet about it (the running joke is that I am the VP of Black Ops). The truth is that my team and I have been very busy solving what we believe to be one of the biggest challenges facing developers today and building a new product that I believe will dramatically reduce the barrier to entry for developers wanting to build applications that run natively on mobile devices.

I firmly believe that mobile devices are the single biggest opportunity today for developers. Cell phones are ubiquitous, and smartphones are becoming so common place, it’s surprising when someone doesn’t have one. According to the March 2012 U.S. Mobile Subscriber Market Share from comScore 234 million Americans age 13 and older used mobile devices, and more than 106 million people in the U.S. owned smartphones. That’s roughly one-third of the US population, and if you are anything like me, your smartphone is the only computing device you have with you at all times, from the time you wake up, to the time you go to bed. While a smartphone (or tablet) may not be your primary productivity device, it is arguably your primary device –the only one you always have within reach.

From a developer’s perspective, this represents a huge opportunity. While lots of developers have already entered the mobile device development arena, only a fraction of the entire developer population is actively doing development for mobile platforms. As businesses embrace mobile devices and start to extend their line-of-business applications, business-to-business applications and direct to consumer applications, more and more developers will have to transition into mobile platform developers.

While mobile platforms are one of the biggest opportunities for developers, they are also one of the biggest challenges for developers. Like the browser-wars of the 90’s, the mobile platform arena is hugely challenging. Every mobile platform provider has their own SDKs, uses a different programming language, and different tools. In fact, if you want to target all of the mobile platforms out there, you need multiple development machines—one for Mac OS X and one for Windows (at the very least you need a Mac and a BootCamp image of Windows). To build one app that runs natively on all platforms requires significant duplication of effort—essentially building and rebuilding the same app on different platforms. None of the platform providers are eager to solve this problem for you—they don’t make developer tools, they make platform development tools.

When I was at Microsoft, my job was to ensure Microsoft built the best platform development tools possible As a result we created awesome tools for development on the various Windows platforms (client, server and phone). What we didn’t do was build great developer tools—tools that made developing applications easier and more enjoyable regardless of what platform was being targeted. The only way to do that in the Developer Division would be to secede from Microsoft and become an independent software vendor (ISV)…and DevDiv would be a big one. Since that wasn’t going to happen I decided that it was time to find an ISV that had the ability to create great development tools regardless of platform. That quest led me to Telerik, where my team and I have been doing just that.

I’d like to invite you to join the Icenium private beta. Icenium is a work in progress (hence the private beta) and steadily becoming the product that I envisioned—a development tool that makes building applications easier and more enjoyable regardless of platform. With Icenium, we intent to build the worlds first Integrated Cloud Environment (ICE) that combines the power and flexibility of the cloud with the convenience of a local coding environment to massively eliminate the complexity of building cross-platform mobile applications. In its current beta state Icenium enables you to build applications for Apple iOS and Google Android, and more platforms will follow. My team and I are very excited about this beta, and we are looking forward to getting your feedback.

D7

There are Only Two Kinds of Device Apps

Just the other day a colleague and I were having an interesting discussion. After a while we realized we were talking about the same things but we each used different vocabulary to describe the things we were referring to. I hate when that happens.

I thought it would be useful to provide a common definition for the types of device (aka mobile) apps we see in the market to help establish a common vocabulary.

As I see it, device applications can be categorized as being either consumer applications or business applications (my colleague likes the term “corporate applications”). These are then also sub-divided, but I’ll get to that soon.

Consumer Applications

IMG_0057Consumer applications are exactly what the name implies – applications used by consumers. These are typically purchased through an app store or market place by the consumer directly. I tend to sub-divide these into five types: data snacking, social/mash-up, content/media, casual games and graphical games.

The key attribute here is that these are acquired directly by the user for a specific non-business purpose. Facebook, Angry Birds, etc. are examples of these types. There is some easy confusion here when we start to think about business (or “corporate”) applications, specifically those intended to connect the user to the business. Is Facebook a B2C app? Not really. It is the product of a company, but primarily a consumer app.

Business Applications

Business applications are built for only a couple reasons – B2C or internal line-of-business (LOB), and it can be easy to blur the line (or at least see the line with blurry vision) if you’re not careful. Some may argue that B2B is another type, but my position is that there is no such thing as a B2B device applications. They are B2C applications where the “C” is simply a user from a client “B”.

B2C

Business to Consumer (B2C) apps are the apps most easily confused with “direct” consumer apps. Is Facebook a consumer app or a B2C app? I think I could argue this one successfully in either direction, but I prefer to think of it as a consumer app (Facebook’s primary business is Facebook, even though IMG_0058their revenue comes from sources other than the user). For B2C I like to think about the company’s primary business. Is the app their primary business, or are they in the business of something else, and the app helps them provide a better experience for their customer?

Alaska Airlines is a company I do a lot of business with. They have a great B2C app. As the consumer, I got the app from the Apple AppStore, even though it’s not a consumer app (see, I told you it could get blurry). This app is a great example of a company that is primarily in a different business (moving people and stuff through the air),who has a great app for their customers. I can use the app to check my upcoming trips, check in for flights, and—for those of you who aspire to be truly paperless—even use it as my boarding pass.

My colleague likes to refer to these B2C apps as “Corporate Consumer Apps.”

LOB Apps

Line-of-Business apps are built by companies (or vendors) for use within the confines of their business. Examples include expense tracking apps, conference room schedulers, and lunchroom debit apps (at Microsoft we even had a game app that the food services division put out enabling you to win a discount on lunch using your Windows Phone). Typically these are developed in house for a specific need, and distributed through some form of internal or enterprise app store.

These are what my colleague refers to as “Corporate Enterprise Apps.”

What Do You Think?

Do you agree with me? When thinking about the different app types for mobile devices, do we agree on the following terms:

  • Consumer apps
    • Data Snacking
    • Social/Mash-up
    • Content/Media
    • Casual Games
    • Graphical Games
  • Business Apps
    • Business to Consumer (B2C)
    • Line-of-Business (LOB)

D7