You are browsing the archive for iOS.

Oxygene on the Big Screen

January 4, 2013 in Android, Elements, iOS, Java, Mac, Metro, Windows, Windows Phone

Android powered Ouya ConsoleYou already know Oxygene is the best choice for mobile development – Oxygene for Java on Android, Oxygene for .NET for Windows Phone and the Windows RT Surface and the beta “Nougat” already providing great support for iOS development. But what if you want to develop on the big screen? Like that 50 plus inch TV in your front room?

Enter the Ouya, the Android powered game console for your TV. They just released their ODK (Ouya Development Kit), and since it is Android powered, it is perfectly supported by Oxygene for Java right out of the box. Oxygene for Java is a completely native Android development tool – there are no forced abstraction layers or additional run-times to get in your way or require updating when new variations or versions of the platform come out.

Red Ant Games has just announced they are using Oxygene for Java to move their Subject 33 to Ouya and Android mobile devices. Subject 33 is currently an Alpha prototype on Windows. They also have plans to support iOS and Mac with “Nougat”.

Profile photo of marc

by marc

Working with User Interface files in Oxygene “Nougat”

January 2, 2013 in Cocoa, Elements, iOS, Mac, Nougat, Oxygene, Visual Studio, Xcode

In this article, i want to talk a bit about working with user interfaces in Oxygene Nougat.

As you know, Nougat is a native compiler for the Objective-C runtime, meaning that it works directly with the classes provided by Apple’s Cocoa and Cocoa Touch frameworks. This extends from low-level classes such as NSString or NSArray to the high-level visual components based around NSView (Mac) and UIView (iOS).

One common way for Mac and (especially) iOS apps to work with UI is to simply create the necessary views and controls that make up an app’s UI from code. But sooner or later, especially when dealing with more complex or sophisticated user interfaces, you will want to use the visual designer. This works on the same principles, whether you are using Xcode/Objective-C or Nougat.

Mac and iOS interfaces are designed in Interface Builder, which as of version 4 is directly integrated into the Xcode IDE, and when working with Nougat, that is where you will work with your interfaces, getting the same experience and the same power and flexibility of UI design that developers using Objective-C get, as well.

There are two file formats used for designing UI on Apple’s platform — the older XIB format and the newer (and iOS-only) storyboard format. The principles for dealing with these files are similar, but for the topic of this article, we’ll focus on XIB files, as those apply to both Mac and iOS development. In a future article, i will go into some more details specific to storyboards.

Background: What are XIB Files?

So what are XIB files? From the point of view of the UI designer, XIB files contain the views or windows that you design in Interface Builder — the controls, their layout and properties, and their connections to your code.

It is important to understand that on a technical level, XIB files are stored object graphs. That means that an XIB file, essentially, is a hierarchical set of objects descriptions. When an XIB file gets loaded at runtime, all the objects defined in the XIB file get instantiated, configured, and connected as described in the XIB.

These objects can be a combination of standard framework classes (such as NSView/UIView, NSButton/UIButton, etc), classes from third party libraries, or even classes defined in your own application code. When the Cocoa runtime loads an XIB, it goes thru the list one by one, looks for the classes with the appropriate names and news up the necessary objects.

Each XIB file also knows about a special object called the “File’s Owner”. This object will not be created when the XIB is loaded. Rather, the object that initiated the loading of the XIB file will take the place of the File’s Owner within the XIB’s object graph — including any connections and references to it. We will see how that is useful and important, soon.

Loading up an XIB

When and how do XIB files (or storyboards) get loaded? There are several possibilities:



If your Info.plist contains an NSMainNibFile entry, the Cocoa runtime will automatically load up that XIB as your application starts up. The global NSApplication/UIApplication instance will become File’s Owner of the XIB, and every object in your XIB will be instantiated.

This mode is common for Mac applications, and in fact you can see it in action in our Cocoa Application template(s). You probably noticed that (aside from the startup code in Program.pas) the project contains an AppDelegate class that is usually used as the “launching point” for your application’s own code.

How does this AppDelegate class get instantiated? Easy: If you own the MainMenu.xib file in Xcode (the xib that is specified to be the NSMainNibFile in Info.plist), you see that — among other elements — it contains an AppDelegate item. This is your own AppDelegate class.


For simple applications, you can get away with just putting all your stuff into MainMenu.xib, but as applications get more complex, that’s a bad idea, not only because — as indicated above — when an XIB is loaded, all objects referenced in it are created. If your application contains dozens of windows or views, you don’t usually want all of those to be loaded up as your application starts.

Instead, it is common practice to pair individual XIBs for each view or window XIB with a matching ViewController or WindowController class — a practice that you will see in just about all the iOS project templates, and also in the *Controller item templates we provide with Nougat.

How does this work?

Simple: your application will define a custom class, usually descended from UIViewController (or NSViewController/NSWindowController) where you will put all the application logic for that view or window. As far as your app is concerned, this class is your implementation for that particular view (or window — for simplicity reasons i’ll stick to talking about iOS Views for now, but the same concepts apply for OS X views and windows).

In the initializer for your view controller, you will ask the base class to load up the XIB file that backs your view, for example by calling

self := inherited initWithNib('MyViewController') bundle(nil);

This essentially tells the base class to initialize it by loading MyViewController.xib (from the main application bundle) and creating all the objects defined in it.

So all those objects get loaded up, but how do you then get access to them from your code? Simple: remember when i said above that the object loading the XIB becomes the File’s Owner? When you load an XIB using the initWithNib() call, your view controller class becomes the File’s Owner — and any connections you set up in the XIB between the File’s Owner and the other elements in your XIB will be connected to your view controller class.


Did i say connections? So how does this work?

Easy, really. XIB files know about two basic kinds of connections between objects: Outlets and Actions.

You can think of outlets as references to other objects. If your view controller class has a property of type UIButton, and your XIB file contains a UIButton, that’s a match made in heaven. You can just Ctrl-drag the button onto the File’s Owner (or vice versa) in the XIB to hook them up, and now you have access to the UIButton from your code, because as the XIB gets loaded and the UIButton gets created, it gets hooked up to your property automatically.

Actions, you may have guessed, can be thought of as events. If something happens with the objects in the XIB (such as a button being tapped), they send out events. Just as above, if your view controller exposes a method with the right signature (that is, any method with exactly one parameter of type “id” or a concrete class), you can Ctrl-drag it into your XIB file to hook them up — and when the event triggers, that method is called.

