Profile photo of marc


Prism XE4, Where Art Thou?

April 17, 2013 in Elements, Oxygene, Uncategorized

Update: (May 26, 2013) We have an official FAQ for the migration of Prism licenses to Oxygene available now at Also updated pricing references within the post to reflect current pricing.

Ok, so the cat is out of the bag, if a few days ahead of schedule: starting with the upcoming release of XE4, Embarcadero Prism will no longer be part of the RAD Studio SKU, and there will be no “XE4” branded edition of Prism.

But worry not. As you all know, Prism has been nothing more than a re-branded version of our Oxygene for .NET product — and Oxygene will keep going on, stronger than ever.

In fact, Oxygene has long outgrown its Prism-branded edition, first when we introduced full native support for Java and Android to the language over 18 months ago, and of course with our upcoming support for truly native iOS and Mac apps, shipping next month.

So “Embarcadero Prism” as a product is going away, but the Oxygene language you have come to love and depend on will continue to shine and evolve, as it always has.

What exactly does all of this mean?

We believe that in the end, this change will be a net positive for Oxygene.

When we first started working with Embarcadero in 2008 to bring Oxygene 3.0 into RAD Studio, Embarcadero had a gap left in their lineup with the discontinuation of their ill-fated Delphi for .NET product. Both companies shared a vision of Delphi and Oxygene — then getting branded Delphi Prism — becoming two sides of the same coin: two languages evolving together and influencing each other to push Pascal forward both for CPU-native Windows development and for managed targets.

Over the years, it turned out that this was not happening, and as Embarcadero was shifting their focus to “(CPU-)native, native über alles” and onto FireMonkey, Prism (and with it Oxygene, as i’m going to start referring to it from now on exclusively) became the odd man out — the product that was there, as part of RAD Studio, but no-one liked to talk about, because it did not really fit the vision of the company.

This became clearer as Oxygene evolved.

We added support for Java and (more importably) Android, but Embarcadero had their own (very long term ;) vision of how they wanted to pursue the platform that conflicted with what Oxygene had to offer. As a result, Oxygene was forced into a split personality — with Oxygene for .NET remaining under the Prism umbrella, and Oxygene for Java becoming a separate product (for a while).

At the same time, Embarcadero became less and less interested in actually marketing and promoting the product, and it was being relegated to a “filler” to pad up RAD Studio as a worthwhile product suite.

Things got even more complicated when we started working on “Nougat”, our vision for really and properly bringing Object Pascal and Oxygene onto the (misleadingly named) Objective-C runtime that is the engine behind iOS and Mac. Once again, Embarcadero had different plans for the platform, and what is more, they — understandably — raised the concern that Oxygene for Cocoa would be too direct a competitor to their efforts on iOS (albeit once again our two companies were following two very different visions).

To wrap things up short and sweet, as of right now, Oxygene is finally standing on its own two feet again.

During the five years of partnership, RemObjects Software has always been the sole technical contributor to the core Oxygene product, and having Oxygene “back to ourselves” really just means one thing: that we can, more aggressively and consistently, continue to drive the product on all three target platforms, according to the vision we have for it. And trust me, we have some amazing things planned for 2013 and 2014, with “Nougat”, our Mac and iOS support, only being the tip of the iceberg.

What does this mean for existing customers?

Worry not. We have every eventuality covered.

First of all, if you already bought Oxygene directly from us or one of our reseller (i.e. without an Embarcadero serial number), none of this will affect you at all, you’re already set.

If you’re an Oxygene user from the Embarcadero side of the fence, now more than ever, make sure you register your XE2.x or XE3.x serial number with us. This way, we know about you and can take care of you moving forward.

If you have registered your XE3.1 serial, you can take advantage of our special renewal price for Prism customers and renew to a full Oxygene package licensed directly from RemObjects Software, for only $499. Remember, this not only renews you for future updates to Oxygene for .NET (the product you have now), but it also gives you the Java/Android and Mac/iOS targets, as well!

If you have active software assurance (SA) with Embarcadero that covers Oxygene, that will of course be honored. Up until August (i.e. one year from when XE3 shipped), you will continue to receive the latest updates to Oxygene for .NET from Embarcadero. This will (assuming your SA is still active at the time) include the upcoming major 6.0 release, next month.

Once your current SA expires, renewing it will not include renewed access to Oxygene, but you can use the link above at any time to renew to the full Oxygene package from us. (Note that the current renewal price of $349 is a special offer and will increase slightly once “Nougat” ships next month.)

It’s probably unlikely that you’re buying RAD Studio XE4 “fresh” without already being an existing RAD Studio user, but if you do, i’m afraid you will not receive “Prism XE4” as part of it. You (and every other Delphi user) can use our special cross-grade offer to purchase a full Oxygene package from us, at $599 (this is also a special offer, and the price will increase slightly once we ship 6.0 next month).

In Summary

As the old saying goes, The King is dead, long live the King! Embarcadero Prism is no more, starting next week, but Oxygene is going stronger than ever.

We, and i personally, are incredibly excited about Oxygene, and about the things we have planned thru-out the rest of the year and beyond. We can’t wait to walk down the road ahead with you.

marc hoffman
Chief Architect & Oxygene Team Lead
RemObjects Software

