Embarcardero is drip-feeding information about its forthcoming RAD Studio XE2 in an annoying manner; nevertheless the product does look interesting and promises cross-platform native code apps for Windows 64-bit, Windows 32-bit, Mac OS X and Apple iOS. I have grabbed some screens from a video recently posted by Embarcadero’s Andreano Lanusse; the video is also embedded below.
Here is Delphi XE2 showing a FireMonkey application in the designer. FireMonkey is a new cross-platform GUI framework.
Note the list of target platforms on the right. If you squint you can see 64-bit Windows, OSX, and 32-bit Windows.
How do you compile for the Mac? It is clear from the demo that Lanusse is running in a VMWare virtual machine on a Mac. He also has a Remote Profile option set to target the host Mac:
He then refers to a “Platform assistant” which you can see running in a terminal window on the Mac. He is then able to compile and run from the Windows IDE:
Finally, he targets iOS, though this is a separate project, not just another target. The process exports the project to Xcode, Apple’s Mac and iOS IDE:
Next, we see the app running on the iPad simulator:
The ability to target the Mac is nice to have, but I suspect it is iOS that will attract more interest, given the importance of Apple’s mobile platform.
Here’s the complete video where you can perhaps puzzle out a few more details.
Update: there is also some Q&A in the comments here.
Graphics rendering is Direct2D or Direct3D on Windows, OpenGL on Mac. FireMonkey renders all components through the graphics API, it does not support use native OS components, though Embarcadero’s Michael Swindell says:
FireMonkey client area controls are rendered by OpenGL on Mac, but appear and work just like Cocoa controls – or however you want them to. There are many different Cocoa UI styles in OSX apps, and Firemonkey can render any of them – including iTunes, or Prokit which is an Apple UI style for Pro apps like Final Cut, not available to devs via Cocoa. Windows are Cocoa Windows and the client areas and all user controls are rendered by OpenGL in HD(2D) or 3D. Menus are std and rendered by Cocoa in the menu bar, and common dialogs are rendered by Cocoa. If the “true OSX” look isn’t for you, you’re welcome to use any included Style, download a custom style, or create your own custom style.
Swindell also addresses the matter of Linux and Android:
We do plan Linux and Android. But no eta yet until we get Win/OSX/iOS out. We would also like to provide language bindings for other languages.
Finally, a bit more about that Platform Assistant:
Developer requires a PC and a Mac (or Mac with VM running Windows). You will develop on Windows, and use the platform assistant (PA running on your Mac) to compile natively to your Mac and the PA handles debugging communication between the Mac and your IDE running on Windows. Delphi (or C++Builder) and Firemonkey create compiled stand alone OSX executables that you can sell/distribute to your users. They are native Mac apps. They “copy install” and run like any other Mac app, or you can use a Mac installer if you like.
Drip feeding? The initial public announcements on August 2nd covered all of the major points.
In a previous release, they tried announcing a little bit of information at a time (presumably to build anticipation), and some people assumed (loudly) that the initial demo represented everything. I like the current “announce everything and fill in the gaps” strategy much better.
Hi Bruce, not sure what public announcement you are referring to? Davidi’s post on 1 Aug, for example, does not refer to native compilation for iOS.
Tim
Hi Tim,
True. That didn’t come out until a couple of days later when people started blogging about the World Tour events.
Do you really think that’s drip-feeding, though? I think it was a missing bullet point on the original announcement.
Some bullet point!
Tim
My guess is that the following clarification has something to do with why iOS support wasn’t initially mentioned:
‘Delphi iOS FireMonkey Applications – using a special version of the Free Pascal Compiler/RTL/FireMonkey until our next generation Delphi compiler is completed.’
http://blogs.embarcadero.com/davidi/2011/08/01/41062/#comment-26012
This also explains why the iOS demo in that video required a separate project file (I also spotted a *.LFM – Lazarus equivalent of a *.DFM – and lack of dotted unit names, both signs of FPC). Presumably that will become unnecessary once the ‘real’ Delphi compiler targets ARM.
I wonder whether there’s been debate internally over whether to leverage FPC or not. FireMonkey is a refactored, integrated version of a product that was already doing this, so it’s not like Embarcadero ever decided to investigate using FPC – rather, the decision would have been whether to *drop* use of it (http://www.ksdev.com/wiki/index.php?title=IOS_Development). (OSX is a different story, since compiler and RTL support for that was already done.)
The .LFM and FPC references in the source code is probably from the original ‘FireMonkey’ source which comes from a third party product called VGScene/VXScene which supported Lazarus/FPC.
VGScene was developed by KSDEv (http://www.ksdev.com/) KSDev and all its technology was aquired by Embarcadero.
@Chris You’re perfectly right. Embarcadero will use FPC and Lazarus until their own ARM back-end will be ready, then they will just drop FPC support. Their goal is to have iOS be just another platform available from the main Delphi IDE by cross-compilation and cross-debugging, just like OS X. FPC/Lazarus is just some transitional step.
I’m quite sure there was some internal debate at EMB about using FPC or not. And I’m impressed that they finally use FPC, even for a first launch. They did not use FPC for 64 bit support – which compiled for Win64 in 2006, see http://blog.synopse.info/post/2010/08/14/FPC-and-Delphi%3A-toward-a-%22fratricidal-war%22 – but they used it for ARM. Open-minded attitude, or just pragmatic? At least, it gives lights to FPC / Lazarus… which deserve it!
Regarding the use of FPC with FireMonkey – we are responding to requests from developers who want to be able to use their Delphi skills and FireMonkey to build applications for many platforms. We are working on our next generation compiler – that has been talked about and worked on for more than a year now. In the meantime, we are leveraging the Free Pascal Compiler, our FireMonkey application platform, and our Windows IDE with Delphi. We are not using Lazarus for anything. For 64-bit Windows we are using our own compiler. There was no internal debate inside Embarcadero about using FPC or not. We continue to work to help our customers and to build great products regardless of what technologies are required to help. Yes, we continue to work on our Delphi and C++ next gen compilers and you will see these when they are ready. What you see is part of the increased investments that Embarcadero is making in development tools and developers.
One other point to add about RAD Studio XE2 and support for additional platforms and languages. RAD Studio also includes new Mobile Connectors for our Delphi and C++ DataSnap Servers. We will deliver Proxy Generators and libraries to allow developers to build mobile clients for Java/Blackberry, Java/Android, C#/Windows Phone 7, and Objective-C/iOS. RadPHP XE2 also allows you to build mobile applications using PHP, JQueryMobile, and PhoneGap. These are also part of our strategy to leverage whatever we can to help developers build mobile clients that work with server side applications we have supported for years.
To reply specifically to A. Bouchez’s comment – these decisions are BOTH open minded and pragmatic 🙂
“drip-feeding information about its forthcoming RAD Studio XE2 in an annoying manner”
In our preview tours – that started last week in Auckland New Zealand – we are showing everything both in a high level Product Address and 5 deep dive technical sessions. This week the team is hitting Sydney, Melbourne and Seoul. Community members are posting informative reports from each stop. We will continue to putting additional information online and answering questions leading up to the launch and release of XE2.
Last Spring we also posted a preview video about the Delphi 64-bit support with lots of technical details and demos to help inform developers. We will continue to deliver all the information needed by developers so that they will be ready to use the product and technologies once they can get their hands or the release.
@David I: IMO, if there really wasn’t *any* internal debate on the matter, then there should have been – I’m not saying the final decision was wrong, just that it surely wasn’t a no-brainer. After a bit of a struggle, I’ve just downloaded the lasted FPC development version, and I have to say I’m disappointed – I knew anonymous methods and extended RTTI weren’t in, but the string type is still Ansi, and the claimed implementation of Delphi generics is nothing of the sort (they’ve taken native FPC ‘generics’ and allowed a Delphi-like syntax, which isn’t the same thing as Delphi generics at all). Roll on a ‘real’ Delphi compiler for ARM I’d say!
Many people said Project X was nonsense, firemonkey and Delphi combined really have pushed the Delphi ecosystem five years yonder which is presumably the intention of bum melon Chinese calendar project naming. Accurate though, given half a farthing. Single source is the tits regardless of what dot net fanboys puke down your face, vector based rendering retracts from standardised component frameworks for obvious reasons. Live bindings renders data aware obsolete and vcl can heed said chuff felch given the movement towards developer peer acceptance.
The key here is connectivity,firemonkey rest library anyone? Plus a side order of standardised cocoa controls RE fm skinning, or call me pirate Peter.
iPhone + connectivity+ standard look > ie keyboard, breadcrumbs, launch wibble and a native pixel perfect Fallick menu is what we demand (request)!! Much love techno wog.
I left the presentation boombazzled, still excitable.
Imagine.
No, seriously imagine > months from now, FireMonkey gains traction. Cocoa no longer a tasty drink, yet known for the kinky wrappers laid forth unto Delphi unit splendour.
I for one, being if sound body and extreme object pascal experience, have faith that this release truly delivers iWhateverYouUse compatibility provided it doesn’t look all Susan Boyle in a plate if chips.
REST enable servers delivering end-client data through a coherent XML data-fart prevents no wrong.
Puffin Party integration a hopeful, the use of FPC seems extra-curricular, but if it saves time and enables RAD then you know Delphi devs don’t jive no beef. Good works Embarcadero!
I’m inclined to agree with Banana Robert, the big thing for me (admittedly having not compiled anything yet!) is the FireMonkey REST connectivity which will allow us to easily rework our existing clientserver apps in the DMZ to become RESTful servers, then FireMonkey can dive straight in.
This is massive, if FM continues to gain support Delphi will be back on top for RAD, exciting to see the direction people go in.
Ross