One of the best things about a class library is the ability to add new functions by addition of new classes and addition of new methods to existing classes.  As Apple expanded MacApp, they could have done that that with minimal harm to existing software.  On the other hand, if they decided to alter something common to all classes, like the way that new objects are allocated or initialized or deallocated, then that would break everything.  If they did that, every single piece of code that anybody had ever written would have to be changed.  But they’d never do that, right?

MacApp.Tech$ and the MacApp Developer’s Association

    MacApp users were able to communicate directly with the MacApp development team using the MacApp.Tech$ mail list on AppleLink.  Apple kept an archive of MacApp.Tech$ and distributed it with new releases of MacApp on the famous Essential Objects and Tools (E.T.O.) periodic CD distribution (starting late 1997 renamed ADC Tool Chest). It makes for pretty interesting reading.  In addition to bug reports and questions about how to do things in MacApp and announcements from Apple about new products and releases, there were a lot of posts that were basically requests to add a host of additional features to the library or to alter it in minor or sometimes really fundamental way. Throughout the entire period that Apple was supporting MacApp, the Macintosh operating system underwent rapid change.  New APIs were added every year, and all Macintosh programmers scrambled to keep up with changes and implement the new features.  MacApp programmers often expected Apple to incorporate all those new features into MacApp as soon as they were released.  It is important to remember that the entire source code for the project was included in MacApp and in the possession of every MacApp programmer.  The Macintosh toolbox was also available.  If a MacApp programmer wanted to use some new API not yet included in MacApp, he could just do it.  The original intention of the MacApp Developer’s Association was to facilitate the distribution of user-contributed additions to the class library.  But most programmers proved reluctant to make changes and additions to MacApp.  In fact, it was risky to make changes in MacApp, because its classes were very tightly interconnected and dependent on each other, and the library was changed often by Apple.  Updates were done by replacing the entire source tree and recompiling.  Messing around with code within MacApp made your distribution very difficult to update.

MacApp version 2

    Version 2 of MacApp was released during System 6 days.  In retrospect, it seems like a pretty orderly update, in that it was mostly additions, and did not require a lot of changes to existing programs.  One exception to this was a change in the class responsible for scrolling.  Scrolling was a little bit of a pain to support on the Macintosh, and one great advantage of MacApp was that it included support for scrolling views that made them really easy to create.  In version 1 of MacApp the class was called TFrame.  A program’s window on the screen was represented by a TWindow object, and the content of the window could contain one or more scrolling region controlled by TFrame objects.  TFrames included the scroll bars and handled all the events that were directed at the scroll bars.  They created a coordinate system for drawing inside the scrollable region.  If you drew into that coordinate system, you didn’t have to worry about scrolling.  Views could be placed inside the frames.  In version 2, TFrame was renamed TScroller and became a subclass of TView.  It made sense I guess, but it caused a lot of changes in working programs.  Busy people whose time was valuable didn’t like to change working code just to keep it working in the new version of MacApp.  I guess there were probably some people who didn’t adopt version 2 for that reason, but probably those were few, because there was a big advantage to upgrading.  Version 2 introduced view resources, and a graphical editor, ViewEdit.  Resources were great, and especially important for user interface components.  The opportunity to lay out your window, scroller, and views hierarchy graphically, and have that turned into a resource that could be read in at run time was a big advantage.

    Version 2 had a lot of bugs.  Bugs drove the programmers crazy, and there was some serious griping in AppleLink.  Apple responded with version 2.0.1, that was mostly a set of bug fixes for version 2. They also issued a technical note, entitled “Bugs in MacApp? Yes, But I Love It!”  This note had a really long list of issues and changes for  MacApp version 2, and a somewhat defensive statement about how it was a big piece of code that of course would have a lot of bugs. It also had this statement:

“The MacApp Management would like to note that MacApp is a high velocity ride with many twists and turns (all alike).  Please keep your hands inside at all times.”

This, it turned out, was true.

