While we strongly believe that creating platform-native UIs for each platform you develop for (and Oxygene does not only reflect but practically enforce that philosophy), there is of course a huge opportunity for sharing non-UI business logic code between platforms.

The open-source Sugar library project provides a cross-platform base library of common classes and functionality that allows you to write shared non-UI "business logic"-type code in a way that lets it compile for all platforms, in spite of the actual runtime classes on these platforms being vastly different.

Sugar does not aim to be a general purpose replacement for each platform's individual APIs, but is targeted specifically to be used for shared code. The idea is that applications will be a combination of platform-specific applications, using the platform's own APIs (making up the majority of the code for GUI and platform-specific services) and shared classes written using Sugar classes.

The all new Elements RTL introduced in Elements 9.1 supersedes and replaces Sugar. Applications using Sugar should port over to Elements RTL easily, since many APIs are the same or similar. We will continue so ship and support Sugar, but we will not extend it with new classes or features, and Sugar will not be updated with coverage for Island.

We recommend using Elements RTL for new projects, instead of Sugar.

How Sugar Works

The vast majority of Sugar is implemented using an Elements compiler feature called Mapped Types that allows platform-native classes to be accessed using a different, shared API defined by Sugar.

For example, Sugar.Dictionary is the class Sugar provides for working with a dictionary of keys and values. The class, and its methods, can be used on .NET, Cocoa and Java in exactly the same way, so code that makes use of a Sugar.Dictionary can be compiled for all platforms. But Sugar.Dictionary is not a "real" class. Instead, it is a mapping to

  • System.Collections.Generic.Dictionary<T,U> on .NET
  • java.util.HashMap<T,U> on Java
  • NSMutableDictionary on Cocoa

That means that when your code is using Sugar.Dictionary on, say, Cocoa, the compiler will actually translate it to code that directly works with an NSMutableDictionary. The same code, compiled for Java, will seamlessly use a HashMap.

This has several benefits:

  • Rather than "reinventing the wheel", Sugar makes use of existing (and well-tested) classes and APIs provided by the underlying frameworks.
  • Sugar never boxes you in; you can always access features of the underlying framework classes, simply by casting (although of course that part of the code then becomes platform dependent).
  • Casting between Sugar and framework classes is toll free, so your platform-specific UI code can be written to use the regular framework classes, but can seamlessly pass those into your shared business code, which expects and works with Sugar classes.

Using Sugar

A version of Sugar is included with Elements, and can be added to your projects via the Add References dialog in Fire or Visual Studio, where the Sugar library should show automatically.

Simply adding the reference and adding the Sugar namespace to your uses/import statements will make the Sugar classes available for you.

Sugar is open source, and the source code is available on GitHub. Contributions are welcome. The bulk part of sugar is written in the Oxygene language, but as of Elements 8, you can open the Sugar projects in Fire and Visual Studio without requiring an Oxygene license, so even C# and Swift developers can contribute. We accept contributions in any of the four Elements languages.


Sugar classes are distributed between the following namespaces, with most common and base classes being in the root Sugar namespace:

See Also