Survey of Cross Platform GUI Architectures
I’m a Mac guy, but I’ve spent a large part of my time working for large software companies. That means that I usually work on a cross platform product that supports both Mac and Windows. The upshot of that is each product has to have a platform layer of some kind so that the correct Windows API’s are called on Windows and the correct Mac API’s are call on the Mac. In my tenure I’ve encountered several different ways of tackling this problem. Some worked very well, while others made me want to quit and become and mime.
The interesting thing to note here is that historically the Mac and Windows API’s weren’t all that different. Sure the Mac Toolbox calls started out in Pascal, but most apps use the C bindings these days. Both the Toolbox and Win32 have very similar ideas about windows, menus, and events, especially when comparing the Win32 API with the Carbon Toolbox. There’s definitely not a one to one mapping for everything, but it wasn’t all that hard to see where you could write a compatibility layer and support both.
There are a few different techniques/architectures for building cross platform frameworks. For this discussion I’ll ignore entire platforms like Java and Adobe Flash which employ virtual machines. I’ll limit discussion to natively compiled applications.
At the end of each section, I’ll rate the architecture. They’ll be evaluated based the cost of maintenance, the initial cost of development, and the user experience they advocate.
-
Emulation
This is where you attempt to make one platform look like the other. For example you implement all the Mac Toolbox API’s that you use on Windows using the Win32 API. That way, you can program to the Mac API’s and it will just “magically” work on Windows. However, given platform popularity this usually means implementing MFC or Win32 on the Mac. Note that this isn’t emulation like what emulators do, but simply implementing a platform API on a different platform.
This technique is unfortunately popular. There are some assumptions that go along with this:
- The only thing required to develop for a platform is writing to the appropriate API.
- If you emulate MFC on the Mac you can hire cheap MFC programmers and get a Mac version for free. (I’ve had managers tell me this with a straight face.)
- It is cheaper and easier to maintain an emulation layer for a platform than the other techniques.
- The platform on which the emulation is taking place is the only platform that suffers.
- There is no other way to port an existing Windows application to another platform.
It turns out every one of these assumptions are wrong.
The first assumption assumes that the emulation layer is going to take care of everything and a Windows programmer will never have to know anything about the Mac. Unfortunately I can guarantee the emulation layer won’t be able to take care of everything and the Windows programmers will have to know something about the Mac. They will have to at least be able to build it on the Mac and figure out if their feature actually works there. But more than likely they’ll also have to know some basic UI guidelines and a general idea of how Mac users expect things to work. This includes the correct menu layout, correct dialog control layout, and the correct modifier keys to use.
The second assumption implies that you can get away with only hiring Windows programmers and they will never ever have to touch the Mac code. Ha! The Mac emulation layer will have to be upgraded and maintained throughout the entire lifecycle of the product, almost daily. The emulation layer definitely is not a write-once-use-many-times sort of thing. You’ll start using new parts of the Win32 API that need to be implemented on the Mac, find bugs in the current implementation, and need to take advantage of new technology on the Mac.
The conclusion to draw from the first two assumptions is any engineer will have to know or learn some basics about the Mac. They will at least need to be able to read some basic Mac GUI code and debug it.
Thirdly, many people look at Emulation compared to, say, Core/Edge and draw the conclusion that emulation is half as cheap because the framework only exists on the Mac (in Core/Edge the framework exists on both platforms). They completely forget about the size of the framework. In Code/Edge you typically have a thin framework on each platform, where in Emulation you have a heavy framework on the Mac. Sure you don’t have anything on Windows, but you spending a lot more time on the Mac just maintaining the framework there.
The fourth assumption people just seem to forget about. I mean, if you’re emulating Windows on the Mac, only the Mac port is going to suffer, right? Nope. Your cheap Windows engineer is going to start writing some code using some newfangled Win32 API and realize that its not implemented on the Mac emulation layer. Oops. They’d implement it on the Mac themselves, but you only hired cheap Windows programmers, remember? At this point, the engineer has to decide if they will ditch the new Win32 API’s or write a Windows only feature. So the Windows app suffers too because it becomes difficult to use the new Windows API’s. In other words, you’re really hurting both the Mac and Windows ports and the users are going to notice that.
The last assumption is that there’s no other way to support another platform. If you’ve got a mature, existing Windows program its not going to be pleasant to port it no matter what option you choose. However, as I outline next, Emulation has a lot of hidden costs that end up making it much more expensive than the other options.
Emulation is also non-incremental. You have to get a substantial amount of the framework written before you can start using it. This means there’s a large up front cost. In my experience it takes about ten or more engineers for about year to implement something reasonably resembling MFC on the Mac. It varies depending on how much Mac expertise you have. There’s also a large cost of upgrading this framework because you can’t upgrade one window at a time to use HIViews (or whatever), they have to be all upgraded at once.
The cost of adding a platform (e.g. Linux) is the same as the initial development. That’s because the platform being emulated (e.g. Windows) isn’t abstracted out in any way.
Finally, the Emulation framework is never complete. No matter how hard you work you’ll never get the Mac to look and behave like Windows even at the API level. It simply can’t be done. There are controls that the Mac has, that Windows doesn’t, and vice-versa. There are highlight and system colors that don’t have counterparts. This will trip up your Windows engineers who expect the Mac to behave like Windows. Since they don’t have any experience on the Mac they don’t know what to do, and you’re stuck.
This is by far the worst way to approach cross platform development, and you should avoid it at all costs. I’ve worked on some large scale projects that used this approach and it was horrendous. The Windows programmers are encouraged to be clueless about the Mac and to hold up that development. It became difficult to do anything with the emulation layer except tread water. This lead to frustration and burn out. In other words, this approach is a great way to lose all your Mac engineers.
Maintenance: D
Initial Cost: F
User experience: C -
Bridge Pattern
This is what Qt does. You write an entire application framework that entirely abstracts out all platform details, and provide a completely consistent cross platform interface. As a result, this architecture tends to like to do everything manually. Qt does not use native controls, but draws the controls itself. It is yet another API set to learn but its really the only one you need to know (almost). You write to this one API and it works on all the platforms.
The benefit is obvious — cross platform consistency. You can just write to the framework and it will just magically work on every platform. Since the framework does everything manually, there is a lot of control to force the consistency.
The are a few disadvantages to this approach. First and foremost, its usually expensive. Either you have to buy a framework that does this (like Qt) or develop it yourself. Unfortunately this approach doesn’t really lend itself to an incremental implementation. To do the most basic thing you need a fairly complete application framework on each of the platforms.
Second, the framework might not be as native as you’d like on each of the platforms. Qt has this problem. To ensure the messaging and event system works completely the same on each platform, the framework will often reimplement large parts of the native platform. This makes it easier to program against, but hurts the user because it doesn’t feel completely native.
Lastly, the framework is yet another API to learn. Both your Mac programmers and Windows programmers have to learn it, if they do not already know it. If, for whatever reason, you need to add a custom control, then you have to start digging around in platform specific code. In that case, the bridge abstraction does not help you. Therefore, having someone fluent in Qt but not Mac and/or Windows (or vice versa) isn’t useful.
Maintenance: B
Initial Cost: F
User experience: C -
Core/Edge
This is a fairly simple idea. You write all your application logic in Standard C++ (or whatever common language and library). This is the “core” part, and should make up the majority of the code. In a MVC architecture, it should optimally be the model and controller parts. You also write core interfaces (class and function declarations) to access the platform specific code, such as the UI (aka the view part). The platform specific code, called the edge code, is written using a native framework or API’s.
This strategy has several advantages. First, it gives the user the native feel and behavior of the platform because you end up using the native framework or API. Core/Edge doesn’t favor one platform over the other, but treats each platform equally. That means each can use the appropriate technologies with out have to emulate the other platform. It also means if one platform has a technology that another doesn’t its easy to use it without hurting the other platform.
Second, it can be implemented incrementally. Since you’re using the native API’s you just start building the app on each platform as you normally would. As you start getting into common logic, or model classes, or controller classes, you simply switch to Core code. That means you write in your standard language with its standard library. (By standard I mean the language that is implemented on both platforms, like C++.) Typically your files will be broken in Core files and Edge files. If Core code needs to call back into Edge code, it calls into a Core interface. The Core interface only takes types defined by the standard language or the Core itself. The Core interface is then implemented by Edge code.
The disadvantage with this approach is that it is easy to degenerate into the Edge/Edge approach. Doing this means you end up duplicating a lot of controller logic on each platform, or perhaps even view code. Some care has to be taken in ensuring the maximum amount of code is written such that it is Core.
Another disadvantage is GUI resources. Since a native framework is used, then each platform is going to have a duplicate set of resources. For a given dialog, it will have to be re-layed out for each platform. If a control needs to be added, it will have be done once for each platform. This actually also provides an upside, which is each platform can use the native layout.
In my experience, Core/Edge is the best architecture to use. It has a relatively low cost, high code reuse, and a very native feel.
Maintenance: B
Initial Cost: A
User experience: A -
Edge/Edge
This is just what it sounds like. Usually there is some common application logic that is shared (as in Core/Edge) but the majority of UI controller code is just duplicated on each platform. There typically is not much effort to make sure any code compiles on both platforms, but each platform is built separately from fairly different codebases.
The one advantage of this approach is that the application will feel very native, which the user will appreciate. The programmers for one platform can concentrate on making it highly integrated into that OS, and make use of new technologies.
The major downside is very little code is leveraged or reused. That means most code ends up being duplicated, once for each platform. That can mean the application gets prohibitively expensive to maintain, and features cost a lot more to implement.
Maintenance: D
Initial Cost: B
User experience: A
This list is not meant to be comprehensive, but to outline the architectures I have experienced. Applications can also use hybrid approaches that mix and match the architectures.
The future of cross platform architectures is going to be interesting. Recently the Mac and Windows API’s have been seriously diverging. Apple is pushing Cocoa, its Objective-C application framework. Not only is it in a different language, its much higher level than the Carbon API’s and has a different object model. Meanwhile Microsoft is pushing C# and .Net. Once again, a different language and a different object model. It is no longer as obvious as how to abstract out both API’s.
As a result, the Emulation architecture, and to a lesser extent the Bridge architecture, become a lot harder to implement. Cocoa is a much higher level than MFC, so implementing MFC in terms of it would be near impossible. The Bridge architecture would also have to find some high level abstractions to properly encapsulate both .Net and Cocoa. In reality, it would probably have to continue what it is doing now: using very low level API’s and do everything manually. Conversely, both the Core/Edge and Edge/Edge would be able to support both Cocoa and .Net. Since the framework is application specific and incremental, its abstractions can be changed to encapsulate the new native frameworks with relative ease.
I will freely admit I am very biased when it comes to cross platform GUI architectures. But that bias comes from me being forced to use each of these in large software systems. From the perspective of this Mac engineer, the Core/Edge architecture is by far the best.