Mac App version 3 and the (sorta) switch to C++

    In 1991, System 7 was released, right in the middle of all the bug identification and fixing, and adapting to the changes in version 2.  There were a lot of new APIs in System 7, and there was a lot of excitement for programmers in making their programs look and work right in System 7.  MacApp provided no direct support for any of that.  More immediately, changes in the operating system in System 7 actually broke some features of MacApp (as it did many other things).  There were some quick bug fixes required to make programs for System 7, not to mention taking advantage of its new features.  At the same time, C++ was taking off as the object-oriented language of choice among programmers.  You could argue that it was bogus to prefer C++ to Object Pascal.  They weren’t really different in capability.  Powerful and complicated things like the standard template library and multiple inheritance didn’t exist yet.  But whether there was a good reason or not, most programmers wanted to learn to use C++, and use it if possible.  MacApp was designed to be usable from multiple languages (even assembly), and from the beginning Apple said that it was possible to use it from C++.  It was true, but writing a MacApp program in C++ was a little unnatural, and raised a lot of questions.  The MacApp.Tech$ list was busy during this time, with programmers looking forward to the next version of MacApp, which they hoped would be more C++ friendly, and would have good support for System 7. 

   Version 3 of MacApp was very revolutionary in one sense.  It was intended for use with C++, and it was clear right away that Apple meant to phase out Object Pascal.  I don’t think that the pressure from this came from MacApp users.  There certainly were people arguing for this on MacApp.Tech$, but it was a subdued discussion, and for every pro-C++ voice there was at least one defending Object Pascal.  I think it must have come from within Apple.  In any case, pre-release versions of version 3 gave programmers a long time to think about what was coming.  There were some other changes.  There was a new and improved view resource (called ‘View’ instead of ‘view’), and there was support for some new System 7 features.  But MacApp v3 was a strange mixture of the original MacApp and a new one that was coming.  It was intended to be used from C++ but it didn’t use object construction and destruction methods native to that language.  You had to initialize and release MacApp objects using the Object Pascal-style methods.  And objects were still allocated using the Macintosh memory manager, and so were handles.  The Macintosh memory manager was clever and versatile, but it was a little slow if you were making and destroying a lot of objects.  And C++ objects were supposed to be referred to by pointers.  It was obvious that MacApp was going to a new place, and this was just a stop along the road.  Some programmers saw this coming, and did not make the transition to version 3.  Because you had the source code to the library, there was no need to follow Apple where it was planning to go with this program.

The Bedrock Head Fake

     MacApp version 3 went final in 1992.  At WWDC in that same year, Apple and Symantec announced that they were working together on the successor to MacApp.  This new object-oriented framework was known by its codename, Bedrock.  It was to be a thoroughly modern class library, reflecting a lot of new ideas about object oriented programming that were emerging at the time.  These ideas were to be outlined in the influential book “Object Oriented Analysis and Design” by Grady Booch.  The book would be published in 1993, but the ideas had already started to have wide sway.  The most important part of it for MacApp and Bedrock was the issue of whether the class library should consist of a single totally interconnected class tree (starting with TObject) or rather a forest of small relatively  independent class libraries that implement a limited set of functions.  The use of multiple inheritance trees was facilitated by multiple inheritance.  In languages that supported multiple inheritance (like C++ starting with Release 2, from about 1991), functions represented by multiple class trees could be readily combined.  Bedrock was not to be a single inheritance tree, but rather a bunch of them.  It was announced that it would be released in the first half of 1993.  MacApp was declared dead, right about the time that version 3 was released.  Obviously, Apple was not of one mind regarding this stuff.  But in January 1993, Macintosh pundit Bob Cringley reported in InfoWorld that Bedrock was “stone cold”, and Bedrock programmers were being laid off.  Symantec’s Steve Levine assured MacApp.Tech$ readers that it was not true, and that Bedrock was fine and on track for a 1993 release.  But there was no 1993 release, and in January 1994, Apple and Symantec announced that they were canceling the Bedrock project, and that Apple would have the rights to whatever had come of it to use as they pleased.  Apple used the Bedrock technology to create a new class library for use by OpenDoc, and MacApp got a new lease on life.  This was a crazy time at Apple, and Apple’s lack of a coherent strategy took a toll on programmers.  Lots of MacApp programmers bailed at this time.  And things were about to change again.

