© 2024 Adriaan van Os  

MacApp back then. ‘The future is OOP’

MacApp was introduced by Apple as follows:

MacApp® is a tool that helps programmers create better applications in less time. It helps programmers work faster by allowing them to program in a style well suited to Macintosh® applications. It also facilitates the implementation of the standard Macintosh interface, including everything from scrollable, resizable windows to multipage printing and undoable commands. It makes programs better because it provides code carefully written by expert Macintosh programmers; as long as you exercise similar care, MacApp applications are virtually guaranteed to be compatible across the whole Macintosh line and to work with all other Apple® products.

At the same time, developing software through procedural programming was deemed ‘too complex’. Programmers were supposed to learn object-oriented programming ‘to prepare for the future’.

So, developers started to use MacApp for application development.

Then, Apple lost interest in the project, as MacApp was no longer deemed ‘hip’. Developers were left in the cold, as with any Apple technology, before and after. Wikipedia gives an overview of MacApp’s history.

BeamMaker, a MacApp application written by Marc Roose on behalf of Voestalpine SADEF, running native on a M2 mini

MacApp today

Wow! Beautiful! Really impressive work. Thanks so much for sharing!    Andy Muehlhausen, Apple Inc.

Since, I have been maintaining the Pascal version of MacApp, up to the current version that runs 64-bit native on Apple M2 processors. With a lot of help from Marc Roose of Voestalpine SADEF.

The current code has come a long way from what we inherited from Apple. The Apple code still contained such things as Motorola 68000-assembly. Over the years, we ported the code from MPW Pascal to CodeWarrior and PowerPC, then it was ‘carbonized’ and ported to FreePascal and Intel. For the 64-bit port to Cocoa, a complete rewrite was necessary, a huge task. Hardly a single line of the original Apple code is still in place.

We haven’t been afraid of making changes to MacApp, where necessary:

• to make MacApp more logically consistent
• to adapt to conventions and limitations of Cocoa
• to improve the code in general.

With all the many changes, the main pillars of MacApp still stand:

• reading and writing ViewEdit and ResEdit resources
• views, windows, dialogs, scrollers, grids, documents, controls, cursors, etcetera
• high-level event- and menu-handling overides
• commands and undos
• emulation of most of Quickdraw
• emulation of large parts of the classic MacOS toolbox
• file specs with long Unicode filenames
• multi-page printing of views and subviews
• fundamental data-structures: dynamic lists and arrays
• the original MacApp demo programs, in enhanced form.

Added are:

• A menu handling toolbox, including reading 'cmnu', 'MENU' and 'MBAR' resources
• Unicode support for all operations
• fast double-buffered asynchronous file IO
• fast streams with built-in asynchronous compression
• thread and thread-synchronizing support
• document-based automatic multiple undo-redo
• a large graphics toolbox
• an xml file writer
• an email relaying unit, using system-installed tools
• powerful text-edit faciities
• fundamental data-structures: single- and double-linked lists
• fundamental data-structures: avl-balanced binary trees
• fundamental data-structures: differential binary trees
• threaded and unthreaded iteration over all built-in fundamental data-structures
• new control types, including a pdf-viewer and a html-viewer.
• a picture-editing demo program named Filtershop
• a text-editing demo program named TextEditor.

In preparation are:

• Headers for Objective-C and Swift.

SectionProperties, a MacApp application written by Marc Roose on behalf of Voestalpine SADEF, running native on a M2 mini

inside MacApp

The 2024 MacApp code base consists of three parts:

• system software headers
• a ‘MB’ procedural library of low-level routines
• a ‘MacApp’ class library of high-level routines.

The MacApp class tree (not including procedural libraries) is given here. It includes a method-index.

For more information, please contact Adriaan van Os, email