Of course outlets and actions can be hooked up between any two objects inside your XIB, not just with the view controller. For example, you can cause an action on one control to trigger a method on a different control.

Ok, so how does the XIB designer in Xcode know about the methods and properties on your view controller (or other classes)? Magic! As you write your classes, Nougat will automatically* update the XIB and Storyboard files, behind the scenes, with information about all the relevant classes and their properties and methods — that is any property marked “[IBOutlet]” and any method marked “[IBAction]”. As you work on your XIB file in Xcode, it sees this information, and makes the connections available.

If you need to expose a new control to your code or want to hook up a new event, simply add a new property or method to your code, and that’s it.

Let Me See This in Action

For this example, i’ve created a new “UIViewController with XIB” from the template. I have then added the following items to the “MyViewController” class:

property myButton: UIButton;
property myLabel: UILabel;
method buttonTapped(aSender: id);

The following screenshot explores the XIB (and storybook) designer in Xcode:

Figure 1: On the left side of the window, you see a hierarchical view of all the objects in the XIB — this includes all visual objects (in this case just the one UIView for now, but also other objects such as the File’s Owner).

On the right side, the “Utilities View” has the “Identity Inspector” pane activated, showing details about the selected object (the File’s Owner). Note that the XIB designer knows that File’s Owner is a “MyViewController”. It got that information from the template – but this is editable, so you can just type in or select the right class name. Of course it should match the class that is loading this XIB at runtime.

Figure 1

Figure 2: We have dropped a couple of controls onto the view — you can see them both visually and in the hierarchy on the left. The right pane has been switched over to the “Connections Inspector” tab, which shows all the connections available on our File’s Owner. Among them, you see our two properties and the method. There’s also a “view” property (defined by the UIViewController base class), already connected to the root view.

Figure 2

Figure 3: Click and drag from the little circle right of the “myButton” name to the button to make a connection to the UIButton. (You can drag to the control on the design surface or to the “Button — Tap Me!” item in the hierarchy.)

Let go when you are over the button, and the connection is made. If you were to go and build your app now, the myButton property would give you access to the button from code.

Figure 3

Figure 4: You can also drag from the hierarchy view to a control. When you let go, the XIB designer will present a list of all properties that match — in this case the UILabel qualifies both for “myLabel”, and for the “view” property (because UILabel descends from UIView).

Figure 4

Figure 5: Connection actions work the same way. You can Ctrl-drag from the control to the receiver (here the File’s Owner) to connect the default action of that control (in this case, the button tap) to a method. As you can see, the Connections Inspector also shows a complete list of all actions that can originate from the control, so you can — if needed — assign them all to individual methods.

Figure 5

Now all that’s left to do is maybe write an implementation for “buttonTapped” such as this:

method MyViewController.buttonTapped(aSender: id);
  myLabel.text := myButton.titleLabel.text;

to see both actions and outlet access in — pun not intended — action.

Terminology: XIB vs. NIB?

In the text above, i talk about XIB files, but the method names all mention NIBs. What’s up with that?

XIBs are a newer, XML based format that is used for the UI at design time. When you compile your app, the XIB files are converted to binary NIB files for you, and those binary versions of the files are embedded into your app. All the APIs working with these files predate the new format (and, at runtime, only work with the older NIB format), that’s why all the method names refer to NIB, not XIB. When you pass around names, you never need to (or should) specify the file extension anyway, so this is a distinction that you can largely ignore (unless you want to go spelunking into your .app bundle).

What’s “First Responder”?

Similar to File’s Owner, “First Responder” is another placeholder object exposed in the XIB file that has special meaning. The First Responder is not a concrete object, but essentially refers to “the first object that has focus that can handle this”.

By connecting actions to the First Responder, you can have them dynamically be sent to different parts of your application, depending on the state your app is in. A good example is the “Edit|Copy” menu in a Mac application. If a text field has focus, you would expect the Copy command to apply to the content of that text field. If a different control has focus, different content would be copied. By connecting the menu’s action to the First Responder’s “copy:” method, Cocoa will take care of calling “copy()” on whatever control or view has focus — in fact, all you need to do to make Copy/Paste work with your own custom view would be to implement the corresponding methods, and they would get called if your view has focus as the user invoked the menu item (or Cmd-C keyboard shortcut).


I hope this gave you a quick introduction to XIB files and how they work. A good 95% of the content of this article is not really specific to Nougat; the same concepts and techniques apply to working on XIB files with Objective-C — that’s by design, because Nougat is a true first class citizen on the Cocoa frameworks and Objective-C runtime.


(* in the current beta drop, this update does not happen automatically yet. You can right-click your .XIB or .storyboard file in Solution Explorer and choose the “Sync XIB”/”Sync Storyboard” to trigger an update.)

Profile photo of marc

by marc

Using RemObjects SDK and Data Abstract with Oxygene Nougat.

December 25, 2012 in Cocoa, Data Abstract, iOS, Mac, Nougat, Oxygene, Visual Studio, Xcode

Nougat is, of course, designed to work with any existing Objective-C libraries out there, because it directly consumes and generates code for the Objective-C runtime. As such, it should come as no surprise that Nougat is ready to use RemObjects SDK and Data Abstract for Xcode, out of the box.

That said, with the new Alpha builds of RemObjects SDK and Data Abstract that we shipped on friday (build .1069), we have made a few improvements that make it even easier to get started with RO/DA in Nougat. These are three-fold:

Read-to-Use .fx files

Unlike .NET and Java, Cocoa libraries do not include easy to parse metadata for compilers to consume. Instead, it depends on .h files to define the available APIs — which is fine when consuming the libraries from a C compiler. Because .h files are slow and complicated to parse, Nougat introduces an intermediary format in the form of .fx files. You can think of an .fx file as “pre-compiled headers” file for a given framework or library; a set of metadata that represents all the information expressed in the framework’s .h files, but encoded in a way that it is easy and quick for the Oxygene compiler (and IDE toolchain) to process, when compiling, driving Code Completion etc.

While Nougat comes with the necessary tools to generate .fx files for any of your favorite third party libraries (and of course ships with .fx files for the supported base SDKs), that is an extra step we want to alleviate, so the new build of RODA/Xcode includes .fx file for those libraries out of the box. After installation, you will find the files next to the corresponding binaries in ./Bin.

All you need to do to use the SDK or Data Abstract from Nougat is to go to “Add Reference”, select the .fx file for your platform (i.e. OS X or iOS) to add a reference. That’s it.

libDA.fx Reference

From the .fx, Nougat will automatically know about all the types in the RO/DA library, and will take care of getting the static library and any dependencies linked in.

Static Libraries for OS X

In the past, RODA/Xcode included precompiled binaries in the form of a framework for OS X and static libraries for iOS. Frameworks are easier to deal with in Xcode, because they combine a binary with its accompanying header files, which is why we chose to ship OS X binaries as a framework. iOS does not support the framework format for third party libraries, so the choice there was easy: static libraries are the only option.

For Nougat, the benefits of a framework (on OS X) are diminished, because metadata is provided in the .fx file anyways, so a static library is just as easy to deal with, and has fewer files involved. For that reason, we have added a static library version of RODA/OS X to the product (in addition to the Framework). Xcode developers can choose to use either version, depending on their preferences (the static library has the benefit of being linkable straight into the executable, which is nice if you’re creating command line tools that use RO/DA); Nougat developers will mostly want to use the new static library alongside its .fx file.

CodeGen for Nougat

For pure Data Abstract use, you’re pretty much all set with the above, but if you’re building custom RemObjects SDK services that you want to talk to, there’s one more step missing: Interface code.

Talking to RO services depends on having strongly typed interfaces generated for your local proxy classes and any complex types you are passing back and forth between the client and the server — and until last week, RO/Xcode generated this code in Objective-C only.

That was not a complete showstopper for Nougat. Remember, Nougat can use any Objective-C library, so you could compile those files using Xcode and the use them from Nougat (in fact, that’s what i’ve been doing with for small RODA project i have been working on over the past few weeks). But that’s not ideal, of course.

The new alpha now includes native Nougat CodeGen for your services, so you can generate an Interface .pas file and add it straight to your Nougat project — as it should be.

The new CodeGen is exposed in three places:

  1. Of course the codegen2.exe command line utility has been updated, so if you generate code from the command line, you can use the /lang:nougat option to have interface files written for Nougat.

  2. Service Builder has also been expanded to support Nougat alongside all the other languages (that menu is getting mighty big!):

Service Builder

  1. Finally, we also added Nougat CodeGen to our on the Mac (which is now really becoming overdue for a rename ;). While we were at it, we also revamped the UI for this tool a bit to make it (simple as it is) nicer to use, and look at:


(and as the beta progresses, CodeGen will also be available directly inside the Visual Studio IDE, as well)

So with that you should be all set to build your first great client application for the Mac or iOS, using RemObjects SDK/Data Abstract and Oxygene “Nougat” over the holidays ;)

Let us know how it all works out!


Profile photo of marc

by marc

Oxygene “Nougat” BETA 2 is out!

December 3, 2012 in Elements, iOS, Mac, Nougat, Oxygene, Visual Studio

On Friday, we shipped BETA 2 of Oxygene “Nougat“, the next major platform for our Oxygene language (in case you have missed it or have been living under a rock, Nougat is “Oxygene for Cocoa” and brings your favorite programming language to native Mac and iOS development. You can read more about it here and in my previous blog posts).

Jim also recently spent some time on a great “Oxygene Overview” video that went live today and gives a first peek at Nougat, too.


It’s been about 8 weeks since we shipped BETA 1 (and we shipped updated builds to testers more or less weekly since then), and the team has been really busy and made great progress on all fronts. BETA 1 was a very early look at the product — it was still very rough, the “this is what you need to know to get started” list was way long, and many things did not (by design) work yet. But we wanted to let the early adopters get started, and we’ve gotten great feedback for this first part of the beta cycle.

BETA 2, out now with build .1139, is a lot more robust, should provide a fairly decent “out of the box” experience to get started, and — most importantly — sees most core functionality working decently.

BETA 2 supports running and (still limited) debugging of Mac apps (Cocoa and console) and iOS apps on both the Simulator and actual devices. BETA 2 has fully integrated the deployment toolchain, so that with the press of a single key (F5, a.k.a. “Start”), your app gets compiled, linked, packed up, code signed, and uploaded to your device. The compiler has been vastly improved in BETA 2, with lots of bugs fixed and lots of features and improvements all thru-out; the corresponding IDE experience has improved as well, for example with code completion and related editor smarts fully understanding the new “multi-part” method name syntax, everywhere.

Of course we still have miles and miles to go before we reach RTM. As promised from the get-go, we are shooting for a release of “1.0” (or rather “6.0”, as it may be) in the “first half of 2013”. Now, we strongly plan for that to not mean “on June 30” (we’re not Apple ;), but we are taking our time to get everything right, and we do still have a good 5-6 months ahead of ourselves in terms of getting Nougat to final.

But, we also know that you are anxious to get started, and a lot of you have been holding off jumping into the dangerous waters with BETA 1. But if you are at all adventurous and inclined to live on the edge a bit, BETA 2 (and its continuing semi-weekly updates) is as good a point to get your feet wet as any.

So what are you waiting for? Assuming you have already ordered your copy of Oxygene, head over to to grab your copy of “Nougat” BETA 2 now! Make sure to check out my “Getting Started” post, as well.

(If you don’t have Visual Studio 2012 installed yet, grab the latest Oxygene for .NET or Java installer from here first, and then install the Nougat beta on top (this will upgrade all three editions to the latest bits)).

Also, don’t forget to let us know what you think — leave your comments here, or join the discussion in our private beta forum at


Profile photo of marc

by marc

Getting started on truly native Mac and iOS development with Oxygene “Nougat”

November 10, 2012 in Cocoa, Elements, iOS, Mac, Nougat

In preparation for “Nougat Beta 2”, our next milestone coming up in a couple of weeks, i wanted to sit down and write up a quick “getting started” article on how to get going with Mac and iOS development in Nougat, including some aspects applying to Mac and iOS development in general (i.e. whether using Nougat or Xcode) that we should not take for granted for people w/o existing Xcode background to know.

Setting up Shop

While Nougat itself works inside Visual Studio 2012 on Windows (for now), it also interacts with some infrastructure on the Mac side that needs to be set up in order to get going. Nougat provides the CrossBox helper application that bridges this gap and allows Visual Studio to hand off tasks to the Mac as needed (and to communicate with iDevices attached to the Mac for on-device deployment and debugging).

Install “Nougat” using the setup we provide.

After you install Nougat on your Windows PC or VM, you will find a file in the install folder. Simply copy this zip file over to your Mac, unzip it and run the contained Done. (for now requires Mono because it is a RemObjects SDK for .NET server).


To do any reasonable work with Mac and iOS development, you will also need a copy of Xcode installed on your Mac. You can get Xcode for free on the Mac App Store (and sometimes you can get newer beta versions at

Note that different versions of Xcode come with different versions of the iOS and OS X SDKs. At the time of this writing, the latest version of Xcode is 4.5.2, and it contains iOS 6.0 and OS X 10.8. Nougat lets you build applications for different versions of these SDKs, but you will need the matching version of Xcode. So if you want to build your application against iOS 5.1, you will need the older version of Xcode, 4.4, that comes with iOS 5.1. Similar, if in the future there’s a beta of, say, OS X 10.9, you will need the proper version of Xcode that comes with that beta.

You can have multiple copies of Xcode installed on your Mac, and you can select the active version in two ways:

  1. In Xcode (whatever version), you can invoke Preferences (⌘,) and on the Locations tab you will find a popup where you can select the version to be active for “command line tools” (which is what Nougat will use):

    Selecting an Xcode Version

  2. Via the command line (i.e. in or via ssh), you can run

sudo xcode-select --switch /path/to/

to select which version of is active (you can also call xcode-select with the –print-path option to see which version is currently selected — in fact, that’s what CrossBox does to decide which version it uses).

With that, you’re almost done. For Mac development (or iOS development with the Simulator), you would be all set, but for creating iOS applications that run on your iDevices, or to create Mac apps for the Mac App Store that use iCloud, you need to set up a developer account with Apple, and create and download some profiles and certificates.

Assuming you went ahead and created a developer account (for either iOS or Mac development or both) at, simply go into Xcode and open the Organizer (choose Window|Organizer from the main menu, or press ⌘⇧2). Select the Devices tab at the top and the Provisioning Profiles item in the source list of the top left.

If you’re already set up in Xcode, you might see some items, if not, the list is most likely empty. Worry not, simply press the Refresh button on the bottom right and Xcode will automatically reach out to and download or create the necessary certificates and profiles to get you started. When done, your Organizer window should look something like this (but probably with fewer items):

Organizer Window

At the very least, you should see profiles called “iOS Team Provisioning Profile: *” and/or “Mac Team Provisioning Profile: *”, depending on which programs you signed up for.

Not displayed here, matching code signing certificates should also have been created in the Keychain for you, called “iPhone Developer: X” or “Mac Developer: X”, where X is your name.

With this, you’re all set on the Mac side, so let’s switch over to Nougat in Visual Studio on Windows and start your first project. For this topic, i’ll walk you thru an iOS project, as that is the more complex scenario compared to OS X.

Your First iOS App

In Visual Studio, select File|New|Project, and browse for the Oxygene Nougat folder. For now, Nougat has a handful of templates, but this number will increase over the beta period and for RTM next year. Right now, let’s pick the “Universal Master/Detail App” to create an app that can run on both iPhone and iPad. This template will use Storyboards for the UI, but we’ll go into those in a future topic.

New Project

Once you press OK, the project will be created and the AppDelegate.pas file will open in Visual Studio. The template already creates a basic runnable application, so let’s ignore the code for this article and focus on building and running the app as is.

As first step, you will want to have a look at the “CrossBox” menu item in the Visual studio toolbar. If you’re freshly starting out, Nougat probably doesn’t know about your Mac running CrossBox yet. There’s two ways to rectify that:

  • Our recommended approach is to install Bonjour on your Windows PC or VM, if you have not already done so (or gotten it as part of, say, iTunes). With Bonjour, Nougat will automatically find local Macs running CrossBox, and you should see them in the CrossBox menu when you click it open. Simply select your Mac and choose Connect.

  • If you don’t want to use Bonjour, or your Mac is remote, no worries: simply choose Add Server… from the CrossBox menu, and you can manually enter the address of your Mac to connect:

    Add Server

No matter which way you picked your Mac, the very first time a connection is established, you will need to authenticate. This is to prevent just any random Nougat user on the local network (or even the internet, if you use CrossBox on a Mac at a remote location) connecting to your Mac and running their apps there. On the Mac side, CrossBox will show a four-digit number in the menu bar, next to the little Oxygene icon (and on Mountain Lion or later, you will also see a Notification Center message pop up). Simply enter that code in Visual Studio on the Windows side and you are set.

You won’t have to do these steps again (unless you get new Mac or a new Windows PC or VM, of course).

Nougat can maintain a list of several Macs running CrossBox, so if you — like me — have a desktop and a laptop running CrossBox, you will see both in the menu, and can choose where to run your apps.

With that setup out of the way, open the CrossBox menu again, and underneath your Mac’s name you should now see the different device options to build for:

CrossBox Meu

  • iOS Simulator: This option, obviously, lets you build your iOS app as i386 executable that can be run in the iPhone or iPad Simulator.

  • iOS Device: This option represents a generic iDevice and allows you to build your app for deployment, even if no real device is found (you can compile, but not deploy or run when this option is selected, obviously).

  • Peter’s iPhone: Any real iDevice you have connected to your Mac will show up here as well.

For now, select your real device name, if you have one, or select iOS Simulator if you don’t.

We could build and (probably) run the application now, but lets have a quick look at some of the project options for Nougat applications before we do. For that, right-click the project node in Solution Explorer and choose Project Properties (or choose Project|Properties from the main menu).

Project Settings

Most of what you see here will be familiar from Oxygene for .NET and Java, but there’s a handful of new options.

First let’s look at the Nougat tab:

Per-config Options

There are two important options here. The first is the Provisioning Profile Name. As you can see, Nougat automatically obtained all the profiles from Xcode on your Mac already.

Every iOS app needs a profile to govern installation on devices, so it is important that you choose one here. By default, the “iOS Team Provisioning Profile: *” is a good choice; as you create other profiles manually on, you can select them here.

Along with the profile goes a certificate that will be used to sign your application. As mentioned before, Xcode automatically created one for you, and to start with, your best option is to select that. Each profile is tied to a specific certificate, so as you create more profiles for real app deployment, you might or might not choose to create different certificates as well. It is important to select matching pairs of profile and certificate, or device deployment will fail.

You will notice that the settings on this page are “per-configuration”, and as you get ready to ship your app, it will be common to use different profiles and certificates for your Debug vs. your Release builds.

Two other settings on this page might be interesting.

The first is the list of Architectures. Nougat is fully capable of creating what Apple calls “Universal Binaries”, which are executables that contain code for more than one CPU type. When we started out with Nougat early this year, we thought it would be a while until anyone would see this support (since we’re not supporting 32-bit Mac apps), but Apple surprised us by introducing a new CPU type, “armv7s” with the iPhone 5’s A6 processor. So here you can choose what CPU types you want your app to support; in general it makes sense to support both, which is the default. (If you uncheck “armv7”, your application will only run on the iPhone 5 and iPad 4; if you uncheck “armv7s”, your app will run on any modern iOS device, but not fully leverage the A6 or A6X.)

The second option is “Create .IPA”, which instructs Nougat to automatically package up your app into an “.ipa” file that is ready to be uploaded to the App Store or sent to beta testers, for example via

Let’s switch over to the Application tab, which contains general project-wide options, some of which are specific to Nougat:

Per-project Options

The first crucial option is the Target SDK, which determines the version of iOS your app is built for. If you simply select “iOS” (or “OS X” for a Mac app), your app will automatically be built with the latest version of the SDK. But you can also select a specific version, for example if you always want to build your app with the older iOS 5.0 SDK, instead of 6.0.

As mentioned before, you will need a matching version of Xcode that contains the SDK you are building against.

Closely related to the Target SDK is the Deployment Target. This setting (optionally) specifies the lowest version of the OS that your app will run on. Different than what you might be used to from Windows, OS X and iOS bind very loosely, so it is entirely possible to build an application against the latest iOS 6.0 SDK and make use of new features from that OS version, and still have the application run on older versions of the OS (provided of course you are careful at runtime to not use features that aren’t available). This option enabled this, and i’ll explore some code techniques for conditionally using newer SDK features in a future article.

If you have an older device that does not run iOS 6 yet, now might be a good time to set the Deployment Target of your project to, say, 5.0.

An option that becomes important when you start creating your own provisioning profiles is the Application ID, as it will have to match the ID specified in the profile you use. The default wildcard profile we saw before will work with any ID, so if you use that, the value here does not matter (much).

There are some more advanced options such as Output type or a custom Entitlements File for code signing that go beyond the scope of this post.


So, having reviewed these project settings, your app is ready to build and run. Simply press the Start button and Nougat will do the rest; after a few seconds, you should see your app be deployed to the device and start up in the debugger.

Mac Apps

For a Mac app, things work similar, but are less complicated to set up initially.

Once again, choose File|New|Project, this time selecting the Cocoa Application template.

New Project

In the CrossBox menu, you will see only one “device” is available for each CrossBox server, and that is the Mac itself. Select the option on the Mac that you want to build and run your app on (if there’s more than one), and you’re set. As above, simply press Start and your app will build and after a few second it will pop up on your Mac’s desktop

The project settings for Mac apps are similar to those we have seen for iOS. You can pick a provisioning profile (but you only need that if you are using iCloud in a Mac App Store app), and you can (and should, but don’t need to) pick a certificate to sign your app.

Only one architecture is supported for OS X apps right now: 64-bit intel. Nougat does not support 32-bit, because, frankly, that is a thing of the past and a legacy architecture. And despite recent rumors, ARM-based Macs are probably still a few years away ;).


