You are browsing the archive for non-tech.

Profile photo of marc

by marc

2013.2 and Beyond

July 17, 2013 in Data Abstract, Elements, non-tech, RemObjects

Hi, everyone.

As we go into the second half of 2013, i wanted to talk a bit more about our plans moving forward, what we have been working on and what we are working on and planning for the foreseeable future.


I can’t believe it’s only been a little over a month since we released Oxygene 6 and Nougat, and so far the feedback we’ve been getting has been just incredible. I am really thrilled to see so many of you diving into Mac and (more so, unsurprisingly) iOS development with Oxygene. Cocoa is a great and exciting platform to be working on, and that will only become more so with the upcoming releases of the groundbreaking new iOS 7, and with OS X Mavericks (both of which i know lots of you have already been using the betas of with Oxygene successfully).

We’re not sitting on our laurels, but moving ahead full steam with development of Oxygene and related technologies, and we have a lot of cool things coming up this and next year.

For starters, we’ve been working on an incremental “July” update for Oxygene 6 to address some bugs and add some minor enhancements here and there. “Gammas” for this release have been out for a while, and we are very close to finalizing the update (think a week or so). July, versioned as 6.0.51 will be a free update for all active subscribers and all Prism XE3.2 users (Embarcadero might have abandoned you on the roadside like a toy they have lost interest in, but we’re not giving up on you!).

Hot on the heels of that will be our August release. Versioned as Oxygene 6.1, this will be a significant update release for Oxygene with a handful of really cool big features and featurettes that i, personally, am very excited about. Of course there is full support for the new Visual Studio 2013 that Microsoft recently announced. There’ll also be ASP.NET MVC 4/4.5 support, and some really cool IDE workflow enhancements, some of which we have been working on for a long while in the background. The first “alpha” of Oxygene 6.1 is available for active subscribers now.

(Do note that as of Oxygene 6.1, the product will no longer be accepting Embarcadero Prism serial numbers, as our collaboration period with the great people at Embarcadero has come to an end for good by the time 6.1 ships. If you are a Prism customer with Software Assurance beyond August 2013, please make sure to contact us, we will take care of you.)

Beyond 6.1, i just want to name-drop a few projects/technologies that we are working on, without going into much (or any, really) detail on them, yet.

There’s “Hydrogene” coming up, which we’ve been dropping a few hints about here and there for a while now. Hydrogene is an exciting new sister product for Oxygene that we think will really be a game-changer. We’ll be rolling out Hydrogene to select beta testers soon, and the plan is to ship the “1.0” product with the Winter (November) release cycle of Oxygene. This is not a promise for a timeline, though, and we won’t ship (or formally announce) Hydrogene until it is ready.

2014 will be a very exciting year for Oxygene and Hydrogene, and we have three related projects that will bring everything together in ways you cannot even imagine yet:

Fire” started as a personal side-project of mine that runs orthogonal to Oxygene (and Hydrogene), and has recently been ‘promoted’ to something we’re officially pursuing as a company project (and which has made great strides since). If and when it ships, hopefully sometime in 2014, it will become a regular part of the Oxygene and Hydrogene products.

There’s also “Marzipan” and “Infrared” (who comes up with these code names, right?), two amazing under-the-hood compiler-level technologies that Carlo’s team has been working on. Thinking about the possibilities with these two techs makes me dizzy, trust me.

Data Abstract and RemObjects SDK

Over on the DA side, we also have big things in the works. We’ve been thinking a lot about the future direction for Data Abstract over the past year or so, and last month we made the decision to stop and switch gears a bit in how we develop and ship DA (and RO). The quarterly releases we have been doing are great for getting new features out on a regular basis, but they also make it harder for the team to sit back and focus on the bigger picture, and on more fundamental changes.

So we’ve decided to take a bit of a break. A break, that is, from shipping significant releases every quarter. As of right now, we’ll be focusing the majority of our R&D effort on the major “next generation” version of RO/DA, which we plan to ship sometime in the first half of 2014.

The umbrella code name for this project is “DA8“, but this is more than just another major version number increase. We are taking a step back and really rethinking DA, and (re-)designing a DA “for the next ten years” (to borrow a phrase). A lot has changed (and is changing) in our industry since we first came up with DA in 2003, and we have a lot of ideas and plans for what we want to do, to not only make DA stay relevant in the changing market, but to make sure that DA remains the leading and best infrastructure for your data access and server development.

Some of these plans are very concrete, some of them are still very vague and in flux. Some of these changes and features we will start talking about (or even have alpha/beta bits of) very soon, while others will remain under wraps a while longer. Some of these will ship with the first DA8 “1.0” release in early 2014, while others will be longer-out. Once again, we’re starting on a new DA for a new decade of technology.

Of course active subscribers will stay in the loop on DA8 as it develops. We will have a regular stream of pre-release builds for you to let you get an early start on some of the new technologies and changes as they emerge.

We’re also keeping the current “7.0” code base active in a branch, and we most likely will keep shipping (very light-weight) quarterly updates for August, November and/or February, to fix crucial bugs or support new platform versions — such as Visual Studio 2013 (which we already have a Gamma of RO/DA out for), Xcode 5/iOS 7/Mavericks, or Delphi XE5.


As you can see, whether you’re using Oxygene or Data Abstract and the SDK (or both!), we have a lot of cool things planned for you for the next twelve months and beyond. Here at RemObjects, we are very excited about all of these projects, and we can hardly wait to show and tell you more.


marc hoffman
Chief Architect

Profile photo of marc

by marc

iOS 7 and OS X Mavericks

