Delphi 2012 Redux

I delayed publishing this post as I contemplated the wisdom of doing so, but 2012 has been a big year for Delphi, so I thought I would review the events of the year and make my predictions for 2013 even if it’s the last day of January rather than the first.


One of the biggest news items was of course Marco Cantu joining EMBT as a Delphi Product Manager. Sadly, this was not the only staff change at EMBT. Barry Kelly among others, decided to leave EMBT, and there were anonymous reports of lay-offs, and a large degree of employee dissatisfaction including no raises for employees since EMBT acquired CodeGear, as well as hiring of junior engineers in economically advantageous areas of the globe.

The new EULA agreement for XE2 included changes prohibiting the use of DBX drivers (EMBT’s and third party) for accessing remote databases in the Pro version of Delphi. These “proposed” changes were leaked to the community, and the agreement was subsequently changed to exclude the new restrictions.

With the release of FireMonkey (FMX) on Sept. 1, 2011 it’s been over a year that FireMonkey has been out in the wild. The introduction of FireMonkey heralded the deprecation of the VCL despite numerous enhancements, it’s clear that EMBT is betting the future expansion of the Delphi/BCB market on FMX.


Since FMX was released, there have been two major component vendors providing support for FMX; TMS and FastReports. Delphi XE3 has also been released with an updated version of FireMonkey (FM^2). With third party advanced grid and reporting capabilities, FMX now has a sufficient tool set to author cross platform desktop applications for LOB (Line Of Business) applications.

Many of the technical blog articles on FMX have been quite critical of its implementation and lack of completeness in the version 1.0 release even in the desktop space.  Some of these deficiencies have been addressed in version 2, but the framework is still maturing, and the latest feedback on FM^2 by those deep diving the technology is not extremely positive.


In the mobile space, several applications were authored and accepted into the Apple App Store using XE2 with FMX before FMX support for iOS was removed in the subsequent release (XE3). Users who bought XE2 for iOS were left with a discontinued version of the framework and development tool, with no clear indication what the future held for them. These early adopters were then required to pay to upgrade to XE3 for the privilege of beta testing the up-coming Mobile Studio, in order to ascertain what their migration path would look like, and whether they should continue to support EMBT’s efforts in the mobile space.

The Future?

With the layoffs/departures from EMBT, as well as delayed compiler releases it appears the decision to bet the farm on FireMonkey is not paying off yet, and even EMBT employees may no longer believe in the strategy. This is further validated by the attempted EULA change which would have required Pro users to buy a higher priced SKU, and the 10% price hike in the new year.

I think EMBT has bitten off more than they can chew. Trying to implement a cross platform UI framework is a major endeavor with minimal payback (development tool licenses only), and lots of competition. There are free frameworks out there, and ones that have been around for a long time. Creating a framework specific to the Delphi/BCB tool set immediately limits its market, and dramatically increases the code base that EMBT has to maintain. From what I can see, they are already challenged in that respect (just look at the number and age of QC reports). It’s been over a year since FireMonkey was released, and the adoption rate appears to be minimal if you look at the available components and applications based on FMX.

IMHO, the writing is on the wall.  Expect to pay more for Delphi/BCB licenses while EMBT pours their revenue into FMX to develop the market.   Expect to wait longer for bug fixes and suffer from longer startup times due to increased anti-piracy efforts. I would also expect that the Android and Linux support will be even later than indicated as EMBT focuses on the Mac/iOS platforms trying to get traction in one of the most appealing market segments for Delphi developers.

As unfortunate as it may be, I believe that FMX will continue to flounder and that’s why you don’t see vendors like Developer Express, or Raize porting their VCL products, and even after over a year the monkey is hardly on fire.  FMX will likely become a niche framework, used by some developers for XPlatform support and 3D development, while the number of developers moving to different languages and tools for new development continues to escalate.  Certainly the release of mobile studio will be a pivotal event for the future of FMX, and therefore Delphi.

