Tag Archives: osx

Quick thoughts on Xcode and Objective C versus Microsoft’s tools

I have been trying out JetBrains’ AppCode which meant working in an Apple development environment for a time. I took the opportunity to implement my simple calculator app in iOS native code.


Objective C is a distinctive language with a mixed reputation, but I enjoy coding with it. I used Automatic Reference Counting (ARC), a feature introduced in Xcode 4.2 and OSX 10.7, iOS 5; ARC now also works with 10.6 and iOS 4. This means objects are automatically disposed, and I did not have to worry about memory management at all in my simple app. This is not a complete memory management solution (if there is such a thing) – if you use malloc you must use free – but it meant that the code in my app is not particularly verbose or complex compared to other languages. Apple’s libraries seem to favour plain English method names like StringByAppendingString which makes for readable code.

I was impressed by how easy it is to make an app that looks good, because the controls are beautifully designed. I understand the attraction of developing solely for Apple’s platform.

I also love the integrated source control in Xcode. You find yourself using a local Git repository almost without thinking about it. Microsoft could learn from that; no need for Team Foundation Server for a solo developer.

I did miss namespaces. In Objective C, if you want to remove the risk of name collision with a library, you have to use your own class prefix (and hope that nobody else picked the same one).


Interface Builder, the visual UI designer, is great but many developers do not use it, because coding the UI without it is more flexible. It is a shame that you have to make this choice, unlike IDE’s with “two way tools” that let you edit in code or visually and seamlessly keep the two in synch. I found myself constantly having to re-display windows like the Attributes Inspector though it is not too bad once you learn the keyboard shortcuts. The latest Interface Builder has a storyboard feature which lets you define several screens and link them. It looks useful, though when I played with this I found it difficult to follow all the linking lines the designer drew for me.

It is interesting to compare the Mac and iOS development platform with that for Windows. Microsoft promotes the idea of language choice, though most professional development is either C# or C++, whereas on Apple’s platform it is Objective C and Cocoa or you are on your own. Although Mac and Windows are of a similar age, Microsoft’s platform gives a GUI developer more choices: Win32, MFC, WTL, Windows Forms, Windows Presentation Foundation and Silverlight, and in Windows 8 the new WinRT.

I get the impression that Microsoft is envious of this single-minded approach and trying to bring it to Metro-style Windows 8, where you still have a choice of languages but really only one GUI framework.

That said, Visual Studio is an impressive tool and both C# and C++ have important features which are lacking in Objective C. I would judge that Visual Studio is the more productive tool overall, but Apple’s developer platform has its own attractions.

Delphi XE2 FireMonkey for Windows, Mac, iOS: great idea, but is it usable?

I am sure all readers of this blog will know by now that Delphi XE2 (and RAD Studio XE2) has been released, and that to the astonishment of Delphi-watchers it supports not only 64-bit compilation on Windows, but also cross-platform apps for Windows, Mac OS X and even iOS for iPhone and iPad (with Android promised).

I tried this early on and was broadly impressed – my app worked and ran on all three platforms.


However it is an exceedingly simple app, pretty much Hello World, and there are some worrying aspects to this Delphi release. FireMonkey is based on technology from KSDev, which was acquired by Embarcadero in January this year. To go from acquisition to full Delphi integration and release in a few months is extraordinary, and makes you wonder what corners were cut.

It seems that corners were cut: you only have to read this post by developer and Delphi enthusiast Chris Rolliston:

To put it bluntly, FireMonkey in its current state isn’t good enough even for writing a Notepad clone (I know, because I’ve been trying). You can check out Herbert Sauro’s blog for various details (here, also a follow up post here). For my part, here’s a highish-level list of missing features and dubious coding practices, written from the POV of FireMonkey being a VCL substitute on the Mac (since on OS X, that is what it is).

Fortunately I did not write a Notepad clone, I wrote a Calculator clone, which explains why I did not run into as many problems.

Update: See also A look at the 3D side of FireMonkey by Eric Grange:

…if you want to achieve anything beyond a few poorly texture objects, you’ll need to design and write a lot of custom code rather than rely on the framework… with obvious implications of obsolescence and compatibility issues whenever FMX finally gets the features in standard.

There has already been an update for Delphi XE2 which is said to fix over 120 bugs as well as an open source licensing issue. I also noticed better performance for my simple iOS calculator after the update.

Still, FireMonkey early adopters face some significant issues if they are trying to make VCL-like applications, which I am guessing is a common scenario. There is a mismatch here, in that FireMonkey is based on VGScene and DXScene from KSDev, and the focus of those libraries was rich 2D and 3D graphics. Some Delphi developers undoubtedly develop rich graphical applications, but a great many do not, and I would judge that if Embarcadero had been able to deliver something more like a cross-platform VCL that just worked, the average Delphi developer would have been happier.