June 17, 2013 in Cocoa, Data Abstract, Elements, iOS, Mac, WWDC, Xcode

As you have probably heard by now, last week Apple announced iOS 7 and OS X Mavericks, new major versions of both its flag-ship operating systems. I had the privilege of being on site in San Francisco and attending WWDC in person, but the keynote with the core announcements is available for public viewing by anyone, and the remaining ~100 sessions of the conference are also available for free to all registered developers (major kudos to Apple for that, and more importantly, for making these videos available so fast, in most cases on the same day as the actual presentations!).

iOS 7 is a major new release and – most observers agree – a game changer. It’s a whole new UI paradigm for the OS, and will be a very exciting release for both users and developers; there are a whole bunch of new technologies that will let you create even better iOS apps, and will make the whole iOS experience even better for the user — in the core OS or with your apps.

Due to the massive UI overhaul, most iOS apps will need a serious rethinking for iOS 7 to stay relevant – which means extra work for developers, but also extra opportunities. From what i can tell (and am allowed to tell), switching an application over to the core iOS 7 “look” will be simple, but really making an app feel at home on iOS7 will require a lot of thought — no way around it.

I have already started moving two of our (internal) apps to iOS 7 while on site in San Francisco, simply because after (foolhardily) upgrading my main phone to the new OS, i could no longer stand looking at the old UI ;). One app is “done” and was relatively straight-forward – mainly a matter of rebuilding with the iOS 7 SDK, and making a few adjustments here and there to better embrace the new style; the other will be more work.

OS X Mavericks (if you don’t like the name, you are not alone. Virtually everybody i talked to or heard talk about it found it “weird”) is a smaller upgrade, by comparison, but also a significant release with a ton of exciting technologies for developers – two that were highlighted in the keynote include the new Maps API and cool new energy-saving APIs and technologies. (And if you’re not excited by being able to make your apps more power-efficient, then you have no business developing Mac apps! ;).)

Of course the big question you’re all asking is how Oxygene for Cocoa is working with the new iOS 7 and OS X Mavericks. The good (and slightly unexciting, because expected) news is: it works just fine. We’ve long had an article on the Wiki that discusses the (simple) steps for hooking up Oxygene with new beta SDKs, and Oxygene is working fine with iOS 7 and with Mavericks (although i do recommend grabbing the latest beta drop of Oxygene, as we already made some tweaks and improvements there).

All the new APIs (IIRC Apple mentioned a number of 1500 new APIs being available) will work with Oxygene out of the box – no need to wait for anyone to create any wrappers or headers for you, and re-building your Oxygene apps with the iOS 7 SDK will give you the new iOS 7 look right away (but not save you from re-examining how to really embrace iOS 7 best with your app, of course).

There are also a few new non-API features that we’ll be embracing with Oxygene as well, but unfortunately those are (afaict) all under NDA, so i cannot talk about them yet. But suffice to say over the next few months we will of course be doing a lot of testing with Oxygene and the new APIs and SDKs to keep Oxygene up to date with the SDKs and the Xcode 5 tool chain.

Of course we’ll also be testing Data Abstract and RemObjects SDK for Cocoa with the new SDKs, and (where applicable) expanding them with support for new APIs. In my testing so far, they work great (both the apps i mentioned above are DA-based, and run fine on iOS 7, for example).


Talking about new iOS and OS X SDKs is always a tightrope walk, as there’s a lot of information that’s under NDA (but available to all registered Apple developers – so do make sure you check out the beta builds and all the videos from WWDC). But Oxygene, as well as RO/DA for Cocoa, are already working great with the new operating systems, and we’ll be working hard to expand those parts that do need explicit support and work to fully embrace the new OSs.

If you have any specific questions regarding support for or issues with the new SDKs, there’s two places to get help: for one, we’ll be monitoring and participating in Apple’s beta forums, so you can post questions about Oxygene there (maybe add “(Oxygene)” to the subject so we can find them easier). And you can also always directly email support.

We cannot discuss the iOS 7 or OS X Mavericks Beta SDKs on Connect; you could be violating your NDA by posting details there, and we’d be doing the same by answering. So be careful.


I’m very excited about both iOS 7 and Mavericks (and i assume i’ll eventually get over the name, too), and so should you. I’m looking forward to seeing what you’ll build on the new OSs with Oxygene and Data Abstract.

Profile photo of marc

by marc

“After which no more maintenance releases are planned”. Not.

June 7, 2013 in Elements, non-tech, Oxygene

Our good friends and trusted long-time partners at Embarcadero have recently sent out announcements to make sure that all of our shared Prism/Oxygene customers are fully aware of their future path for continuing using the Oxygene language, coverage of Oxygene updates for the full period of Software Assurance this customers have paid for, and are assured that their technological investment in Prism/Oxygene are savely going forward.

I thought it might make sense to post this message here, to make sure noone misses it.

Dear Embarcadero Customer,

Embarcadero Technologies is pleased to announce the release of Embarcadero Prism XE3.2.

Embarcadero Prism is no longer an included product within RAD Studio as of the XE4 release. Maintenance updates will continue to be provided through August 2013, after which no more maintenance releases are planned.

We wish you success in using this latest Embarcadero Technologies product.


Embarcadero Product Management

We want to thank our friends and partners at Embarcadero once again for getting the word out on this, and for letting our shared customers know where to obtain Oxygene going forward, especially beyond August. It goes without saying that we (RemObjects Software) will honor all active SA contracts, on our dime, beyond August. Please contact us if you have any questions.

Oxygene 6 now includes Oxygene for Cocoa

May 31, 2013 in Elements, Guest Post, Java, Oxygene

Ah, it’s been released… The May 2013 release of Oxygene, released on 27th May 2013, brings us Oxygene 6.0, and Oxygene 6.0 brings us the official release of Oxygene for Cocoa.

The Oxygene language now gives ways of coding for all the currently interesting platforms using the three available editions of Oxygene:

  • Oxygene for .NET (formerly also known as Delphi Prism) – targets the .NET platform, allowing you to build Windows applications, Windows phone applications, Silverlight applications and so on, using the relevant .NET frameworks. Also targets the Mono platform, allowing applications to go to the many places where Mono goes, such as Mac and Linux and also Android and iPhone/iPad using Xamarin.Android (aka Mono for Android) and Xamarin.iOS (aka MonoTouch) using those frameworks.
  • Oxygene for Java – targets the Java runtime, allowing you to build Java apps, Java servlets, Java applets and also, perhaps most interestingly, Android apps. Java apps will use your chosen Java frameworks and Android apps use the Android SDK framework.
  • Oxygene for Cocoa – targets iOS and OS X allowing native ARM applications to be built for iPhone and iPad as well as 64-bit native OS X applications. Applications are built against the native OS X Cocoa and iOS CocoaTouch frameworks.

Oxygene is hosted in Visual Studio 2012 (support for Visual Studio 2010 has now been phased out in Oxygene 6.0). If you don;t have a copy of Visual Studio 2012 the Oxygene installer can set up the Visual Studio 2012 shell first.

For existing users of Oxygene for .NET and/or Oxygene for Java there are some new features added to Oxygene 6.0, including a spate of new conditional defines to help distinguish which compiler built your code or which platform you are targeting:

Oxygene 6.0 edition Edition define Platform define GC/ARC define

However the main thrust of the release is Oxygene for Cocoa, which works in conjunction (if you want) with Apple’s UI designer to support visual UI design via nib (.xib) files or storyboard files. It also understands and fully supports multi-part method names so that it fits in directly with the Objective-C naming system and can represent and refer to any existing methods. It support the iOS Simulator, supports debugging there and on-device and offers all the options needed to sign and provision your apps. It supports ARC (automatic reference counting), understands bridging and uses an LLVM back-end to generate good ARM and 64-bit Intel code.

It ships with all the standard frameworks imported and has a tool that allows you to import any additional libraries you need to work with. Because Oxygene always uses the frameworks that natively exist on the target platforms, there is not an awful lot to learn specific to Oxygene when building Mac or iOS apps. Anything you learn on the Internet about how to build aspects of Mac/iOS apps applies directly – it’s just a case of expressing the various local API calls in the Oxygene syntax, which is a very familiar Object Pascal based syntax.

During pre-release development Oxygene for Cocoa was called Project “Nougat” and I worked with it a lot to keep tabs on how it progressed. I’ve built a whole bundle of test apps to keep on top of (mostly) iOS application development techniques by simply following various online Objective-C tutorials, and just entering the code in Pascal instead of in Objective-C.

I’m delighted Oxygene for Cocoa is now released as I’ve been productive with the tool for quite a long time now. I’ve wanted to make blog posts about how I do thing with it, but given it’s just a syntax shift there hasn’t really been much of a need for it. I guess maybe I’ll do one at some point to show the basics of building up an iOS app in the Visual Studio IDE and getting it launching in iOS Simulator, but after that it’s just writing code in the same way any other iOS developer does; just in Pascal.

On June 17th I’ll be demonstrating the product with a talk at a Developers Group meeting in Maidenhead, UK.

You can find more information about Oxygene for Cocoa at these links:

Buying Oxygene is reasonably pocket-friendly. If you’re new to it then $699 gets you all three versions. Otherwise there is a $499 renewal price for existing Oxygene for Java or Prism customers, a $599 cross-grade price for any users of Embarcadero Delphi or of older Embarcadero Prism versions (XE2 and below) and also a $99 academic price.

If you want to see how you get on with Oxygene 6.0 without committing you can always pull down a trial version first.

Profile photo of marc

by marc

Letting Oxygene and RemObjects SDK wake you up in time for WWDC

April 3, 2013 in .NET, Cocoa, Elements, iOS, non-tech, Nougat, WWDC

On Monday, it being a holiday and all, i found myself with a free half hour before dinner and so i decided i’d write a small little application with Oxygene that can both serve as an example for some cool technology interaction, and also does something useful for me: a Client/Server app that monitors the Apple WWDC webpage for changes and notifies me via Push Notifications on my iPhone when the page changes.

The whole thing was literally done and up on GitHub in about twenty minutes, start to finish (writing this blog post will probably take longer than writing the app ;), and i figured i’d give you a rundown of what it does, how it works and how i did it.

I started by going to and setting up a new App ID with a Push Notification certificate. Any app using Push Notifications needs a unique, non-wildcard ID, so i could not just use one of my existing IDs and profiles.

After downloading the profile and the new Push Certificate, i exported it from Keychain Access as a .p12 file without password protection (to keep things simple).

(The .p12 file is the only piece missing from the WWDCNotify distro on GitHub. You must create your own to run the app, or else we’d get our streams crossed when more people run the app with the same certificate.)

Next, i created the server app. I wrote that in .NET, so i can use Mono to either run it locally on my Mac, or i move it to one of our Linux servers on EC2, if i wanted to.

I started with the RemObjects SDK for .NET new project wizard. The server is really simple, as it doesn’t define any of its new services, it just links in our open source Apple Push Provider (source on GitHub), which provides two pieces of core functionality needed for Push notifications on the server:

  1. It provides the APSConnect class that encapsulates the protocol for submitting notifications to Apple’s servers.
  2. It provides a ready-to-go RemObjects SDK Service that clients can call to register for notifications — along with all the infrastructure to manage the list of registered devices.

Nothing but these few lines of code are needed to set up the Push service:

var lCertificatePath := Path.ChangeExtension(typeOf(self).Assembly.Location, 'p12');
PushDeviceManager.DeviceStoreFile :=  Path.ChangeExtension(typeOf(self).Assembly.Location, 'devices');
PushDeviceManager.CertificateFile := lCertificatePath;
PushDeviceManager.APSConnect.ApsHost := ''; // for this app, we're staying in the sandbox
PushDeviceManager.RequireSession := false;

I tell the PushDeviceManager.RequireSession the path to the .p12 file (which i included in the project and set to be copied next to the .exe), the file to store the registered devices in (again, it goes next to the .exe to keep things simple), the URL of the Apple Push Server, and finally i tell it to not bother with requiring clients to authenticate.

And with that, the server is done and ready to let clients register for push notifications…

Of course there are no notifications being sent yet. To handle that, i created a quick static class that uses a timer that fires every five minutes. When that happens, it downloads the content of the website and compares it to the previous version:

var lNewWebsite: String;
using lClient: WebClient := new WebClient() do 
  lNewWebsite := lClient.DownloadString(URL);

if assigned(fLastWebsite) and (fLastWebsite ≠ lNewWebsite) then begin

If that is the case, it will send a notification with message and sound to all registered clients:

for each d in PushDeviceManager.Devices.Values do
  PushDeviceManager.APSConnect.PushCombinedNotification(d.Token.ToArray, 'ALARM ALARM! The WWDC Website has changed', 0, 'default');

It’s that simple.

Because i have a mild case of OCD, i also made the server send a regular notification without sound (every few hours), to assure me that the service is still running. And on startup, it will also send a notification that the server has been (re)started — again really just to set me at ease that everything is working, when launching or re-deploying the server.

Ok, if you think “well, that was easy”, wait till we get to the client. I added a second project to the solution, this time an iOS app based on the Simple App template — which does nothing but show an empty view. (For completeness sake, i went into Interface builder and made the empty view show the Default.png image, instead of just a white screen.)

To communicate with the server, i imported the interface file for our Push Server by going to the RemObjects SDK|Import Service menu and choosing the RODL file from the Push project above (i could also have pointed it to the URL of the running server instead).

Literally all the code that drives the app is in the AppDelegate class:

In application:DidFinishLaunchingWithOptions:, we add one line of code:

application.registerForRemoteNotificationTypes(UIRemoteNotificationType.UIRemoteNotificationTypeAlert or

to let the OS know we are interested in notifications, and want alerts and sounds.We then implement two callback functions that will be called either if registration for push was successful, or if it failed (which will happen when running it in the simulator, for example). application:didRegisterForRemoteNotificationsWithDeviceToken: and application:didFailToRegisterForRemoteNotificationsWithError:.

When registration fails, we simply show an alert view with the error message.

The success case is more interesting:

method AppDelegate.application(application: UIKit.UIApplication) didRegisterForRemoteNotificationsWithDeviceToken(deviceToken: Foundation.NSData);
  var p := new ApplePushProviderService_AsyncProxy withURL(new NSURL withString(URL));
  p.beginRegisterDevice(deviceToken, startWithBlock(method (aRequest: ROAsyncRequest) begin
      var lAlert := new UIAlertView withTitle('All set!') 
                         message('You are registered for Push Notifications!') 

Here we do an async call to the RegisterDevice function exposed by the server, passing the deviceToken we received (this is the token the server will hold on to and use to later send a message to our device). We pass a block that gets called back when the call was successful and — just for completeness — we show a message that everything went well when that happens.

And that’s it. I run the server with “mono WWDCNotify.exe”. Run the client app once to let it register, and then forget about it.

Top 10 Reasons to use Platform Native APIs

March 14, 2013 in .NET, Cocoa, Cooper, Elements, non-tech, Nougat, Oxygene

What are native platform APIs? They are the APIs provided by the platform vendor that define the platform. On Android this is the Android SDK. On iOS it is the Cocoa Touch Frameworks. On Windows and Windows Phone it is WinRT and the .NET Framework. There are undocumented APIs, and even calls that circumvent the platform APIs, but they are not considered part of the platform API.

In addition to the native development tool provided by the platform vendor, there are 3rd party development tools providers (such as ourselves) with their own solutions. The 3rd party tools typically either focus on providing a better solution for the specific platform, or sacrifice native platform support with the objective of cross-platform simplicity. There is no reason to sacrifice platform support, as you will see in these top 10 reasons to program to platform native APIs.

Platform Native APIs are Great

Those who programmed MS-DOS applications or the early Windows API no doubt remember what a pain those APIs (or lack of) were to work with. Back then it was great to have a good abstraction to make the platform easier to work with. Today’s platform native APIs encompass all the productivity enhancements that are found in the the best abstractions. Typically, the productivity enhancements that come from additional abstractions are only in the form of familiarity and developer’s resistance to learning a new API and framework. You know things are getting carried away when there is a Java abstraction for developing Windows Phone 8 applications and a .NET abstraction for building Android applications.

The Law of Leaky Abstractions

All non-trivial abstractions, to some degree, are leaky.” If your tool forces you to use some non-trivial abstraction on top of a platform’s API, at some point it will leak – there will be something that the abstraction cannot do, or somewhere the abstraction behaves differently from platform to platform. If you are serious about developing for any platform, you need to understand the platform’s native API. The more non-trivial the abstraction, the less of the platform it can abstract successfully and the more likely you will need to move to the platform native API. If you are going to need to learn the platform API anyway, you might as well start there. No need to learn both the abstraction and the platform API – that is twice as much work.

Native Documentation

Documentation is a lot of work. Good documentation is even more work. On each platform, the platform vendor provides the documentation of the platform along with all the best practices and examples. For each additional level of abstraction that requires another level of documentation to consult. Chances are that the documentation will eventually refer you to the platform API documentation. Wouldn’t it be nice to just start at the ultimate authority and not have to wade through incomplete and outdated layers of documentation?

No Bloatware

If your abstraction adds additional graphic libraries or run-times, your application suffers with bloat. These abstractions replace the functionality already present in the platfrom and make your app bigger, slower to start-up and less responsive at runtime. Some of these add-ons are worthwhile, but if you need to double (or more) the size of your app just to write “hello world”, then you are probably using the wrong solution.

Rapid Release Cycle

When a platform vendor releases a new API you want to be able to take advantage of those features right away. It may surface new hardware features, or just introduce better ways of doing things. If you are forced to use an abstraction, you need to wait for the 3rd party to update their abstraction. This may be fairly quick, or you may have to wait for their release cycle, which, depending on where they are in development, could mean the release after the next. No matter how fast a vendor has been in the past at updating their abstraction library, a point will come where they are not updated when you need them.

Support for Platform Deviations

If a hardware vendor comes out with their own SDK extensions or variations on a platform, they will provide their support at the level of the platform API. If you are stuck behind an abstraction, you will not have access. The openness of Android is a great example with extensions like Google TV, Epsion Moverio, Ouya, and Google Glass. If you are interested in cutting edge platforms like these, you need a development tool that doesn’t lock you behind an abstraction.

Native User Experience

Each platform has a typical user experience. This comes from the native platform user interface widgets and the way they behave. It also comes from design guidelines provided in the platform documentation. If you are using an abstraction for your user interface, even one that tries to look and act like the native one, it will get in the way of this native user experience. When it comes to user experience, close isn’t close enough. Using the native platform user interface controls is the only way to give your users the experience they expect.

Less Points of Failure

Everything always works great in the demonstrations, but the more layers of interoperability and wrappers required to make your application run, the more points of failure. When you develop for the platform API directly, you are not handicapping yourself with black boxes or other points of failure for your app. The first time you find yourself debugging into that abstraction layer, you will really wonder if it was worthwhile to shackle yourself with it.

Maximum Developer Flexibility

Platform APIs are huge. In the process of creating a wrapper, choices are made to simplify or eliminate options. These simplifications and eliminations result in less flexibility for the developer. Tying a project to a subset of the features of the platform reduces what you can do with your project. Don’t tie your hands!

3rd Party Support

The majority of 3rd party components and books are going to support the platform’s API. The further you are from that, the less support you are going to have. Want to use a cool 3rd party custom control? Hope they port it to your favorite framework. And what are the odds of a book about the specific features of the platform you want to explore covering it via your specific pair of shackles?


Cross-platform abstractions are only going to get in your way and tie your hands. Any benefit in getting you up to speed faster will be lost in the long term when you hit the rough edges of the abstraction. That is the reason Oxygene is designed to use the platform native APIs directly. There is no forced or complex abstraction to get in your way of using the platform and making the best app possible.

Profile photo of marc

by marc

Creating a Turn-Based Game for iOS: Nougat Tic-Tac-Toe

March 11, 2013 in Elements, iOS, non-tech, Nougat, Oxygene, Visual Studio, WWDC, Xcode

Over the past couple of weeks, i have been working on a new sample project for Oxygene “Nougat” on the side. After having gotten Browse500 into the App Store in January and showing how to reimplement a simple native UIKit control from Objective-C in Nougat last month, i wanted to create another example that illustrates the benefits of how Nougat interacts directly with the native APIs, and i picked a technology i knew nothing about at all to do so: Game Center.

I’m not a big gamer; i don’t find myself playing games much, and i have certainly never written one before, so this was a great opportunity to explore something new.

For those of you not familiar with it, Game Center is a technology Apple ships in iOS (and now also Mac OS X) that allows for games to interact across the network to create multi-player games, and to keep track of achievements. Game Center is not about graphics, or game UI, or anything of the sort (there’s other frameworks for that), it’s only for bringing players together.

I decided to create a simple turn-by-turn game, that is, a game where multiple players (in this case two) can interact, but only one player is active at a given time. Once a player has made their move, it’s the next player’s turn. To keep things simple, i picked a game that everybody knows and that is dead simple to implement, game playing wise: Tic Tac Toe. This way, having to explain the game itself won’t get in the way of the sample code.

To start with, i had to dig myself into the Game Center documentation and i watched a couple of videos on Turn-by-Turn gaming from WWDC 2011 (sessions i didn’t attend at the time). As it turns out, the API for interacting with Game Center for such a game is surprisingly easy and straightforward, and i was up and coding in no time.

Before we get started looking at the code, let’s look at the prerequisites:

  • Here’s the amount of effort anyone from the Oxygene team had spent on thinking about or working on making GameKit (the framework for interacting with Game Center) available to Nougat, before i started this endeavor: 0. Nada. Nil.

  • Here’s the amount of legwork i had to do before i could work with the GameKit APIs, just like every other Cocoa developer would: i added a reference to GameKit to my project. Done.

That’s it. No begging someone to translate header files, or waiting for someone to create a crappy abstraction wrapper class. Add a reference, and use the APIs as Apple intended them — that’s the way development should be.

The Code

Let’s dive into the code.

First of all, the full code of Tic-Tac-Toe is included in the latest Nougat beta, and it’s also available in my Github account for anyone to explore.

There’s really three separate parts that are of interest as a sample project in this app:

  1. The GameKit integration
  2. The game board, implemented as a custom UIControl
  3. The computer player algorithm, generously provided by my good friend and long-time Oxygene user, Jeremy Knowles.

Let’s look at GameKit first.

Working with GameKit

There’s four main classes or concepts that you will work with for GameKit.

The first is the local player, a singleton object that can be obtained via a call to GKLocalPlayer.localPlayer. This objects provides the game with information about the local player — most importantly their ID, and whether the local player is in fact registered and authenticated with Game Center or not. If the player is not set up for Game Center, Tic Tac Toe will simply disable the appropriate UI and just allow local vs. computer game play (although it would be possibly for a game to provide a signup UI, if so desired).

Next is the GKTurnBasedMatchmakerViewController, which provides access to the standard GameCenter UI. It gives the user access to any and all games they might already have going on, as well as the chance to start a new game. In Tic-Tac-Toe, i make this UI available via a button in the navigation bar, and all that’s needed to show the view is code like the following:

var request := new GKMatchRequest;
request.minPlayers := 2;
request.maxPlayers := 2;
var mmvc := new GKTurnBasedMatchmakerViewController withMatchRequest(request);
mmvc.turnBasedMatchmakerDelegate := self;
mmvc.showExistingMatches := true;
presentViewController(mmvc) animated(true) completion(nil);

This code brings up the Game Center UI, with the list of games (if any) or straight with the “Start New Game” (if not). Via the GKMatchRequest, we force the number of players to exactly two. (Game Center itself allows games for up to 16 players):

Tic Tac Toe Game Center

The way Game Center works for starting new games is that it lets you either invite a known friend who also plays the game or — much more interestingly — auto-match you with another random player. One thing that’s cool is that after starting a game, it will always be your turn — you will either be thrown into another game that was started earlier by a different user, or you will get to start a fresh game, depending on what games are currently live and waiting for players. If you start a fresh game, you get to make your first move, and then and only then does Game Center go out and try to find someone for you to play with.

Going back to the code level, what we are looking out for is a callback on the turnBasedMatchmakerDelegate that we assigned above. Our root view controller class implements some 4 methods from the IGKTurnBasedMatchmakerViewControllerDelegate interface, and the match-maker view controller will call us back on these when interesting things happen. This is a very common pattern in Cocoa, and is how the platform handles “events”.

In particular, the callback we care about for starting a new game is:

method turnBasedMatchmakerViewController(aViewController: GKTurnBasedMatchmakerViewController) 
       didFindMatch(aMatch: GKTurnBasedMatch);

This method actually gets called any time the user picks a game in the Game Center UI — whether they are starting a new game, or selecting an existing game. This is neat, because it means we can leave all the game management to GameKit, and don’t need to keep track of ongoing games ourselves.

This callback receives the third important class, a GKTurnBasedMatch. “All” we need to do when this method is called is load the passed match as the active game. In the Tic-Tac-Toe app, we do this by calling our own loadCurrentMatch() method, which does all the heavy lifting.

Every match contains a binary blob in the matchData property that describes the current game state. The content of this binary blob is entirely up to our game, but we can use it to store up to 4KB of data, and this data will automatically be passed between all the participants as they take their turns. In turn, our Game will read the data, let the active player make their move, and then store the updated game state, as we will see in a few moments.

Loading a Game

Loading a game is done with two method calls, first, a a small helper function loads the binary data into an NSDictionary, and then we ask the board to load its game state from that dictionary (the idea being that in a future version, our game might store additional info in the dictionary that the board does not care about — that’s why i decoupled the data the Board class reads/writes from the actual binary format).

var lDictionary := dictionaryFromData(fCurrentMatch.matchData);

The same happens in reverse when we later save the updated game state. Of course, when a new game is first started, there will be no data present (GameKit doesn’t know anything about how our game data is structured, after all), so our code will need to be prepared to find an empty NSData object in matchData.

The second part, in addition to loading the board data, is determining the active player (if any) and enabling the game play. Each GKTurnBasedMatch has a currentParticipant property of type GKTurnBasedParticipant which links to the current player (it also has a participants array that contains all (two) players). We can compare this participant’s playerID to that of the local player.

If they match, it’s the local player’s turn, so we display “your turn”, and enable the board. If they don’t match, it’s either the remote players’ turn (if currentParticipant is assigned), or the game has finished. In either case, we show the proper status message, and leave the board disabled.

Playing a Turn

If it was the local player’s turn and we enabled the board, we’re done for now, and await the player to make a move. This all happens inside the Board class, which will call us back via the board() playerDidSelectGridIndex() method, once the player made their move.

What we need to do then is determine the game status (the player might have made a winning move, for example), re-encode the game status, and pass control back to game center.

There are three scenarios we need to cover:

  1. The player has won by managing to place 3 “X” markers in a row.
  2. The board has been filled (and the game just tied).
  3. Any other case — the game is still on.

In the two game-over scenarios, we set the appropriate status (Won/Lost/Tied) on each of the game participants, and then call endMatchInTurnWithMatchData() completionHandler() to tell Game Center that the match has ended as part of the player taking his turn.

In the other case, we call endTurnWithNextParticipant() matchData() completionHandler() to let Game Center know that the local player is done, and game play can move to the next player.

In either case, we will pass the updated information on what our game board looks like now, via the matchData parameter.

It is worth noting that it’s up to our game to tell Game Center “who’s next”. In our case, that decision is trivial (it’s the player that’s not the local player), but Game Center allows for turns to be passed in arbitrary ways, depending on your game’s needs — it doesn’t always have to go around the (virtual) table.

Once we called either of the above fund methods, it’s no longer our turn, and all we can do is wait for the remote player to make a move.

Handing Remote Turns

Of course, eventually the remote player will make their move, and GameKit provides a second delegate interface for this case, IGKTurnBasedEventHandlerDelegate, which we have hooked up to the GKTurnBasedEventHandler.sharedTurnBasedEventHandler singleton.

What will happen once the remote player moved is that Game Center will show a notification banner to the user, saying something along the lines of “It’s Your Turn”, and play that annoying fanfare sound. When and only when the user taps that notification, will we receive a call to the

method handleTurnEventForMatch(aMatch: GKTurnBasedMatch) 
       didBecomeActive(didBecomeActive: Boolean);

method to let our application know that something happened. This is nice, because it saves us from worrying about showing any UI to the user to ask if they, say, want to switch from the game they are currently looking at to the one that has received a response. When we get the callback, we already know that the user has decided to view the game in question.

So all we really need to do is the same as we did in … didFindMatch() above: load the passed match and enable the board, if appropriate.

House Keeping

This basically takes care of all the Game Center interaction needed for our simple game. There’s a few more minor items that i won’t go into detail for this post; for example, there’s a callback you will want to handle to quit games if the user selects to delete them in the Game Center UI. There also are APIs for providing a custom UI for the list of games, instead of relying on the standard UI provided by Game Center (all Tic-Tac-Toe does with this is adjust the Game Center button to either read “Games” or “Start”, depending on whether there are any games ongoing or not).

In Tic-Tac-Toe, all the GameKit interaction is located in RootViewController.pas, which is only ~500 lines of code total, so it should give you a good overview and starting point for your own game.


There are a couple of caveats you might want to be aware of when working with Game Center games; these had me stumped for a short while, so hopefully pointing them out here will help save you frustration:

  • In order for Game Center to work, your app needs to be registered on iTunes Connect with the appropriate app ID. Even for the simulator. This is counter-intuitive if you are used to App Store development, because normally you don’t have to go to iTunes Connect to register your app until you’re (almost) ready to go and submit it. For Game Center, you need to register it first. If you don’t, GKTurnBasedMatchmakerViewController will just come up looking all empty and dysfunctional.

  • As best as i can tell, you must specify “gamekit” in the UIRequiredDeviceCapabilities section of your Info.plist file for things to work properly.

  • Finally, and most importantly, notifications do not work in the Simulator. If you worked with Push Notifications before, this might not come as much of a surprise, but realize that callbacks such as handleTurnEventForMatch() … will never, ever be called on the Simulator — which seriously will impact how you test game interaction. (In essence, i found the only way to work around this was to manually invoke the GKTurnBasedMatchmakerViewController and re-select the active game to trigger the app to reload the game data and detect the changed game state.)

The Game Board

The second piece of interest in the game is the Board class, which implements all the UI of the game as a really simply UIControl descendant.

The implementation is fairly straight-forward; the class maintains a 3×3 array to keep track of which player has claimed a particular spot on the game board, and in which move (by keeping track of the move number, the game can show different versions of their “X” and “O” markers, making the board look more dynamic).

The begin/continue/endTrackingWithTouch() withEvent() methods are overridden to keep track of — you guessed it — the user’s finger, and they use animations to fade the user’s game piece in and out, and to move it to the next appropriate spot, as the finger moves. (You’ll notice that while the user can move their finger all over the board, the game piece will always “snap” to a fixed position in the closest matching grid spot with a smooth animation.)

All the game pieces (the grid, the “X” and “O” game pieces, etc.) are pre-created images, and the game pieces come in 5 versions (since 5 is the maximum number of moves any one player can make).

The entire Board class is really straightforward and there isn’t much worth covering here that won’t be clear from looking at the code. Worth pointing out is the makeComputerMove method, which invokes Jeremy’s mean ComputerPlayer class, which is used when not playing in Game Center mode.

Tic Tac Toe Board


I think that’s it (and it’s probably enough ;). Make sure to check out the code on GitHub, and let me know what you think!

Oh, and: even though the code is written in Oxygene, as are the code snippets here, i hope the general description of how to work with GameKit will also be useful to “regular” Cocoa developers using Objective-C. Another nice thing about Oxygene working directly against the standard Cocoa APIs without any abstractions!

Profile photo of marc

by marc

“Nougat”, Beta 3

February 11, 2013 in Elements, iOS, Nougat, Visual Studio, WWDC

Beta 3

On Friday, we shipped BETA 3 of Oxygene “Nougat”, a major milestone in our progress to bring the Oxygene language you know and love to the “Cocoa” platform for truly native Mac and iOS development.

The big benefit of Oxygene “Nougat” over other non-Apple tool chains for Mac and iOS is that it fully embraces the platform and is a native compiler for the Objective-C runtime (which is at the core of Mac OS X and iOS development) that works directly with the native Cocoa API and controls.

This means you get all the benefits of the platform and you can work with and access all the same APIs that Objective-C developers using Xcode can. You can, for example, attend WWDC or NSConference or read and watch any of the trillion online tutorials out there on iOS (and Mac) development — and all the things you see and learn apply directly to the code you write with “Nougat”.

My friend and college Jim has created a great new video to introduce “Nougat” and show you around Beta 3, which you can find here.

Beta 3 is a huge milestone for us, in that we believe it represents a state in the development of the product where we can call it “usable for production work”. That doesn’t mean we’re close to RTM yet — we have big and strict plans for how solid we want the product to be for “1.0” this summer — but it does mean that it is solid enough that you can start doing serious work with it. I should know, as i already have my first app created with Nougat in the App Store: Browse500. (Full source is on GitHub, too).

What’s Next?

As mentioned above, we still have a long way to go before RTM. Beta 1 last October had the goal of, well, getting something out to you guys to play with, and we got a lot of great feedback. For Beta 2 we focused on getting all the basic tool chain support in place (debugging, deploying, etc.) and our main focus for Beta 3, which we just shipped, was stability, so we spent most of our time fixing bugs in the compiler, IDE and toolchain. For Beta 4 we are shifting focus back on features — there are still quite a few things missing in the language, and we have lots of improvements and enhancements planned for the tool chain and the Visual Studio IDE support.

“Nougat” is not standing still, and the next two months should be a whirl-wind of new stuff going into the product.

After Beta 4 (and possibly a Beta 5), we are still on track for an official “1.0” release (actually, it will be 6.0) in late spring/early summer.

Get Nougat!

How do you get “Nougat”? If you bought or renewed Oxygene from us since last October, you already have Oxygene “Nougat” as part of your product portfolio. Simply head over to and get your copy of Beta 3 (and don’t forget to participate in the beta forums as well to let us know what you think).

(If you have a Suite Subscription for Xcode, that of course includes access to Oxygene “Nougat”, as well).

If you have a license for Oxygene for Java or for Embarcadero Prism XE2 or XE3, you can renew to the full suite of Oxygene for all three platforms at $349 in our secure online shop.

If you own Delphi XE2 or later, you can take advantage of our cross-grade offer for $399 to get the full Oxygene package.

And finally, the full Oxygene package is available for new users at $499.

Profile photo of marc

by marc

Introducing Browse500, the first Nougat app on the iOS App Store!

January 17, 2013 in Elements, iOS, Nougat, Photography

I’m more than thrilled to announce the immediate availability of, the very first app written in Oxygene “Nougat” to be submitted to and approved for the iOS App Store.

Dog-fooding is important, and as you know, we do a lot of it here at RemObjects. In early December i started out creating a small “real life” iOS app with the goal of (a) putting Nougat thru its paces, test it and find bugs, (b) create a nice sample application that illustrates Nougat and core iOS and Cocoa concepts in a real application and (c) “test” App Store submission.

I did not expect any problems with app store approval — after all, Nougat creates 100% native Cocoa apps that are virtually indistinguishable from those created with Xcode and Objective-C, but i wanted too “prove” that a Nougat app gets accepted (even with “Oxygene” in the compiler meta data, for example).

I was not disappointed. I submitted Browse500 on December 28th, the day the iTunes Connect (the place where you submit apps) was back from its holiday shutdown, and version 1.0 was approved just a few days later. I did not put 1.0 live in the store for two reasons: for one i’ve been working on the app and kept improving it while 1.0 was waiting for review, and for another, there were a few bugs and leaks that would kill the app after some period of browsing because it ran out of memory. Those were easily fixed thanks to Instruments. 1.0.2 was submitted last week and approved last night.

So what is Browse500?


From the user’s perspective, it’s a nice little app to browse the 500px photo community. It lets you browse popular and, as they call it, “fresh” photos, view individual photos full screen, and drill into individual user’s portfolios to see all their photos.

It’s simple, it’s quick, and it turns out i actually use it all the time myself to browse photos.

I’ll be expanding it over time; i have a “bookmark” feature in the works that’s not active in 1.0.2 yet (but that i’ve been using frequently), i have more navigation ideas, and i want to add support for logging authenticating (right now the app browses anonymously only), voting, favoriting, etc.


From the curious developer’s perspective, Browse500 is an open source app, [available on GitHub], written in 100% Oxygene Nougat that illustrates a wide range of iOS technologies and concepts, including:

  • The awesome and fluid kind of standard UI you get by using the proper iOS frameworks rather that weird hack frameworks that aren’t native
  • Use of UITableViews and iOS 6’s awesome new UICollectionView, which i use to implement the main “album” view of the app
  • Using custom UICollectionViewCells and custom UIViews
  • Working with both XIB-based and all-in-code views
  • Using Grand Central Dispatch to write asynchronous code that loads images and data from the net on demand and in the background — you’ll see that the album view is an endless stream of photos that just keeps filling with more as you scroll until 500px runs out of photos to show you
  • Using iCloud to sync settings (1.0.2 as one setting) and data (the 1.1 will have the bookmark feature alluded to above)
  • Using third party Objectve-C APIs (the app uses the open source PXAPI library to talk to
    … and much more

As mentioned, the app is on the App Store now, so if you are mainly interested in playing around, go get it (it’s free). And of course it’s a Universal app for iPhone and iPad.

The app is also fully open source. You can get the full source code from the GitHub repository (you will need the latest Nougat beta), and i would appreciate feedback, comments and &mdashl of course — pull requests.

Also, don’t forget to rate the app on the App Store!


(Disclaimer: The photos in this view are not by me.)

Profile photo of marc

by marc

Happy New Year 2013!

January 1, 2013 in non-tech, Photography

Happy New Year 2013


A happy and successful new year of 2013, from everybody here at RemObjects Software!

We have lots of great things planned and in the works for 2013, and can’t wait to share them with you.