RemObjects have officially released the September update to Oxygene with the usual round of bug fixes and some dramatic improvements in the tool chain.
Cocoa – Principally iOS 7
My focus with Oxygene most recently has been on the Android side. My previous experience with using the Cocoa (iOS) support was similarly rewarding. Using Interface Builder in Xcode to design the UI already worked very well since Xcode is able to directly open xib files independently of any project, but it did mean that you were only working in the context of one xib.
Now Oxygene creates and maintains a complete Xcode project alongside the Visual Studio one, incorporating all project resources, which means that you can open that project in Xcode and work in the full, project-oriented context !
The improved integration now also means that once you have finished working in Xcode you do not have to “Sync the xib” back on the Oxygene side – the projects are kept in sync automatically.
It was hardly an onerous step but it was possible to sometimes forget so this removes a little bit of friction from the workflow.
Of course, the iOS 7 support in Oxygene is way more than skin deep.
Unfortunately at the moment the only iOS 7 capable devices in our household are my partner’s work iPhone and iPad. I shall have to get purchasing approval from the Accounts Department (she hates it when I call her that 🙂 ) for a development device if I want to explore the new API’s fully using anything other than the simulator (although support in this area has also been significantly improved to keep step with the improved capabilities in Xcode itself). 🙂
Also on the iOS side, Oxygene now also supports x86_64 and so can target the 64-bit iOS simulator.
arm64 for actual devices is coming very soon (this month all being well), subject to testing on actual hardware.
Android
On the Android side, Oxygene now has support for the JNI. Of course, in this case things work in the opposite direction than in Delphi. Instead of bringing Java into the native realm with Oxygene JNI support enables an Oxygene Java project to call into native code, should the need arise.
There have been further improvements in the language to make writing Java in Pascal even more pleasant that already it was. And finally there is already support for the yet to be released Java 8.
Oxygene goes from strength to strength. 🙂
Hydrogene … ?
I am increasingly intrigued by another RemObjects product in the wings: Hydrogene
I can’t find anything about this other than that a “hydrogenelanguage” domain name has been registered (currently redirects to the Oxygene pages) and that RO seem very excited about it. What I have learned so far is that it will be a companion product to Oxygene (all platforms) but not part of it.
So far the best guess I can come up with – and it is only a guess with no basis in any evidence or clues or “inside information” or any such things – is that it is a new language front-end for the Oxygene back-end compiler architecture.
C# for Java and Objective-C perhaps ?
I cannot stress enough – this is pure, entirely uninformed guesswork.
If anyone can shed some light – without breaking any NDA’s, obviously – I’d love to find out what it’s really all about. 🙂
I also think it is a C# front end. Here is a comment snippet from Marc Hoffman in Google+ Oxygene:
marc hoffman
Moderator
01.06.2013
One thing at a time ;). Right now, I think C# would be most interesting as a second frontend. Stay tuned for more in that (real) soon. 
A couple of months ago I posted to the Oxygene google+ community (https://plus.google.com/113885579045966583715/posts/2wfsE8D1JVL)
suggesting they should consider a C# edition of Oxygene. That is a C# compiler that produces native apps for the existing platforms instead of apps that sit on top of Mono such as those built with Xamarin. marc more or less hinted that this was already on their minds at the time.
I have a good feeling that this might be their direction.
Now what I would love to see is a c# that produces native code instead of managed code on Windows!
I wonder if there really is a niche for just Yet Another C# implementation. But let them try if they wish..
OTOH i’d rather see some declarative UI and behavior description language. Something unifying GUI design, like Sugars is intended to unify data types
C# is native on iOS (and could not be not). It is just linked against a fat MONO/CLR runtime.
However even with that fat runtime, most lanbguage features, based on managed environment, were reduced.
Same happens to GCJ comparing with VM-native Java compilers.
Oxygene is targeted at thin runtime, so i’d expect native C# by RemObjects be even more restricted than Xamarin’s or GCJ
Funny thing, they changed something in WordPress and the comment field no more works in Opera (native Opera, not recent Chrome-in-disguise versions) :-/
Indeed, I have to go to the “committee” to get purchase approval. I sometimes find it easier to ask for forgiveness rather than permission 🙂
There is big secrecy concerning Hydrogene. I have no idea I see it in the beta downloads but I will wait. I am an old chatterbox so I will not download. It must be something different than Oxygene.
Enabling their multi-platform tools over to the C# would be a game-changer for RO as it puts them in direct competition with Xamarin who presently are stealing a march over most in the mobile space for Windows developers. I was very impressed with Oxygene but just the fact that it’s a Pascal language put us off (having just moved from Delphi primarily for concerns about future hiring/existing staff (inc myself) concerns over future employment prospects). If Oxygene was available using C# it would certainly be a big incentive for us to backtrack from Xamarin – just the cost benefits alone would justify the move.
I don’t understand why being Pascal should put you off. The most important aspect of developing for the new mobile platforms is learning the frameworks and API’s on those platforms. The language on top of those frameworks is a tiny part of the overall “knowledge domain”.
With Oxygene I get to learn the important, portable skills – the platforms and frameworks – without having to put up with Java/Objective-C/C#. If I am forced to learn those syntaxes in the future, so be it. But the hard part – the knowledge of the frameworks and platforms – will be behind me and come with me. 🙂
I agree however the world has pretty much passed Delphi and Pascal by in terms of the market for skilled people available to hire and the employment prospects going forward for my developers internally if they decide/need to move on (as an M-ISV owner I have the same concerns for myself). When we decided to move from Delphi we needed something that would tick all of the boxes and moving to another Pascal framework would not have addressed these 2 concerns. Just having C# on a job posting or on a CV is a massive boost for the prospects of hiring an experienced developer or getting employed. It’s sad but it’s the way the market is today. We’re happy to have moved away from Delphi but I was very attracted to Oxygene and if they have another product which has C# as it’s “front-end” language then that really is a winner for us. I just hope the rumours are true :O)
I also think it will be a huge win for the RemObjects guys – presently they’re largely limited to a small market of disgruntled ex-Delphi users – by having a multi-platform C# edition of a framework which is massively superior to Xamarin’s Mono-based approach they could be on the cusp of massive commercial success which all of their efforts have deserved.
I think the world has moved on, yes, but not in the way that you think.
Time was when language skills were important because the language was the platform. You didn’t just hire a C++ Windows developer, you hired a C++/MFC developer. But even then, you would be less inclined to consider a C++ OWL/VCL developer. When you hired a Delphi developer you weren’t hiring a Pascal developer you were hiring a VCL developer.
Java, .NET and Cocoa – to name just 3 – change all that.
.NET framework was deliberately language agnostic right out of the gate. Java too always separated Java the language from Java the JVM. Objective-C and Cocoa have a similar arms-length relationship. It is precisely this of course that makes Oxygene even possible and why Oxygene for Win32 makes no real sense at all because Win32 lacks the rich frameworks of more modern platforms.
I think a C# front end for the Oxygene compiler will be important but for depressingly wrong reasons.
It will be important because people unable to separate language from framework in their perception, will take Oxygene more seriously as a result. That of course is a good thing for RemObjects. It is just a shame that those people do not recognise that there is simply no need for it in the first place.
You yourself conflate things in your final paragraph, talking about “a multi-platform C# edition of a framework”. Oxygene is not a framework, it’s a language that supports multiple, disparate frameworks. A C# front end for that technology only changes the language you use with those frameworks.
I completely understand and agree with your points – Oxygene’s Pascal-esque language is a “front-end” language to Oxygene’s approach to target multiple frameworks in the same way as Hydrogene will target the same frameworks but with C# (hopefully!). I used the word “framework” in relation to Oxygene only as a way to refer to their approach. The skills developed in targeting each framework are transferable between languages however unfortunately in the job or recruitment market that’s not instantly obvious or justifiable – however depressing that may be.
Anyhow we’ve standardised on C# now for about 6 months since abandoning Delphi and the possibility of having access to the benefits of the Oxygene “approach” with our chosen language without having to go with Xamarin and pay their astronomical license fees ($999 per platform, per developer, per year if you wanna use VS) could be a big advantage for us and a potential goldmine for RO.