.net, apple, codegear, embarcadero, mono, software development, windows

Code for Mac Cocoa in Visual Studio – surprised to see this?

12 Comments

I grabbed this screenshot from a preview just installed:

Cocoa app in Visual Studio

It comes from Delphi Prism, a new product from Embarcadero/Codegear which lets you code for .NET using the Delphi language, an object-oriented version of Pascal. The product is not as new as it first appears. It is based on an existing product from RemObjects, called Oxygene, which it now replaces.

Here’s the story in a nutshell. 2003: Borland, the company which created Delphi, decides (rightly) that .NET is here to stay, and releases Delphi 8, a pure .NET version. Nobody wants it, because it has no advantages to speak of over Win32 Delphi (which is faster), or C#, which is the Microsoft .NET language.

At that time some voices muttered that what Borland should do is to integrate Delphi into Visual Studio, rather than doing its own .NET IDE.  One was Marc Hoffman at RemObjects, only he did more than mutter: his company developed its own implementation of Delphi Pascal for Visual Studio, called Chrome.

Borland soldiers on with Delphi 2005, which does both .NET and Win32 in a single IDE. Developers are happy to have a new Win32 Delphi, but most still don’t see the point of the .NET stuff. Further, Delphi 2005 is buggy; many stick with Delphi 7. Next comes Delphi 2006: more of the same, but less buggy.

There’s a couple of problems with Delphi’s .NET support. First, it is always out-of-date compared to Microsoft’s .NET tools. Second, it has component library schizophrenia. There’s VCL for .NET, based on Delphi’s component and GUI library, but that’s not compatible with .NET components built for Windows Forms. There’s Windows Forms, but that’s not compatible with existing Delphi code. Borland decides to deprecate use of Delphi .NET with Windows Forms. This is really for VCL developers, it says.

Next comes Delphi 2007. Nice product, but where’s .NET? Gone. Nobody seems to mind [and it turns up later in RAD Studio 2007*]. Delphi 2009, gone again. But now there’s Prism, and it is a complete U-turn. Forget VCL.NET. It uses standard .NET libraries, runs in Visual Studio, supports Windows Forms, ASP.NET, WPF, and soon Silverlight. Oh, and it’s based on what that other guy did back in 2004, with some Borland Codegear Embarcadero technology thrown in: dbExpress database framework, client support for DataSnap multi-tier applications, and the Blackfish pure .NET database engine.

Very good; but there’s still that awkward question: why not use C#? The answer, I guess, being either that you love coding in the Delphi language, or you want to use one of the Delphi-compatible libraries.

Or that you want to use Mono, which of course is what enables those tasty Mac options in the New Project dialog above. You can also use C# with Mono – possibly you should, since it is Mono’s core language – but in Prism it comes nicely integrated into Visual Studio. Well, somewhat nicely. In practice there are a few extra steps you need to take to get it working. The recommendation is to run Visual Studio in a VM on a Mac, since Windows cannot run Cocoa applications. And you’re going to be using Apple’s Interface Builder; there’s no GUI designer in Visual Studio itself.

Hardly enterprise-ready then; but still an intriguing development.

*Added correction thanks to John Moshakis’ comment below.

12 thoughts on “Code for Mac Cocoa in Visual Studio – surprised to see this?”

  1. I used to be a big Delphi fan, it introduced a real drag and drop method of creating Windows applicaions, but now VC C# Express Edition (or whatever it is called) does a lot of the same things as uses the latest and native .NET implementation so I haven’t used Delphi in a long time.

    Also don’t forget Mono’s role in making C# cross platform. A friend and I are developing a relativly complex application which, if you avoid a few potholes, runs great on Windows, Linux and OS X thanks to Mono.

    Gary

  2. I can’t see any real reason to use Mono instead of Java for multiplatform development but refusing to learn Java.
    Unlike .NET Java is not designed with *one* platform in mind. Unlike .NET/Mono Java offers the same features on each supported platform without waiting someone to catch up.
    I am surprised that CodeGear sells JBuilder and instead of telling its customers “needs managed/multiplatform code? Go Java. Need a solid native compiler for Windows? Go Delphi or C++ Builder”.

  3. @Luigi

    I think this is more about offering a choice, rather than undermining Java. I’d guess that Codegear is investing much more in native code Delphi, than in Prism.

    Tim

  4. IMHO it’s more about wasting again resources than offering a competitive product. Face it: .NET is a Microsoft Windows product. Every other implementation is just dust in the eye to lure Java developers into adopting .NET and then have them run MS products to get something working.
    Should CodeGear cover .NET development? Sure. Cover where .NET development matters: MS OSes with latest frameworks. Keep head to head with MS, and forget about “multiplatform” .NET.
    Or I am afraid you will release a tool no one needs again, and you will drop Mono support soon or later…

  7. Mono -> .Net was slow…
    Java -> JRE was slow to…

    JBuilder was a great product, but Borland seem abandon it
    Kylix was a great product too (although the quality isn’t that good), but Borland seem abandon it
    Prism was a great product too, we really need FORM DESIGNER to be there, no points to use it if C# can did that better, will Embarcadero abandon it in next 5 years? who knows

    We need native compiled code that can run everywhere… and i really love to see how Lazarus and Freepascal have done so far, opensource, cross-compile, native code, LCL that looks like VCL, yummy…

  8. .NET / mono is not slow. Go and test it yourself. GDI+ is slow, yes, but when using Gtk# or Cocoa# you’re not even noticing that you’re not running a native app on Linux / Mac.

    Well, on the other hand: If you’re a fan of ugly, non-ergonomic and slow UI’s, and of writing a lot unnecessary code again and again, you can of course use java.

    And yes, writing my applications for the Mac (not for Linux – I don’t know people running linux on the desktop) in object pascal, that offers more features than C# does, is a thing I see a lot of commercial potential in. If you don’t see it, it’s better for me 😉

  9. Java GUIs are not slower than .NET ones. As GDI+ is slow, Swing was, SWT is not.
    And frankly I don’t see any reason to write applications on Mac using ObjectPascal and a VM. Objective-C does the job better. If you do, it’s better for me.

  10. I’m split on whether Prism’s support for Mac Cocoa is a good thing or bad. On one hand the idea of using Object Pascal to write apps for the Mac (and Linux for that matter) sounds exciting. On the other hand I already took the time earlier this year to learn Objective C and Xcode. And I released an iPhone app last month.

    A year ago I probably would have gone with Prism no questions asked. I even looked at Free Pascal at the beginning of the year as the possible language of choice for me to do Cocoa development. But today, given that I already know Objective C and Xcode, it’s unlikely I will move to Prism for Cocoa development. Of course that could always change once I get my hands on Prism and have played with it a bit. Or if Prism is ever supported in Xcode.

  11. {QUOTE} Kirby Turner says:
    November 11th, 2008 at 5:43 pm

    I’m split on whether Prism’s support for Mac Cocoa is a good thing or bad. On one hand the idea of using Object Pascal to write apps for the Mac (and Linux for that matter) sounds exciting. On the other hand I already took the time earlier this year to learn Objective C and Xcode. And I released an iPhone app last month. {/QUOTE}

    Are you saying that a new product should not be released because of the programming language that you chose to learn and implement your software?

Comments are closed.