MacApp

Pascal versions MacApp was a direct descendant of the Lisa Toolkit, Apple's first effort in designing an object-oriented application framework, led by Larry Tesler. The engineering team for the Toolkit included Larry Rosenstein, Scott Wallace, and Ken Doyle. Toolkit was written in a custom language known as Clascal, which added object-oriented techniques to the Pascal language. Initially, development for the Mac was carried out using a cross-compiler in Lisa Workshop. As Mac sales effectively ended Lisa sales, an effort began to build a new development platform for the Mac. Lisa Programmer's Workshop became in 1985 the Macintosh Programmer's Workshop, or MPW. As part of this process, Clascal was updated to become Object Pascal and Lisa Toolkit offered design notes for what became MacApp. As Apple announced it was dropping MPW Pascal support in 1992, this version didn't get updated, not even with System 7 support, and Pascal developers were left out on their own to port MacApp 2.0 to the PowerPC. C++ versions By this point, in the late 1980s, the market was moving towards C++, and the beta version of Apple C++ compiler appeared in 1989, around the MacApp 2.0 release. This move was subject to a long and heated debate between proponents of Object Pascal and C++ in the Usenet and other forums. Nevertheless, 3.0 managed to garner a reasonable following after its release in 1991, even though the developer suite, MPW, was growing outdated. Apple then downsized the entire developer tools group, leaving both MacApp and MPW understaffed. One of the reasons for this downsizing was Apple's long saga of attempting to introduce the "next great platform" for development, almost always in the form of a cross-platform system of some sort. Their first attempt was Bedrock, a class library created in partnership with Symantec that ran on the Mac and Windows, which died a lingering death as both parties eventually gave up on working with the other. One of the reasons for their problems was the creation of OpenDoc, which was itself developed into a cross-platform system that competed directly with Bedrock. There were some attempts to position Bedrock as an OpenDoc platform, on 28 August 2001 to the delight of many. However, in October the product was killed once again, this time forever, and support for existing versions of MacApp officially ended. The Carbon-compliant PowerPlant X did not ship until 2004, and today Cocoa is almost universal for both MacOS and iOS programming. MacApp today MacApp is being kept alive by a dedicated group of developers who have maintained and enhanced the framework since Apple stopped supporting it in 2001. MacApp has been updated to fully support Carbon Events, Universal Binaries, Unicode Text, MLTE control, DataBrowser control, FSRefs, XML parsing, Custom Controls, Composite Window, Drawer Window, HIView Window and Custom Windows. MacApp also has C++ wrapper classes for HIObject and HIView. Also the Pascal version, based mainly on MacApp-2, has been ported to Mac OS X and Xcode. It features long Unicode filenames and streamed documents with automatic byte-swapping. MacApp supports the Xcode IDE. In fact at WWDC 2005, after Apple announced the transition to Intel CPUs, it took a single developer 48 hours to update MacApp and the MacApp example apps to support Universal Binaries. ==Description==

: This description is based on MacApp 3.0, which had a more advanced underlying model than the earlier 2.0 and differed in many significant ways. The Mac OS itself has a very simple event handing system. The event structure passed from the operating system to the application has only an event type like "keypress" or "mouseclick", and details of its location and the modifier keys being held down. It is up to the application to decode this simple information into the action the user carried out, for instance, clicking on a menu command. Decoding this could be difficult, running through lists of on-screen objects and checking if the event took place within their bounds. MacApp provided a solution to this problem using the command pattern, in which user actions are encapsulated in objects containing event details, and then sent to the proper object to carry them out. The logic of mapping the event to the "proper object" was handled entirely within the framework and its runtime, greatly decreasing the complexity of this task. It is the role of MacApp's internal machinery to take the basic OS events, translate them into semantically higher-level commands, and then route the command to the proper object. Not only did MacApp relieve the author of having to write this code, which every program requires, but also as a side-effect this design cleanly separated code into commands, user-facing actions, and their handlers, the internal code that did the work. For instance, one might have commands for "Turn Green" and "Turn Red", both of which are handled by a single function, ChangeColor(). A program that cleanly separated commands and handlers was known, in Apple parlance, factored. Factoring of a program was particularly important in later versions of the Mac OS, starting with System 7. System 7 introduced the Apple Events system, which expanded the original Mac OS's event system with a much richer one that could be sent between applications, not just from the OS to a particular application. This was combined with the AppleScript system which allowed these Events to be generated from scripting code. In MacApp 3.0, Apple Events were decoded into the same commands as if they had been initiated by direct user actions, meaning that the developer didn't have to write much, if any, code to directly handle Apple Events. This was a major problem for developers using earlier systems, including MacApp 2.0, which had no such separation and often led to Apple Event support being left out. In keeping with its role as an application framework, MacApp also included a number of pre-rolled objects covering most of the basic Mac GUI—windows, menus, dialogs and similar widgets were all represented within the system. Unfortunately, Apple typically supplied lightweight wrappers over existing internal Mac OS code instead of providing systems that were usable in the "real world". For instance, the TTEView class was offered as the standard text editor widget, but the underlying TextEdit implementation was severely limited and Apple itself often stated it should not be used for professional applications. As a result, developers were often forced to buy add-on objects to address these sorts of needs, or roll their own. The lack of a set of professional quality GUI objects can be considered one of MacApp's biggest problems. These problem has been addressed with the release of MacApp R16. MacApp R16 uses standard Carbon controls for all MacApp GUI objects. For instance, Carbon introduced the Multilingual Text Engine (MLTE) for full Unicode text and long-document support. In R16, the original TTEView class has been superseded by the TMLTEView, which uses the MLTE control. ==Notable Users==

Adobe Photoshop was originally written with MacApp 1.1.1, in Object Pascal, and later ported to C++ and MacApp 3.0 for Photoshop 2.5. After MacApp cancellation by Apple, maintenance was taken over internally by the Photoshop development team, ported to PowerPC, and transformed to be shared with the Windows platform port. As of 2025, some legacy elements are still part of the code for the Photoshop UI. ==References==