You are browsing the archive for Cocoa.

Avatar of marc

by marc

Data Abstract, RemObjects SDK and Hydra “Spring 2014” Releases

March 31, 2014 in .NET, Cocoa, Data Abstract, Delphi, Hydra, Java

On Friday, we released the latest updates to our Data Abstract and RemObjects SDK products for all five platforms, as well as for Hydra. Like always, a whole bunch of fixes and improvements across the product lines are gathered together in this release.

For Data Abstract and RemObjects SDK, this is also our last planned release for the 7.0 product version, as we prepare for a major new product cycle — codenamed DA8 — starting with our summer release in May. As such, this update focuses mainly on bug fixes and smaller enhancements (of which there are many).

The new release also includes official support for use with our recently released RemObjects C#, including project templates and IDE improvements to let you build .NET, Cocoa and Java apps with RO/DA using our C# implementation, as well as building managed hosts and plugins for Hydra.

As always, the new update is free for all users with an active subscription, and available on the customer portal. Our free 30-day trial downloads have also been updated to the new version.

If your subscription has elapsed, then now is a great time to renew. Renewing will not only give you access to the new 7.0 update, but also access to the beta versions of DA8 that will become available over the course of April, as well as the first (and future) DA8 or RO8 releases throughout the year.

If your previous subscription ended a while ago, you will be happy to hear that we recently updated our online shop to automatically grant “amnesty renewals”. That means you can be assured that your renewed license will always cover the current product and at least six months of future updates from your renewal date.

If you have or are considering getting a Suite subscription, remember that the Suites for .NET, Cocoa and Java now also include RemObjects C# — so you get been more value at the same great price as before (and you can always up-renew from RO or DA to the Suite, of course).

But enough talk, i’m sure you’re anxious to try out the new bits. We’re happy to have this new set of updates out to you now, and we’re extremely excited about what we have coming for DA8 and RO8 this summer and beyond.

marc hoffman
Chief Architect

Avatar of marc

by marc

Announcing the Oxygene “October 2013″ Update

November 4, 2013 in iOS, Nougat, Oxygene

Dear readers,

we may be a day late and into November with this announcement, but we’d like you to know that the “October 2013″ update for Oxygene has been made available earlier this week.

What’s New

The October update is mostly a bug-fix release, but it also includes a couple of rather significant new features on the Cocoa front.

