We’ve heard lots of noises about Embo’s pending Delphi support for iOS over the last 6 months or more and now the wait is over.
The iOS support has arrived, but not as the largely expected add-on to XE3, but instead as a new version: XE4 (available with or without iOS support). Delphi XE4 has arrived (along with C++Builder XE4 and RAD Studio XE4) and now targets:
- 32-bit Windows
- 64-bit Windows
- 32-bit OS X
- iOS Simulator (Intel)
- iOS (ARM)
There is a flurry of activity about this new release over the blogosphere and here’s a summary of the key points regarding information about the product and regarding the product itself.
Information
- The product will be announced to the web during a launch webinar on Wednesday (24th April, 2013). Full details can be found here and the registration page is here.
- The product landing pages for Delphi, C++Builder and RAD Studio have been updated to cover the new version.
- The formal press release announcing the new version can be found here.
- XE4 documentation is online with the landing page at http://docwiki.embarcadero.com/RADStudio/XE4/en.
- iOS tutorials can be found here.
- For those with a serial number you can download the RAD Studio XE4 .iso DVD image from download page or directly from this link.
- Trial versions can be obtained from here for RAD Studio XE4, here for Delphi XE4 and here for C++Builder XE4. As well as the regular trial versions there is also an AppWave trial (so-called Instant Trial), which is set up in minutes and can be removed trivially; the link is here.
- What’s New in Delphi and C++Builder XE4.
- What’s New In C++Builder 64-bit Windows.
- Marco Cantú’s white paper The Delphi Language for Mobile Development is available from here and you can see the Table of Contents in Marco’s post here.
- Delphi Prism aka Embarcadero Prism, the Embarcadero-branded version of RemObjects Oxygene for .NET, is no longer supplied with RAD Studio. RemObjects will be happy to continue a relationship with you, and tempt you to their approach to multi-device support, which revolves around Oxygene for .NET, Oxygene for Java and their forthcoming Oxygene for Cocoa.
Product details
The main thrust of this release is the Delphi support for iOS, specifically two new cross-compilers that support targeting the iOS simulator (Intel) and native iOS (ARM) called dccios32.exe and dcciosarm.exe.
As you might expect there have been a raft of changes in FireMonkey to support this wider platform range and improve the existing platform support. Indeed FireMonkey has now changed from being known as FM2 to now being FM3. The online help has much information on the changes to FireMonkey.
The IDE has new mobile form designers (no longer floatable) and new target platforms to get your app on the simulator or iOS device. Of course FireDAC is in the box too.
InterBase ToGo is now supplied as an option for an embedded database in your application, including iOS applications. Note that InterBase ToGo requires a license to be bought, whereas IBLite does not (and also does not support encryption, more than 1 core, more than 1 connection, etc.). More info on InterBase ToGo is available in this quick-start guide.
iOS support has been added for SQLite, IBExpress and the MIDAS client components (notably TClientDataSet).
The iOS compilers introduce the Next Generation Delphi language, which some of you will have seen hints of in the Delphi XE3 source code via the NEXTGEN conditional compilation symbol that is checked for in many places. This Next Generation Delphi support is currently only available in the iOS compilers, though it’s a safe bet we’ll also see it in the Android compiler, whenever that appears.
The Next Generation Delphi compiler takes the opportunity to off-load some aspects of the Delphi language that are a little archaic and at the same time bring in some new helpful features.
Things that have gone/changed include:
- Some of the many string types have gone (AnsiString, UTF8String, RawByteString, WideString, AnsiChar, PAnsiChar, PWideChar, OpenString, ShortString) leaving just the basic type string , an alias for UnicodeString.
- Pointer support is gone. For interfacing with external library APIs there is a new TMarshaller record, which works with the TPtrWrapper record.
- Strings are 0-indexed instead of 1-indexed by default. It is recommended you employ TStringHelper (introduced in XE3) to work with strings as it knows about the string indexing on the different platforms.
- Strings are to be considered immutable. Currently you can change string contents but will get a warning for your trouble. This is to encourage you to change the code to use a TStringBuilder to build a new string. Future versions may change the warning to an error.
- Inline assembler support is gone.
- You are advised to rewrite code that uses with as this is likely to be removed in future versions. I can see the benefit in enforcing this, as I have bumped into so many scope errors caused by over-zealous with usage over the years…
New things include:
| Symbol: | Defined: | For compilers: |
| AUTOREFCOUNT | if ARC is available | dcciosarm, dccios32 |
| CPUARM | if the CPU is ARM-based | dcciosarm |
| EXTERNAL_LINKER | for compilers with an external linker | dcciosarm, dccios32 |
| IOS | target platform is iOS | dcciosarm, dccios32 |
| NEXTGEN | for Next Generation Delphi compiler | dcciosarm, dccios32 |
| UNDERSCOREIMPORTNAME | for compilers that add leading underscores when importing libs | dcc32, dccosx, dccios32 |
| WEAKREF | for compilers that can use weak references | dcciosarm, dccios32 |
| WEAKINSTREF | when weak references are defined for instances | dcciosarm, dccios32 |
| WEAKINTFREF | when weak references are defined for interfaces | dcciosarm, dccios32 |
- {$ZEROBASEDSTRINGS ON/OFF} controls whether 0-based or 1-based string indexing is active. You can, for example, use this to force 1-based indexing in mobile code that you haven’t yet updated
- {$EXTENDEDCOMPATIBILITY ON/OFF} allows use of Extended data type on platforms that do not normally support it (Win64 and iOS). The given support offers the expected 10 bytes storage but doesn’t offer the higher floating-point support that Win32 Extended gives.
- [volatile] to indicate the field may be changed by other threads (it’s a hint to the code optimiser).
- [weak] to mark a weak reference.
- [Ref] to ensure constant parameters are passed by reference rather than by value.
Given these changes there is a page that talks about how to migrate code from the desktop to iOS.
Taking all the above onboard, it looks currently like Embo offer a common component framework (also, slightly confusingly, referred to as a platform) to program against for different target platforms (Win32, Win64, OS X, iOS) in FireMonkey (aka FMX aka FM3). As for your Delphi code, however, it would currently appear that desktop code and mobile code will look a bit different, thanks to the string changes (1-indexing to 0-indexing and the push towards immutability) and of course the specific form factors of the UI on the respective platforms.
So, you build a mobile UI and you build a desktop UI. With the desktop UI you take great care to ensure the app looks like a Windows app when compiled for and running on Windows (menu layout, button order and placement on dialogs), and looks like a Mac app when compiled for and running on OS X.
Then when you come to build the code base, you write it once for the desktop using all the standard Delphi-desktop paradigms of creating objects and ensuring they are destroyed with try/finally/free/end. On the mobile side you skip all that and let objects be cleaned up by ARC, and ensure weak references are specified where appropriate.
I’m sure the desktop compiler will catch up with these changes at some point, but in the interim there is a requirement for quite a bit of conditional compilation, or making use of no-op calls in the mobile code. And if/when the desktop compiler catches up, that will potentially force a big hit in massaging desktop code into the new realm of Next Generation Delphi.
It’s all a bit up in the air as to how things will pan out, but to my eyes currently, the only common thing is the FireMonkey framework. Other than that, the coding and design looks to require dedication per platform targeted. Which is no bad thing. In my opinion, when targeting a given platform you should put some effort into making sure the application works gracefully and looks in keeping with its peers.
With that mindset in place, the iOS support looks pretty neat and the changes to the language make Delphi behave a little more like many of the other popular languages in existence. I’ve certainly got no issues with kicking out with and dropping to a single string type. Let’s just be careful to not play the “write once run anywhere” card too frequently, eh?