Platform-independence is a funny thing: a lot of developers strive for it, although they will never needed it. I’ve experienced this a number of times in my professional life where someone didn’t want to use available system frameworks because they lock you to a specific platform, even though 99% of the customer base are on that single platform. Maybe it’s also related to the whole Not-Build-Here-syndrom where developers mistrust code they haven’t written themselves.
Others really do need platform-independence but equate it to “my product has to be the same on all platforms” which either results in people writing their own UI rendering code or using stuff like QT or JAVA. As a consequence, the product indeed looks and feels the same on all platforms, but it breaks the metaphors of the individual platform, cannot exploit the inherent technologies and often UI is missing basic features that are standard on the platform (e.g. font scaling capabilities for 4k displays, mouse wheel integration, etc).
A third, related aspect is when platform-independence isn’t the goal but implied by reusing technology, either due to political reasons or to time/budget limitations. This can lead to particularly weird code and/or products as the target app has to go through hoops to make the stuff work. Discouraging examples are the use of web-code embedded inside native mobile apps or CPU-algorithms being ported to GPU just because the customer wants to use his shiny new GPU.
To sum it up, there are lots of situations where ushering the words “platform-independence” can get you into a lot of trouble…
A Device in Every Pocket
So why do we care? Platform-independence is sort of like multi-CPU programming: Nobody really wants to have to deal with it but it is becoming more and more important and we have reached the point where it cannot be ignored anymore. A couple of years ago, a company might have been fine to focus just on Windows and ignore Mac OS X. But try the same policy with mobile devices: If you have a Windows app, someone is bound to be interested in an iOS version. If you have an iOS app, someone will ask for an Android version … or a web-version, a Windows-phone version, a Linux port, the list goes on.
Game Studios have the same problem, they’re just a few miles ahead on that road. Nowadays, a big AAA title has such a big production budget, a studio cannot afford to only release it on a single console. There has to be a PS4 version, an XBox version, a PC version, sometimes even a reduced version for Wii U or older generations. Luckily for them, there are nowadays a couple of very good 3D engines (e.g. Unreal, Unity, etc) that work on multiple platforms or bigger studios develop them themselves.
Interestingly enough, the recent years have also shown a contrary development: Due to the rise of the app store business model and the growing number of Mac/mobile devices, more and more developers produce software that is custom tailored to a single platform. Pixelmator is a create example of an application that perfectly integrates into the operating system, both from a UI as well as a technology standpoint. There is a whole category of apps/companies that solely exist on iOS! However, from what I gathered through reading articles, listening to interviews and so on, there are just a handful of companies that can really pull of a successful and sustainable business model by just focusing on one platform (unless it’s Windows).
When Things go Wrong
Back in early 2014, when I started my 3D modeling app project, I was sure that I would eventually have to support at least 4 platforms: Windows (largest potential customer base), Mac OS X (what I’m working with myself), Linux (for render-farm/server support) and at least one mobile operating system. I had a lot of previous experience using the Qt-framework so that seemed like a natural choice – at least for the desktop part – but honestly, after working primarily on UX/UI/product design for the last couple of years, a one-fits-all solution didn’t cut it. I wanted to use WPF on Windows for all of the customization capabilities, Cocoa on OS X to have Core Animation for fancy, modern animations, have a native, touch-oriented UI on iOS, and so forth.
The aha-moment came when I talked to some people that produce a pretty well known music software. They had written their own UI framework so the software is exactly the same on all platforms, which of course brought the benefit of consistency but at the cost of not being able to do some very basic UI things. I remembered that a colleague of mine ran into the same trade-off with his long-time side project and that Blender 3D also does all the UI itself. The latter is particularly interesting as there has been a lot of discussion/critique of its user interface in recent months/years.
Finally, I talked to a number of software architects that work in larger companies that struggle to move to the mobile platforms. They usually run into two problems:
- Time to market of new features: If the back-end server and the web front-end have a new feature, it in general takes too long until it the same feature is available in the mobile app. This is usually a sign of the the mobile app being too decoupled from the main project.
- Terrible User Experience: Just copying over UI/UX-metaphors from a desktop/web version to a mobile version does not work: The screen estate is different, the device usage times are different, the UI has not been designed for touch. This is usually a sign of the mobile app being too closely couple to the main project. It might not necessarily have to do with code sharing, but also with people trying to apply a mindset that works on one platform to another where it doesn’t.
So the main question is: should platform-independence equate to the same UI?
A Single UI on All Platforms?
For me the answer is no! Sure, there are examples where UI-consistency are a good thing: Take Adobe Photoshop or Ableton Live. Those are applications that sort of exist by themselves. You open them up, work for a couple of hours or even your whole work day, close them and shutdown the computer. It’s great that I don’t have to care that my personal desktop is a Mac and my employer is giving me a Windows box, the tool is the same.
But what about your word processor? Should Microsoft Word use the exact same window chrome and menus on both Windows and Mac? Maybe, but in the end, if I can make my font bold and place a picture I’m happy. I rather have something that integrates nicely into the operating system I’m on. Again, mobile devices are best to illustrate the point: Would you want to have all of those Word menus on your iPhone screen? I rather have the solution that gets the most productivity/joy on each system. Now, that criteria may in many cases lead to having a single-UI on all platforms, but it doesn’t necessarily have to!
Decoupling the User Interface
As mentioned before, one of the initial concepts of my 3D modeling application project was to have dedicated, native UIs on each system. To my surprise, the whole topic of platform-independence gets way easier if you take the UI out of the equation! Imagine for a moment that your application has no user interface: There are no windows, no buttons, no menus, etc.
What remains are – roughly speaking – data structures, communication (e.g. TCP-networking), I/O with the file system, some algorithms, job execution/threading, business code and a lot of glue code. In the example of my modeling app, there is the scene graph that holds the user data, mesh classes for geometric operations, file importers and exporters, layouting code, etc… none of which is really platform dependent or difficult to get platform-independent!
Then there is of course a lot of application code: How are user inputs processed and turned into 3D navigation for example? Which modes does the interface operate in? How are multiple documents handled? Again, this is not really platform-dependent.
If you start by the classic Model-View-Controller (MVC) pattern, you can actually chop off quite a lot that is platform-independent if done right. Funny enough, there was an Apple Talk on WWDC 2014 called “Sharing code between iOS and OSX” that comes to the same conclusion. The problem is the way we all developed applications until recently, a lot of business logic is tightly coupled to the UI layer. As we move to modern UI programming, e.g. reserving the main thread for the UI and executing everything else in the background, things actually get better. A similar effect is achieved by using unit tests: The less code is in your UI, the more can easily be tested by unit tests.
With my 3D modeling project, I therefore adopted the concept of an SDK: The actual UI/application layer is platform-dependent and very thin, just a couple of thousands lines of code, a few UI controls, etc. The vast majority of code is inside a platform-independent core (=SDK) that is C++11 and platform-independent thanks to BOOST and a couple of similar libraries. Everything that might be useful to multiple devices/platforms is abstracted and moved into the core. As a result, the application itself is mainly a case of opening up the right controls and configuring the core: I have two documents, the first document has loaded this file, the viewer is dragging the mouse from this to there, etc.
Porting to iOS
To proof the validity of the software architectural design concept, I’ve started developing an iOS 3D viewer application in parallel to my OSX 3D modelling application. Getting an initial version running that could load a file, render it and do some simple functions like changing the render mode or taking a snapshot took approximately just one day! And most of the time was spent on getting the 3rd party libraries like freeimage and BOOST compiled on the ARM platform!Of course, doing the UI and making it a complete application will take a bit more time, but to stress the point, that is work that would have had to do anyway! The iOS app has – by choice – a completely different UI concept than the OS X version to really make it feel like a native iOS app.I plan to do a Windows version soon which I expect to be done almost as quickly, I just have the extra effort of writing C#-wrappers for my C++11 code as I want to do the application layer in C#/WPF.
Leave a Reply