As a longtime Delphi user you might be wondering: Why should I check out this Oxygene thing? Especially now that Delphi proclaims support for Mac, iOS and Android, as well.
This page looks at some of the many reasons as to why Delphi is not an appropriate solution to bet your development investment on in the long run – especially for the new mobile platforms.
One big marketing point for Delphi that you'll find in every second sentence describing the product is that it supposedly is a "true native" compiler. But what does that mean? When Embarcadero says "true native", they mean that their compiler compiles directly to x86 or ARM binary code. That certainly is one measure, but one that is becoming increasingly more irrelevant.
Delphi does not support compiling to 64-bit for Mac OS X, and the Mac platform – more so than Windows – has been truly 64-bit for a long time now, since 2007. In fact, no serious Mac developer these days still ships 32-bit only applications.
Delphi was a year and a half late in supporting 64-bit for iOS – leaving its users stranded without being able to submit their apps to the App Store for several months, in early 2015.*.
Delphi does not build Android apps that run on anything but a very limited set of CPU types. Android hardware uses a wide range of CPUs, from different ARM chips to Intel Atom, MIPS and other CPUs. But applications built with Delphi require specific CPU and GPU hardware and will not run on any device.
And while Delphi claims to provide "true native" Android support, it uses the so-called "NDK", bypassing the Android SDK and everything that makes Android, well, Android. Even Google themselves recommend that the NDK should not be used for general purpose app development. Delphi then wraps those NDK-based apps in a small Java shim to get the OS to run them. "True native", indeed.
Delphi does not support Windows Phone, despite that platform being ever-growing and becoming a strong third player in the mobile market. In fact, Embarcadero has stated that they're not interested in the platform and would consider supporting Blackberry before they did Windows Phone. Of course this might be because Windows Phone cannot be supported with a "true native" compiler.
It goes without saying that Oxygene fully supports 64-bit for Mac and iOS, and since it compiles for the Dalvik runtime for Android, Oxygene can build apps that run on any available Android device. And of course, Oxygene embraces .NET on the Windows side, letting you build apps for Windows Phone or using the WinRT and Windows 10 UAP frameworks, as well.
Delphi uses a new framework called "FireMonkey" for building cross-platform user interfaces.
FireMonkey does not use the platform's native UI controls, but rather renders controls itself, using skins that aim to mimic the original controls of the platform. As such, FireMonkey (or FMX for short) UIs never look truly native, and always feel awkward and out of place – especially so on the mobile platforms, where 100% fidelity, not just in the looks, but also in the timing and the physics of how the UIs behave are crucial.
What's more, this means that FireMonkey apps cannot automatically adapt to changes in the UI as the operating system evolves, relying on Embarcadero to update their skins for the new look. Famously, users of Delphi XE4 were forced to pay the upgrade price to XE5 to obtain support for the new look on iOS 7.0, despite XE4 shipping mere months before iOS 7 was announced.
By contrast, Oxygene uses the native controls on each platform, so that your applications feel native by default – because they are. So when iOS 7 came out, apps created in Oxygene automatically got the new look.
Delphi, especially with FireMonkey, but also for more traditional VCL-based Windows applications, creates huge executables (or executables with huge dependencies on Delphi runtime packages), because the entire framework needs to be linked in and deployed with the application. This is especially a concern on the mobile platforms, where download restrictions exist over 3G, and where customers might incur extra cost for large downloads. Delphi executables are measured in the megabytes or tens of megabytes.
Because Oxygene uses the platform's native frameworks as its runtime, Oxygene executables can be small, dare we say, tiny. Often in the ballpark of tens of kilobytes, for simple apps.
Let's face it: with some minor exceptions, such as (unstable) Generics, the Delphi language has been pretty stale and not evolved much since the mid-nineties. By today's standards, it feels antiquated and clumsy to work with – for example in the way it still forces you to manually manage each object's lifetime with lots of try/finally blocks and calls to Free.
By contrast, the Oxygene language started as a big superset of what Delphi had to offer, back in 2004. And it has been evolving by leaps and bounds since then, with new features that help you save time and write more efficient code being added all the time.
But that doesn't mean that Oxygene is hard to get into. On the surface, Oxygene is the Object Pascal you know and love – with some very minor cleanup. The new and advanced features are there for you to discover at your own pace. For example, you can write lots of great code in Oxygene without ever discovering the colon operator. But once you do discover it, you can't imagine how you ever lived without! And Oxygene is stock-full of nice little gems like that.
You can read more here.
Delphi sets out to promise the holy grail of software development: Write your code once and run it on all platforms. But that promise falls apart pretty quickly.
For one, the mobile version of Delphi actually breaks a great deal of compatibility. If you want to reuse your desktop code on mobile with Delphi, get ready for some pain: The indexing of strings changes from 1-based to 0-based, just for chuckles (WTF?). 8-bit strings, including ANSI and UTF-8 are gone, with no good way to reuse your code that relies on them. The memory management model differs – while the desktop still needs those pesky try/finallys, Delphi for mobile uses ARC. In practice, real live code never ports over as easily as promised – or at all.
And that's even before asking the question if it even makes sense for your desktop app to be ported to mobile as is. (To which the answer is, most likely not.)
For sure, Oxygene is a clean slate, and does not even pretend that your existing Delphi code will compile "as-is". But it's consistent across all platforms. Whether you build apps for Windows or Mac, iOS or Android: Strings are zero-based, memory management is taken care of for you via GC/ARC, and the language is consistent.
The one area that has been Delphi's forte when it first shipped over twenty years ago was Windows development. At the time, the VCL was a state-of-the-art and much needed abstraction layer on top of the sparse and clumsy-to-use Win32 API.
But a lot has changed in the Windows world since 1994, and not a lot has changed in Delphi, really. The VCL has been largely stagnant for at least a decade now, and is by many considered to be in maintenance mode. Embarcadero is focusing their efforts on FireMonkey to the detriment of the VCL, but the consensus among developers is clear: FireMonkey is far from being ready for prime time – on Windows maybe even more so than on the other platforms.
At the same time, Microsoft has been aggressively improving its API stack for app development. There's the .NET framework, which is now the established de-facto standard for writing apps on Windows no matter how much Embarcadero would like to convince you of the opposite with their "true native" shenanigans.
And of course there's the new WinRT platform – which is based on and essentially an evolution of the .NET platform – that drives Windows 8 and Windows 10. More on that below.
Delphi has to offer nothing but the sound of crickets when it comes to .NET or WinRT, with Embarcadero banking on being able to scare developers away from it with misleading marketing messages that compare .NET to "scripting languages".
With Oxygene, developers have full access to all of the .NET and WinRT platforms, letting you create everything from state-of-the-art Windows Desktop apps (using WPF, the framework that Delphi's FireMonkey is trying to mimic) to apps for the "Modern" Windows 8 and 10 platform, Windows Phone, and even Windows-based tablets.
Delphi does not support Windows RT, Windows 8 or Windows 10 "Modern" Apps, despite Embarcadero claiming the opposite and shipping some skins that make regular Windows Desktop apps look like "Metro" apps. But these "Metropolis" apps are not true "Windows 8/10" apps, and they will not run on Windows tablet hardware, such as the Surface.
With Windows 8.1 out now and Windows 10 coming soon, it is clear that the changes Microsoft has made to its operating system in Windows 8 are here to stay, and that creating applications for the new interface and the "Windows Store" will only become more important for Windows developers, moving forward.
As covered above, Oxygene of course has your back, with full support for "WinRT", the .NET-based frameworks behind Windows' new UI layer. After all, wouldn't it be silly for a state-of-the-art Windows development tool to not support that?
All this sums up to one take-away: Delphi has been a great development tool 10 or 15 years ago, and it popularized the Object Pascal language – which we love every bit as much as you do, if not more. But it's showing its age, and not keeping up with the times.
Oxygene is the language you love taken to the next level, and will be relevant for the next twenty years.
Oxygene itself has been around for about 8 years now, and we have proven that we can keep innovating, and keep it alive and fresh – both as an evolving and ever-improving language, and in terms of embracing new platforms swiftly, but cleanly and consistently.
If you love Delphi, then words cannot express how much you'll love Oxygene. Give it a try now: