You are browsing the archive for non-tech.

Profile photo of marc

by marc

About our Build System Infrastructure, CI2

July 21, 2015 in non-tech, RemObjects, Tools

Over the past couple of weeks, we have been working to migrate our build servers to a fully AWS-hosted solution. Our build system has become pretty sophisticated over the last few years, so I thought I would talk about it a little bit, on the off chance that some of you might find it interesting, or get ideas for your own build chain out of it.

Our build system is based on a home-grown infrastructure we call “CI2”. CI2 is a set of tools that we have written over the years that coordinate product builds and – in short – handle Continuous Integration for our products. Essentially, that means whenever someone commits a change to a project to Git, the system goes out and creates a new build of the software and eventually tests it to make sure the new change integrates ok and does not break anything.

CI2 is written in Oxygene (of course) and makes heavy use of RemObjects SDK and Data Abstract for communication.

Until a couple of weeks ago, the bulk of the system had been running on a custom Xserve server – a rack-mountable Mac server machine that Apple stopped making a few years back – that we owned, and co-hosted with a local hosting company here in Berlin. We’ve long been wanting to migrate this to a fully cloud-based hosting solution on Amazon Web Services (which we use for everything else), and when one of the disks in the sever started flaking out a couple of weeks ago, we decided that now was as good a time as any to tackle that.

With how CI2 is structured (I will talk more about that shortly), the migration was pretty smooth, in general. Most of the holdup was that we needed some more infrastructural changes. Because in the past all the builds happened on the same physical machine, we had quite a bit of logic in place that assumed the individual build VMs could access shared drives, and the like. Also, our local VMs had over the years gotten bloated, as we installed new tools, new versions of Delphi and Visual Studio required by the builds, and so on. We wanted to start with clean virtual machines in EC2, and that meant doing some well-deserved clean-up and simplifications to our build scripts – which actually makes the builds better, as well.

As of last Friday, we’re done, and have all our products build cleanly and successfully on the new infrastructure. As an added benefit, builds have gotten a lot faster, as well. It used to be that we waited a good 40 minutes for a full Elements build to finish – and that was without generating all the different set SKUs we build for releases we ship. On the new system, a complete build, with the large Shell-containing setup and everything, finishes in under 25 minutes.

Faster builds means a more productive team, as with complex products like ours, often one needs to wait for a new build from CI before a change can be fully tested.

How CI2 Works

But let’s take a quick look at how CI2 works.

As I mentioned before, CI2 is not a monolithic system, but a set off tools that work together, locally and across the network, to perform all the various tasks. It’s a very flexible and expandable system that has grown and gotten very sophisticated over the past 10 or so years (the first commit in our CI2 Git repository is from 2009. And mind you, the 2 stands for “version 2” ;)).


It all starts with CIStarter.exe. CIStarter is a very minimal tool that gets the whole CI system up and running.

CIStarter does only a couple of things:

  • Based on information read from either a local config file or (more likely, in production use) from EC2 instance data configured in AWS, it connects to an S3 bucket and downloads the actual CI2 system to the local server.
  • Optionally, it runs a tool called CIPrerequisiteInstaller to, well, install prerequisites needed for building our products. More on that below.
  • Finally, it passes things off to run one of the other CI tools or servers to do the actual work. These will usually be CIMainServer, CIBuildServer or CITestServer.

CIStarter has very little logic of its own, and the idea is that (a) only the exe (and optionally a config file) need to be deployed to a server, and more importantly that (b) the CIStarter itself will never really change, even as the core CI2 system gets upgraded.

This means CIStarter can be “burned” into a base image for a virtual machine (be it on EC2 like we use now, or any other virtualization system), and new instances can be booted up as needed. The core CI2 system – which does get regular updates and fixes, of course – can simply be updated on S3, and new instances will always use the latest system.

It’s worth noting that CI2 can run on Windows, Linux and Mac OS X – and we have it, in fact, in use on all three platforms, as you’ll see below.


The first thing CIStarted does after downloading the system from S3 is run CIPrerequisiteInstaller.exe, a small tool that installs and manages all the various packages of tools and files that might be needed to build our products. Like the system itself, these are obtained from S3, so publishing a new prereq is as simple as uploading it to the right bucket, and any new CI instances will pick it up on next run.