14 Responses to “Delphi 2012 Redux”

  1. Kyle Miller Says:

    “It’s” is “its.”

    XE2 users developing for iOS will continue to be able to develop for the platform they purchased the product for. XE2 does not cease to function. They will even be offered a path going forward called Mobile Studio.

    FMX is a Delphi technology, so was the VCL. Has FMX been perfect out of the gate? No. Neither was .NET. It’s still early in its life. I reserve judgment.

    Dev Ex is playing wait and see. Even when they stop waiting, don’t expect QuantumGrid FMX to appear. Dev Ex is committing a limited amount of resources to Delphi products.

    “I would also expect that the Android and Linux support will be even later than indicated as EMBT focuses on the Mac/iOS platforms trying to get traction in one of the most appealing market segments for Delphi developers.”

    It is the least appealing for me.

  2. Greg Says:

    I think you nailed things quite accurately.

  3. Andre Says:

    After spending some time with the development of iOS Apps in Delphi XE2 and see the removal in XE3 really made me think about the whole issue. As a long time pascal developer, it’s definitively very nice to use this knowledge and create Apps for iOS or any other mobile application (if possible). BUT should I really invest money and time using Delphi, i mean, the new Mobile Studio? The mobile technology (Hardware and OS) is changing in a very high speed and I’m not sure that Embarcadero is able to follow. For example: What should I do now with the nice feature that made many people update to XE2 “New in XE2! FireMonkey Platform for creating applications for iOS 4.2 and higher”, if I can’t use it to develop anymore using my updated computer (Actual version of Xcode, Mac OS, free pascal, etc)? If someone plan to develop for iOS, maybe the faster way using pascal may become much more expensive than trainings and additional time required to develop using Objective-C. Other cheaper and similar option than Mobile Studio is for example using “gaming frameworks” like Corona SDK and you will also be able to develop easily applications for many mobile platforms like Mobile Studio ….just some of my thoughts…

  4. John Says:

    The ship is sinking

  5. Dmitri Popov Says:

    I quess they see now that Firemonkey was a mistake. Mobile Studio will become the major product with RAD Studio in maintenance mode. EMBT will milk it as long as they can financing mobile development tools.

  6. A. Bouchez Says:

    About the future of Delphi, there are some traces in the RTL source code of XE3 about what it may be.

    The memory model is prepared to change, from manual object lifetime process (or TComponent ownership) to an ARC model.

  7. Thomas Mueller Says:

    I am not really surprised by the slow uptake and the lacking maturity of Firemonkey. Developers and component vendors just learned from the fiasco of the abandoned CLX and Kylix.

    “Fool me once, shame on you; fool me twice, shame on me”

    I am not going to “bet the farm on Firemonkey” but on the other hand, we are mostly developing in house applications and we don’t use Apple products.

    OTOH Lazarus looks much more promising than ever.

  8. Says:

    Hey, Larry’s back to posting. Cool.

    The cost problem you’re facing isn’t the fault of Delphi or Embarcadero. It’s the world as a whole. Imagine if the going rate for software development services were $1000 per hour. Would Delphi cost a lot then?

    If you are having problems attaining a substantial rate for your services (I know I am) then it’s time to rethink your business. I’m offering Delphi development services because I enjoy working with Delphi.

    Years ago you could ask $300 per hour and get it, no problem (heck that was a low rate). But, today is different. Keep in mind the markets are being bolstered by government support in most countries on this planet. That should tell you something!!!

  9. André Says:

    I find the idea of FMX good. To be regardless of windows controls and messages feels well. Free scalability Canvas also.
    But the realisation of the styles is bad and above all the LiveBindings are not usable. The Controls are built up needlessly elaborately and too many methodes are not changeable (privately or not virtual).
    Something is still to be done and not only for XE4. Embarcadero has it in the hand.

  10. Bunny Says:

    300 USD per hour, omg. This was the rate of a consulting firm in 2k in rare cases. Guys you are spoilt:)

    The only trouble in my country - ok income tax and social assurance + fees are about 50% + 5% other fees. 20% VAT. So purchasing power is not high. Cigarretts and fuell include 60 to 70% fees (end price is 100%). Other factors have to be considered too (office, maybe car ….) Super Fuel 1,4 EUR per liter, pack of cigarettes is about 4 EUR. Chamber of commerce takes away 2% of the turnover if you have a bigger business, the chamber for the employees 1% of the gross salary , the communities charge extra fees per employee…

    The cost for the IDE is not the big thing in general. What hurts is if productivity drops. The avg. ‘productivity’ of a developer is 50% in best case. In reality it’s 40% on an average. You can have a hourly rate of about 60 to 80 EUR. Assume what I call the productive time can be charged. We don’t have such a huge demand for things that can built with Delphi.

    What can help you to earn money to reinvest is a continuous flow that does not break. Honestly what becomes shipped must be rock solid produced in shortest time and no big change concerning the requirements found. Customers don’t pay for a functional specification, they want it for free and give it to the competition afterwards… industry is different.

    This all together leads to a market that is splits into 2 categories. You can make/be part of huge projects or very tiny. I think this is reflected in the communication
    a) Stores … App. Tiny business but paid per piece and not hours - advantage
    b) ORM and similar - big architecture, if not customizing.

    Happy those who have mid sized projects, but I think those are rare.

  11. Peter Says:

    FMX has a interface problem!!! I want to dev with FMX but I can’t. It is impossible to compile VCL code with FMX. The interfaces are almost incompatible. Often people say, FMX is a new framework without conjunction to Win. I can answer here: why it is possible to compile code for Win, Linux, iOS and Android with Lazarus from one and only code base???

  12. Larry Hengen Says:


    I completey agree! I blogged about the inconsistencies between the two frameworks in a previous post, pointing out how these require conditional compilation and impeding a single source, multiple target (FMX and VCL) application. Essentially you have to choose either FMX or VCL, and converting a VCL application to FMX is that much harder.

  13. Chris Says:

    The last things FMX need are more virtual methods and aiming for ‘interface compatibility’ with the VCL. Randomly virtualising things contributed to FMX’s bad design at the outset (and is still somewhat with us in XE3, e.g AddObject and InsertObject). As for VCL interface compability, that would require imposing funky Windows-isms (even Windows 3.1-isms) on FMX, which would be bizarre. FMX suffers from enough VCL’isms as it is! (I’m looking at you, Application.MainForm…)

    That said, FMX manages to mix an over-reliance on copy and pasting from the VCL sources with annoying different-for-different’s sake aspects too - Text not Caption, the silly IsXXX semi-convention for Boolean read/write properties, the meaning of Margins and Paddings flipped, etc. The problem with those sorts of differences IMO is that they hamper learning the framework, not that they prevent recompiling the original FishFacts demo as an Android application. I mean, why on earth would you want to?

  14. Joseph Says:

    When he took over a floundering Nokia, which continued to ship the same outdated product even as the market and world had changed, Stephen Elop distributed a memo in which he compared the situation the company faced to that of being on a “burning platform”. Embarcadero faces a similar situation to that of Nokia, but instead of a burning platform, Embarcadero appears to have burning monkeys. :-)

    I think you nailed it when you pointed out the problem with tying Firemonkey to Delphi. Delphi has shrunk to a niche, and that leaves Firemonkey in the same situation. They also don’t seem to understand that they have competition (not a word on their website comparing either Delphi or Firemonkey to their real world competition).

    I’d been thinking the last few days along the same lines and had been wondering if they would have been better making Firemonkey a standalone framework and produced bindings for numerous languages - in other words, the path taken by Qt. I’d also been thinking that the VCL might be a rapid application development framework, but Object Pascal was never designed as a rapid application development language (not with Pascal’s obsessive type checking). I don’t think they’re remotely in the position to debut a completely new language, however. A more open Firemonkey would have been the only viable alternative.

    Meanwhile, Qt will have official Android and iOS support this year, and it’s a very stable platform - it has to be, since it’s used in embedded devices, including medical. Mono also makes .Net available on Android and iOS (and Oxygene can bring Pascal syntax to Mono and Android’s Java dialect). I think Embarcadero’s major problem that encapsulates almost all the others is that they simply no longer offer anything unique. Competitors exist that can do it better, do it cheaper, or sometimes both. Their marketing doesn’t produce a single case study of someone converting to their tools and achieving productivity gains or cost savings. The other overriding problem is not having enough resources - this affects quality control, development speed, beta-quality products being shipped as final versions, lack of documentation, etc. Their lack of resources (combined with lack of popularity) make it impossible to foster/maintain a robust ecosystem around their products. Nowadays, you need either a healthy open source community or a monopoly’s assets (Microsoft) to do that.

    At this point I really don’t know what I’d do if I were running the company (their database tools were floundering as well before being taken private).

    >The memory model is prepared to change, from manual object lifetime process (or
    >TComponent ownership) to an ARC model.

    Maybe they really ARE going to be making a rapid application language? :-) I just commented on Nick Hodges’ blog yesterday that manual garbage collection and static typing are not traits of rapid application development languages.

Leave a Reply