My previous article introduced an eclectic range of GUI development environments for OS X. If you prefer programming in such environments, then you will surely be interested in including a modern human interface into the apps which you develop. Although this might seem an obvious corollary, in practice developing ‘proper’ apps is not so simple.

Apple’s tools for developers have long been exemplary, and have pioneered many modern advances. Back in the days of Classic Mac OS, around about Systems 6 and 7 (in current numbering, Mac OS 6.x and 7.x), the preferred SDK was Macintosh Programmers Workshop, which was a sophisticated mixed GUI and command environment.

The preferred language for Mac development was then Object Pascal, which was specially designed by Niklaus Wirth, creator of Pascal, for Apple. You also had the option of using one of the earliest major class libraries, MacApp, which was written in Object Pascal and provided in source.

Today, Apple has forced a lot of change, particularly with OS X. Because of its NeXT origins, Objective-C became the preferred language for development, and all OS X features were accessed through its bindings. Over the last couple of years, Apple has somewhat belatedly and reluctantly accepted that Objective-C is perhaps not ideal, and has developed the next generation language Swift, now in version 2 and going cross-platform.

So those trying to produce interfaces to OS X from other languages have had to wrestle with platform dependency, Objective-C bindings and their idiosyncracies, and the vast, elaborate, and ever-changing beast that is OS X. Some have dropped out and opted instead for cross-platform toolkits such as Qt or X11, which instantly draw flaming arrows from OS X enthusiasts. But a few have done their best.

Xcode: multiple languages

The preferred model when developing in Xcode is to bind other languages into an Objective-C (or, now, Swift) harness rather than give other languages direct access to OS X features. For example, there are instructions available for using Haskell in an Xcode Cocoa project.

For some apps, this works well, but often becomes too demanding of the developer. The option is usually there if you want to try it.

Script Debugger: AppleScript

You can still enable the old AppleScript Studio palette in Xcode’s Interface Builder, but it is deprecated, and does not work (or conflict with) Script Debugger. AppleScript already includes a limited range of functions to support basic use of the OS X human interface, such as opening and saving files, and simple dialogs.

However, any self-respecting programmer will need to get their head around AppleScriptObjC, the framework which was introduced with OS X 10.6 to replace AppleScript Studio. This essentially gives full access to anything which can be achieved in Objective-C, although it is not particularly friendly to use.

You will probably be far better off using some of the tools and documentation provided by Shane Stanley here, which includes a replacement script development environment which you can use alongside Script Debugger and Xcode. The end result is not always as elegant as AppleScript should be, but is amazingly powerful and flexible. I am surprised at how few people seem to have discovered this route to OS X app development.

LispWorks 7: Common Lisp

As you might expect from a commercial Lisp implementation, LispWorks comes with several options for its human interface. These include CAPI, its own cross-platform environment which looks good and works well but is not a ‘standard’ OS X interface, access to GTK, and full access to everything available to Objective-C. The latter is not normally used for its interface, because it is so much quicker and simpler to use CAPI. However you could if you wanted write a ‘proper’ Cocoa app using Objective-C calls, but without the overhead of Xcode.

Haskell: Haskell

Among the library modules provided in this new and very sleek SDK is Language.C.Inline.ObjC, in the language-c-inline package. This supports making inline Objective-C calls from Haskell, and there is another bundled module Graphics.SpriteKit.

Sadly at the moment the documentation is lagging the SDK’s capabilities, and the only tutorial and example material which covers this area is restricted to demos within the playground environment. Hopefully its developers will shortly provide some additional help.

iMops: Mops/Forth

iMops includes a basic library giving access to Cocoa features including menu, window, view, button, and file classes, and a generic interface for Objective-C which should allow use of anything else supported by OS X. Being Forth-based, use of these pre-defined classes and addition of your own is quite a verbose and laborious process. You would probably not want to code an all-singing spreadsheet using iMops, unless you had a lot of time to kill.

Factor: Factor

Factor supports a range of different ways in which to implement a human interface, including a GTK binding, an Objective-C/Cocoa bridge, X11 Xlib and GLX bindings, and an AppleScript bridge. To assist, there are also bindings provided to the standard CoreFoundation, Core Graphics, and Core Text libraries. A multitude of examples is provided, although none shows a full OS X user interface.

Others

DrRacket’s Racket/Scheme has its own X11-based human interface, but includes platform-specific features such as a regular menu bar, Finder file open and save dialogs, etc.

APLX’s APL implements a basic OS X user interface, and provides the standard (for APL, which is of course cryptic in comparison with any other language) auxiliary processor interface to Xcode-developed bundles written in C source, allowing its extension.

R does not have any GUI of its own, and outputs graphics, plots, etc., into hosted windows.

Microsoft’s Visual Studio Code does not yet appear to support the development of its own standalone apps for OS X.

Platypus can bundle most scripts into a more friendly app, with basic access to the UI, and Pashua provides a quick way to add dialog boxes to script languages.

I welcome your suggestions of other SDK interfaces which give access to ‘proper’ OS X apps.