Of course CIPrerequisiteInstaller keeps track of which prereqs are installed, and only downloads and installs what’s missing. Prereqs are also incrementally versioned, so newer versions of a prereq can be uploaded, and get installed as needed.

Prereqs we have set up for our system include things such as Elements (we need Elements to build Elements ;), different Delphi versions, packs of third party libraries, and other tools.

One of the cool things is how we handle Delphi. As you might be aware, Delphi installers are slow and bloated, so installing Delphi is not really a good option. We need all versions of Delphi from 7 through the latest XE8 on our system, and if we were to run the installer for each, getting a new instance all prerequisited would, probably quite literally, take half a day (not to mention hundreds of gigabytes of disk space). Instead, our Delphi team figured out a way to package Delphi so that it can be xcopy-deployed with just the files we need to build with it. When a new version of Delphi (or an updated version of an existing version) comes out, we can get all the build machines updated to have it in a jiffy.

Prereq packages themselves can be made up from an .exe installer that runs quietly, or can be a .zip with a Train script that does installation or deployment. CIPrerequisiteInstaller manages unique install locations that individual prerequisites can use, assuming they don’t have a well-defined place they get installed to (for example, our Elements prereq simply runs the Elements installer, while our Delphi packages drop their files where CIPrerequisiteInstaller tells them to).

The idea is that CIPrerequisiteInstaller can both take a cleanly set up and freshly booted build machine instance and get it set up with all the prereqs we need, and it can incrementally update an existing live instance with just the new prereqs that we added.

In our case, we have both a clean AMI that we can boot up to start from scratch (which is little more than a fresh Windows install with CIStarter), but also one with the current set of prereqs already installed. Of course, instances booted up from the latter are quicker to start and ready to run a build.


Once everything is set up, CIStarter passes execution on to one of (currently) three different server tools. Which one is determined by the config file or the EC2 Instance Data.


CIMainServer is the brains of the whole operation. It’s a very lightweight server that does not need its dedicated machine (ours runs on a small Linux EC2 instance that also hosts our email, some of our websites, and other infrastructure, for example).

What CIMainServer does is keep in touch with all the actual build servers via RemObjects SDK super channel connection, and monitor the known Git repositories (some of which we host ourselves, and others we have on GitHub) for changes. As new commits are detected, it will fire off build requests to a suitable build server (i.e. one that’s idle and has the right platform and setup to build the project in question).

Currently, we only distinguish between Windows and Mac build servers, and any server can take a build request for any product on its platform. In theory, one could set up dedicated build servers per product (for example, we could have a server running that builds only Elements and not Data Abstract, if we wanted).

In the long run, CIMainServer will also be able to boot up and shut down EC2 instances as needed, depending on demand. For example, we could have a skeleton crew of one server running over the weekend (if that), but come Monday morning when things get busy and people commit changes and want their builds quickly, it could boot up a few more instances. Currently, we don’t do that, and just run two “t2.large” instances for Windows and one Mac build machine.

CIMainServer uses a small database to keep track of known repositories, active and past builds, as well as their success and testing results. That database could be hosted in RDS, but we find the extra cost isn’t justified since we don’t need that level of fail-over and recovery support, so we just run a local Postgresql DB on the same Linux machine that hosts CIMainServer itself.

CIMainServer is also CI2’s connection to the outside world.

Of course it starts builds automatically as its sees changes in Git, but it also lets us start builds manually (for example if we want a build with a non-default set of options passed to the build scripts, or when the system is locked from doing automatic builds so we can start builds in a controlled order, which we usually do for RTM and public beta builds).

For that, CIMainServer interacts with Slack to listen to commands in the chat channels where our teams hang out, and to also report back statuses. For example, I can simple say “start build elements lockdown” to shoot off a new build of “Elements” from its “lockdown” branch. When a build finishes, a message gets posted to the right channel, along with the URL where the final binaries can be downloaded, or where the log file can be found, if there was a problem.

CIMainServer also has an RO/DA based API, and we have small apps for Mac and iOS that can be used to control builds, get a more detailed status overview, and receive push notifications for critical failures.


If CIMainServer is the heart of the operation, then CIBuildServer is the muscle.

