Hands on with Delphi XE2 for Apple iOS

Last week Embarcardero released RAD Studio XE2. RAD Studio is the suite of tools based on Delphi, a language – originally called Object Pascal – and visual development tool which still has a loyal following. XE2 is the most interesting new release for years, introducing a 64-bit compiler for Windows and cross-platform support for Apple’s OSX and iOS.

I have been trying the final release, paying particular attention to the iOS support, bearing in mind the importance of Apple’s mobile platform. The RAD Studio IDE only runs on Windows, so the most convenient way to target Apple’s platform is to install on a Windows virtual machine. I used a Parallels VM running Windows 7 64-bit, hosted on OS X Lion.

Setting up for iOS development with RAD Studio XE2 involves several steps. First, you have to use the new FireMonkey application framework in order to do cross-platform work. FireMonkey emerged after Embarcadero acquired the intellectual property of a company called KSDev early in 2011, along with its founder Eugene Kryukov:

KSDev’s intellectual property has been purchased by Embarcadero Technologies, the makers of Delphi and C++Builder Rapid App Development Tools. I am excited to announce that I have joined Embaracadero’s next gen frameworks team leading a very exciting project. As a result I will no longer operate the KSDev company and will not be accepting any further orders for KSDev products.

The products in question were Delphi frameworks called VGScene and DXScene, and these seem to have been melded with remarkable speed into what is now called FireMonkey. FireMonkey controls such as buttons and listboxes are all custom drawn, which is good for cross-platform consistency, but bad if you want your application to look and feel truly native. FireMonkey is not compatible with Delphi’s VCL (Visual Component Library), though the basic controls like TButton and TEdit are similar. FireMonkey applications can be either 3D, with the emphasis on Flash-like visual effects, or HD, used for more traditional user interfaces.

Support for Mac OSX is more fully integrated than for iOS. You can easily add an OSX target to a FireMonkey application, but for iOS you have to create a new application that only targets iOS. Another difference is that Embarcadero has its own Mac compiler, whereas the iOS support depends on the FreePascal open source compiler. If you are targetting OSX, you can code and debug entirely from the Delphi IDE, whereas for iOS you have to export your project and compile in Xcode.

In order to prepare for iOS development, you first need a Mac with XCode and the iOS SDK installed. Next, install RAD Studio XE2 on Windows. Then find the FireMonkey-iOS folder in the directory where RAD Studio XE2 is installed. This contains FireMonkey-iOS.dmg. Copy this to the Mac side, mount it and run the FireMonkey iOS installers to add FreePascal and the FireMonkey libraries to your XCode setup.


If you are also doing OSX development you will also need to install the Platform Assistant on the Mac, but for iOS this is not required.

Now you can go over to the Windows side, start a new application observing all the tasty new options, and choose a FireMonkey HD iOS application.


This creates a new form sized for an iPhone 4.0, though of course you can amend this. There is a tool palette which looks well-stocked with components, but note the following warning:

While you are designing your iOS application, you can only use components that are supported on iOS devices. However, the Tool Palette might contain components that are Windows-only or otherwise not supported on iOS.

That is an annoyance, and contributes to a feeling that iOS support is a little, dare I say, unfinished. Still, undaunted I built my sample app, following the path I have trodden before by creating a simple calculator.


You might wonder why all the buttons are green. I did, too, and played around a little trying to change it. This seems to involve creating a custom style. I started doing this, but decided it was not necessary for my simple test. It does make the point that the default appearance does not have the iOS look and feel.

There is what seems to me a small bug in the designer. If you select more than one control, the sizing tabs disappear and there is no visual evidence that the controls are selected, other than a heading in the Object Inspector that reads “n items selected.” At first I thought it was impossible to select more than one control, but this is not the case. However, there is no clipboard support in the visual designer. For example, if you want several buttons that are exactly the same, you need to add them individually, then multi-select and set the properties as needed.

While developing an iOS app, you can test it by running it on Windows within the IDE. When it is ready to test on iOS, you need to export the project. To do this, you need a command-line tool called dpr2xcode.exe, which is in the RAD Studio bin folder. Running this from the command-line is inconvenient, so the usual approach is to use Configure Tools from the Tools menu to add it to the IDE.


It is puzzling that Embarcadero has not included this by default.

Running the tool creates an xcode sub-folder in your project directory, with an .xcodeproj project file along with some default icons. I then copied the entire project folder to the Mac. It is also possible to use a shared folder accessed from both Windows and Mac, though I found this does not work if the folder is on the Windows side, so I simply copied it back and forth.