The PowerPC Revolution

   In 1994, Apple announced that it was abandoning the Motorola 680x0 processor family, and going with the IBM PowerPC.  This changed a lot of things, including MacApp (which still contained a lot of 68k-specific code).  A new version of MacApp was necessary. Programmers who were not too shell-shocked to continue with MacApp were open to big changes, and there was some new Bedrock-derived technology available at Apple.  Version 3.1 was a major break with the previous MacApp tradition. System 7 had a kind of virtual memory that mitigated the need for the traditional Macintosh memory manager, and so the Bedrock memory manager could be adopted for object allocation.  In the new system objects were allocated as non-relocatable allocations in a special object heap and referred to by pointer in the standard C++ way.  MacApp programs could not support System 6, and Object Pascal support was abandoned completely.  While they were at it, MacApp architects changed the names of a lot of methods for no reason other than to make them more pleasing to the eye.  Porting your MacApp program to version 3.1 was a big job, and Apple provided a bunch of tools, called Witches Brew, to automate as much of it as they could. And on top of this, AppleScript had been announced.  It seemed to be the future of Macintosh programming, and guess what-- MacApp 3.1 had no support for AppleScript. If you were sticking with MacApp at this point, you were a true die-hard.  But the demise of Bedrock gave some hope that Apple would commit itself to MacApp as its premier programming framework.  AppleScript support started to appear in prerelease versions of MacApp in 1994.  There was hope.

CodeWarrior and PowerPlant

    The transition to PowerPC changed the landscape for Macintosh programming tools.  Although MPW kept up with the changes very well, most programmers, including those working at Apple, gradually shifted to a new IDE, CodeWarrior by a Quebec company, called Metrowerks. They released their first version of CodeWarrior at WWDC in 1994, about the same time as MacApp v3.1 was released.  CodeWarrior offered very rapid compilation and a modern IDE with built-in debugger.   It had a great C++ compiler and could compile MacApp.  Pretty soon, CodeWarrior became the best environment for building MacApp and MacApp programs.  And Metrowerks built their own class library, PowerPlant.  PowerPlant was not an advanced system inspired by the latest ideas about object-oriented programming.  It was a practical system that tried to provide object-oriented solutions to all the operating system features that Macintosh programmers needed to use.  It wasn’t a research project, it was a product.  PowerPlant stayed stable as things changed, and grew by additions, not by revolutionary redesign.  Coming to PowerPlant was like finding a stable foster home for MacApp programmers.  Although MacApp continued to be supported at Apple, it gradually was used less and less, even by Apple programmers.  More and more of the Macintosh operating system came to be built in PowerPlant.  Even the Finder.  As late as OS X version 10.4, the Finder was still a PowerPlant application.