On start, CIBuildServer just connects to the main server, and then waits for instructions. When it receives a build request, it goes out to Git to clone the repository and check out the right branch, and then fires off to the build script found in the repo to build the product.

Of course, it also does a lot of maintenance around that as well, including cleaning up after a build, managing the different folders where different branches are checked out for each repository (we keep the checkout around, because a simple pull is a lot faster for subsequent builds than cloning fresh every time would be), and so on.

CIBuildServer also takes care of publishing the finished binaries and the build logs (to S3, of course), as well as keeping CIMainServer up to date with the build status.

The actual build scripts we use are all based on Train, our JavaScript-based build script engine that is already open source, but in theory CIBuildServer can also pass off to other systems (in the past we used FinalBuilder, which CI2 still supports even though we no longer use it), and the infrastructure is pluggable so that other runners can be integrated as well.

We currently run CIBuildServer for Windows in EC2 virtual machines (these are new since we switched from VMware machines that ran on our Xserve). Since Amazon doesn’t offer OS X-based virtual machines (unfortunately), we also currently run CIBuildServer on a local Mac mini. In the long run, we might switch to something like MacMiniColo. Only the “DA/Cocoa” build needs the Mac, everything else builds on the Windows machines.

The nice thing with how the whole build system is distributed now is that the location of the build servers is immaterial; the only difference we see from the Mac builds running locally is that the upload and download to and from S3 is a bit slower that it is from the EC2 instances (where S3 access is so blazingly fast we were blown away. In fact, a lot of the caching of S3 content that we built into Train and CIStarter feels unnecessary when running on EC2).

The Shared Bucket

One thing that required the most rethinking before we could move to EC2 was what we refer to as “shared” files.

While our products build independently, we do have a lot of inter-dependence between them. For example, Everwood builds as its own repository, but both Elements and RO/DA need it to build. The DA/Cocoa build needs binaries from the DA/Windows build (such as Relativity Server), and vice versa.

In the past this was handled with a shared folder that all build VMs (and the Mac) had access to, but for the move to EC2, this infrastructure had to be switched over to leverage S3.

The way we handle this is that every build that runs gets passed a dedicated S3 location where it can publish generated binaries that other projects might need access to. This location is unique for the project (the ”repository”, really), and the particular branch that builds.

For example, the Everwood build zips up the binaries needed by the other projects, and publishes them to the Shared bucket. When an Elements build runs next, it can use a predetermined logic to find the version of Everwood in S3 that most closely matches the right branch, and grab the bits from there. I say most closely matches, because there will not always be a 1:1 match, of course. We might have a “develop-feature-X” branch in our Elements repo, but no such branch in Everwood – so it will fall back to “Everwood/develop” instead.


The third and last server (currently) is CITestServer. Like CIBuildServer, it runs on its own instance (or instances, although we only run a single one currently). What CITestServer does is wait for builds to finish, and then grab the “dedicated” installer off S3, run it, and apply our suite of tests to it. As with the builds itself, statuses are reported back to CIMainServer, which can post to Slack, send push notifications, and keep track of test results and their evolution over time in the database.

By default, we run tests for the latest new build of every single-word branch (i.e. we’ll test “develop”, but not “develop-feature-x”) that’s new when the test server becomes idle. Tests can take a long time, in many cases longer than the actual product builds, so it’s not uncommon for – say – three consecutive builds to run, but only the first and the last to get tested. Testing times are also what lead us to compromise and test sub-branches such as “develop-feature-x” on demand only.

Our tests once again leverage Train, and a testing infrastructure called “Afterhours” that lets us run test suits created using various different testing frameworks (such as NUnit/XUnit on .NET, DUnit on Delphi, JUnit on Java, as well as of course our own EUNit), as well as some domain-specific test runners we have for Elements, and collect all their results in a standardized manner.


Final binaries, as well as log files from builds, tests and even prerequisite installs are all published to S3. The beauty of S3 is that it’s fairly fail-over resistant, and very accessible.

For giving our staff access to the builds as they get done, we have a few pages on the Staff portal on our website that monitor the respective S3 buckets and offer the files in them for download. This works based on the same infrastructure we use for the public and licensed downloads that are available from our website for you, the only difference being that we skip CloudFront, and just chose a S3 bucket location that’s closest to the bulk of our team, to give the fastest possible download speeds.

