Introducing Icenium – an Integrated Cloud Environment for Hybrid Mobile App Development

Today is a day that my team and I have been looking forward to for a long time. Today I am happy to announce that Icenium, an Integrated Cloud Environment (ICE) for hybrid mobile app development, is now available to everyone!

The Story Begins

Back in July 2011, I left Microsoft and joined Telerik to take on an ambitious idea. In my time at Microsoft I had spoken with hundreds of developers and was able to witness first-hand the frustration that many of them felt working with Integrated Development Environments (IDEs) – they were big, bloated and most were designed with only one platform, or one platform vendor in mind (e.g. Visual Studio, xCode, etc.). For developers that targeted multiple platforms, using these IDEs meant downloading, installing and managing multiple platform SDKs and two or more separate development environments. For example, targeting the most relevant platforms in the world today – iOS and Android – meant using xCode with Objective C and Eclipse with Java, along with all the SDKs and tools that go along with them. Nearly 3 GB of downloads to install and maintain (not to mention, you have to have a Mac OS X environment, automatically excluding Windows-based developers). I was no different from the developers I talked to. I used these tools all the time. They took up a lot of my time to download and configure, they took up a lot of hard drive space, and they required a powerful development machine.

I also observed that while I was writing code, I was also listening to music from Pandora, saving documents in DropBox, and keeping notes in Evernote. Nearly everything I used daily was not only cloud-connected, but the cloud played a significant role in enabling the technology; that is, the technology wouldn’t have functioned without the cloud. Everything except my development tools (OK, maybe I’d deploy an app to the cloud, but the cloud didn’t aid me in my development efforts).

An ICE Age is Coming

The idea that a development environment required all of the SDKs and platform dependencies to be installed locally on a development machine with massive RAM and a big hard drive felt so antiquated compared to the other apps I used which were light-weight and used the cloud in a meaningful way. This made me want to redefine what a development environment was. I wanted to build something that enabled developers to build across a variety of platforms, and now that cloud connectivity was ubiquitous for developers, it was possible.

I left Microsoft in pursuit of a company that would allow me to chase my crazy idea, and Telerik is just that crazy (talking to you Forte). I didn’t want to build just another IDE. I wanted to build something different; I wanted to build an ICE – an Integrated Cloud Environment. I believed that we could improve cross-platform development by decoupling the gestures of writing code from the platform dependencies required when building apps. Specifically I wanted to decouple coding from the big, bloated SDKs that limited the development experience to one where the coding environment and the target environment required affinity.

The primary objective in building an ICE was to enable developers to build apps that targeted any relevant platform from any development. My theory was that we could extract the SDKs from the local coding environment and turn them into cloud-based services that could still function as part of an integrated workflow for developing apps. In other words, it still had to be an integrated development experience, and the cloud – not your OS and RAM – would become the enabling technology. The experience had to be functional, capable and simple. The age of having to master multiple complex development environments and SDKs is coming to an end. The new ICE age will usher in a new type of development tools, and the dinosaur IDEs will die off soon enough.

Welcome Icenium

Icenium™ is the realization of that vision. Icenium combines the convenience of a modern coding environment with the power and flexibility of the cloud to manage platform dependencies. Icenium enables you to build applications without being limited by the development environment having to be compatible with the run-time environment (e.g. Mac OS X to iOS). It enables you to focus on the content of your application without the headache of managing multiple SDKs and development environments. With Icenium you can use Windows, Mac OS X, Linux, or even device operating systems, like iOS on an iPad, to build hybrid applications that are distributable through the app stores, and run natively on iOS and Android devices.

I believe web developers are looking for ways to move from mobile-optimized web sites to building apps that run on devices, so we built Icenium with web developers in mind. We leverage Apache Cordova (aka PhoneGap) to enable you to use HTML, CSS and JavaScript to build your application. When your project is compiled, we build the iOS and Android native bits in the cloud, which means you don’t have to think about SDKs, Objective C or Java. Just focus on your app and leave the platform dependencies to us.

We also tailored the development experience to web developers. Most web developers (me included) prefer to work with capable, text-based code editors (and not WYSIWYG tools that modify your code without your consent), a browser and some debugging tools, such as WebKit Inspector, so we designed Icenium to work the same way. The Icenium coding environment is a simple text-based code editor, packed with advanced capabilities including syntax coloring and formatting, real-time error detection, refactoring, code navigation, and more.

Each development client (Icenium Graphite for Windows and Icenium Mist in the browser) includes a device simulator that enables you to test your application much like you would test a web app in a browser. The device simulators include options for simulating iPhone, iPad, Android phone and Android tablet, including a geolocation simulator and the ability to rotate and flip the device. The device simulators expose the ability to use WebKit Inspector-based debugging tools – the tools you already know. We have tried to replicate the working style you already use for web apps, making the transition to mobile application development simple and intuitive.