Redesigned, Terminated, and A New Beginning

    The transition represented by version 3.1 of MacApp was finalized with version 3.3 in 1995.  Development of MacApp slowed greatly at this point.  This may seem like a bad thing, but to harried MacApp programmers it was a relief to be able to spend their time adding new features to their programs instead of just keeping current with the class library.  Also, Apple MacApp documentation, which had always been great but had often had trouble keeping up with the changes, finally got current and stayed that way.  But pre-releases of MacApp that arrived with E.T.O. showed some changes coming in MacApp.  The version numbers were renamed, starting as MacApp 3.3 Release 10, and with increasing release numbers after that.  Soon, those were known as just R11, R12, etc.  The naming scheme made them seem like small changes, but they were not.  There were two big threads of change in these releases. The first was Windows support.  There was hope that MacApp could become a cross-platform development system.  In those dark days, it was thought that all development platforms had to support Windows or suffer ultimate demise.  The other thread was the breakup of the single inheritance tree of MacApp; the fulfillment of Apple’s Bedrock ambitions. 

    TObject was removed as a part of Release 13 in 1997, and MacApp became a set of class libraries.  Confusingly, one  library was called MacApp, and the rest were a group of mostly independent libraries called the Apple Class Suites. Windows builds in Release 14 were reputed to work, at least to some degree (I never tried it). 

    In the years following the NeXT purchase and the development of Rhapsody and Mac OS X, the future of MacApp seemed grim.  NeXT engineers brought their own class library to Apple, as well as a contempt for the programming tools developed at Apple.  But Rhapsody failed to win the enthusiasm of big programming houses (especially Adobe and Microsoft), and the Macintosh programming model was modernized and made workable as Carbon.  This was an opportunity for MacApp.  MacApp was carbonized, and ported to Apple’s Project Builder.  The final version, R15.1 (2001), was a workable environment for building programs for Mac OS X.  But apparently MacApp was not part of the Apple strategy for programming for OS X.  The MacApp project was cancelled soon after the release of R15.1.  The MacApp community was informed by this post on the macapp-dev list (the successor to MacApp.Tech$).

    Apple allowed MacApp to continue to be supported privately, and it has continued to be so, because of the efforts of Mike Rossetti and (especially) Steve Graesser at Club MacApp.  The current version is R16.1.  It is a completely usable Carbon framework and compatible with XCode 3 and OS X 6 (Snow Leopard).  Of course, it is probably rare that anybody starts a new program using MacApp today, but it would be possible to do, and it is relatively easy to keep your old MacApp programs working and supporting new operating system features.  I guess that Apple may eventually drop support for Carbon programs.  They have already indicated their intentions by denying Carbon programs 64 bit status.  The old Apple would have probably terminated support for Carbon by now.  But the current administration in Cupertino has created a much more stable environment for programmers, despite the continued rapid evolution of platforms and technologies.  And it looks like Carbon will live on, at least for as while, as the announcement of OS X 10.7 (Lion) has been announced, and Carbon seems to be still there.  MacApp might live a little longer. Thanks, ClubMacApp.

The Most Famous of all MacApp Programs

      Photoshop was written by Thomas Knoll in the late 1980’s.  It was made using MacApp version 1.  It is easy to verify this by looking at the About... box, which includes the required credit to MacApp in it.  A similar credit is present in the every version of Photoshop I have looked at.  The last one I have is version 10 (the one in CS3).  Versions 1 and 2 of Photoshop were done using Object Pascal and MacApp version 1, as indicated by a quick look using ResEdit.  They have a code segment entitled %_MethTables, which is the standard place for the MacApp method tables, and no ‘view’ resources. My copy of version 4 is a fat binary, and has ‘view’  and ‘CMNU’ resources, indicating that it was made using MacApp version 2.  But that is a 1997 release.  Clearly, Knoll and Adobe did not make the transition to MacApp version 3.  In the About... box of version 4, MacApp is credited for the years 1986-1993.  That is consistent with having not made the version 3 transition.  In version 5.5 (1999), the strings in menu resources have been crazily mangled in a way that was never done in MacApp, and Apple is credited for MacApp for the years 1985-1988.  Apparently,  Photoshop reduced its use of MacApp code in the meantime.  Presumably they quit using any new MacApp technology later than 1988.  Seems not completely right, because the ‘view’ resource was part of version 2, but whatever. The OS X version in CS3 still has some MacApp resources in it, and credits MacApp, but it’s a little hard to see what MacApp code they could be using now.

   No doubt, Adobe forked their own version of MacApp some time near the release of version 3 of the library, and continued to use if for a long time after that, moving it in new directions of their own making.  Maybe I should have done that.  No, I don’t think so.  MacApp was a wild ride, but it was also an education.  Thanks, MacApp folks, for taking me along.

-- BG (basalgangster@macGUI.com)