Hopefully this has given you a quick introduction on how to get set up and get started with Oxygene Nougat to create Mac and iOS apps. The steps outlined here are based on “Beta 2” which we plan to have out to testers within the next couple of weeks, but most of it should already apply to the current “Beta 1” drops that are available now.

Of course, details and the workflow might be subject to change and further fine-tuning between now and RTM next year.

How can you get your hands on the beta? Easy: If you already bought your copy of Oxygene, simply head over to and get started now. If you haven’t, well, what are you waiting for:

Let us know what you think!

Profile photo of marc

by marc

What is “Nougat”? — Part 4

October 19, 2012 in Elements, iOS, Mac, Nougat, Oxygene, Uncategorized, Visual Studio, Xcode

In the first three parts of this series, we took a look at the basic concepts and design principles behind Oxygene “Nougat”, and the IDE experience. In this fourth installment, i’d like to give you an overview of the build and deploy process, and a quick peek at debugging.

Building your project is something that happens behind the scenes and most of the time, we don’t think much of it. We press F5 in the IDE, and a few seconds later our app is running. But a lot is going on behind the scenes to get from your source code to the final executable — and a lot more than usual, for building Mac and iOS apps.

Let’s have a look. All that we’ll be seeing here happens, of course, behind the scenes and automatically, without you having to worry about a thing.

It all starts with the Oxygene compiler, which takes your source files and turns them into executable code. For Nougat, that is the same Oxygene compiler you know and love, only instead of emitting a final “.exe” or “.jar” file as it would do for .NET or Java, it generates a file with CPU-native binary code for either x64 or armv7(s), and a “.o”. (In fact, if you’re building an iOS app with armv7 and armv7s support, the latter being new for the iPhone 5, it will generate two such files.)

On the back-end, Oxygene leverages the great LLVM compiler, which generates highly efficient code.

The “.o” is not the final executable, it still has to be linked. So next, our toolchain calls “ld”, which is the linker. This happens via CrossBox, passing the “.o” file over to the Mac, linking it against all the frameworks it needs, and returning the final executable (which is extension-less) back.

At this stage, we’re done if we’re building a Mac console app, that is, a simple executable that you want to run from the command line. Most Mac (and all iOS) apps aren’t simple console apps, so there’s more that needs to be done to get a final, runnable app — and Nougat does that for you, of course.

Mac and iOS apps come as what is called “Bundles” — which are really folders with an .app extension that are treated as individual files by the OS X finder and other parts of the OS. In the Project Properties of your Nougat app, you’ll find a checkbox called “Create .app Bundle” (checked by default in most templates) that enables this functionality:

With the option set, Nougat’s build chain will take the executable generated above, along with any other files your app needs (such as images or other resources) and generates a full .app bundle. It will also automatically generate an Info.plist file describing your app, or take an existing Info.plist file that’s part of your project and adjust/tweak it as necessary.

The Info.plist file, next to the executable, is an important part of the .app bundle that tells the OS how to run our app, what documents it supports, what application icon to use, etc.

If you’re building a Mac app application, you can be done at this point, and the resting .app bundle is fully runnable. However, these days it’s good practice to digitally sign your application (and in fact that’s required for iOS apps, and also for Mac apps if you want to use the Mac App Store).

How do you sign your app? Nothing easier than that. Looking at the Project Properties again, there’s an option called “Code signing certificate name”, along with a drop down that shows you all the (relevant) certificates Nougat found on your Mac that can be used for signing apps (this list will differ between Mac and iOS projects). Simply select the right certificate, and when you build, Nougat will automatically code-sign the final .app bundle for you.

For iOS apps you will usually choose a “iPhone Distribution: XXX” or “iPhone Developer: XXX” certificate issued by Apple, where XXX is your name or your company name. Distribution certificates are used to build apps to ship on the app store or deploy to beta testers or inside your company; Developer certificates are used while you’re testing your apps on your own devices.

For the Mac, you can choose between “3rd Party Mac Developer Application: XXX” certificates for deployment of Mac App Store apps, or you can use Apple’s new “Developer ID Application” certificates, for non-MAS apps.

In either case, all you need to do is select the certificate, and off you go.

iOS applications also need what is called a “provisioning profile”, generated on Apple’s developer portal, to govern how they can be run. As you might have guessed, there’s an option in Project Properties that lets you pick the provisioning profile you want to use from a list, and Nougat takes care of the rest.

The actual code signing, once again, happens on the Mac, marshaled over transparently via CrossBox, so you don’t even notice it’s happening.

There’s a few more things that might have to be done as part of this process (for example .xib and .storyboard files that might be part of your project will get post-processed into a binary format before being included in your .app bundle), but finally, we have a finished .app bundle that’s ready to be used — run, debugged or, hopefully at some stage, be submitted to the App Store.

Running and Debugging also happens seamlessly. In the CrossBox menu we already saw in my previous post, you can select a Mac or a Device (real or virtual) connected to your Mac:

The menu will list any Mac on the network that’s running CrossBox, as well as any remote CrossBox server you might have connected to. Underneath each Mac, you can select the device you are building for and deploying/running/debugging on. For Mac OS X applications that is just the Mac itself, but for iOS, you can choose between the “iOS Simuator”, a generic “iOS Device” (which lets you build for a device seven without having a real one attached), as well as any actual devices connected to your Mac:

For iOS, the selection you make here affects several parts of the build process. First of all, the Mac you select is of course the one that will be used for all tasks that need to be handled Mac side (linking, code signing, etc).

More importantly, by either choosing “iOS Simulator” or a device (whether a real one or the generic “iOS Device”), you are telling Nougat whether to build your project for device hardware (i.e. in most cases armv7 and armv7s binary, and against the real iOS SDK) or for the Simulator (in which case it will generate an i386 binary, linked against a separate Simulator version of the SDK).

Finally, the device choice also influences how your finished application runs. If you selected a real device, Nougat will deploy the .app to that device, and optionally launch it there, to run or be debugged, and if you selected the iOS Simulator, the app will launch in the simulator on the Mac. (Obviously, an app cannot be deployed or run on the generic “iOS Device”, that option is for building the app only.)

Debugging the application is almost unspectacular, in spite of a lot of effort having gone (and continuing to go) into this: Nougat adds a full Mac and iOS debugging engine into Visual Studio, based on the LLDB debugger, allowing you to use virtually all of the capabilities of the Visual Studio debugger that you are used to from .NET (and Java — where we did the same). You’ll be using the debugger as you always have:


Ok, so this post took you on a quick tour on what happens behind the scenes when you press “Start” to build and run your Mac or iOS project.

In hindsight, there’s a lot happening, but none of it is any black magic. Nougat takes care of all the gory details for you, so you don’t have to worry about provisioning profiles, code signing and the like, but it will document all the steps it takes (and any command line tools it runs) in the MSBuild log, so that there’s no “black box” and you can know what’s going on, if you care.

Reminder: Keep in mind that the Nougat beta is active now (we started last Monday), so if you pre-ordered the Oxygene 5.2 bundle or own a Suite Subscription for Xcode (we’ll have to rename that one, won’t we?), you have access to the beta now. If you didn’t — well, what are you waiting for? Order your copy now!

Stay tuned for more.

Profile photo of marc

by marc

What is “Nougat”? — Part 3

October 2, 2012 in Elements, iOS, Mac, Nougat, Oxygene, Visual Studio

In the first two parts of this series, we have taken an initial look at Oxygene “Nougat” from the compiler side. Today, i want to delve deeper into some aspects of the IDE experience for Nougat.

We have gotten a lot of questions about our IDE plans for Nougat over the past few weeks. As you know, right now Oxygene for .NET and for Java both focus on Visual Studio as an IDE, and — at least for the time being — so will Nougat. There are a lot of arguments for and against different IDE choices, but it really boils down to resources: we have a great and solid IDE experience for Oxygene in Visual Studio already that Nougat gets to inherit relatively easy, and there’s only so many things we can do at once. So for “1.0”, the initial Nougat release, we are focusing on the compiler and tool chain, leveraging our existing IDE.

For the future (2013 and beyond), we are looking at additional IDE options — not just for Nougat, but for all three target platforms, however, it’s too early to talk about those ideas yet.

Nougat in Visual Studio

So what does Nougat in Visual Studio look like? Well, pretty familiar ;). If you’ve used any of the other two editions of Oxygene before, you will feel right at home with Nougat. You will start creating new apps using one of the included project templates, of course:

Project Templates

And once you start coding, you get all the great IDE features you know and love — from code completion to inline errors:

Inline Errors and CC

Just as in .NET and Java, Solution Explorer is the central point for managing your project (the only giveaway being the green tint in the project and code file icons).

Solution Explorer

Under the References node in Solution Explorer, you manage the Frameworks (or libraries) that your project links against. Need to reference another framework? Easy, just choose “Add Reference”, and you get a list of all the frameworks provided by the SDK your project is targeting — or you can browse to add other frameworks, for example third party libraries such as Data Abstract.

Project Templates

As discussed in the previous post, Oxygene uses .fx files that provide a sort of “pre-compiled header” cache of which members are exposed by the frameworks, and Nougat (in its current alpha build) ships with ready-to-go support for OS X 10.6 thru 10.8 and iOS 5.1 and iOS 6.0 (but you will be able to seamlessly work with newer SDKs when they come out, w/o needing us to update Nougat with explicit support).