Publishing files for our customers (for releases, beta builds, and sometimes one-on-one to your Personal Downloads folder) is as easy as moving the files from one bucket to another (which we currently do manually as needed, but could automate in the future, if we wanted to). We can also give select customers “Fire Hose” access to all the builds that CI2 emits.

S3 offers automatic cleanup/maintenance functionality that we use to move older builds off to Glacier, and eventually delete them (except for the release builds we of course archive, we don’t really need each of the 57 Elements builds that ran yesterday for more than a couple of weeks).


So that’s our CI2 system, as it’s currently in use. We’re fairly proud of it, and very happy with how it works and what it provides for us, so it is a bit of a shame that right now it is purely internal and not many people outside of RemObjects get to see (or use) it – even if you do get to see and use the products it generates.

Who knows, maybe we will change that one day and make CI2 available for general use, be it as open source or as product. The main thing stopping that is that while the system is very flexible and configurable, it does still have a lot of “RemObjects-isms” – little bits and pieces that are made to work exactly how we need it, but aren’t precisely how everyone else would want it. And of course, it being used internally only, it can be pretty rough to set up and configure in places (for example, we add new products/repositories so seldomly that we have no tool for it, but simply add a new row to the database manually ;)).

But whether CI2 will ever see the light outside of our virtual halls or not, I hope you found this an interesting read, a good look behind the scenes of how we work here at RemObjects. And maybe it gave you a couple of ideas for your own build infrastructure.

At the very least, make sure to check out Train, our awesome build script engine. It’s open source and completely free – as is the .NET JavaScript engine that drives it.

Let me known what you think!


Profile photo of marc

by marc

WWDC 2015 and Elements

June 15, 2015 in "Silver", Fire, iOS, Mac, Nougat, watchOS, WWDC, Xcode

It’s been another exciting year at WWDC, even though i personally did not make it out to San Francisco this time. But staying home also has its upsides, as it means I had lots of time to dive into what’s actually been released.

As always there are many things new and coming in the Apple ecosystem that affect our Elements compiler, and with that Oxygene, C#, Silver and of course Fire. Let’s have a look.

New SDKs

Like every year, WWDC brings new editions of OS X and iOS, namely version 10.11 and 9.0. This time around, these new SDKs add not just new functionality (of which there is plentiful), but Apple also made some pretty drastic changes to the API headers, mostly in service of better inter-operation with Swift.

Because most of the headers use new Objective-C language features, such as annotations of nullability and (limited) generics, the new SDKs do not cleanly import with our current FXGen tool. After all, FXGen cannot know about new Objective-C syntaxes that just shipped.

But worry not. Myself and the team have been hard at work this week to update everything, so with the new Elements beta build we will post today (and the new official 8.1 update release coming next week), the new SDKs now import fine and are fully usable – including all the new frameworks and APIs. So get coding!

We’ll continue to work on the import so that for the next release (Elements 8.2, which goes into beta soon), we’ll be able to leverage a lot of the new information these SDKs headers now expose, which will allow us to represent Cocoa APIs even better in Silver, C# and Oxygene. For example, APIs will reflect the more accurate nullability information that’s now available, making them easier to deal with – especially from Silver.


Now, in addition to new iOS and OS X SDKs, Apple also shipped a third, brand new platform SDK: watchOS. On the SDK level, watchOS is very similar to the existing SDKs for Mac and iPhone – it’s just a bunch if frameworks.

In fact as part of the new work on the importer, the watchOS 2.0 SDK is already importing fine, and our compiler is already happily building against it. But of course fully integrating Watch support is more involved – there are many parts of the toolchain and the IDEs that we need to review and expand. Working on this will be a high priority over there next couple of months as watchOS gores thru the betas, and we plan on shipping watchOS support in Elements 8.2 in the Fall (and of course make it available incrementally in the betas, prior to that).

Swift 2.0

The third and last big thing to mention is of course Swift. At WWDC, Apple introduced Swift 2.0, which brings many cool (and some awkward) improvements to the language. Like with version 1.0, there’s a lot tom like here, but also some things that have us scratching our heads in terms of syntax choices ;). But in general, we’re very happy with how Swift is evolving.