Icenium Graphite™

Graphite Code Editor with Error Detection — Icenium Graphite with real-time syntax error detection.

Icenium Graphite is an installable development tool for Windows operating systems. It is a WPF app that provides you with the ability to build a cross-platform mobile application, test it in a device simulator, build the app (in the cloud of course) and deploy it to multiple devices at once. When you are ready, you can switch to a “release” build setting, add your icons and splash screens and package your app for publishing to the Apple AppStore or Google Play.

Icenium LiveSync™

Icenium LiveSync is one of the truly magical features of Graphite. With LiveSync you can build and deploy your app to one or more iOS and Android devices with nothing more than the click of a button. Your app is built in the cloud, and then delivered back to Graphite where it is pushed over USB to all connected devices.

I usually have 10 or 11 connected at once, including iPhone 4S, iPhone 5, iPad 1, iPad 3, Google Nexus, Google Nexus 7, Galaxy S2 Skyrocket, Galaxy S3, Galaxy Tab 8.9”, Galaxy Note 10”, HTC One X, and the Kindle Fire.

After the app is on the devices you can test it out and see how it works on different screen sizes and pixel densities (e.g. Retina display), not to mention different form factors (phone and tablets). If you want to make a change, simply add, edit or remove the HTML, CSS or JavaScript in your project and click “Save.” When you do, the changes are saved (in the cloud of course) and immediately pushed down to the running app on all connected devices. That means you can work in rapid iterations and see your changes on the devices in real-time, as you make them.

Icenium Mist™

Icenium Mist is the browser-based sister of Graphite. Mist provides nearly all of the same functionality as Graphite, and works on a variety of platforms. I use Mist on my MacBook Air, and even on my iPad, when I am away from my office. Mist also includes the modern conveniences of Graphite, such as syntax coloring, statement completion, and version control integration, as well as a browser-based device simulator that can render your app on an iPhone, iPad, Android phone and Android tablet.

Since Mist is browser-based, it doesn’t have access to deploy apps to devices via USB. Instead, you can build your app and deploy it to a device by downloading the app and pushing it to your devices manually, or simply scan the on-screen QR code and the app will be downloaded to your device.

LiveSync On-Demand

Whether using Graphite or Mist, we’ve included the option to use LiveSync in an “on-demand” way. If your app is on a device and either you’ve disconnected it from USB (when using Graphite) or you deployed the app manually or with a QR code, you can request an app update easily and the content of the app will be refreshed based on your latest saved changes in either Graphite or Mist. If it’s an iOS device, simply press three fingers to the screen for a couple seconds and you will see the download begin. If it’s an Android device, simply press the context menu and the download will begin. LiveSync on demand means you can see your changes on any device, anytime, anywhere.

Icenium Ion™

iPhone_4S_Vert_Ion — Icenium Ion enables you to forget about device provisioning during development.

If you’re familiar with Apple’s iOS development model, you know that in order to deploy an app onto an iOS device you need to first provision that device through the Apple Developer Center. Icenium fully supports working with provisioned devices – in fact Icenium can aid you in creating the Certificate Signing Request required when requesting a device provision. However, if you want to try out your app without provisioning your phone, or you want a stakeholder or beta tester to try out your app and give you feedback, then Icenium Ion is the tool you need. Ion is a development and testing utility (downloadable for free from the AppStore) that enables you to load your app onto any iOS device regardless of whether or not it has been provisioned. Simply scan a QR code provided by Icenium and the app will download and launch inside Ion. Of course, LiveSync on demand works perfectly with Ion too.

Version Control

Of course a development tool wouldn’t be complete without integrated version control, and a cloud-based tool better integrate with popular cloud-based version control systems, so we did just that. By default all Icenium projects are connected to an integrated Git repository in the cloud, and you can optionally configure your project to use any URL-based Git repository, including GitHub and BitBucket. Both public and private projects are supported, enabling you to collaborate and version your code safely.

Kick the Wheels (for a while)

As I mentioned, today we have released Icenium for everyone to use. In fact, I don’t want there to be any barrier in your way to trying out Icenium, so I decided to make it free for the next 6-months. We won’t begin charging anyone for Icenium until May 1, 2013. So go to Icenium.com, create an account and start building cross-platform mobile apps today. I’ll bet you can build an app faster than it takes to download xCode.

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.

Existing assets: Which languages does your development team know? What languages are your legacy content assets coded in?
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?
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:

Want to target multiple mobile platforms
Want to take advantage of device capabilities like geolocation, accelerometer or the camera
Want the app to be useable when the device is offline
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.