Until recently, the world was a much simpler place for a programmer. Not so long ago, almost the whole world was just using Windows for all the computing requirements and, as a developer, to ensure that your programs would have a maximum audience, you would just need to develop for Windows, or at least make sure your program would work on Windows or somehow together with Windows. Then, when the web came along, many of us shifted to developing web apps, and once again, we could rest assured that everyone can access and use our application, as long as we followed the web standards (and as long as we remembered to take into account the IE "specialties").
Contrary to what I hear many people say, the world didn't suddenly and radically change in 2007 when the iPhone was introduced. Mobile applications had been developed long before that, on Symbian, J2ME and other platforms. Obviously the iPhone did present an iteration of improvement (although from a programmer's perspective I would find it highly debatable whether the change from eg. Symbian's C++ to Objective-C can really be considered an "improvement"; but obviously that is not the only angle from which iPhone technology should be observed), and it had a great practical effect: Mobile applications, and mobile computing, became popular! Up until then, developing mobile applications was constrained to smaller, simpler applications, and its reach in terms of the industry as a whole was limited. So until the recent years, mobile applications didn't really play a very big role in the discussion of "development platforms". The world was still thinking Windows.
Today, the world is no longer thinking Windows. It's funny how fast the world can sometimes move. Now Windows is considered the underdog, and the world is thinking Android and iOS. Those who don't think Android or iOS, may be thinking HTML5, J2ME, Blackberry, Mac OS X, Linux, or something totally different. And new platforms are being introduced all the time (1) (2). The power balance between the different platforms has not settled, and no platform comes out as conclusively dominant (eg. while Android seems to currently have an upper hand on market share, iOS is said to still have an edge in terms of earnings and revenue .. and things continue to change). So for a developer, the ability to remain flexible between the platforms is of paramount importance. The business and/or career of a committed, exclusive iOS developer will be ruined if the iOS platform declines (which many will argue is unthinkable or impossible, but in fact this is no more unthinkable as would have been the thought of the decline of Symbian just a few years ago .. yet it happened, and those countless individuals and companies who focused their businesses and careers on Symbian C++ programming, were either ruined or forced to go through a painful transition). So whether or not we agree on this, my personal advice to any programmer today (like it was also in the times of Symbian) is NOT to focus your talents on a particular platform or technology, but to remain flexible.
Now the reason why the world of today can seem difficult for a programmer, is because your flexibility needs to cover a wider range of topics than before. Back in the earlier days of the personal computers, things were very simple: Everything was text and keystrokes. Then the mouse was added. Windows, GUIs, buttons; multithreading, networking, etc. Now we have touchscreens, tablets, smartphones, and we still continue to have mouse and keyboard, but not everywhere; then we need to worry about input methods, screen sizes, DPIs/PPIs, and some platform vendors are not making it any easier by trying to solve some of these problems in ways that increase complexity rather than reduce it. Regardless, it's a complicated world out there, and it's all just getting started.
The technologies that try to make sense of all the different software environments are often referred to as "cross platform technologies". Even that is not new; cross platform technologies have existed for a long time as well. It's just that before, even cross platform technology was easier. Back in the days when everything was mostly based on C (or at worst, C++), developing an all-encompassing cross platform technology framework mostly involved creating a library in C or C++. Now it is not quite enough anymore, since languages and platforms are now much more varied (eg. Android/Java, iOS/Objective-C, Windows Phone/C#, FirefoxOS/JavaScript, etc).
This has lead cross platform technology vendors to come up with colorful ways to try to bind all these things together. Indeed, it's a demonstration of human inventiveness what all "crazy" things have been done to try to make this work. Those of you who have heard one of my talks recently would know that I like to talk about these things. I usually present the different approaches in a few categories:
1. The "scripted" approach, where cross platform functionality is achieved through a scripting language and a native interpreter for each of the supported platforms. This is paired with the closely related "MoSync" approach that involves some fun tricks with a custom bytecode format, but that is fundamentally quite similar to the "scripted" approach.
2. The C++ approach (which is effectively the "traditional" way), in which the cross platform functionality is attempted through the use of a C or C++ library.
3. The "web browser" approach, using web technologies in a browser and/or in a native application wrapper that calls the system browser component to display the application.
In addition to these "common" methods, the approach that we employ with Eqela is what I call the "source code conversion approach", where we achieve cross platform functionality on the source code level, regardless of the programming language. It's like writing Objective-C programs without ever learning Objective-C. In terms of flexibility, performance and architecture, of course we feel that this is the best way to approach the problem. In future posts, I plan to tackle more on the details of the different approaches, their respective pros and cons, and why we felt it best to do something different (alternatively, if possible, you can of course attend one of my talks, and chances are I'll touch the topic one way or another).
Feel free to let me know if you feel that you know a cross platform development approach that doesn't quite fit the above categories.