Of course we already started on bringing Silver, ur implementation of Swift for .NET, Java and Cocoa, up to speed with the latest language changes. Some parts were easy to do, while others require some more thought.

For example, Apple added ”Error Handling” to Swift, but it is very different from exception handling as it is needed on .NET and Java (and supported in Silver via a Language Extension). We have some cool ideas hewn to integrate the two in a way that’s convenient and intuitive, but we’re still fleshing out the details.

We’ll be working on adding Swift 2.0 support over the course of the next couple of months, as part of Elements 8.2 (and remember that Swift 2.0 itself is in beta right now as well, and bound to change more between now and the time Xcode 7 ships. In fact, in there WWDC sessions Apple was already talking about features not in the current beta release yet).

We’ll update a page on our documentation site with progress on Swift 2.0 support as things move forward.


Let us know what you think. And make sure to check out Elements, if you have not already!

Profile photo of marc

by marc

“Under new Management”

June 9, 2014 in non-tech, RemObjects

On behalf of all three co-owners of RemObjects Software, I am very pleased to announce that we have chosen Steve Scott (“Scotty”) to serve as the new Chief Executive Officer (CEO) for the company.

I have known Scotty personally for many years, and he has worked with us for the last 7 months as a developer evangelist. In that time, he has shown an excellent strategic understanding of both our business and the industry that surrounds it. When it came to choosing a new CEO, Scotty was the obvious choice, and we are very excited about this change.

As one of the many benefits of welcoming Scotty to this new position, it frees me (the CEO until now) to focus more tightly on the technical side of the company, both across our current line of products (including Elements and Data Abstract) and for future technical direction development. Our upcoming “Fire” product later this year will be the first to benefit from this additional technical attention.

We feel that with this new structure, RemObjects Software is now in an even better position to move on to the next level as a company that provides high quality and industry-leading software tools to developers who care about getting it right.

marc hoffman

Profile photo of marc

by marc

Xcode 6, iOS 8, Yosemite, Swift, and You

June 4, 2014 in Data Abstract, Elements, RemObjects C#, WWDC

As you’ve probably heard by now, Apple release a whole lot of goodness for developers on Monday. As an Oxygene or RemObjects C# (or even a Data Abstract for Cocoa) developer, you’re probably asking yourself how these changes affect you.

Obviously, there’s a lot of things we cannot talk about yet — in part because it’s been less than two days since the new stuff was announced and we need to do a lot more research — and in part because many of the details are under NDA, and will remain so until Fall.

So, what can we say?

iOS 8 and OS X 10.10 Yosemite SDKs

The new SDKs import fine with the latest Gamma build of Elements that’s available to licensed users, and they will import fine with the imminent June release (based on that Gamma) that is coming later this week.

Why do you need a new build? Two reasons: We expected OS X 10.10 to not import with the previous version, simply because the internal integer versioning system Apple uses for OS X was reaching a conflict at 10.10 and our importer wouldn’t know how to calculate the right version code, until we looked at what Apple decided to do there. So that is broken “by design”. There were also a couple of small oddities in both 10.10 and 8.0 that our importer didn’t handle (basically, some Objective-C construct that was too weird for us to run into it sooner). Those had to be fixed.

In general (and moving forward) we aim for new Beta SDKs to import clean with current/previous Elements builds, w/o requiring action from us, of course.

Xcode 6

With the new SDKs imported, Oxygene and RemObjects C# work, as far as we can tell in our limited testing, fine against the new Xcode 6 command line tools, besides some issues with the Simulator APIs, which have changed pretty significantly in version 6.

If you run into any problems, remember that you can always change the version of Xcode that Elements sees back to Xcode 5.1, using the xcode-select tool, without needing to de-install Xcode 6. So you don’t need to hesitate about installing Xcode 6.

Of course we need to and will do more testing (especially on some of the areas with new features) to get Xcode 6 fully supported by the time it ships.


Of course the big announcement on Monday was Swift — Apple’s new programming language that’s destined to replace Objective-C in the long (or even short) run. It’s very exciting to see Apple take this step, which frankly I had been expecting – but not quite so soon, and not with such a drastic change in language style (Swift is *very different).

