I just stumbled upon a really, really great post on Steven Sinofskys Blog.
His article is about the challenges of cross-platform development in general, and he brings up some rather good points on why some approaches will eventually fail.
I'm pretty sure he doesn't even know about FireMonkey, but this is what he has to say on cross platform libraries in general:
One of the most common approaches developers attempt (and often provided by third parties as well) is to develop or use a library that abstracts away platform differences or claims to map a unique “meta API” to multiple platforms. These cross—platform libraries are conceptually attractive but practically unworkable over time. Again, early on this can work. Over time the platform divergence is real.
And then he continues:
Worse, as an app developer you end up relying on essentially a “shadow” OS provided by a team that has a fraction of the resources for updates, tooling, documentation, ..
[...]
It is important to keep in mind that the platforms are evolving rapidly and the customer desire for well-integrated apps (not just apps that run).
The very last point is what I already stated in my own post on why FireMonkey is wrong. I didn't even write about the even more important first ones. And this only are quotes from one paragraph where he thinks about cross-platform libraries.
I strongly suggest that you take a few minutes and read what Sinofsky wrote about cross-platform development. And then, if you currently feel that FireMonkey could be the right tool for you, try to understand his points and re-think your position on cross-platform tooling. I'm sure you will see that FireMonkey can't be the right tool for you - or anybody.
What do you think about Xamarin or PhoneGap? Afaik both are tools providing an abstraction layer so you can develop for all other plattforms from a single source.
PhoneGap uses HTML/JS as an abstraction layer.
Xamarin instead provides the Mono BCL and additionally offers a clean bridge-code (not an abstraction!) to the platform.
Of course it also leverages the cross-platform capabilities of Mono for basic OS functions (for example socket IO), but those are trivial and do not differ a lot from platform to platform.
By simply bridging to the platform and enabling you to use the native platform classes as if they were .NET classes, and also offering a simple way to do the bridging for yourself for classes that are not part of the platform (i.e. additional third party libraries / SDK’s for iOS or the mac), it merely enables you to use your existing .NET skills and runtime know-how on the other platforms.
This enables you to fully access the native platform through C# (or any other .NET language). What you do is in fact leverage MVC and write a distinct GUI for each of the platforms while using the model and your business logic from a single source.
In the end, thats a totally different approach than an abstraction layer.
Let me explain. Once upon a time (almost 40 years ago) a company from Austria well known for superb chandeliers of high quality started to ship to Hong Kong. First there was no problem first but over the time the ‘crystals’/glass parts started to drop on the floor. There was nothing wrong with chandelier in general the air was saline. The small chains started to become rusty and the one or other broke. Lessons learned. Chandeliers redesigned …
There are always adoptions you will have to make when you move an app or application. It’s totally independent from the vendor aiming at the developer to be innovative as mentioned in the article.
In my opinion it’s more effective to decide for one platform and benefit from a certain success that does come or make it successful. The Firemonkey is one of many platforms.
You will see the idea of unification on different platforms will die many sudden deaths again. Vendors do not only lock-in they simply create locked-in platforms. No single company can bridge that gap. Neiter horizontal (in time) or vertically (serving various platforms).
So the Firemonkey is maybe little false today but all other unification approaches will prove false tomorrow anyway. The reuse of knowledge about the usage of classes in the answer provided to Manuel is nice but a billy goat is nice too. From a business perspective I tend to think that it’s easier to hire a qualified developer in a foreign country that knows a platform very well than trying to somehow find a compromise on the technical level in order to meet a pricing scheme. Delphi and the Firemonkey can be of assistance in this case in order to compensate a certain trade-off that comes with the fore-mentioned approach but will never show superb excellence in the area of providing the better way to go especially when combined with the Firemonkey – in no way become this effective combination the Delphi+VCL had been again.
Customers expectations are higher. That’s human. The more a human is used to an abstraction the more dissatisfied they become. A car was very beneficial – horse dung disappeared from the streets in the cities but today people decide for whatever reason but not because of being in the position to go fast from point A to B. Smartphones from this perspective are sophisticated cell phones. Those spread earlier than the laptop, maybe around the same time.