In “Project Properties”, one of the options you will find is the SDK selector. You can select a generic SDK name (such as “iOS” or “OS X”) and Nougat will link against the newest version of that SDK type it finds (the equivalent of selecting “Latest” in Xcode), or you can select a specific Target SDK, say “OS X 10.7”


So now you’ve written your app — what’s next? You’ll want to build and run it, of course. Nothing easier than that. Nougat comes with a helper application codenamed “CrossBox” that you can run on your Mac(s). Nougat’s IDE integration will automatically find any local Mac running CrossBox and let you deploy and run your Mac applications there. Ditto for iOS applications, where CrossBox will let you select the simulator or any attached iOS device and run your app on there — simply by pressing “Start”.


If your Mac is not on the local network (maybe you have one hosted with MacMiniColo who have a very awesome special offer this week), or are renting a Mac via MacInCloud, Nougat won’t find that Mac automatically, but you can of course manually connect to it by specifying its address.

Mac-side, CrossBox provides nice, Mac-native UI to let you know what’s going on, including Notification Center support on Mountain Lion, when your apps start or stop running, etc.

Inline Errors and CC


Ok, so this has been a summary of the Nougat IDE experience, on Speed. Stay tuned for our next part, where we take a closer look at the build-and-debug process!

Profile photo of marc

by marc

What is “Nougat”? — Part 2

September 21, 2012 in Elements, iOS, Mac, Nougat

In this second part of our series on the upcoming edition of Oxygene for Cocoa, codenamed “Nougat”, i want to go into some more details about the compiler — the heart and soul of the product — and what we plan for it to deliver.

Target Platforms

As mentioned in Part 1, Nougat is a compiler for the Objective-C runtime, and will generate code on the same level as Apple’s Objective-C compiler (Clang/LLVM) does. As such it will generate (Delphi lovers, rejoice ;) CPU-native executables —a first for Oxygene — for the following three targets:

  • 64-bit Intel Mac OS X Applications
  • 32-bit ARMv7 iOS Applications
  • 32-bit Intel iOS Simulator Applications

Your first question might be “why only 64-bit for OS X”, and the answer is twofold:

One: No-one really, seriously, still creates 32-bit Mac applications. Every Mac sold has been capable of running 64-bit for way over 5 years now.

Two: Much more importantly, with OS X Leopard (that’s 10.5, which shipped, again, five years ago), Apple introduced what is commonly referred to as the “modern” Objective-C runtime. This is a newer, better version of the runtime that Cocoa apps run on, and many advanced features, such as ARC, are only available on that new runtime. This “modern” Objective-C runtime, you guessed it, supports the above three platforms, but it does not support 32-bit Mac OS X.

We could go out of our way to support the older runtime, but the current thinking is Nahh, it won’t be worth the hassle. If nothing else, the lack of ARC would be a major bummer.

Automatic Reference Counting

As you might have guessed from the above, Oxygene supports and fully embraces ARC, the Automatic Reference Counting model Apple introduced at last year’s WWDC. In fact, we’re so sold on ARC that we’re planning to make it non-optional.

For those unfamiliar with the matter, what does ARC mean? ARC means that the compiler automatically keeps track of reference counting for you. Under the hood, Objective-C uses a retain/release model for keeping track of object lifetimes (similar to COM and Delphi Interfaces). When wanting to hold on to an object, it used to be you’d call “retain” on it. Once you were done, you’d call “release” (and there’s the concept of autorelease pools which sweetens this memory management model some more). With ARC, you don’t have to (in fact, you cannot) keep track of retain/release — the compiler handles all of that for you.

The end result is that memory management is pretty much taken care of for you, and the kind of code you write in Nougat will be comparable to what you do in the Garbage Collected .NET and Java environments (although ARC is not garbage collection, but deterministic memory management).


Like most platforms, Objective-C (due to its roots in C) has both simple types — such as integers, booleans, C-style zero-terminated strings — and class-based types that can represent the same kind of data.

Staying in line with its counterparts for .NET and Java, where such a thing is common and expected, “Nougat” will automatically handle boxing and unboxing for numbers, string and arrays.

For example, you can simply write 5, and the compiler will take care of converting that int to and from an NSNumber for you, when boxing is needed. For example, you can write

var x := 5; // "x" will be an Integer.
myDictionary.setValue(x) forKey('five');


var y := NSNumber.numberWithInt(5); // silly, i know.
z := y+5; // "y" will be unboxed.

In a similar fashion, string literals and C-style strings and NSString will be interchangeable, with the compiler doing the right thing for you.


As a native Cocoa compiler, Nougat will need to let you reference other frameworks and libraries — be it the core operating system frameworks provided by Apple (such as Cocoa, UIKit, MapKit, you name it) or third party (or even your own) frameworks and libraries.

As mentioned in Part 1, Nougat is no bridge, and requires no mappings to be defined. Rather, Nougat directly understands and consumes the exiting Objective-C frameworks — just like you would expect, and just like Oxygene does on its other two platforms.

Now, Objective-C frameworks and libraries don’t have the rich meta data that Oxygene is used to — they are just binaries with compiled code, and C-style header files. Because parsing C (and Objective-C) headers is a time-consuming and inefficient process, Nougat introduces an intermediary format, which we call “.fx Files” that the complier references. .fx files are generated automatically by a tool that comes as part of Nougat, and you can think of them as something like pre-compiled headers — a binary representation of all the definitions found in a framework’s headers.

Nougat will come with pre-created .fx files for the major OS versions we’re supporting (right now the internal alpha drops provide OS X 10.6, 10.7 and 10.8, as well as iOS 5.1 and 6.0), so the compiler (and the IDE) is ready for you to use those frameworks right from the Go. But if there’s a new OS (or beta) coming out that you want to use, it will be as easy as a single click to get that new SDK exposed to Nougat — no need to wait for the NDA to expire and/or us to ship updated support.

How does this look/work from the developer’s point of view? Simple. Just as always, you’ll go to Add Reference to add a new reference to your Oxygene project. The IDE will show you a re-filled list of frameworks in the SDK your current project is targeting (say, OS X 10.8), and all you have to do is, say, pick “CoreLocation” from the list, and you are ready to use the APIs exposed there.