Swift opens up a lot of opportunities, but also challenges. On the one hand it “competes” with our Oxygene and RemObjects C# compilers for the spotlight of “more modern languages on Cocoa”, but on the other, it also opens developers up to the very idea that Cocoa does not have to mean Objective-C.

There’s also a lot of technical work for us to do. Swift does not compile to straight Cocoa objects, but brings its own object layer and APIs that Oxygene an RemObjects C# developers will want to interact with, and there’s work needed there — work that I can’t talk about in more detail, because much of Swift is covered by the Apple NDA until it is released. Of course we are fully committed to making this work, so that you can use code written in Swift as seamlessly from Elements as you can use the code written in Objective-C today.

If you’re a Data Abstract or RemObjects SDK for Cocoa developer, you’ll probably just want to use those libraries from Swift. This should just work out of the box, because Swift and Objective-C already mix and interact seamlessly in Xcode 6. Of course we’ll do a lot of testing on this front, see if maybe RO/DA can use some API revisions to make it work even better with Swift, and we’ll be providing project templates for Swift once Xcode 6 ships.

I will keep you updated as things develop. For now, I’ll let you get back to playing with the new toys!


Profile photo of marc

by marc


April 14, 2014 in non-tech


The Heartbleed vulnerability found in OpenSSL last week has everyone worried, and rightfully so. So of course we did an investigation and wanted to let you know the status of how Heartbleed has affected us and, by extension, you as our customers.

In short, it hasn’t, and everything should be safe.

Our servers run a combination of Windows Server, Linux, and even Mac OS X Server. Thankfully, we found none of our server software to be running OpenSSL versions that were affected by Heartbleed. On top, our customer-facing website is running on Microsoft IIS (using ASP.NET and Oxygene) and thus not using OpenSSL to begin with. This is the site that all logins (including for direct website login, but also for Single-SignOn to services such as Talk, or for license downloads from within products) go through, as well as all payment information when you place orders. (On an unrelated note, we want to point out that we never store your payment information. It is passed through to the merchant as you place an order, but your credit card details are not retained by us.) We have received no information from our back-end merchant services provider to indicate they have been affected by Heartbleed.

Our Products are not directly affected by Heartbleed either. Only RemObjects SDK for Cocoa used OpenSSL under the hood until about two years ago, but the library was used only for purposes of the “AES Encryption Envelopes” feature, which does not cover the surface area of the Heartbleed exploit. In addition, RemObjects SDK for Cocoa was migrated away from OpenSSL to Apple’s CommonCrypto library about two years ago, so any applications built with recent versions of RO/Cocoa does not leverage OpenSSL at all.

Standalone RemObjects SDK or Data Abstract Servers implemented in .NET and running over HTTPS using Microsoft’s or Mono’s HTTPS base implementation (pretty much the standard/default if you are running a .NET based RO/DA server and did not go out of your way to hook up a custom SSL layer) are not affected by Heartbleed. Neither are applications hosted in Microsoft’s IIS web server and using Microsoft’s SSL/TLS stack.

That said, if you are deploying RemObjects SDK or Data Abstract servers via HTTPS, we still recommend that you review the parts of your tool stack that fall outside of RemObjects SDK and Data Abstract itself. For Example, Delphi’s Indy libraries optionally use OpenSSL to implement SSL/TLS functionality, so depending on what version of Indy you are using, and what version of OpenSSL you are using with it, your application might be affected by Heartbleed. The same may be the case if you are hosting RO/DA service applications on a web server such as Apache that might be using OpenSSL under the hood.

We will continue to be on the lookout, and keep you informed if any new information arises.

Profile photo of marc

by marc

“Steps” for iPhone 5S — written in Oxygene

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


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

Profile photo of marc

by marc

Come See Brian Long Talk about Android Development with Oxygene at BE-Delphi

October 7, 2013 in Events, non-tech

I’m told that our friend Brian Long will be giving a presentation at BE-Delphi’s annual developer event in Antwerp, Belgium, on November 21.

Brian is a great presenter; we had the pleasure of having him as a guest speaker at DSConf and he has presented on Oxygene for Android and iOS in the past — so if you’re anywhere near Antwerp in November, make sure to check out his talk, and the conference in general.

From Brian’s session summary:

Oxygene is an Object-Pascal based language previously well know in its .NET incarnation as Delphi Prism. Oxygene for Java produces Android apps that run where Android does – in Android’s Dalvik VM. It is for those who have a background in Delphi or a history of Pascal programming from previous times, or anyone who fancies something a bit different from Java, and who wants to use the standard Android APIs in the Android SDK to build lightweight, standard Android applications (or, for that matter, Java applets, servlets, etc.) that can run on any Android device of your choosing.

We’ll look at Oxygene for Java’s capabilities and features in the context of building and deploying an Android application using OS-native controls. We’ll see how the product works, bump into some enhancements to the evolving Object Pascal language and show that Oxygene for Java is a first class citizen in the world of Android development.

You can find out more about BE-Delphi at

Welcoming the new RemObjects Software Developer Evangelist!

October 1, 2013 in non-tech

RemObjects is very pleased to welcome Steve Scott (aka “Scotty”) to the post of Developer Evangelist for the company!

ScottyScotty brings a wide range of skills to the table, as his CV shows:

Steve Scott  has  been a  developer for 26 years. He started as a developer in 1987, when he was writing accounting software using COBOL on a Convergent Unix machine using vi as his code editor. Since then he has worked on mainframes, minis, 16bit and 32bit Windows (C++, Paradox and Delphi), .NET (C# and Visual Basic), OS X and iOS (Objective-C and Cocoa). During his career he claims to have worked on more hardware and learnt (and forgotten) more languages and IDEs than any sane man should have to.

During the late 1990s he was an active member of the Delphi community spending some time as the technical lead of the UK Borland User Group (UKBug), as well as being the technical lead for the popular DCon conferences and a regular speaker at BorCon.

As the 21st century took hold, he made the move to .NET and became a respected speaker at many .NET conferences around the world.

In 2007 he jumped ship and headed into the world of Apple to work on Mac and iOS software. In this new world he became the founder of the iDeveloper Blog, host of the iDeveloper Podcast and creator of NSConference.

Scotty will be focusing on improving the user-facing side of the company – work on bringing our products to the attention of more developers world-wide, improving accessibility and discoverability for new users, and working with the teams on enhancing the over-all user experience. You can also expect some more RemObjects TV and Radio in the near future, as well.

Outside of his responsibilities at RemObjects, Scotty will continue to be an asset to the developer community at large, thru his other projects such as the iDeveloper site and podcast, and NSConference.

Android resources

September 20, 2013 in Elements, Guest Post, Java, Oxygene

For those Pascal programmers looking at building Android applications, be it with Delphi XE5 or with Oxygene for Java (I work with both!), here are a few Android-related resources that may come in useful:

  • Google’s Android Device Manager – if you mislay your Android device this allows you to locate it on a map (if it’s got a data/WiFi connection) and also ring it (presumably if it’s a telephone – I haven’t checked whether this option does anything on a tablet). Clearly this is similar to Apple’s Find My iPhone functionality.
    [Update: Jim confirms that tablets will happily ring too]
  • Using remote Android emulators – because Android emulators emulate the device CPU they can be hideously slow, and basically unusable in a VM. If your dev tool runs in a VM then it can be useful to communicate to an Android emulator (technically called an Android Virtual Device or AVD) either on the host machine or another machine on your network. This is a useful technique entirely independent of your chosen development tool as it revolves around how your local adb.exe communicates with the emulator. This post by Jim McKeeth runs through how to set this up using SSH. You can also find a write-up in the Delphi online documentation.
  • If you are using Oxygene for your Android development you may want to look at setting up your AVD to use an x86 CPU, potentially taking advantage of Intel Virtualization Technology via Intel HAXM (Hardware Accelerated Execution Manager) to provide VM acceleration. Delphi developers cannot take advantage of this because Delphi targets the ARMv7 CPU.
  • App testing across many devices. The Android emulator has long been held up as pretty much the only way of testing your app across the range of form factors that different devices can offer. Now it’s not the only option though, as Apkudo for Developers offers developers a free online app-testing platform where your app will be tested on over 260 different Android devices. Just upload your app to the queue and a report will be sent back when the tests have been run.
  • Since Android’s Ice Cream Sandwich release introduced the Roboto font as the default, you may want a copy to install on your machines. You can download it from the link in the blue box here (or this is the direct d/l link).
  • Google’s sample icons pack can be downloaded with this link.
  • For anyone who does presenting it can be very useful to have a means of showing on your computer screen what your device is doing. There are various VNC-based solutions for this out there, but Jim McKeeth has built a simple solution using repeated screen-captures called Android Screen View. You can download the source code for it here or pull down a build here.
  • The Android dashboards show you the percentage of devices sharing various characteristics as obtained from the Google Play store. All the devices in question will be running Android 2.2 (FroYo) and above.
    This device breakdown can be useful to decide what OS and form factor to ensure you support.
    On the dashboards you can see the breakdown of:
    • Android OS versions
    • Screen sizes and densities
    • OpenGL version
  • If you have a nose that needs to be poked inside everything, consider pulling down the Android source code. Information on how is available here.
Profile photo of marc

by marc

Embarcadero Prism to Oxygene License Migration

August 15, 2013 in Elements, non-tech, Oxygene

form Prism to Oxygene

Dear Embarcadero Prism Customers,

we want to thank you once again for choosing Oxygene for your .NET development needs in form of Embarcadero Prism.

As you might have already heard, our collaboration and reseller agreement with Embarcadero is coming to an end, and starting with our next upcoming release Oxygene for .NET will be available exclusively from us at RemObjects.

We can assure you that the product itself is alive and well, and with or without Embarcadero we are looking towards a bright future for Oxygene – on .NET and on the other platforms supported by the Oxygene language.

The end of our agreement with Embarcadero, however, means that starting with the upcoming Oxygene 6.1 release the product will stop accepting Embarcadero “Sanctuary” serial numbers, and we’ll be switching all customers over to our own unintrusive, no-nonsense licensing system.

Embarcadero Software Assurance

We do realize that many of you have purchased Software Assurance with Embarcadero in good faith that it would continue to include Prism.

Because we believe in treating our customers fairly, we have decided to fully honor any SA contracts between you and Embarcadero that have been purchased or renewed before April 22, 2013 (the date when Embarcadero announced its discontinuation of Prism) on our own dime, and you will continue to receive free updates for the remaining period of your SA from us.

In order to get you set up on our side, we kindly ask you to do two things:

  1. If you have not already done so, please make sure to register your latest XE3.2 serial numbers with us at We will use these registrations to keep track of customers with (potentially) active SA.
  2. Please send us an email to with details about your current SA contract, including when it was bought or renewed and when it expires. Based on this information, we’ll set you up with the appropriate Oxygene for .NET licenses in our system.

If you have active Software Assurance for RAD Studio XE3 or Prism XE3, and you have not received an XE3.2 serial number, please reach out to your contacts at Embarcadero (and feel free to include in CC for your communication, so we can also follow up on our end) to ask them for your XE3.2 key.

We do apologize that we need to ask you for these manual steps, but unfortunately we receive no information or details about Prism users and their SA contracts from Embarcadero, so the only way we have to move you into our system you is by you contacting us.

Renewals, and/or moving to the full Oxygene Package

If you do not have Software Assurance, or your SA ends before August 23, 2013, we have attractive renewal options explicitly for Prism customers that will let you upgrade/renew to our full Oxygene package — with Oxygene for Cocoa, Oxygene for Java and of course Oxygene for .NET..

We have emailed everyone who registered their Prism serial number with us with the details for this today.

If you have not registered your serial yet, but are going to do so, we will email you once we received your registration. If you have any questions, or for some reason cannot register your serial number (maybe because you’re on Prism XE or later, which we don’t accept serials for), please just email with your details, and we will sort you out as best as we can.

Exciting Things Ahead

We’re very excited about the things we have planned for Oxygene (and Hydrogene) moving forward. The imminent 6.1 release contains some very cool features that many of you have been asking for, including initial support for Refactoring (that we’ll build upon further going forward) and other IDE and language enhancements. And we have more exciting and more groundbreaking things planned for the rest of the year and for 2014.

We hope that you will continue to put your faith in us and in Oxygene, even without Embarcadero. Prism, and the Oxygene Language, always have been 100% driven by us at RemObjects, and it will keep getting better and better.

We’re looking forward to having you along for the ride as we move ahead further.


marc hoffman
Chief Software Architect
RemObjects Software