I opened the project in Xcode, and was prompted to “Modernize” it in Xcode jargon, to no ill effect. At this point I could successfully build it and run in the iPhone emulator.

Of course I wanted to test it on an actual device. I attached an iPhone 4 and did the Apple provisioning dance. After the usual messing around with certificates, it worked.


and here it is on the iPhone:


It works, and to that extent I am impressed. That said, I am disappointed with the performance. This is subjective, but I am talking about the responsiveness of the UI. There are perceptible pauses, which for such a simple app is surprising. I have created this same app numerous times using different development tools, and had expected that the Delphi version would be up there with the best, but while it is acceptable it is less responsive than some of the others.

Let me add though, a Delphi developer will find the process described above a easier than learning Objective C, and I was able to create this fully working app in an afternoon so I should not complain too much.

Maybe when Embarcadero comes up with its own iOS compiler there will be some improvement.

23 thoughts on “Hands on with Delphi XE2 for Apple iOS”

  1. You may “dare say” that the iOS support is a little unfinished. But why not go as far as Embarcadero ? And simply acknowledge that it is a LOT unfinished. 🙂

    They aren’t trying to pass the iOS support off as “prime time” – far from it. It is very much a preview, not finished. But they are I think rightly proud of what they have achieved so far, and I can’t wait to see what they achieve in the finished product.

    This might also explain the performance of the code on your iOS device… as I understand it, the compiler actually used to generate the iOS code in x-code is the FreePascal compiler (FPC). I hope I am not doing the efforts of the open source community on that project a disservice when I say that on every occasion that I have investigated the FPC as a potential alternative to Delphi I have come away disappointed, not least by the performance of the code it produces. So yes, I too would expected a significant leap forward when the Delphi compiler itself is producing the final executable code for the device.

    Great post tho… this and the future support for Android are a source of much excitement and anticipation in the Delphi community right now and could be a great opportunity to expand that community even further in the near future!

    1. Thanks for the comments. While I agree with you, I don’t see anything on the official RAD Studio XE2 page I referenced that says iOS is unfinished or a preview.


  2. Thanks for the details. This will help me make a decision whether to wait.

    BTW, a typo:
    If you are targetting iOS, you can code and debug entirely from the Delphi IDE, whereas for iOS you have to export your project and compile in Xcode.

    Which is which?

  3. Actually, it is quite weird to hear that a native application produced using DELPHI->FPC is less responding compare to other non-native application.

    Can it be the FM framework is too complex for a small processor? I doubt that this issue got something to do with quality of native code generated by FPC. but of course, if embarcadero can produce a ARM compiler then ther are big possibility that we can see a better output than what we have right now.

    1. It must be to do with the custom drawing for the FireMonkey controls. My guess is that non-visual code performs fine though I have not tested this yet.


  4. There’s a lot “unfinished” in Delphi, since Delphi 3 at least. Often a framework was introduced because that technology was “hot” then, delivered with some rough edges and unfinished features due to tight releases schedules, then it was forgot and never finished and polished. It happend with DCOM/Midas/Datasnap, it happened with the several web frameworks attempts, it happened with their XML transform tool, it happened with web services support. Even the new Datasnap was released without a lot of needed basic features (security especially), and is still slowing adding them. Of course nothing was said to be “unfinished” or a “preview”, but often many pieces were and some are still missing. I refer often to them as the “non finito” (http://en.wikipedia.org/wiki/Non_finito), but there it is art, in Delphi it’s just missing pieces.

  5. Obviously it’s not “code speed”. It looks like the FMX code for iOS is simply not tuned or not using all the right APIs (OpenGL I suppose). When they get their hands onto fixing this (I suppose this is a bug) the delays would be gone.

  6. The UI sluggishness you see likely has absolutely nothing to do with FPC. My own tests show that both FPC and the underlying ObjC classes are plenty fast. Here are some example results:

    (1) I took 25,000 lines of non-UI code from a scientific model and added it to a simple app to exercise the code. Performance is great, even on a 2nd generation iPod touch. This code makes heavy use of strings, TStringList, expression evaluation, file I/O.

    FPC-compiled ARM executable size is 1.1 MB.

    (2) I also have an app with 15 UITextField controls on a view. Populating these controls with text from a Sqlite db shows no noticeable delay on a 2nd gen iPod touch.

    FPC-compiled ARM executable size is 630 KB.

    No, I think what you’re seeing is something common to most UI frameworks when they try to reproduce and simulate what the underlying, highly optimize native UI controls do. I doubt if an Embarc compiler will make any difference – its code might even be slower and bigger – afterall the Free Pascal boys have been at this a while on ARM.

    Probably Embarc made a decision that the iPad 2 is the baseline device for FM – certainly that’s all you see in the their demos. And in a year or so that will be the dominant performance level. It appears as though Apple might ship 20 million iPads this summer. And the iPhone 5 will probably have performance similar to the iPad 2.

    A more serious drawback is the current lack of access to the other frameworks. If you think of FM as the rough equivalent of UIKit, then that leaves 38 other frameworks, including support for accelerometer, GPS, camera, contacts, calendar, Sqlite, etc. etc. These are the frameworks that non-trivial apps will use.

    It is possible to create cross-platform libraries for some of these things that are common to all mobile devices (Android too) and maybe we’ll see something like that, meaning you won’t have to work with the ObjC (or Java) classes. PhoneGap has shown that this is possible even for JavaScript:


    However, PhoneGap has been at this for over 3 years; Embarc has just started.




  7. Real applications need Files and Databases. Any ideas if they have done any work in this area, for example, supporting sqlite?

  8. Really good , just a question how could you build it in Xcode to real Device use , I mean I’ve done a little project and built it in XCode but i could not find where it saves the Final product ( like *.exe in windows ) , i think its extension is .IPA .
    Cause i hear that you must get a certificate or a Code or something like that from Apple to be able to use your project in a real Device, is that correct

  9. These two statements seem contradictory —

    “If you are targetting OSX, you can code and debug entirely from the Delphi IDE, whereas for iOS you have to export your project and compile in Xcode.”
    “While developing an iOS app, you can test it by running it on Windows within the IDE.

    You can code and debug from the IDE. And the process to test and debug on the target platform, be it OSX and iOS, are really not that far apart. One has a platform assistant to make the process easier. One doesn’t… yet.

  10. “You might wonder why all the buttons are green. I did, too, and played around a little trying to change it. This seems to involve creating a custom style.”

    You don’t need to create a custom style – you can choose to use one of the several pre-built styles – right mouse click in the IDE on a FM UI component – you get to the style editor. Choose Load – to load one of the styles and then click Apply to all – you get that style for all FM components you are using.

    if you want circular buttons (with glow effect) – Set the button’s StyleLookup property in the object inspector to:
    StyleLookup = ‘CircleButtonStyle’

    And, yes, you can create custom styles and style books. I fully expect that people will upload styles that developers can use.

  11. One more point on iOS integration – there is a unit file – iPhoneAll.pas that you can use to access everything on the iPhone using Object Pascal. We have on our roadmap to provide components eventually for proper design/development. We are also working on a next generation Delphi compiler to support ARM chip and mobile devices. We are only using FPC for iOS in the meantime to get developers started.

  12. Good post indeed to get uninitialized delphi developers started with Mac platform. Just one point though. For any debugging or testing purposes especially device specific code (even printing) we need to test application on real target platform because behind the scene IDE hooks up the code related to current platform on which it is being debugged/tested and not the desired platform.

    To give you an example, if you need any printer APIs like begindoc or try to manipulate printer(s) on current system then the application being debugged on windows system will be using FMX.Printer.Win and not FMX.Printer.Mac!. So while you may see nothing wrong while testing on windows system, it will simply fail on desired/target system (MAC).

    Indeed a long way to go………………and hopefully this will not share Kylix’s fate

  13. Hello Tim,
    First of all, congratulations for your successfull attempt;
    I’d like to know how would be the development for Ipad; if I understood well, we need an Apple computer to finish the job and then export the programm from Apple to Ipad ? Or can we do all the job on Delphi XE2 and export the program to Ipad ? ( we’ll probably need to Jailbreak Ipad too!).

    Tks for you comments.

  14. I purshased the Eugene Kryukov’s KSDev components 2 months before they were bought by Embarcadero. In the Eugene Kryukov site there was an option to buy with an extra value for the lifetime free updates and support. I and another ones paid this extra value. Nice trick Eugene Kryukov! Have we got these life updates and support from Embarcadero now?

  15. ::I’d like to know how would be the development for Ipad; if I understood well, we need an Apple computer to finish the job and then export the programm from Apple to Ipad ? Or can we do all the job on Delphi XE2 and export the program to Ipad ? ( we’ll probably need to Jailbreak Ipad too!).::

    You need to connect your iPad/iPhone to the Mac using a USB connection. So you need a Mac or put Mac OSX on a PC which is what we’ve done (but it is much simpler just to buy a Mac).


Leave a Reply

Your email address will not be published. Required fields are marked *