Most importantly, this release officially introduced 64-bit ARM support for the Apple A7 chip in the new iPhone 5S and the new iPads that came out today. Last month we laid a lot of the groundwork with 64-bit compiler support, but now [you can build]( your apps for your devices in 64-bit mode, as well. Very exciting.

We have also started officially shipping .fx files for the new Mac OS X 10.9 “Mavericks”, and we’ve extended the Cocoa compiler to support the new “instancetype” feature introduced/mainstreamed for Objective-C by the iOS 7 and OS X Mavericks SDK.

And of course there are a good 100 additional fixes and improvements in this update, across all three platforms.

How to get Oxygene 6.1.57

As always, this release is a free update to all active subscribers, and can be downloaded now.

If your subscription has elapsed, now is a great time to renew to get access to the latest release and all the good stuff we have cooking for the near future.

Oxygene for Prism Customers

Remember that Oxygene 6.1 is also the first release that is no longer available from Embarcadero under the Prism brand, and it will not accept Prism XE3.2 serial numbers. But as a reminder: we are committed to honoring SA contracts Embarcadero might have sold you with the promise of Prism coverage (i.e. before April 23, 2013). Please email with your SA details, and we’ll sort you out with ongoing access to Oxygene for .NET for the remainder of your SA period. (You can read more about this here).

Of course, if you do not have SA, or if you want to take advantage of Oxygene on the Cocoa and Java/Android platforms as well, you can always renew or cross-grade to the full Oxygene package at any time.

More to Come

2013 is drawing to a close, but we’re not done yet. We’ve got one whopper of a release planned for the end of this month (and lots of cool stuff are coming in 2014 as well). So make sure stay up to date with your subscription.

Happy coding!

Avatar of marc

by marc

“Steps” for iPhone 5S — written in Oxygene

October 30, 2013 in iOS, non-tech, Nougat, Oxygene


I’m more than thrilled to let you know about “Steps“, my next/new iOS app.

Steps is a small but helpful app, which works exclusively for the new iPhone 5S, because it uses the new M7 chip that Apple has introduced with the 5S to gather motion data and let you know how many steps you are taking each day.

Whether you’re interested in that to keep track of your daily workout, or just want a fun way to explore this cool new feature of your iPhone — Steps is a great way to do it.

On first launch, Steps gathers up to 7 days of previous walking history. That’s right — Steps (or rather, the M7 chip ;) has been hard at work for you even before you bought it! So you have some data to look at immediately.

In addition to showing your daily step count, Steps (new in version 1.1) also aggregates your average daily steps for the past week and month, and it will keep track of what your personal best has been, so far — including encouragement to beat it, when you get close.

Over time, and without you ever having to think about it again, Steps will update to load in more data as you roam about, all the while keeping track of your past history. Eventually, you’ll have months and months of walking data to look at. You don’t need to launch Steps manually for this to happen (although you will want to launch it to have a look once in a while).

And because it uses the new M7 chip, Steps can do all of this without affecting your iPhone’s battery life at all.


It goes without saying that Steps is written 100% in Oxygene for Cocoa. And as with all my previous Oxygene iOS projects, full source code is available on GitHub at

So, if you have your iPhone 5S yet, make sure to grab your copy of Steps on the App Store, for only 99c. And if you’re a developer, make sure to check out the code, as well!

Originally published on

Avatar of marc

by marc

Announcing the Oxygene ‘September 2013′ Update

October 2, 2013 in Cocoa, Java, Oxygene

We’re very happy to let you know about the immediate availability of the September 2013 release, the first of two smaller monthly updates we have planned for the Oxygene 6.1 release cycle.

This release, Oxygene, is mostly a bugfix release, but it also contains a handful of significant improvements and new features.

iOS 7.0

On the iOS side, a lot has changed over the past few weeks. Apple has released the final version of iOS 7.0; they have also started shipping two new iPhones, one of them with an all new 64-bit ARM CPU, the A7, and there is also a brand new version of Apple’s IDE — Xcode 5.

While Oxygene has been working well with iOS since it hit beta in June (just a few days after we officially shipped Oxygene for Cocoa), this new release adds official support for iOS 7.0 and Xcode 5. This affects several areas.

First and most importantly, with iOS out from under the NDA, we’re able to ship .fx files for iOS 7.0 in the installer, making it easier (and the default) to build your apps for the 7.0 SDK, without you having to run FXGen yourself to get access to the new SDK.

iOS 7 is not just a new look (although that is a big part of it), but also brings with it a huge amount of new APIs that you can start using in your apps immediately. From TextKit to SpriteKit, from enhancements in UIKit to more options for background operations (such as updating content in your app while it is not running).

There’s a lot for developers to love in iOS 7, and you have full access to it from Oxygene.

What’s more, in last month’s update we shipped significant enhancements to Deployment Target support in Oxygene, which makes it really easy to take advantage of iOS 7, while still supporting older versions of iOS at the same time.

Apple’s new Xcode 5 has changes that affected our process for working with XIB and Storyboards, forcing us to rethink how this is handled – with the end result that we now have a much better and more flexible solution in place. A new menu item in Visual Studio will let you create/update a full Xcode project that will contain all your .XIB and .storyboard files, along with knowledge about other items in your project, including your classes, but also resources such as images.

Once created/updated, you can simply open the project in Xcode and edit your UI files to your heart’s content. Save, and when you go back to Visual Studio and build your app, your changes will get picked up automatically.

We have also made improvements to the iOS Simulator integration. Just as in Xcode 5, Oxygene now lets you choose exactly which type of simulator you want your application to run on — not just iPhone vs. iPad, but also screen size, and whether to use the Retina screen or not. Right from the CrossBox menu:


The September 2013 release also includes support for the all new 64-bit iOS Simulator. When building for iOS 7 (or later), you can now select x86_64 as second iOS Simulator architecture to build for, and get your iOS apps ready for the A7 chip.

Support for arm64 for building applications to run as 64-bit on the device is working in our labs and will be available for the next (October 2013) update and in our current beta builds. Unfortunately, it did not make it into the September release due to timing issues – we figured you would probably want us to test extensively on real hardware, before shipping a compiler to you. Real hardware which has only been available for little over a week now, of course.


Three significant improvements have been made on the Java and Android platform, as well.

First, we have implemented support for Java Native Interface (JNI) in the compiler, making it really easy to access non-Java libraries and APIs from your application.

Secondly, we have expanded our syntax for Inline Interfaces to allow them to be descendants of existing abstract or concrete classes. This has been a much-requested feature from Android developers, and will make many Android APIs much easier to consume.

Finally, we have updated the compiler to be compatible with binary format changes coming in Java 8. While Java 8 (currently still in beta and very much in flux) is not an officially supported platform yet, this will allow you to get started experimenting. This is exciting news for those of you living on the cutting edge.

There’s More

These features are rounded off by over 70 additional fixes, enhancements and improvements, all throughout the product, and across all three platforms, .NET, Cocoa and Java.

We’re very excited about this update – and about what we have still planned for the rest of the year – and we hope you will like it, too!

marc hoffman
Chief Architect

Avatar of marc

by marc

Data Abstract and RemObjects SDK for Cocoa on iOS 7 and the 64-bit A7

September 30, 2013 in Data Abstract, iOS, Xcode

Hi. I wanted to give you a quick update on the status of Data Abstract and RemObjects SDK with regards to both the new iOS 7.0 and – more interestingly – the new 64-bit iOS on the iPhone 5S.

Over the past couple of weeks, we have been debating whether we should make a small interim update to RO/DA for Cocoa available to “officially” support the two new platforms/technologies, and we have decided against such an update, for the following reasons:

We’ve (of course) been testing the RemObjects SDK and Data Abstract code base with iOS 7.0 since the first beta, and with 64-bit since the iOS 7 GM and the iPhone 5S is out. The current code base as shipped in the Fall release about a month ago is working perfectly with iOS 7, and no changes are needed.

It is also working fine on 64-bit (ignoring some minor warnings), as expected – after all, the same code base has been running on 64-bit Mac OS X since forever. Still, it would be nice to ship an update release that contains a universal binary pre-compiled for arm64 out of the box, but there’s one downside to that:

Right now, if we switched RO/DA to build for arm64 by default, that would mean we’d also need to set the minimum deployment target to iOS 7 – which in turn means the binary we’d ship would not allow you to build applications that still target iOS 6 (or lower), something we know many of you still do.

On the flip side, for those of you who would like to build your RO/DA based apps for 64-bit, it is a simple job to rebuild RO/DA yourself: Simply open the project in Xcode, change the architecture to ARCHS_STANDARD_INCLUDING_64_BIT (and clear the deployment target, of course), and hit rebuild. (We’re also making a pre-release build available today that does have 64-bit enabled (at the cost of losing deployment target options, as indicated.)

Apple is promising to sort out the deployment target situation “next month” to allow arm64 to co-exist with older deployment targets, and we figured it would be best to hold out for that — especially given how easy it is for you to manually rebuild for 64-bit now, if you need it.

I will keep you posted as this develops – and once again, us holding back on shipping the update does not mean that the current code base you have now is not perfectly fine for arm64 use already.

Let us know what you think.

Avatar of marc

by marc

An update on Oxygene support for iOS 7 and arm64

September 13, 2013 in iOS, Nougat, Oxygene

Over the past couple of days, unsurprisingly, a lot of people have asked me about our plans for supporting iOS 7 and – more specifically – the arm64 architecture used in the new iPhone 5S.

Of course the news is good.

General support for iOS 7 on armv7 and armv7s (the current CPU platforms in iPhone 5 and older) has been in Oxygene since forever. We don’t ship .fx files for iOS 7 yet (that would have been a violation of Apple’s NDA, as long as iOS 7 was in beta), but Oxygene comes with a tool that lets you generate those files yourself with a single drag and drop for any beta SDK (including iOS 7 and OS X 10.9, a future iOS 7.1, etc). The July release also included additional fixes to make the import for iOS 7 more seamless.

So in general, Oxygene has been ready for iOS 7.0 for a while now, and i know that a lot of you have of course been using the two together, as have i myself for some of our internal apps (and in fact our is already in the App Store, ready for iOS 7.0).

Of course, this support only extends to 32-bit iOS – which, to be clear, is fine and good enough to build and submit iOS 7 apps, including those that will run on the new iPhone 5S, today. (You’d want to extensively test your apps on the device before submitting 64-bit versions, anyways.)

So what about 64-bit?

Obviously, we only learned about the new A7 chip being 64bit alongside with the rest of the world outside of One Infinite Loop only yesterday. So work is needed for Oxygene to support the arm64 architecture that drives the CPU in the iPhone 5S.

We’re on that, and we don’t expect it to be a big deal, because Oxygene (a) builds on the open source LLVM backend, which does the bulk of the work for supporting different hardware architectures (and operating systems) and (b) is designed from the ground up for multiple architectures, and for creating universal binaries (that is, executables that contain code for more than one CPU). In fact, you’ve already been building those, if you build for armv7 and armv7s – 64bit just adds a third, albeit more different, architecture.

So mostly, we’re talking minor tool chain adjustments and improvements, as well as extensive testing.

  • The .fx import (mentioned above) has been updated to support arm64 yesterday and is done, pending testing. The .fx files now have three architectures for iOS: armv7/armv7s/arm64 and a dual-architecture for the Simulator: i386/x64. That’s right — there’s a 64-bit Simulator, as well.

  • With these new .fx files, arm64 will automatically show up as platform to build for in the IDE, and the compiler and the rest of the IDE toolchain will automatically pick up 64-bit support for your iOS projects. (There are new Conditional Defines you can use to test for bitness, such as __arm64__ on device and _x86_64__ on Simulator.)

  • The IDE and build chain does some magic with regard to building for the Simulator. In particulate, you never explicitly choose a Simulator SDK or i386 as architecture; instead, you configure your project for the iOS SDK and the ARM architectures you want, and if you build for Simulator, the build chain (and IDE smarts such as Code Completion) automatically switches over to the Simulator SDK, and to i386. The logic here needs to be refined to include _x86_64 if your app is built for arm64, so that you can build 64-bit Simulator apps. The devil is in the details (and it’s kind of funny that the compiler is ready to build 64-bit Simulator apps already, if only the toolchain would ask it to ;)

  • No use building 64-bit Simulator apps if you can’t run them – so we need to expose an option in the IDE to let you choose different Simulator versions (not just iPad vs. iPhone, but also bitness, and while we’re at it, Retina vs. Non-Retina iPad, and iPhone screen size).

  • The actual arm64 compiler backend needs to be tested. It’s been in the LLVM code base for a while, but we have not used it ourselves yet. So we need to test it against our Oxygene front-end and make sure all works well. Of course Oxygene already does x64 support on the Mac side, so we’re fairly confident. (64-bit support in the Simulator is pretty much identical to the existing Mac support; it uses the same x86_64 back-end, but it is, officially, a different platform/operating system combo).

    Rumor also has it Apple has extensions to LLVM that aren’t published on the open source LLVM yet. It remains to be seen, possibly not until we have actual hardware, whether those extensions are crucial to have for compiling working iOS arm64 apps, or whether they are just icing on the cake that is the existing LLVM arm64 support that’s already public.

None of these are hard problems, just stuff that takes a day or two to do well (for example, i thoroughly refactored and abstracted the Train script that drives the .fx import in FXGen, as part of adding arm64 support to make the architecture handling much nicer and more flexible for the future).


We don’t want to make any promises (especially since final/real testing will depend on me getting hold of an iPhone 5S in a timely fashion to have test hardware, and with Apple not doing pre-orders this year, i guess that means i’ll be queuing up at the Apple Store here in Berlin again, next Friday ;), but we’d like to ship official arm64 support in the September update at the end of this month.

We’ll also try to get as much support as possible (untested on real hardware of course) into the next beta drop. At the very least, this will include the full .fx files for 64-bit, and it’s pretty likely to include 64-bit Simulator support, as well.

That said, remember that arm64 is not crucial for building iOS 7 apps. You can (re-)build your apps against iOS 7 now (i have been since mid-June), and submit those as armv7/arm7s. They will run fine on iPhones 5S, too. Once we do have arm64 support fully finalized, you can rebuild them with the extra architecture enabled.

As mentioned before, even if we had arm64 support ready this very second, it’d be pretty foolish to submit your 64-bits to the store before you can test them on real 64-bit hardware. More so, given that your apps will get little benefit from being 64-bit until you had the chance to properly extend and design them to take advantage of the platform. So we think our timeline should work well for you.

Beta Access

Remember: All Oxygene users with active subscriptions have full access to our beta releases, which give you early access to cutting edge stuff such as this. Visit the Beta Access page on our wiki for details, and make sure to install our (linked from the same page) to stay in the loop with new builds.

Now, i’m sure you have iOS 7 apps to build and submit to the App Store, so i’ll leave you to it…

Avatar of marc

by marc

Announcing Oxygene 6.1

September 9, 2013 in .NET, Cocoa, Java, Oxygene

We’re thrilled to announce the immediate availability of Oxygene 6.1, the next feature release for Oxygene after the introduction of Oxygene for Cocoa earlier this year.

Like most of our monthly updates, this “August 2013″ release contains a vast number of fixes, improvements and enhancements all across the board, and for all three platforms. It also provides a small handful of new major features that we are really excited about and think will make a great difference in your day-to-day work using Oxygene.

First off, 6.1 marks the introduction of our Refactoring engine for Oxygene. We’re starting out small, with one very useful refactoring: the ability to safely rename identifiers solution-wide. But this also lays the groundwork for more refactorings to be added in the near future.

We have also vastly expanded the Go To Definition feature of the IDE to work for external references. This makes it easier than ever to have a peak at the declaration of the classes you are using, from .NET classes such as System.String to Cocoa ones such as UITableView. Just right-click, choose Go To Definition, and Oxygene will bring up the class declaration – in full Pascal syntax, of course – ready for you to review, or to copy method headers from.

Cocoa developers will love to hear that we added even better support for Deployment Targets to the compiler, with improved weak linking, and optional warnings when your code uses classes that may not be available in the lowest deployment target SDK you selected for your project. This goes way beyond what Xcode offers, and – especially with iOS 7 coming up now – will make your life supporting apps on new and older OS versions so much easier.

Of course that’s not all. There’s also support for optional interface methods in Cocoa, unsigned integer types on Java, and much more. You can find the full list of changes on our What’s New and Change Logs pages.

How to get Oxygene 6.1

As always, Oxygene 6.1 is a free update to all active subscribers, and can be downloaded now.

If your subscription has elapsed, now is a great time to renew to get access to the latest release, and all the good stuff we have cooking for the near future.

Oxygene for Prism Customers

Oxygene 6.1 is also the first release that is no longer available from Embarcadero under the Prism brand, and it will not accept Prism XE3.2 serial numbers. But as a reminder: we are committed to honoring SA contracts Embarcadero might have sold you with the promise of Prism coverage (i.e. before April 23) . Please email with your SA details, and we’ll sort you out with ongoing access to Oxygene for .NET for the remainder of your SA period.

Of course, if you do not have SA, or if you want to take advantage of Oxygene on the Cocoa and Java/Android platforms as well, you can always renew or cross-grade to the full Oxygene package at any time.

More to Come

2013 has been a great year for Oxygene so far, but we’re not done yet. We’ve got more amazing things planned for the rest of the year, and beyond. So make sure to stay up to date with your subscription.

Happy coding!

marc hoffman,
Chief Architect
RemObjects Software

Avatar of marc

by marc

Duck Typing in Action

July 31, 2013 in .NET, Cocoa, Cooper, Nougat, Oxygene

I came across a really awesome use of Duck Typing yesterday, and i wanted to share this with you, since i think Duck Typing is one of those features in Oxygene that are incredibly powerful, but underrated – probably even unknown to many users.

This is actual code that is live on our website, and it’s driving the downloads lists for licensed products and betas.

Both download pages are driven by the same .ascx, which runs a query to get the products a user has access to, and then compares it to the available downloads (passed in as aFiles), to determine what files to show. The code looks something like this:

method DynamicDownloadList.PrintProductFiles(aFiles: sequence of BetaFile; aBeta: Boolean);
  if aBeta then begin
    var lProducts := from p in DataAccess.Linq.GetTable<ByUser_BetaProducts>(...) 
                       order by p.DisplayOrder;
    // loop and print out files
  else begin
    var lProducts := from p in DataAccess.Linq.GetTable<ByUser_LicensedProducts>(...) 
                       order by p.DisplayOrder;     
    // loop and print out files

The code that i’ve abbreviated behind the “//loop and print out files” comment was actually just 5 lines, but it was mostly identical for both beta and final downloads. I still had to duplicate it, because the two LINQ queries, of course, returned sequences of different types. Which is kind of a bummer, if you think about it – these are two queries (actually, Data Tables defined in the DA server that apply quite a bit of complex logic) that return the same kind of data, but due to the way LINQ works, because they are different tables, the resulting objects are of different classes.

So even though both ByUser_BetaProducts and ByUser_LicensedProducts contain fields like ProductID, Name, ImageName, and so on, it’s not really easy to write code that can be shared and work against either version. (To boot, these classes are auto-generated by LINQ, so it’s not like i can just add a common interface to the ancestry list, either.)

Yesterday i set out to expand the logic for the download display a bit (in particular to improve how the unified “Oxygene” download shows for people who own all three platforms), and i found the duplicate code turning too complex to stay duplicated. Sometime it’s fine to copy/paste 3-5 simple lines of code into two places, but this was getting more sophisticated than i liked sharing and maintaining in two places.

Duck Typing to the rescue!

So what i needed to do was write code that could work on two classes that have no common ancestor and no shared interface, but look “similar”. Exactly what Duck Typing was made for!

First, i went ahead and declared the following interface:

  IByUserProducts = public soft interface 
    property ProductID: System.Guid read;
    property Name: System.String read;
    property ImageName: System.String read;
    property OptionalMessage: System.String read;
    property DateExpires: nullable System.DateTime read;

that defined all the members from the query i needed access to.

Next, i adjusted the LINQ code just ever so slightly:

method DynamicDownloadList.PrintProductFiles(aFiles: sequence of BetaFile; aBeta: Boolean);
  if aBeta then begin
    var lProducts := from p in DataAccess.Linq.GetTable<ByUser_BetaProducts>(...) 
                       order by p.DisplayOrder 
                       select duck<IByUserProducts>(p, DuckTypingMode.Weak);
    // loop and print out files
  else begin
    var lProducts := from p in DataAccess.Linq.GetTable<ByUser_LicensedProducts>(...) 
                       order by p.DisplayOrder 
                       select duck<IByUserProducts>(p);
    // loop and print out files

The only thing i changed is that at the end of the from clauses i added an extra select operator to change what the LINQ query returns: duck-typing the specialized class returned from DA into the custom IByUserProducts interface i declared.

Now, instead of returning sequences of ByUser_BetaProducts and ByUser_LicensedProducts respectively, both queries return the same type: a sequence of IByUserProducts.

This, in turn, means that i could take all the code from “// loop and print out files” and move it into a separate function, called from both branches.

Presto: shared code!


If you’re eagle-eyed, you might have noticed that i’m passing DuckTypingMode.Weak to the duck() function in the first branch, but not the second. What does that do?

Simply put, i lied when said that the two queries returned the exact same set of fields. In fact, the query for release products returns a few extra fields, including the expiration date (which i need to gray out newer downloads if a subscription expired – in contrast to beta downloads, where the whole product just disappears).

DuckTypingMode.Weak allows the duck typing to IByUserProducts to succeed, even though the underlying class does in fact not fully qualify for the interface, because it’s missing the DateExpires property. Oxygene will instead inject a stub that will throw an exception if DateExpires were to be called.

But that’s fine. All i need to do in my now shared code is check the aBeta flag, and make sure i don’t actually call DateExpires when i know it’s not there, and i’m all good!


To summarize, Duck Typing is an awesome way in Oxygene to let you write code against classes that have the same (or similar) API, but don’t have a common ancestry or shared interfaces.

Of course, if you have full control over the class hierarchy yourself, the easiest (and cleanest way) to achieve this is to just define an interface and have the classes implement it. But sometimes, as in this example, the actual classes are out of your hand. Duck Typing lets you get around this nicely and safely.

Soft Interfaces

You might have noticed that i used the soft keyword when defining the interface, above. This was actually not fully necessary, as the duck() function will work with any kind of interface.

Soft interfaces approach duck typing from the opposite end: by defining the interface as “soft”, i don’t actually need the duck() call, as soft interfaces carry with them the information that they may automatically be duck-typed too, with a simple cast. As such, a simple select p as IByUserProducts would do to convert the types.

However, soft interfaces use the default (static) duck-typing mode by default, not the weak duck-typing. So this approach would have worked for the Beta branch of my code, which is why i chose to explicitly call duck() in both cases, for clarity. (Yes, i could/should drop the unnecessary soft keyword then, but i left it in to have an excuse to talk about it here ;).

You can read more about Duck Typing and Soft Interfaces on our wiki.

Avatar of marc

by marc

Announcing the Oxygene 6 “July 2013″ Update

July 30, 2013 in .NET, Cocoa, Cooper, iOS, Java, Nougat, Oxygene, Platforms, Prism, Visual Studio, Windows

Oxygene "July 2013"

We’re thrilled to inform you that the “July 2013″ update for Oxygene 6 is available now.

The team has been incredibly hard at work since we shipped Oxygene 6 in May, both on this update and on the next feature release coming up in August, and the “July 2013″ update brings with it a good ~140 fixes and improvements across all three editions and across the entire toolchain, from compiler to IDE.

Even though we consider this update a “bug-fix release”, we could not stop ourselves from including two major compiler/language enhancements, as well: On the Java/Android side, the Oxygene language has gained full support for unsigned integer types — a feature not available in the Java language and not officially supported by the Java Runtime, we know that a lot of you who use Oxygene on Java have been looking forward to this. On the Cocoa side, the compiler has been updated with support for Oxygene’s trademark Future Types (one of my favorite features), based on GCD under the hood.

With these two changes, we’re taking another big step towards bringing the Oxygene language closer together on all three platforms.

What’s Next?

We’ve also been busy at work for the upcoming 6.1 release (for which alpha/beta builds have been available for a while now) and beyond. Check out my blog post for more details and some hints at what is coming up. We’re very excited.


Embarcadero Prism customers, please note that the “July 2013″ release will be the last update made available to you under the Prism brand, and the last release to accept Embarcadero serial numbers.

Please make sure that you have your Prism XE3.2 serial number registered with us, so that we know about you and can contact you about moving forward. As mentioned in the past, we will honor existing SA agreements you may have with Embarcadero beyond July – but we can only do that if we know who you are ;).

As always, if you have any questions or concerns at all, please contact us at

marc hoffman
Chief Architect

Avatar of marc

by marc

Introducing the RemObjects “Beta” app for iOS and Android

June 26, 2013 in Android, Build System, Data Abstract, iOS, Oxygene, Uncategorized

We’re constantly trying to optimize the workflow for publishing and announcing beta releases. Oxygene has been on a weekly beta cycle for a long while now and we’re trying to get RO/DA onto a more regular (maybe bi-weekly-ish) cycle as well (i’ll be writing more about our upcoming plans for RO/DA over the next year or so, soon), and we want to make the process of publishing new beta builds easy for us, and the process of being notified about new beta builds easy for you.

As part of this, two changes have been made recently.

Firstly, if you have installed any beta build of a product post our May 2013 releases, our Everwood Update Check will now notify you not only of new release versions, but also of new beta builds being available – making it very likely you’ll be find out about new builds within 24 hours of actively using a beta product.

But we wanted to do more, and so we’ve started developing an app to keep the hard-core beta users amongst you even closer in the loop: Welcome to the “Beta” app.

“Beta” is a small app, available for iOS and Android on the respective app stores. The iOS version has been available for a couple of weeks now (i got it approved shortly before WWDC), and the Android version is live as of now. What does “Beta” do? Two things, really.

The most important thing, it will receive and show to you Push Notifications when new beta (or release) builds for your products are available. Are you anxiously awaiting the next Oxygene beta drop each friday afternoon? Your iPhone or your Android will now let you know!

So “Beta” will be useful even if you never ever run the app again, after the first time.

But you can also go into “Beta” at any time, to see the list of current beta and release products available to you, including a shiny “NEW” badge on builds shipped within the past two days. Over time, we might expand beta to show more info (such as to let you know whether a new build is covered by your current subscription or not, look at change logs, and more).

What does “Beta” look like? Here’s the iOS version:

(including a sneak peak at what it will look like on iOS 7), and here’s the Android version:

So where to get the app? You can get “Beta” on the iOS App Store and the Google Play store, respectively. In addition, we’ve also made full source for the app available on GitHub; of course it is written in 100% Oxygene, the client apps and the Push server.