The company must be aware of this, and one reading of the journey from VSCene/DXScene to FireMonkey is that Embarcadero has been madly stuffing bits of VCL into the framework. Eventually, once the bugs are shaken out and missing features implemented, we may have something close to the ideal.

In the meantime, you can make a good case for Adobe Flash and Flex if what you really want is cross-platform 2D and 3D graphics; while VCL-style developers may be best off using the current FireMonkey more for trying out ideas and learning the new Framework than for real work, pending further improvements.

On the positive side, even though FireMonkey is a bit rough, Embarcadero has delivered a development environment for Windows and Mac that works. You can work in the familiar Delphi IDE and code around any problems. The Delphi community is not short of able developers who will share their workarounds.

I have some other questions about Delphi. Why are there so many editions, and who uses the middleware framework DataSnap, or other enterprisey features like UML modeling?

There appear to be five editions of Delphi XE2: Starter, Professional, Enterprise, Ultimate and Architect, where Architect has features missing in Ultimate – should the Ultimate be called the Penultimate? It breaks down like this:

  • Starter: low cost, restrictive license that is mainly non-commercial (you are allowed revenue up to $1000 per year). No 64-bit, no Mac or iOS. $199.00
  • Professional: The basic Delphi product. Missing a few features like UML diagramming, no DataSnap. Limited IntraWeb. $899.00.
  • Enterprise: For more than double the price, you get DataSnap and dbExpress server drivers. $1,999.00
  • Ultimate: Adds a developer edition of Embarcadero’s DBPowerStudio. $2999.00
  • Architect: Adds more UML modeling, and a developer edition of Embarcadero’s ER/Studio database modeling tool. $3499.00

The RAD Studio range is similar, but adds C++ Builder, PHP and .NET development. No Starter version. Prices from $1399.00 for Professional to $4299.00 for Architect. The non-Ultimate Ultimate is $3799.00.

All prices discounted by around 40% for upgraders.

The problem for Embarcadero is that Delphi is such a great and flexible tool that you can easily use it for database or multi-tier applications with just the Professional edition. See here, for example, for REST client and server suggestions. Third parties like devart do a good job of providing alternative data access components and dbExpress drivers. I would be interested to know, therefore, what proportion of Delphi developers buy into the official middleware options.

As an aside, I wondered about DataSnap licensing. I looked at the DataSnap page which says for licensing information look here – which is a MIDAS article from 2000, yes Embarcadero, that is 11 years ago. Which proves if nothing else what a ramshackle web site has evolved over the years.

Personally I would prefer to see Embarcadero focus on the Professional edition and improve humdrum things like FireMonkey documentation and bugs, and go easy on enterprise middleware which is a market that is well served elsewhere.

I have seen huge interest in Delphi as a productive, flexible, high-performance tool for Windows, Mac and mobile, but the momentum is endangered by quality issues.

Building PasswordSafe for the Mac: Lion development hassles

I am doing some work on a Mac at the moment. On Windows I store passwords in PasswordSafe, an open source utility that works well, so I wondered if I could access my PasswordSafe database from the Mac.


I could have run the Windows version in Parallels, which I have just installed, but I figured a Mac version would be more convenient. I didn’t see a Mac build among the downloads, but PasswordSafe is cross-platform, so I downloaded the source to do a quick compile.

I was glad to find README.MAC.DEVELOPERS.txt in the PasswordSafe source and set to work. The first task is to download wxWidgets, a cross-platform GUI library, so I went off to download that. Ran the osx-build-wx script as instructed. Result: error message stating C compiler cannot create executables.

The problem seems to be that PasswordSafe expects GCC 4.0 but the latest Xcode installs GCC 4.2. The solution suggested here is to remove Xcode 4, install Xcode 3, and then reinstate Xcode 4. There are related issues concerning PPC fat binaries and older versions of the Mac SDK.

That solution seemed risky and ardous to me, and I remembered that I still had an old Mac Mini from which I was forced to upgrade in order to install Lion, the latest OS X. I hooked it up, removed Xcode 4, installed Xcode 3, and set to work again.

I get the impression not many people build PasswordSafe for the Mac. The first issue I discovered was that the steps in in the README.MAC.DEVELOPERS.txt don’t mention that after running osx-build-wx you also have to run make in order to build static libraries. That was easy though. The next thing is to load the supplied PasswordSafe project into Xcode and build.

I did that but got an error – the linker could not resolve SizeRestrictedPanel. The fix was to add SizeRestrictedPanel.cpp and SizeRestrictedPanel.h to the project. PasswordSafe then built and seems to work fine, on Lion as well as earlier versions of OS X, though there are a few cosmetic issues. You can see from the image that the caption for the New Database button is slightly awry.

If anyone wants my build, it is here. There is also a Java version, and some people have success with that on the Mac.