Cross-platform development is a big deal, and will continue to be so until a day comes when everyone uses the same platform. Android? HTML? WebKit? iOS? Windows? Maybe one day, but for now the world is multi-platform, and unless you can afford to ignore all platforms but one, or to develop independent projects for each platform, some kind of cross-platform approach makes sense, especially in mobile.
Sometimes I hear it said that there are essentially two approaches to cross-platform mobile apps. You can either use an embedded browser control and write a web app wrapped as a native app, as in Adobe PhoneGap/Cordova or the similar approach taken by Sencha, or you can use a cross-platform tool that creates native apps, such as Xamarin Studio, Appcelerator Titanium, or Embarcardero FireMonkey.
Within the second category though, there is diversity. In particular, they vary concerning the extent to which they abstract the user interface.
Here is the trade-off. If you design your cross-platform framework to include user interface widgets, like labels, buttons, grids and menus, then you can have your application work almost the same way on every platform. You can also have tools that build the user interface once for all the platforms. This is a big win in terms of coding effort. If the framework is well implemented, it will still adopt some of the characteristics native to each platform so that it looks more or less native.
Some tools do this by drawing their own controls. Embarcadero FireMonkey is in this category. Another approach is to use native controls where possible (in other words, to call the API that shows a button, rather than drawing the button with the graphics API), but to use custom drawing where necessary, even sometimes implementing a control from one platform on another. The downside is that because those controls are not in fact native, there will be some differences, perhaps obvious, perhaps subtle. Martin Fowler at ThoughtWorks refers to this as the uncanny valley and argues against emulated controls.
Further, if you are sharing the UI design across all platforms, it is hard to make your design feel equally right in all cases. It might be better to take the approach adopted by most games, using a design that is distinctive to your app and make a virtue of its consistency across platforms, even though it does not have the native look and feel on any platform.
Xamarin Studio on the other hand makes no attempt to provide a shared GUI framework:
We don’t try to provide a user interface abstraction layer that works across all the platforms. We think that’s a bad approach that leads to lowest common denominator user interfaces.*
CEO Nat Friedman told me. He is right; but the downside is the effort involved in maintaining two or more user interface designs for your app.
This is an old debate. One of the reasons IBM created Eclipse was a disagreement with Sun over the best way to design a cross-platform user interface framework. Sun’s Swing framework, derived from Netscape’s Internet Foundation Classes first released in 1996, takes the custom-drawn approach, which is why Swing apps always look like Swing apps (even if you apply the “Windows” look and feel). A team from IBM, some originally from Object Technology International which was a company acquired by IBM, believed it was better to wrap native controls with a Java abstraction layer, created SWT (Standard Widget Toolkit) to do that, and used it to build Eclipse.
Personally I am wary of toolkits which rely heavily on custom-drawn controls rather than native controls, though I see their value. On the other hand, Xamarin Studio is so far in the other direction that it removes some of the benefit of a cross-platform framework.
My prediction is that Xamarin will come up with its own GUI abstraction framework in future, along the lines of SWT. It is a compromise; but one which delivers a lot of value to developers who want to create cross-platform apps with the maximum amount of shared code.
*I have never understood this use of the term “lowest common demominator”. The LCD in maths is the lowest number into which a specific group of numbers divide exactly, so it is an elegant thing. In cross-platform what you should strive for is the highest common intersection: to make available all the features common to each platform.
Update: in April 2014 Xamarin announced Xamarin Forms, a GUI framework which wraps native controls in a XAML implementation (XAML is the presentation language also used by Microsoft, for WPF, Silverlight, Windows Phone and Windows Runtime (Windows 8) apps. There is a quick hands-on here.
The concept was the *maximum* common denominator. Also the least common multiple. But there wasn’t such thing as the lowest common denominator at all (for any practical purposes).
I’m also for native controls as far as it’s reasonable. Unfortunately there is always some program that I like that has its own GUI and needs special attention.
Here’s what I would like to see:
1. Visual Studio dev, with C# classes compiled down to native code like dot24, and unlick monotouch so no framework on android. Do the same for Ios like monotouch does in that case.
2. Design in XAML with native control representations in the designer for iOS, Android and WP. (and anything else) But have separate designers for each of the 3 UIs, thus allowing complete customization of the UI, but a single development tool, and methodology (xaml) between the 3.
3. Compile to each, and each would then use the native UI, with shared code between them, and C# and Xaml for the UI in each for maintenance.
I don’t mind building 3 UIs. I would do it anyway because they’re very different. I do mind having to have to manage 3 skillsets to do so. If one dev could write xaml for each of the 3 UIs life would be awesome. Obviously each of the 3 xamls would have different functionality and different controls that roughly were similar, but that’s ok. I don’t mind that.
Do me this is the holy grail, and didn’t require LCD, just a single dev tool and skillset.
Word is, according to David I., FireMonkey will start exposing native controls where possible.
What native widgetset should a cross-platform widgetset mimic? I think that’s the question. With qooxdoo, for example, it looks as though they mimic iOS – see their Mobile Showcase:
http://demo.qooxdoo.org/current/mobileshowcase/index.html#%2F
With qooxdoo, the key, non-trivial widgets like List and Picker are still very iOS-like even when you switch to the garish Android “theme”.
My prediction is that cross-platform widgetsets that started out mimicking something from the 90s (WinAPI / VCL) will have to move toward native long before Xamarin moves toward a cross-platform widgetset.
Phil – FireMonkey doesn’t ‘start out mimicking something from the 90s (WinAPI/VCL)’. In fact, in its original form, it was more keen to pay homage to Cocoa that it was to the VCL. E.g., it faithfully imitated even on Windows that irritating OS X combo box behaviour where the dropdown list pop up in front of you. (Doesn’t do that now, thankfully!) Also, wouldn’t ‘non-trivial widgets like List and Picker’ be obvious targets for wrapping the native API, even if the framework generally is custom drawn? This would then go with how on the desktop side, ShowMessage, MessageDlg and (on OS X) InputQuery all delegate to the native API in XE3.
>> Another approach is to use native controls where possible
This is the FireMonkey approach for mobile. In iOS FM uses native SDK controls wherever the devices UX demands are extremely specific – ie keyboard, alerts, messages, picker wheels, etc -and where there is no tangible benefit, ie common / simple controls like buttons and tabs, they are rendered and animated with the FM/GPU engine appropriate to the native UX on each device.
>> cross-platform tool that creates native apps, such as Xamarin Studio, Appcelerator Titanium, or Embarcardero FireMonkey.
Xamarin and Appcelerator apps are both VM driven (Javascript and Mono) and Firemonkey apps are native ARM machine code.
Xamarin and Appcelerator provide common language (C# or Javascript) against ea device platform SDK/API – so multiple codebases across devices.
Embarcadero provides common language (Delphi or C++) against Firemonkey SDK/API – so single codebase across devices including Windows and Mac PCs. Delphi is Win/Mac today and iOS in preview, Android in beta this summer. C++ is Win/Mac with iOS and Android in beta this summer.
There are different xplat application needs, and one size doesn’t fit all:
* Apps that need a truly native interface – a framework with highly decoupled interface and logic code is needed
* Apps that can work with an “almost native” interface, framework like FireMonkey or the like can work, as long as they are kept updated and don’t deceive the user too much
* Apps that can work with their own interface, frameworks like Swing can be used, as long as the user is willingly to learn the new interface (the web helped, since users had to learn a lot of different interfaces..)
IMHO there is no “best approach”, the one to use depends on your users target and your application needs. My applications needs a truly native interface, so no FireMonkey nor something alike Swing could work.
“My prediction is that Xamarin will come up with its own GUI abstraction framework in future, along the lines of SWT”
I’m surprised you didn’t mention XWT:
http://savanne.be/xwt.pdf
https://github.com/mono/xwt
Having the native controls available at runtime is one thing having them available at design time is another. Do you really think that web and mobile devices will need anything but best of breed designs – artwork. I think the major point is developer’s denial concerning the design. Developers do no longer design GUIs. Ask the UX designers, it’s their party.
Issues are solved a different way on different platforms. On one hand people don’t get tired repeating ‘the most clever solution has to be found’ and post pictures of Albert Einstein talking about simplicity and on the the other rewrite what UNIX does provide out of the box at the command line via utilities for example instead of simply invoking those. The whole code reuse myth does already die at this point and portability a blink of an eye later or a lot earlier. The world is not POSIX and humans are not POSIX compatible.
The widget sets and all these ideas origin from the time of Motive and similar. These days people had been happy about 256 colors, buttons and list boxes, maybe the Arial font too. Today the world is a different one, maybe one of those alternatives will be this successful so that people accept a certain kind of common look and feel – they did in the case of HTML too or they will not. We cannot know now. In case of HTML there is a certain acceptance, why not use this technology as a front-end technology. If we already know that there is a way, … just an idea. OS native is never wrong, but in the bitter end always those products made it that could solve everything in the very detail and in a way they fit to the device.
In case of Enterprise Software – in Europe – look at what SAP uses and use the same. Or at least consider the way those things work in a first place. Titan and Appcelerator, because they support mobiles too. The logic is not sane, but you know … to use what SAP uses is never false.
According Embarcadero FireMonkey Documentation:
FireMonkey uses lightweight GUI controls on top of a cross-platform abstraction, which is implemented for Windows and Mac OS X. Lightweight controls mean that every pixel is drawn by FireMonkey; no native (heavyweight) controls are used. This approach favors fidelity across platforms over fidelity to the host platform, side-steps the “least common denominator” problem of heavyweight cross-platform frameworks, and allows FireMonkey to create its own control and application design rules.
It is certainly a valid approach, but the downside is that they are *not* true native controls and sometimes will not work quite as expected.
Tim
According Interview with Andreano Lanusse:
Source:
http://www.dextronet.com/micro-isv-insights/interview-with-embacardo-about-delphi-firemonkey-and-misv-business
It is the choice of the developer and what they are aiming for. FireMonkey is designed to be a rich platform and applications can look fully native on each platform. Or applications can take advantage of FireMonkey’s capabilities to deliver fully custom experiences and the same custom appearance on all platforms.
The exception is platform specific characteristics such as menus, common dialogs, etc – for example Mac menus are part of the desktop whereas Windows menus are part of the app, and iOS does not have menus – in these cases FireMonkey always yields to what’s correct for the particular platform.
FireMonkey applications use the GPU to render user interfaces using FireMonkey’s scalable vector powered “style engine” and FireMonkey’s 3D forms. These capabilities allow developers to build “rich” applications with GPU powered effects, transitions, animation, and image processing
David I said:
The team is working to surface native controls for FireMonkey on each platform. Then developers will have the choice to use vector drawn components in their projects across all platforms – or to choose to have native controls on each specific platform. More to come when additional FireMonkey capabilities are completed.
@Tim.
As expected by the platform user, not by the application user. I personally prefer to use an application that works in the same way in any platform, than one that has a different behavior.
It is a VERY bad idea to abstract the user interface for many reasons. Go look at the SAS System if you want a large example of why. Most users are not using multiple platforms, and they want every app to look native like it belongs on their system.
I find this topic interesting and the comments even more interesting. Surely we can simply be guided by the usual pillars of software development like the SOLID principals. If we adhere to the open/closed principal then the “lowest common denominator” abstract widget will be extensible on each platform. This will allow the common part to be reused and the only the part that varies to be written per-platform.
The UI framework that I’ve written for use in my business achieve the above and supports a number of GUI toolkits, including native desktop, OpenGL rendered and web (HTML+JavaScript) user interfaces. It’s now at the point that it’s a simple matter of loading different DLLs at runtime plus a little configuration to switch toolkits.
I’m surprised by the polarized views that come out on this subject when surely we should be converging on approaches that maximum reuse of code across platforms while facilitating extension on each platform when required.
Cheers,
Dan
Emulated controls? That will be like Java AWT or Swing then? Looks awful and non-native to every platform it runs on!
I think JQuery Mobile is a great toolset. We recently re-engineered an objectiveC app in JQM in a few days and thats even going to the device for things like geo-location and mapping. I’m not sure what the advantage for native ARM is when if you want to go completely cross platform then the newest platforms; WM8 and BB10 use HTML5 as the basis for creating apps.
Gary
Reading all of the comments left I will say this. I prefer a native 100% binary program over an interpreted language any day. At this time the same thing that happened when Delphi 1 came out is happening today. Delphi 1 while impressive at the time took 3 versions to become the most powerful development tool at the time. We build native TCP servers that route and process over 80,000 electronic medical prescriptions a day from over 4,000 locations and we are looking for a solution to allow our prescribers to go mobile. We initially tried to use PhoneGap/Cordova and all I can say is, “What a piece of crap”. I have been looking forward to they day that Embarcadero decided to produce a native ARM compiler. Developing in XCode reminds me that Unix programmers should not be allowed to develop and IDE. As far as productivity is concerned Rad Studio beats any of the interpreted development environments in the market right now and I will not even mention the power and freedom of the language. Regardless of whether it is C++ Builder, my favorite, or Delphi (The best for GUI design and database access). That being said Firemonkey is still in its infancy but I have a feeling that when XE5 comes out I am pretty confident that it will be a pretty impressive framework and much more mature. Hopefully this time Embarcadero will make the right decisions and will not allow the language to fade away. After 30 years of programming I can honestly say that truly experienced Delphi/C++ Builder programmers since the Turbo Pascal days are in general much, much more experienced than pure .Net, Java programmers or any other interpreted language. Interpreted languages have a use but it is certainly not for developing truly efficient and fast applications. I will continue to cast my vote for Embarcadero and FireMonkey.
@LAH C# and Java are compiled and not interpreted.