These are exciting times in the mobile development space, especially for followers of RemObjects work. Whilst the likes of Xamarin and Embarcadero pursue their cross-platform abstractions, with varying degrees of success, RemObjects have been focussing on delivering genuinely native solutions and the long term vision that underpins their compiler architecture is proving itself in their ability to react Swiftly [sic] to the changing development landscape.
RemObjects have, up to now, largely focussed on delivering great compiler and language technologies, leaving Microsoft and Apple to take care of the heavy lifting involved in providing an IDE, plugging their toolchain into VisualStudio and Xcode where appropriate. However, for a while there have been hints that something was afoot within RemObjects in this space themselves, and this week the covers came off of Fire, which has now entered public beta.
Fire itself is built using RemObjects technologies so it is not only an interesting development but also a concrete example of the capabilities of their products. But what is it ?
Quite simply, Fire is a Mac Native (OS X) IDE, supporting all of the platforms and all of the languages that RemObjects themselves now support. For platforms this of course means:
- .NET (and thus WinRT / WinPhone)
- Java (and thus Android)
- Cocoa / CocoaTouch (i.e. OS X and iOS)
Xcode and Visual Studio are not removed from the mix entirely. When working with xib files, Fire launches the Xcode Interface Builder tools. When working with xaml in a .NET project, Fire only provides access through Finder, presumably leaving you to find your way to it with Visual Studio.
IMHO this is not great problem. Not only is it very early days in the development of Fire, when working on a .NET application it is likely I think that a developer will choose to remain within the Visual Studio IDE for such work, with all of the capabilities for working with .NET project files that this provides. Fire clearly makes more sense when working on iOS / OS X projects and in that context, not having to switch from a Windows VM to the host OS X environment when working with certain project files is clearly a boon.
For Android projects neither Xcode (!) nor VisualStudio offer much that Fire itself does not, so this is perhaps the one area where developers will simply choose which they prefer.
Not Only But Also
For languages the beta announcement of Fire included something of a surprise, with the list of supported languages being extended once again:
- Oxygene – a.k.a RemObjects Pascal
- Hydrogene – a.k.a RemObjects C#
- Silver – a.k.a RemObjects Swift
Yes, that’s right, RemObjects now support the new Swift language from Apple. But of course since Silver sits atop RemObjects compiler technology this means that you aren’t limited to only iOS and/or OS X with RemObjects Swift. RemObjects Swift can also be used for .NET and Java/Android projects as well !!
Having said that, whether it was a problem in the beta release of Fire, or merely indicative of the very early stages of development in this area (Silver has currently only been pre-announced), currently it seems that Fire is [somewhat ironically] only able to create Java/Android projects using the Swift language. I haven’t yet tried the latest beta of the more “traditional”, VisualStudio based Elements to see whether the Swift support is any further advanced in that environment.
It is far too early yet to do a meaningful comparison of Fire against Visual Studio or Xcode which aside from anything else are obviously more mature products, and I do find myself wondering whether it is an advisable move for RemObjects to spread themselves into this space and how much of their efforts will be consumed in further developing this IDE. But as long as they can do so without taking their eye off of the compiler and languages ball, then it can only add to their strengths and the way that they have responded so swiftly to, um, Swift, suggests that this is certainly not a concern.
I have said it before and no doubt will again. Yet I continue to be surprised at how accurate and yet both understated the observation actually is: These are seriously interesting and exciting times for RemObjects.
Long may it continue! 🙂
One of the reasons we haven’t switched to RemObjects Oxygene from Delphi is because we dislike VisualStudio. If they would create an IDE similiar to Delphi IDE we would switch in an instant and never look back.
This is not your “daddy IDE” at all, don’t expect another delphi here.
Is a new IDE experience, fastest than any other ide. The best way to feel it is test.
Best regards.
Enterprise will continue to use Windows for LOB applications. When Linux finds its way into mainstream enterprise, then IT departments will shift to Linux. It will be a win or lose effort for the enterprise computing market and Microsoft and IBM dearly know this. Embarcadero and buddies better be prepared with a miracle that is as good as or better than Delphi at this point.
BTW, Mac OSX will always remain a specialist platform for the graphics design department, the folks in marketing and advertising and the likes.
Steve, your comments are a little outdated, check again how many enterprises adopted mac desktops, growing every day. And not related to “graphics design department” at all.
And BTW, Windows is with version 8 crap and fix crap 8.1 version every day less professional than veer. Mac is the better unix out there like it or not.
>When Linux finds its way into mainstream enterprise, then IT departments
>will shift to Linux.
You don’t think Linux already permeates mainstream enterprise? When Linux completely dominates cloud computing and big data?
http://www.zdnet.com/survey-shows-companies-need-linux-talent-and-they-need-it-bad-7000011579/
>Embarcadero and buddies better be prepared with a miracle that is as
>good as or better than Delphi at this point.
Honestly I think the time for miracles may even be past. Proprietary development tools are an anachronism at this point. Open source doesn’t work well with all types of software, but tools for developers written BY developers? There’s no better fit for open source than development tools. Almost every proprietary language has disappeared that isn’t supported by a monopoly (MIcrosoft) or been reduced to serving legacy needs. Even Microsoft has open sourced parts of their C# ecosystem and JetBrains has open source versions of their IDEs (which actually obtain feature parity with some commercial IDEs). EMBT occasionally leverages open source (such as FreePascal or LLVM) but has shown no real knowledge of how to give back or build a community around a code release. As open source and Linux continue to gain traction I agree that it doesn’t look good for any vendor with a completely closed solution, let alone an outdated and expensive one.
Moving into mobile seemed like a good idea with no clear leaders at the time, but it seems like Xamarin is emerging ahead of the pack (it won the Jolt Award for best mobile solution unanimously and was declared head and shoulders above its competition) and competition continues to heat up, including Digia bringing Qt to mobile. The fact that they’re offering a free version of AppMethod now after having been adamant at release time that there were no plans to do so suggests it’s not making the splash EMBT intended. The move to mobile might be failing to gain them the new customers/revenue streams they hoped for. It might really be too late for them; I don’t think there was a plan B.
>BTW, Mac OSX will always remain a specialist platform for the graphics
>design department, the folks in marketing and advertising and the likes.
I disagree. The future suggests the average consumer may do most of their computing on mobile devices or, conversely, things like TVs. The desktop PC may itself become the specialist platform of the future. Just as we’ve seen even entry-level desktop PCs offering “good enough” performance for average needs (including integrated sound/graphics), mobile will eventually hit that point as well.
Windows, OS X and Linux are all viable computing solutions. I don’t believe any of them possess defects that would limit them to niche markets. Of course, each excels in different areas.
I don’t see the point of yet another IDE. Why not just integrate RemObjects languages/infrastructure into an Eclipse plug-in?
Because Eclipse to start! 🙂
Juste read marc reasons and then you can’t disagree (or agree). 😉
http://www.remobjects.com/elements/fire/more.aspx
I find it interesting that a company a lot smaller than Embarcadero has the time and resources to develop a new IDE from scratch while we’re always being told that EMBT doesn’t have the resources to rewrite their IDE (nor their compiler, apparently). It also highlights the capability of their tools and demonstrates their willingness to “dog food” their own products. EMBT has yet to produce anything of significance in FireMonkey.
For those who understand their products better – the Fire web page says that it was made mostly with their C# “compiler”. It also talks about native widgets. I first had my hopes up that this IDE would run anywhere Mono does. Now I’m thinking I’m wrong – does the compiler/native stuff mean that the IDE is locked into OS X?
That said, I find it baffling/sad that there are Delphi fans using OS X yet stuck running Windows in a VM to run Delphi. I would think that if you’ve made the move to OS X the last thing you’d want to do is deal with the updating/antivirus/UI of WIndows, VM or not. Testing another target on a VM is a normal practice – but coding in a VM? Worse, for OS X, running your debugger inside a VM while testing code outside it? That’s something that seems to be limited to the wacky world of Delphi.
Yes, I believe that Fire is an OS X only project.
Reading between the lines a little bit, I think that the cross-platform managed code that RemObjects talks about in Fire relates to the compiler itself. The cross-platform aspect being the fact that it is the same compiler that is hosted by the Visual Studio hosted environment on Windows. But just as the Visual Studio UI are specific to the Windows platform, the UI aspects of Fire are specific to the OS X platform.
As for us Delphi fans that have moved to OS X, what else can we do but put up with a VM ? Until Embarcadero produce a OS X native Delphi IDE, Delphi is a Windows product. I presume you are thinking of the cumbersome nature of developing/debugging in the VM while code is running on the host OS ? But for me, Delphi is used only for Win32 work, so the dev/debug environment is simply entirely contained within the VM so it’s not really an issue for fans in that position.
For Android/iOS, when debugging/testing on devices at least, whether the IDE is on the host OS or in a VM doesn’t really alter the experience. The only time things get a bit messy (for me) is when developing for OS X using Elements, and that really only because my domestic workstation doesn’t have room for a 2nd monitor (the 27″ iMac screen being plenty big enough otherwise that I don’t usually miss having a 2nd monitor).
You’re correct, Jolyon. Fire itself is a native Cocoa app, an every Mac specific. It’s written in RemObjects C# (and some Oxygene — the two mix freely within the same project).
The shared part is .NET based (written in Oxygene mostly). that’s code that has been around forever, mostly, and includes the core compiler, and “IDE smarts” such as the code that drives Code Completion, Refactoring etc. Essentially anything with deep knowledge of the actual code and language(s). We’re hosting that (currently) via Mono and a small intro layer we write (and open sourced) called Marzipan, that makes the managed code transparent to call from the unmanaged Cocoa code that the core IDE is written in. Eventually (post “1.0”) we’ll be switching that part over to run natively as well, with another cool technology we have in the works that let’s you compile .NET code to run unmanaged.
And the fact that it is written in RemObjects C#, it means they can decide to cross-compile an IDE for Windows too, once Fire starts to ‘spread’ 😉
Not quite that simple. The cross-compilable bits are already cross-platform, using the mono framework. The UI elements are entirely OS X native, and therefore cannot be simply “cross compiled”. I do not think that the aim is to create a cross-platform IDE, rather it was to provide an OS X IDE experience. Windows is already taken care of by VisualStudio.
In days gone by I think there may have been an option to plug-in to Xcode in a similar way to that was done with VisualStudio, but I think Apple closed those doors some time ago.
As others have suggested, an Eclipse plug-in might have been an option, but frankly one reason I like using RemObjects C#/Oxygene is that it means not having to use Eclipse !!! And I do wonder whether the effort to develop an Eclipse plug-in might not have ended up as being just as great as that for building Fire. 🙂
> Windows is already taken care of by VisualStudio.
But Linux isn’t taken care of by anything. 🙁
>As others have suggested, an Eclipse plug-in might have been an option,
What about an IntelliJ plugin? There’s already one for Pascal….
http://www.siberika.com/pasidea.htm
Once we get DWScript + full Qt bindings plus a plugin for Eclipse or IntelliJ, Delphi is rendered obsolete.
Which raises another problem….
Some people will want an Eclipse plug-in. Others will prefer IntelliJ. Still others might even suggest building it into Lazarus. Any more for any more ? 🙂