82 responses to Prism XE4, Where Art Thou?

  1. Thumbs up, Marc! :-)

  2. Marc,
    I am interested, but where can I find licence no. of my RAD Studio XE2 ?

    • i’m not sure where you kept it ;). You need the serial key that you also use when installing Delphi (or Prism). It’s like 4 blocks of 4-6 numbers and letters.

  3. Great timing, too! I’m reaching the end of a commitment, so I’ll FINALLY be able to continue to persue the interests I started with Oxygene :D

    • Excellent! We’ve missed your input on the Nougat beta. get testing now ;)

      • I’ve missed testing the Nougat beta! Actually, I’ve missed being able to do ANYTHING FUN ever since I had to install Windows 8 ;)

  4. Can you name some android and .net apps built with Oxegene that I can download to checkout ?

    • Guess not. Here an easy one. Does it work with Devexpress components ?

      • While i have not used DevExpress’ASP.NET components particularly, myself, i see no reason why they should not work with Oxygene. As i explained in one of the other comment branches, the great thing about Oxygene is that it works directly with the underlying platform. .NET is very language-agnostic on top of that, so as a general rule of thumb, any well-written third party component will work with *any* .NET language — whether C#, Oxygene or Boo.

    • Rob,

      My apologies for not getting to your post yesterday. We have a couple of case studies up at, and we are working on more; we also working on a gallery. For android specifically, two prominent games in last years Pascal Game Developer’s challenge, including the winner, were written in Oxygene for Java. On the iOS front, we already have two of our own (or rather, my personal) apps in the App Store (i blogged about them over the past couple of months), even though the product is still in beta.

  5. So how does Oxygene compete with Xamarin? The both seem similar from what I can tell, using .NET to build apps for iOS or Android. Of course the languages are different (C# vs Object Pascal) and Oxygene seems to support more platforms, but the mobile platform is what I am most interested in.

    • Oxygene doesn’t use .NET to build apps for iOS or Android.
      In fact, Oxygene for Java compiles directly to Java, and can consume Java binaries directly. There’s no “cross-compiling” here, Oxygene compiles directly to the platform (so Oxygene for .NET compiles to .NET, Oxygene for Java compiles to Java, and Oxygene for Cocoa… you get the idea)

      • @Simon,
        I am still wating for your L4D, :-) I’ve supported it.

        • That’s the aforementioned commitment… but I’m not going to derail Marc’s thread by discussing it in here. If you’re on Google+, you can find me there and I’ll go into detail!

        • if that was Lua4Delphi, then after it disappeared there another project starter, though it only targets pre-Unicode Delphi

    • Simon already hit the sweet spots in his reply, i think.

      Language aside (All of the Xamarin stuff will also work with Oxygene for .NET), the main difference is that Xamarin’s targets all platforms via .NET. You are always coding against the .NEt framework, and wrapper/bridge classes for the underlying platform frameworks (e.g. the Android or Cocoa libraries). This certainly has some benefits (the level of generic code that can be shared across platforms is bigger, because you have the core .NET classes everywhere), but the main downside in or book is that it still separates you from the platform. You can’t use the new classes in the iOS7 SDK the day Apple makes the beta available. You can’t use any random third party Java or Cocoa library you find online.

      Oxygene, instead, compiles straight to the underlying platform, and against the frameworks of the platform. When you’re building for Java or Android, you directly reference, say, the .jat files that make up the Android class libraries, and your resulting output is a .jar executable, indistinguishable form what a Java-language developer would generate with the “official” compiler. The same is true on Cocoa. you work directly against the frameworks Apple provides (or any other Objective-C libraries out there); you directly descend from or work with NSObject, UIButton, etc. And the executable you are building will participate directly on the Objective-C runtime; there’s no bridging.

      In essence Oxygene is “just” another language for the JVM or for the Objective-C runtime. It sits at the exact same level as the “official” languages — Java or Objective-C — do, and has the full power and access they have, without compromises. (in addition to being a lot more powerful a language ;).

      Does that make sense?

      • I cannot agree with you with ” You can’t use the new classes in the iOS7 SDK the day Apple makes the beta available. You can’t use any random third party Java or Cocoa library you find on-line.”. In case of SDKs will xamarin deliver the bindings really soon. In case of custom libraries you can develop the bindings yourself. Xamarin has advantage of using .NET Framework which enables easier developing platform independent libraries (PCL). Remobject can easier user platform and platform libraries.

        Two approaches one goal. Use what you need.

        I don’t either xamarin and oxygene.

        • Ladislav,

          feel free to disagree, of course. The point is, Oxygene can use these SDKs and libraries *without* anyone having to create bindings for you, whether it’d be us or you yourself. With Xamarin, you *are* dependent on getting bindings from them — and while i grant you that they have been reasonably (impressively) fast in providing thosebindings on the same day as the SDKs RTM, i can also guarantee you they will not have them on the day the SDK comes out as beta, because until that day, *no-one* outside of Apple will have seen those SDKs. The same is the case for Delphi (minus any track-record to show us how fast new features and libraries will be made available, since Delphi’s abstraction is on a level that’s way higher than Xamarins. With Oxygene, you can use the beta SDK the second you get your hands on it.

          I give you that Xamarin using .NET on all platforms does give it a higher level of code sharing across the platforms. That definitely is a point in their solutions favor — at other costs, of course.

          FWIW, i’m a big fan of Xamarin, and i think they are doing great work. We use and rely on Mono for a lot of our server-side development. Half of our company infrastructure runs on services written in Oxygene and running on Mono. (and Oxygene for .NET actually works great with all parts of Xamarin’s tool chain, including their Android and iOS targets).

  6. This is good news! But first buying AnyDAC to the chagrin of other 3rd party component vendors, calling FreePascal a competitor despite using it for XE2, now believing RemObjects is a competitor… Embarcadero really doesn’t know how to make friends.

    I look forward to see what comes out going forward with Oxygene back completely in the control of a company that seems to have a “kinder, gentler” approach to their customers.

    Were there any constraints before in regards to ways you wanted the language to develop that weren’t allowed but now you will be free to? And in a more general sense, what is the balance of priorities regarding language improvement vs. Delphi compatibility (is that even a major concern)?

    • Code *sharing* with Delphi (i.e. letting you maintain one active codebas that will compile with both) is a secondary concern for us, TBH. Our main focus is on making Oxygene great, and on making it easi(er) to share code between the three Oxygene platforms. When it comes to Delphi, we’re mostly looking at improving ways for you to import/convert existing code to Oxygene more easily, with tools such as Oxidizer (which lets you adjust many of the smaller language differences automatically, when getting Delphi code into your app).

      The main part that makes sharing code between Oxygene and Delphi tricky is not the language, anyways, it’s the different libraries and frameworks — Delphi has the RTL and VCL, that’s deeply intwined in most Delphi code, and that’s the part that won’t easily be sharable without loads of IFDEFs that make sharing the code more work than just keeping to code bases (if the Delphi code base iss till needed, as well).

      The same is true, to a degree, for Oxygene between the three traget platforms — .NET, Cocoa and Java. We’re working on our Sugar open source library there (which will go into public beta next month), to provide a set of common base classes (sort of what the RTL is in Delphi) that can be shared across the three targets *and* be toll-free bridged (and toll-free castable) to the actual framework classes. IOW, you’ll be writing generic code that works with, say, a Sugar.Dictionary and a Sugar.HttpConnection. But under the hood, it’s really compiling down to code that uses a Systems.Collections.Generic. Dictionary, when compiling for .NET, and an NSDictionary when compiling for Cocoa. The idea is that you’d be suing Sugar *only* for the back-end pieces of code you want to share across platforms, and write truly platform-specific code for the UI, and other places where it matters.

      It would be cool if we could provide a version of Sugar for Delphi as well, i suppose. But Delphi lacks a crucial language feature that Sugar is based on, Mapped Types. (That said, with Sugar being open source, maybe someone form the community would be interested in creating a pre-Delphi implementation of the Sugar classes).

      • I am now super interested in nougat because I just read the Xe4 do wiki and ios Delphi strings are zero based and immutable. Wat? Please tell me oxygene string semantics are not this different from classic pascal and I will love Oxygene forever. It’s not just code sharing that breaks when you pick new semantics. It’s developer brains that melt.

        • Warren,

          sorry to disappoint you on this oe front, but Oxygene has zero-based, immutable strings — it has from day one, and that’show the natie strings behave on all the platforms we support, .NET, Java and Cocoa.

          The “Sugar.Legacy” library (which is a project on top of Sugar for providing some Delphi/RTL-style APIs) as a 1-based mutable string as a mapped type that can be sued optionally (once Sugar,Legacy is there). But i’d not suggest that as a general purpose “solution” for this.

          You’ll be surprised how easy you get used to strings being immutable, and that it’s really doesn’t make the code harder or less elegant, as one might think initially.

        • ps: i posted a reply on your blog post too (or tried); i’m not sure if it went thru and is just pending approval, or if it got lost in the void, as i didn’t get any sort of confirmation when i submitted it, the text field just went blank again…

  7. Great! Just want to confirm the Nough will be pulic released next month?

    • Barring ay unforeseen showstoppers or mishaps, we’re planning for the “May 2013” release to be Oxygene 6.0, which will be a major release for both .NET and Java, and also be the first release to include the new “for Cocoa” targets as well, yes. So far, things are looking really good and i think we’re well on track — but i don’t want praise the day before it’s over, as we say in german.

      Of course like with all our products, May/6.0 will not be a monolithic release, and we’ll continue doing monthly updates (and we’re already planning and scheduling for the June release ;)

  8. Good news Marc. It was only a matter of time and came as no surprise.

    We’ve been a Delphi RO SDK user for many years now and we took the decision a couple of months ago to commit to Oxygene and probably Hydra for our future windows platform development.

    As I posted elsewhere it’s also telling that we see the future with Nougat for iOS and not FireMonkey. The continual “bad air” around the Delphi eco system combined our own gut feelings coinciding with many of your postings on native platforms have led us to this position.

    Personally I can’t muster any enthusiasm for the upcoming XE4 whereas your direction feels right. The protracted issues with Delphi haven’t helped their cause either, from the 64 bit trials and tribulations to the reported FireMonkey quality / bloat and the perceived hire and fire mentality of Embarcadero.

    Good luck with the upcoming release, I am looking forward to getting stuck in to Nougat later in the year….

    • Thanx, Paul, for the trust and confidence, we won’t let you down. Please help us spread the word!

      • AS. hmmm, blog engine is better be enhanced. I just lost few minutes of text. I got some mail-related error, and when i pressed “back” buttons and pressed “Reply” all the text was gone. Some JScipt was too eager to delete everything i typed…

        Well, is that Sugar-related thunder worth it ?
        Delphi/Kylix has RTL, FPC has RTL, Apache Runtime project, Qt, GLibc, C++ standard libraries, Scala Runtime (using to compile for CLR)…. Sugar just looks one in a row. Every language has RTL, now Oxygene has too. Just so story,

        If Sugar is so unique, beyond compare with all other RTLs that it is worth all the fanfares, i hope there would be really convincing tech articles on topic.

        • Damned if you don’t, Damned if you du, huh? On the one hand, we have people complaining that Oxygene doesn’t do enough to abstract the three platforms completely, on the other we have people complaining that we try to provide any optional abstraction at all.

          For one, Sugar is an option, only. You would only use of for code that you specifically want to keep cross-platform. If you set out to write JUST an iOS app, or JUST an Android app, you would most likely not touch Sugar.

          For another, what makes it different is that it’s a mapping library, mostly. Ie, you could write a business rule module that takes a Sugar.URL, downloads it, processes it, and returns a Sugar.Dictionary. You can then use this class from your Cocoa code, pas in an NSURL and get back an NSDictionary. The same class, you can use from your .NET-specific code, pass in a System.Uri and get back a System.Collections.Generic.Dictionary.

          Right now, Sugar is still in private beta on github. Once it goes public, we will of course have articles on it, including how to use it and how to contribute to it.

          • Scala RTL is an option – you can directly use Java RTL
            C++ std libs are optional, you can always use OS API, ditto for Qt, GLibc, Apache Runtime.
            Delphi/Kylix/RTL are largely optional, KOL project stripped non-optional RTL to bare minimum.

            Mapping is not very new also, with less or more efforts it can be done on Scala (Scala 1.x did not used IKVM, they tried to map their string to JVM and CLR strings on compiler level). Even in Delphi advanced records it can be done using properties and inline functions and implicit typecasts.

            Perhaps i just saw few fans, who are shambling with burning eyes, and says “You totally must rush and buy Oxygene!”
            “but why?”
            “Because it has Sugar and it would be next best thing, and to get Sugar you must buy Oxygene!”
            “But there is FPC, and it has x-platform RTL, and…”
            “How can you compare? Spaghetti mess, plagued with $IfDefs”
            “And how can Sugar replicate *behavior* without falling to Ifs or IfDefs ?”
            “Oh, it is Sugar, it is Oxygene, it is beautiful!!!”

            It did not help that FMX proponent jumped into the forum and told that as a designer he can easily replicate MacOS look-and-feel and nothing else matters. Well, he did replicated look, static one. But not behavior, not feel. And SWT vs Swing debates touched this for long.

            I don’t question that you can easily map static, one-off, immutable data storage units, like perhaps that copying that URL string from ObjC runtime to Sugar RT. But i have beeeg doubts it is possible to seamlessly replicate behavior by other means than reducing it to largest common divisor.

            Maybe you managed it, dunno. But as of now, it looks as overhyped Oxygene RTL, like if Embarcadero gave RTL a separate name and mentioned it here and there. Are dynamic arrays cool ? Of course. Generics ? Yes. Strings ? Sure. Does it make Delphi RTL worth special branding as anything more than set of routines supporting Delphi language? no.

            Well, i’ll be looking for those articles, why Sugar is so sweet. but from a sceptical side of the rainbow, it frankly looks like just overhyped quite ususal thing. If i am wrong and there are realyl some hidden gems, i would read those article with great interest.

          • Not really sure what point you a re trying to make, Arioch.

            Sugar is, or will be, an optional feature that people cal choose or use or not use. it will provide functionality that some people have asked for, those who don;t want to use it or dont need that functionality will not be forced to use it. It’s not an “RTL” for Oxygene. It’s an independent class library that serves a specific purpose.

            Also, no-one is “rushing” anyone to buy Oxygene. You realize that Oxygene is na time-proven product and language that has existed for what is getting close to a decade, right? We believe Oxygene has a lot of good things it brings to the table. People who like those features should and will use it. People who don’t, should not and will not. It’s like every other product on the planet, in that way.

  9. Oxygene looks good but the one great thing missing IMHO are “components” and the component concept.
    Components are one of the greatest thing Delphi has ever had: drop a few components and you can create an amazingly powerful application in a matter of minutes. Xamarin understand that as they now provides a component store. Unity 3d has a very rich (and profitable) component store too.
    From your web-site, I fail to see any component vendor supporting Oxygene, or any mechanism easing the creation of cross platform components for Oxygene.

    • John,

      Oxygene can use all the components available on the platforms. .NET, for example, has a vast ecosystem of component vendors and open source libraries, and the vast majority of them are not tied to C# and will work with any language. The same is the case (although the ecosystem isn’t quite as vast as .NET) for Java and Cocoa.

      That’s the whole point of Oxygene: unlike other development environments, including Delphi, Xamarin or Unity 3D, as an Oxygene developer you do not live in a tiny bubble where you can only use the components and tools designed specifically for Oxygene. The entire .NET/Java/Cocoa world of components is your oyster.

      • Marc,
        I understand and respect your way of seeing things. This might make sense for many (some ?) willing to spend time for each platform.
        Mine is from a long-time “spoiled” Delphi developer: with limited human resources, time and money (and who has plenty of those ?) I need to be able to create cross-platform applications without worrying about finding the right library for each platform, dealing with differences, updates, learning, bugs for each of them, having to learn more than needed on a specific platform. In that case, I’d rather directly use Objective-C or Java.
        As an example, I need to use DataAbstract, aDevExpress grid or an FTP library and let it be the one responsible to adapt on the platform. I need to have common architecture, methods and properties, not completely different ones.
        It looks like you are doing half the work: you are creating a common language for all platforms, and that’s all. We developers need to understand and investigate each specific platform to build on that language.
        Don’t get me wrong, being close to the platform as you are is a great strength and a valid marketing point. But in the end, I think some might choose a higher level, more abstracted yet faster cross-platform solution.

        • John,

          to be quite blunt, Oxygene just might it be the tool for you then. There are solutions such as Delphi’s FireMonkey out there that aim at letting you write one set of code that runs (badly) on all platforms. We could try and make Oxygene do the same, even if it goes against every grain of what we believe in how things like thuis should be handled — but what woud be the point?

          I think it’s good to have variety our there. Our focus with Oxygene is very much targeted at developers who do want to take the time and learn the platform (and in fact consider it a benefit, not a downside, that Oxygene lets them deal directly with the actual platform).

          It will not be for everyone, and i can understand the allure that “we take care of everything for you” solutions such as FireMonkey or Xamarin offer. But in the long run, its my believe that it will lead to mediocre apps. I’ll be you that the next awesome, featured-on-the-App Store will never, ever, be one created with something like FireMonkey. It will be the ones where the developer really took the time to understand the platform, and crafted a great app that takes into account how the platform works, and what users expect.

  10. I just downloaded Oxygen for Java, but I didn’t find a designer to create a GUI for a Desktop or Android App. So, my question is: How do I design a Desktop or Android App?

    • We currently dont have an *integrated* designer for Android, as for a long time there wasn’t an official one (and Google and most professional Android developers still recommends designing UIs by hand-crafting the XML), but Oxygene uses the standard Android XML layout files, so you can open them in any of the available third party designers. We are looking into providing official designer support more tightly integrated with Oxygene, in the long run.

      • I think “we” Delphi developer need an integrated designer into Oxygen for all three types, in order we can switch easily :)
        As John wrote, the component concept makes Delphi so strong.

        • Change is never easy. Oxygene is not Delphi, and it’s not trying to be a drop-in replacement for Delphi. It embraces some quite different development philosophies, and switching to Oxygene does require a certain openness to learn new things.

          We’re purposely not going the same route for Oxygene as Embarcadero is with FireMonkey. Not to be different, but because we believe out approach will yield the better apps.

          As i mentioned in my reply to John, the ecosystem for components that can be used with Oxygene is *vast*. The very first “learning curve” step you need to take is to get away from the thinking that you need to look for Oxygene-specific components. There will be few to none (and that’s a good thing!). Even our own component libraries for .NET, Java and Cocoa *(chiefly, Data Abstract) are not libraries “for Oxygene”. They ar eLibraries for .NET, for Java and for Cocoa, respectively. An dof course they all work awesomely with Oxygene, but from the library/component designers perspective, that’s secondary, and really something that just comes “for free” with a well-designed .NET/Java/Cocoa library.

          • Just to emphasize Marc’s response…. The *vast* array of libraries available that the Oxygene approach opens up was one of the reasons for our deciding to embrace it and move away from Delphi as our sole tool chain.

            The Delphi 3rd party component provider space has shrunk to an incredibly low level in my opinion. When you look at the few quality providers out there, even they are committing more and more resource to the world outside Delphi and the VCL.

            The world continues to change and even Embarcadero is attempting “something” with its FireMonkey approach. I belive they are being overly ambitiuos and ultimately their endeavours are doomed as they won’t be able to keep up with the pace of change required in the mulit platform world.

            Put that another way. How many component providers do you think will be delivering 3rd party tools for FireMonkey on iOS ? Are you going to be happy with what comes from Embarcadero if little to nothing is forthcoming ?

            By providing you with a language you are familiar with in .NET, Java and Cocoa environments, Oxygene gives you the keys to ALL the 3rd party libraries that are specifically targetted for those platforms. The world can continue to evolve at whatever pace it likes and you will always have access to the latest components and libraries. You won’t be stuck in a slow lane or even grid locked by Embarcadero’s refusal or inability to move things along at the required pace – required by your customers for the latest and greatest button, graph or whatever.

            How many new and “must have” components have Embarcadero delivered for the VCL over the last few years ? The answer in my opinion is no longer to say that is the 3rd party providers fill that space as increasingly they patently aren’t.

            Any developer wants to have the largest target audience for their application so tying yourself to a niche like FireMonkey which isn’t a disruptive enough technology simply doesn’t make economic sense in my view.

  11. Very good. (comment is longer now)

  12. We have a 10 users named license of rad Studio xe3. When i use this Serial number do you know that is a 10 users license?

    • i’m afraid we won’t. All the info we can gather form a serial number is what product code it refers to. But if you drop me a quick mail to after registering the serial, i can sort that out for you manually.

  13. Please invest a bit more into documentation. Oxygene is awesome, but in order to learn it effectively some structured documentation would be nice. A wiki doesn’t cut it, in my opinion.

    • I see two conflicting/separate messages here.

      For one, fully agreed, we need more and better docs. I’ve already been on this like the devil these past few months (some weeks more, some weeks less, as other things keep us busy), and the wiki has been throughly restructured. A lot of new content has gone in, and a lot of areas have started to fill with really extensive content. A lot more areas still need improvements (or any coverage at all), yes. I’m for docs to get a lot better between now and the 6.0 release in May, and they will be a continuing effort, moving forward.

      That said, a “wiki” is really an implementation detail of how the docs site is provided, and we;re finding that the wiki format make sint tremendously easy(er) for us to manage this content and update it on the fly and out-of-band with actual product deliveries. I;m not sure why by nature of being wiki-based, the documentation does not “cut it” — although i would appreciate concrete feedback or complaints as to what you find problematic with the wiki as such.


      • Hi marc,

        Let me interject here on the subject of documentation. In an earlier comment, you said,

        “Change is never easy. Oxygene is not Delphi […] switching to Oxygene does require a certain openness to learn new things”

        For my own part (and there are plenty like me) I am a single-handed Delphi developer of some years and I (& I strongly suspect others such as me) are looking longingly at Oxygene and other RO products because we see quality products driven by a competent, wise and pragmatic management team. I suspect you already realise this but what is stopping us “lone-rangers” from switching to Oxygene and .NET is the high cost of switching for no apparent gain – in other words our users see no benefit, therefore we can’t charge for it, therefore the cost of re-training must be borne by the developer.

        I realise that your products are favourably and competitively priced, but they are only a small part of the total cost when you factor in cost of replacing 3rd party VCL components with .Net versions, but by far and away the biggest cost is the learning curve. Whilst I am getting up to speed with Oxygene (for example) I am not earning money by delivering other projects. This loss of income is a dealbreaker & anything that can reduce that down-time will encourage developers like me to switch.

        In short then — I love what you’re doing at RO (big fan of RO/DA) and would dearly love to leave Delphi behind and join the .Net/web development community. But the time cost is too high and any training targeted at getting Delphi devs up to speed with Oxygene would encourage us and help us switch.

        Thanks for listening, I hope that was clear enough

      • The problem I see with wikis is that they make it too easy to put half finshed stuff in there.
        Documentation should be taken seriously, especially if it is for such a small niche language like oxygene.
        I also think that having a real book available on Amazon would boost sales.

        • @Arni – what you see as “unfinished” I see as a “planning”. The problem with a wiki is that the authors’ plans are on public view – which is okay in my opinion. The alternative is what? A book that is incomplete or a CHTM file that is also incomplete? Unfinished documentation is a product of lack of authoring resources, not of the medium used.

          Perhaps the real problem with a Wiki is that it seems to promote the development of “reference” material,, rather than whitepapers or how-to articles that better suit beginners or developers who want to cross train.

          Like I said in my earlier post, if RO concentrated on a little cross-training materials such as “Oxygene for Delphi Devs” then I think they’d reap the rewards with an increase in sales.

          – Stu

          • Stuart — exactly. Sure, the wiki shows you lots of unfinished things. but those things would not be written sooner, byt virtue of not being in a wiki. If anything, id say our docs would not be half of what they are now (however you wanna judge what we do have now) if not for the ease of being abe to just go and change any part on the fly.

            Only the wiki gives us the amount of flexibility needed to maintain the docs like this. Sure, the wii doesn’t make up for each day still only having 24 hours, and us thus not getting as much docs done as we’d like, as fast. But then, no other format for the docs would either — it’d just cost even more overhead that distracts form actual docs writing.

            Agreed WRT “Oxygene for Delphi” devs. We have a section for that, and lots more content planned in that area.

          • Stu — one of many articles to come, in this area:


            Also, the “hub” for all things for Delphi developers moving to Oxygene (work in progress):


          • HI Marc,

            (No Reply button on your posts, so replying here)

            Thanks for the info on the docs – had missed that completely :) I’ll be looking into this for potential new projects., I just need to be brave… ;-)


      • The problem with the RO documentation wikis, and many wikis in general, is navigation. When looking at a page, you have no idea “where you are” in relation to the documentation tree. The left hand “contents” bar is a static set of starting points, but once you navigate across pages by clicking on links, you become “lost”, unsure of where you are, where you have been, or how to quickly get back to a particular point without a lot of back button clicking.

        I’m fine with on-line docs, but I hate the wiki concept. IMO, a better approach is that of products such as Help & Manual, which use a more traditional book/hierarchical approach and provide multiple output formats, including on-line/html from a single source.

        • Kevin,

          i see your point, but i disagree. The whole thing about a Wiki is to embrace that the structure of such documentation is *not* strictly hierarchical, but a mesh of topics that are interlinked. A wiki does that justice, a hierarchical document does not.

          Although i can see how as a matter of taste one would prefer one over the other.

  14. Great news, great messages. Please help me better understand the concept. I’m a Delphi developper, not a beginner, but not a very skilled one either. I use some 3rd parties components to drive databases, schedulers, IO excel, pdf, reports. Well you get the idea.
    I’m seriously considering to switch as I absolutely don’t trust Embarcadero anymore. Now If I was to swtich to Oxygene, how do I design GUI for win and web applications ? Do I have a GUi Designer ? Or.. I don’t know ? Could please explain to me ? Kind regards, Arnaud.

    • Don’t! Switch to Visual Studio Express 2012; it’s free and superior to all other development tools. I’ve been a Delphi fan for ages but unfortunately it doesn’t cut it and oxygene is nowhere near to level of Delphi or Visual Studio.

    • Arnaud,

      Oxygene provides fully integrated visual designers for WIndows — WinForms, WPF (which i would recommend to use) and the new Metro/WinRT —, for WIndows Phone, and also for ASP.NET Web development, yes. In general, WPF is an awesome framework for creating WIndows GUIs, and a vast step up from both VCL and WinForms (which i’d consider roughly on par, canceptually and design-level wise).

      We have a great video to help you get started with WPF at

      Not wanting to step on Zerps parade, in addition to of course having the much more powerful (and nicer, since Pascal based) Oxygene language, Oxygene provides a true superset of what Visual C# Express can offer, including the same great Visual studio IDE, but without the resttictions of Express. The Visual Studio Express editions are also severely limited in regards to using third party tools (you can;t integrate *any*). So i woud hesitate to call Visual Studio Express “superior” to anything ;).

  15. No upgrade path from Prism XE?

  16. Think you very muchMarc for your answer. So can you confirm that for instance, I can use Devexpress .net components with oxygene ?
    Also what do I have to do to crossgrade? I have rad RadStudio Xe2, rad studio XE, and even an old delphi 6 entreprise . My Rad studios came with Prism and many others embt tools that I never used.

    Tanks in advance, Arnaud

    • Yes, DevEx controls will work with Oxygene for .NET.

      As a RAD Studio XE2 customer, you can use our 349 renewal price mentioned above. Note that this will renew for one year from the XE2 end date – ie from August 2012 most likely. You can also use the 399 cross-grade option also mentioned above, that will give you a fresh subscription.

    • I can attest to the fact that DevExp .NET and ASP.NET components work flawlessly with Oxygene. I’m workign on two seaparate ASP.NET projects, and two desktop projects. I’ve had ZERO problems, and have been using the 6.0 alpha/beta version of Oxygene for .NET while testing out Nougat.

      I have zero regrets moving from Delphi to Oxygene.

  17. I sent Embarcadero a note this morning that XE4 is the final straw, the one that broke the camel’s back. No more Enterprise licenses and no more Software Assurance. In the last round of upgrades I dropped from Enterprise to Professional w/SA as Embarcadero’s deliverables delivered less value and more bloatware.

    Their vision is misguided (IMO), their policies questionable – to be more than kind, their software a bloated patchwork and my patience at an end. No more purchases to be a team player in the hopes that the next release will deliver the goods.

    What I’ve noticed over the years about RemObjects is that there is a clear and consistent vision, deliveries that meet or exceed the specs, honesty with its customers and a willingness to go the extra mile to help customers. The contrast could not be more obvious.

  18. Marc,

    In retrospect, I must say that Delphi Prism aka Embarcadero Prism was DOA. As an existing Oxygene customer prior to the transition to Embardadero, the relationship with Embarcadero was awkward as best.

    Although the idea appeared to be a win-win for all, but in the end was a loser for RemObjects Subscription customers who were transferred to Embarcadero Maintenance. This is because we were treated as second class citizens. For example, whenever there was an Oxygene update, Embarcadero somehow forgot to deliver the new keys, etc. Sometimes, we had to wait days or weeks to get it all ironed out. Secondly, IIRC, we lost access to betas, etc., until RemObjects implemented the license registration process, but that wasn’t perfect either.

    However, I think the current direction is definitely for the better. I’m planning on upgrading to the full Oxygene pack as my Embarcadero Maintenance nears expiration.

    Regarding the cross platform discussion on this post, I have the following comments. I mostly agree with your thoughts on native implementations as you have discussed in previous posts. I prefer truly native UI rather than a one size fits all approach like PhoneGap, which in my opinion is not optimal for the underlying platforms. As an Android phone and tablet user, I really don’t like when developers port their apps from iOS and keep the same look and feel. It’s sub optimal and I usually immediately uninstall such apps. Each platform has its own design guidelines. For the best user experience and expectations, apps should adhere to those guidelines. In this regard, I believe Xamarin has a compelling offering. Xamarin leverages the native UI implementation while also offering a pleasant development experience.

    • I agree that Xamarin is a compelling option for mobile but at $999 per dev/per platform they’re following Embarcadero’s lead in pricing small ISVs like ours out of the market for their tools. While Xamarin have a cheaper edition you can’t use it with VS which renders it virtually useless to us. I think the RO guys have got their pricing for Oxygene right on the nail.

      • Dan said on May 1, 2013

        Well said. I guess that’s why I haven’t purchased a Xamarin license yet.

  19. will this have MVC framework?

    • marc said on May 1, 2013

      Are you referring to ASP.NET MVC, specifically, or MVC as a more general concept? We are currently working on integrating full ASP.NET MVC4 support, probably in a release shortly after the upcoming May release. Some other platforms use MVC — Cocoa is heavily based around MVC, and using Oxygene for Cocoa will embrace that; other platforms use other patterns, for example there’s MVVM that’s gaining popularity for WPF development.

      Longer-term we’re looking into some guidance and helper toolage for “recommended” ways to apply MVC or MVVM to better share code across different platform’s GUI layers — but that is for later, right now for the imminent 6.0 release we’re pretty focused on the core language, compiler and related toolchain for Cocoa (and ofc Java/Android and .NET). Once we have all three platforms out, we can start putting more focus on higher-level things.

  20. As a long time Delphi developer, I only have one question… does your cross-grade offer apply to those of us looking to move from Delphi 7?

    You (and every other Delphi user)…

  21. Now that RemObjects and Embarcadero are going their separate ways, what about revisiting one question I asked last year. Oxygene for Win32 (or Linux). Even without a framework like VCL It would be useful for us (linux/windows services), and I think you (I imagine the more targets the more robust it will get)

    Also tried to post using Firefox and did nothing, also tried emailing you directly I guess it was sent to spam. :) Using Chrome now.

    • marc said on May 10, 2013

      What would you do from Oxygene without a framework? Pretty much all you coud do would be to do integer arithmetic in memory.

      The Embarcadero partnership is not what has kept us form pursuing an x32/x64 Windows or Linux compiler. The fact that there’s little-to-no benefit to said compiler, over what we already have to offer, has.

      ps: my apologies re Firefiox, not sure what the issue is. Thuis is pretty much a plain vanilla WordPress install…

  22. Forgo to to also ask one more thing: Any news on the Eclipse plugin for Oxygene for Java?

    • marc said on May 10, 2013

      It’s not something we are actively pursuing right now. We have research ongoing into various IDE options, but nothing to announce, and nothing that will come out this year; we’re focused on the compiler(s) and the Visual Studio IDE for now, and have lots of exciting plans in that area that wil take our focus for 2013.

  23. Dave said on May 22, 2013

    Seriously Marc. We need a native Oxygene compiler for Windows Platform. If you can make a native iOS Oxygene compiler. Then sure you can make one for Windows.

    I am getting sick of Embarcadero and their shitty marketing. Time has come for native oxygene windows compiler..

    • marc said on May 22, 2013


      seriously, you probably don’t. Embarcadero and the Delphi community has spend years indoctrinating everyone that “native code” is some magic thing. Like when you look at their recent “Why true native” video, where they show diagrams that aim to let you think that in .NET code, when you click a button, it takes 2 seconds for the application to register.

      This is all bullshit.

      “native” and “.NET” really are no different, in how they run on the CPU. If you’d attach a “native” debugger to your .NET process, you would see it running the exact same kind of instructions that your “native code” app would. It’s not “interpreted” like Embarcadero would like to have you believe, there’s no “Virtual Machine”. It’s x64 (or x86) instructions, running on the CPU. If anything, .NET code will often be better optimized for the actual hardware you are running on, since when you;re building a “native code” .exe, you can’t really optimize for the very latest CPU technology, since you don;t know whatCPUs your users will have (not to mention that Delphi’s CPU-specific optimizations stopped somewhere at 80386).

      The only thing that a “native code” Oxygene for WIndows will give you is that you no longer have access to the vast class library you have with .NET. There’s nio benefit to it (except for a checkmark on the feature list), only downsides.

      If you’re looking for the future of Object pascal for WIndows, it’s already there, in Oxygene for .NET. Unless you’re writing video codecs or device drivers (in which case you probably will use C++ anyways) you most likely really don’t need a “native” compiler. Embarcadero has just been really good at making sure you think you do.

      • Dave said on May 22, 2013

        I just did a test.. and Delphi GUI seems snappier than .NET / Oxygene. So .NET is faster then?

        • marc said on May 22, 2013

          What type of GUI did you use? WinForms has some speed issues (which ironically have nothing to do with .NET, but with the fact that it uses GDI+, which has no hardware acceleration. It’s not the .NET code in a WinForm app that makes it feel sluggish, it’s the drawing (which is actually native and in core Windows)). I would suggest using WPF for building .NET based GUI apps.

          So taking UI responsiveness of WinForms as a measure for .NET vs native code speed is misleading, at best.

          Now, you might say “so what good does it me that .NET is not the culprit, if .NET created GUI isn’t as snappy as the VCL”, and you might have a point. But us doing a native CPU compiler would not solve that problem.

          If we did a native code compiler for Windows, we’d have to write our own class library and GUI framework (which is utterly out of the question, given our resources). If we were to do that, we might as well make build it on .NET (and just not use GDI+ ;). Which brings us back to square one: we really don’t need a native compiler for Windows, and creating one doesn’t really solve the problem.

          WPF is actually fairly decent, though. It’s more sophisticated and at a higher level that the VCL (it’s closer to FireMonkey in concept — FireMonkey is essentially an attempt at a (bad) WPF clone), so it does have higher demands on the graphics hardware than VCL, WInForms or plain “directly use the Windows Common Controls from Win32” does, but it does work well, and lets you create pretty amazing and sophisticated UIs.

          • Dave said on May 22, 2013

            VCL is indeed faster than Winforms. And i hope you guys can do something about it. Maybe port VCL over to .NET :)

          • marc said on May 22, 2013

            The VCL is a copyrighted close-source library; no-one but Embarcadero can port it anywhere.

            As mentioned before, we don’t have the resources to build our own class framework to rival the VCL, or the .NET Framework. We just don’t, no matter how cool that would be. Now maybe if you can help spread the word and get a few thousand extra Delphi developers to check out and switch to Oxygene, that might look different in the future. (But really, this point will just get more and more moot, over time).

            But as of right now, we have our hands ful with what we already are doing on the Oxygene (and related technologies, and there’s lots of cool stuff coming you guys haven’t heard about yet) front.

            Remember that Microsoft has thousands of developers working on .NET. Even Embarcadero has dozens of people working on Delphi and the VCL and FMX. The Oxygene team is a handful of people. Literally.

  24. Marc (& the rest od RemObjects team) your progression is IMPRESSIVE. You guys (and a couple other teams) keep Pascal alive. keep pushing it forward. THANKS!!