Objective-C itself does not use or know namespaces. For Nougat, types and other external definitions will automatically be partitioned into namespaces based on the frameworks they come from. So, for example, your code files might have uses UIKit, CoreGraphics; in their uses clause, and your code will automatically have all identifiers from those frameworks in scope. If you want to use a class that’s not in scope, you can always prefix it with the namespace, just as you’d expect, i.e.


Part 3

Testing and deploying applications in Nougat. . .

Profile photo of marc

by marc

“Native platform development is going to be the approach”

September 12, 2012 in Android, iOS, non-tech

Mark Zuckerberg about the new native Facbeook app (via Appleinsider, The Verge):

“Native [platform development] is going to be the approach that we go with for iOS and Android”. “We’re betting completely on it.”

Smart thinking, and much in line with our own philosophy on the matter.

He goes on:

“The biggest mistake we made as a company was betting too much on HTML5 instead of native [platforms],” and, “We burnt two years.”

Profile photo of marc

by marc

What is “Nougat”? — Part 1

September 12, 2012 in Elements, iOS, Mac, Nougat

When we launched our new Oxygene website and Oxygene 5.2 last week, we also gave a sneak peek at an upcoming new edition/platform for Oxygene, codenamed “Nougat“.

This is the first in a series of posts about “Nougat”, in which i want to go into a few more details about our plans and the technologies behind Nougat, so you can get a feel for what to expect from the product, as we wait for the first beta to be made available.

So what, exactly, is Nougat?

Nougat is a third independent target for the Oxygene language and compiler, targeting the Apple Cocoa and Cocoa Touch development platforms.

More strictly speaking, Nougat is Oxygene for the Objective-C Runtime.

What does that mean?

Similar to Java, the term Objective-C has overloaded meanings. Of course there is Objective-C, the language, which is what most people think of when they hear the name. It’s the language that Apple’s Xcode IDE uses to let developers create native applications for both of its platforms: (Mac) OS X and iOS.

But underneath the language (and to a large degree influencing how Objective-C as a language works) lies the Objective-C Runtime (OCR, for short). That runtime (oversimplified, a set of C APIs) defines how objects look in memory, manages run-time type information, handles the passing of messages (a.k.a. method calls) to objects, and so on.

The way i like to think about it, the Objective-C runtime puts Cocoa someplace in the middle of “managed” platforms (such as .NET and Java) and “unmanaged” development architectures such as Delphi or C++. So when talking about this, i often call Objective-C “half managed”.

“Nougat” brings the Oxygene language to this Objective-C runtime, in that it compiles Oxygene language code into objects that natively live in this runtime, and seamlessly interact with other objects in the same runtime. It is not a “bridge” (such as MonoTouch, RubyCocoa, or the (now deprecated) Java/Cocoa Bridge, but a fully native second language — in no way second to the Objective-C language itself — that runs on this runtime.

This is important for several reasons:

You’re creating true Objective-C objects

The classes your define in your Nougat application will compile down to true OCR objects. The runtime will see these objects and interact with these objects in the same way that it does with objects created by an Objective-C developer in Xcode. In fact, the runtime cannot even tell them apart.

When you, say, define

  RootViewController = class(UITableViewController)

then this “RootViewController” class you are defining will be a true descendant of UITableViewController — with no bridging magic inbetween. If the table view sends a cellForRowAtIndexPath: message to get data to display, the runtime will dispatch that call directly to the cellForRowAtIndexPath() method that you hopefully implemented.

You’re interacting with true Objective-C objects

Just like your classes are true Objective-C classes, all the classes and object instances you interact with will be true Objective-C classes, as well. If you hold a string object, that’s a true NSString instance, and if you are calling


you are simply sending the object the hasPrefix: message, just as an Objective-C developer would be with [myString hasPrefix:@"foo"]. (Note that Objective-C’s message sending is nil-safe, and thus corresponds to Oxygene’s colon operator, while a call such as myString.hasPrefix('foo') would throw an exception on nil calls, as you would expect from Oxygene code.)

No awkward manual mappings

Just to be completely clear, there is no manually defined “mapping” between APIs defined in Cocoa and the APIs Oxygene sees (or vice versa), as there is in most Cocoa bridge solutions. There’s no magic table in Oxygene that tells the compiler how to match a call to hasPrefix('foo') to the right method on the NSString.

The Oxygene compiler, instead, simply has full direct knowledge of the Objective-C APIs and does those calls directly — just as Objective-C itself would: it takes the name, packs it up in a selector, and calls the OCR’s objc_mmsg_send() function.

In fact, if you have a variable of type dynamic (or, aliased to that type, id), Oxygene will let you make just about any known method call on that object, just like Objective-C does.

Beautiful Cocoa-style method calls

This also means that Oxygene has full support for Objective-C’s more verbose method naming convention — something that is crucial, really, as a developer would want to interact with the Cocoa APIs as they have been designed and intended (for better or for worse — i personally find Cocoa beautiful).

I purposely picked a simple and uncontroversial example with hasPrefix: above, but what Cocoa APIs are known for are of course the infamous “muti-part” method names, where the method name reads like a sentence with the individual parameters interspersed in between. Consider for example stringByPaddingToLength:withString:startingAtIndex:. How would you call this in Oxygene?

Most bride-based solutions go for one of two options: they would either provide an (often overloaded) method named after just the first part, e.g. stringByPaddingToLength(20, " ", 5) or they would concat the entire name into one big chunk of text, such as stringByPaddingToLengthWithStringStartingAtIndex(20, " ", 5).

For one, yuck. For another, this would require manually crafted mapping tables, which Oxygene does not use — as explained above, Oxygene just handles the Cocoa APIs, any Cocoa APIs, straight up.

So how do you call this method in Oxygene? Simple:

myString.stringByPaddingToLength(20) withString(' ') startingAtIndex(5);

Simple, elegant, and it preserves the “readable as a sentence” aesthetics of the underlying API. What’s more, the syntax seamlessly works with any method an OCR object might declare.

The same goes, of course, for declaring methods in your own classes — both when implementing things such as delegates, but also when designing your own class APIs in Cocoa style:

method stringByPaddingToLength(aLength: Integer) withString(aString: String) startingAtIndex(aStartIndex: Integer);

What’s Next?

With this first post, we have only just begun to scratch the surface of “Nougat”. Stay tuned for more in this series over the next few weeks.

Oh, and be sure to buy or renew your copy of Oxygene now to be among the first to get access to Nougat when the beta hits early next month.

And let us know what you think in the comments below!

See also part 2 . . .