One of the tenets of Oxygene is that it does not abstract away the different runtime environments it supports, but instread embraces each platform, according to our philosophy on native development. The result is a development experience that is virtually identical on the language level, but provides full access to the capabilities of each underlying framework and generates truly native applications on each of the platforms.
On .NET (and its open source Mono counterpart), Oxygene works directly against the assemblies provided by the framework or by third parties. The Oxygene developer sees the same classes and types that are visible to C# or VB and the output generated by the Oxygene compiler are 100% pure .NET assemblies as well, virtually indistinguishable from those created using other .NET languages.
Oxygene developers have access to the full range of framework APIs, such as the .NET base classes, WPF, WinRT, WinForms, System.XML, Sytem.Data, and so on, as well as to any and all third party libraries written in C#, VB or Oxygene itself.
Oxygene also has full support and language integration for platform-specific features such as LINQ, the Parallel Framework, and more.
Applications created with Oxygene for .NET, especially servers and command line untilities, can (when using the right set of APIs) seamlessly run on both Windows (using .NET or Mono) and Mac OS X and Linux with the same executable. In fact, a lot of our own internal infrastructure here at RemObjects is implemented with servers created in Oxygene and Data Abstract for .NET and runs on our Windows, Linux and Mac OS X Servers, without much (or any) extra work to support these extra platforms.
When we brought Oxygene to the Java runtime, one of our main gaols was to preserve the core benefits of what made Oxygene great and carry them over to the new platform. As such, Oxygene for Java also works directly against the frameworks and class libraries provided by the platform; Oxygene projects directly reference .jar files and have full access to the classes and types defined in them. The classes you define yourself and that make up your code are true Java classes, and compiled to .jar files indistinguishable from those created by a Java compiler.
For Dalvik, which is Google's variation of the Java runtime as used in Android, we support full integration with the tool chain to provide final Android executables — using the same sets of tools and conversions that a Java Language pp would go through, but all fully integrated into the Oxygene build and deploy cycle.
We also extended the language with new elements to make it integrate well with its new surroundings. Anonymous Interface Implementations, for example, make it easy to provide event-handlers and callbacks, Java platform style.
When creating applications for Mac and iOS with "Nougat" (currently preparing for beta availability and shipping in early/mid 2013), Oxygene developers will have full access all the Objective-C-based frameworks that make up the development environment — from base libraries such as Foundation, over AppKit/UIKit, to all the feature-specific frameworks like GameKit, CoreData, you name it. In addition, Oxygene also provides full access to the non-object-oriented CoreFoundation level and base C RTL, where needed.
The Oxygene language has even been extended to make both Objective-C "multi-part" method names intuituive and natural to use in a Pascal environment — both when calling exisitng APIs and defining your own classes.
Of course, external open source and third party libraries, such as our own Data Abstract for Xcode, are fully accessible as well.
Just as on the other platforms, the output generated by the Oxygene compiler is a fully native executable for the Objective-C runtime, all but indistinguishable from those created using actual Objective-C. And libraries or frameworks created using Oxygene can be seamlessly consumed by regular Objective-C developers as well.
To help writing code that can be shared across two or all three of the frameworks, we are working on an open source cross-platform helper library for Oxygene, code named "Sugar".
Sugar is an optional base library that provides shared APIs for many commonly used standard classes, such as Strings, Lists, Dictionaries, etc, allowing for more code reuse between the platforms. It does not reimplement its own versions of the core base classes, but rather amends the standard types that exist on each platform with a common API, using a unique Oxygene language feature called "mapped types" that we introduced explicitly just for this purpose. These cross-platform APIs are applied toll-free and cast automatically, making it easy to write platform-specific code on the higher levels of your application, but working with the same base objects using platform-independent APIs in lower-level shared code — without any runtime overhead.
For example, a Sugar.Dictionary is a regular Dictionary
The idea behind Sugar is to not compete with the platform native libraries (be it the .NET, Java or Cocoa frameworks) but to integrate with them — letting developers write common code that can be shared between the different platforms and that can seamlessly interact with the respective platform-native libraries.
Sugar will be an open source project available for participation on GitHub, soon.