The Early Days

As you said, the most important languages on the Mac in its early days were Microsoft's BASIC, Pascal, and, of course, 68000 assembly. The Macintosh's System Software and ROMs were themselves programmed largely in assembly, with a bit of Pascal thrown in (mostly for pieces that were ported directly from the Lisa). C was merely a niche language in 1984, and I doubt very many copies of these were sold, but that doesn't mean you didn't have choices!

The two earliest C compilers available for Macintosh were Hippo-C and Consulair Mac C.

Other early options included Manx Software's Aztec C (see also this site), Megamax C, and Softworks C (which Kevin Killion claims was "the very first C language compiler for the Mac", for which he wrote the front-end, but I cannot find independent verification for this claim). All of these compilers were available on other platforms, too, especially the Atari ST.

Hippo-C

As far as I can tell, the very first C compiler ever released for the Macintosh was Hippo-C, developed by Wendell Brown, the founder of Hippopotamus Software.

The Wikipedia article on Brown has the following picture, showing him with Steve Jobs, with the caption claiming that the picture was taken "at the launch of Brown's Hippo-C software for Macintosh, January 1984":

^{(Image courtesy of Carol Rukomii Holladay, via Wikipedia, licensed under CC by-SA.)}

Macintosh was introduced to the world on January 24, 1984, and even if Brown had held a separate launch event a few days later for his C compiler, I doubt he could have persuaded Steve Jobs to show up. Plus, Jobs is wearing a silver bow-tie in the picture, which looks like the same one he wore that fateful day at Apple's Annual Shareholders Meeting. This is pretty compelling evidence that Hippo-C was the first C compiler for the Mac, available at the computer's launch.

However, I can find vanishingly little information online about Hippo-C. I find a few editions of InfoWorld offering it for sale, one off-handed mention of it in a November 1984 MUG newsletter ("…how about your impressions of the various development environments…Is Hippo C any good, or what?"), but no reviews of it in Macintosh magazines. Most of what I can find discusses it in relation to the Atari ST, for which it was also available. The Atari ST and the Macintosh both used Motorola's 68000 microprocessor, so it makes sense that the same assemblers and compilers could be used for both, but I can't be entirely certain that Hippo-C ran natively on the Macintosh, as opposed to being a cross-compiler for the platform.

Most likely, it never really caught on, so that by the time programmers had gotten serious and the Mac presses were rolling, it had been displaced by...

Consulair Mac C

It is confirmed by multiple independent sources that Consulair Mac C was available in 1984, but I can't find an exact launch date. This review by Léo Laporte in Issue #3 of MacDeveloper magazine says that the author has "been using it full-time since November, '84", so it was at least commercially available by then. However, I'm not sure how long it was after the Mac's introduction that it became available. Whether or not it was available at the very beginning, this seems to have been the most popular C compiler for the Mac in the early days, and there is plenty of information available about it.

Consulair Mac C is also notable in that it is one of the few—perhaps the only—early C development systems for Macintosh that were not cross-platform. It was developed by Bill Duvall, who worked alongside Doug Englebart at Stanford on ARPAnet and later Xerox PARC on Smalltalk. Considering that Duvall also developed the Macintosh 68000 Development System (an assembler, known as MDS) for Apple, it is no real surprise that his C development system used the same editor and tools, being nearly drop-in compatible with MDS.

All of the source code for the C libraries was supplied with the compiler, so programmers could modify it if they wanted, or even use it as a learning guide. This was pretty important, because examples of Mac code were not readily available at this time! (Only the Str2Dec and Dec2Str functions lacked source code, since these were licensed from Apple, not written by Duvall, and therefore shipped in binary form only.) There was even a makeshift console window provided, so you could actually make use of the decidedly command-line-centric functions in the standard library (printf, getc, etc.) from your Mac applications.

Laporte's review (linked above) provides a number of interesting details about Consulair's Mac C, including what libraries it shipped with, what aspects of the language it supported, what else you needed to get started, and how much it cost. I won't quote all of this here, so go and read the article!

There's also a March 1991 interview with Bill Duvall, conducted by Michael Swaine and originally published in Dr. Dobb's Journal, available on this site. Although most of it is focused on Duvall's thoughts about HyperCard and later ventures, it does contain some interesting and relevant information about his C development system; in particular:

Dr. Dobb's Journal: When did you first get involved with the Macintosh?

Duvall: I became involved with the Mac some years before it was released when Apple asked me to write an assembly language development system for the Macintosh: an editor, a debugger, an assembler, and a linker. Which I did.

DDJ: Why did Apple come to you?

Duvall: The fellow that Apple hired to head up the Mac as an engineering manager was Bob Belleville, a person with whom I had done a lot of work at PARC. He had a need for a development system, knew that I had some expertise in that area, and asked me to come and do it.

DDJ: Early Macintosh developers may know you as the author of that development system, and more Mac developers should remember your company, Consulair, for its C compiler. But Consulair was around before the Mac.

Duvall: Consulair was first formed in the mid-'70s. Most of our work was in the area of word processing; in particular, we did a lot of work in one of the early Japanese word processors. There was a fair amount of systems work, writing operating systems. There was some language development; we did some debugging systems, things like that. In general, [it was] what you would classify as advanced development or systems programming.

DDJ: You were doing tools for programmers, then?

Duvall: We always worked on development systems, but primarily up until the early to mid-'80s we had done development systems as internal tools. In fact, we first wrote what later became the Consulair C compiler in the late '70s as a tool for programming our own projects. This was just after the publication of Kernighan and Richie's original book, and I looked around to see what was the best system programming language around, one that was going to be around for the next few years, and came to the conclusion that C was probably the best candidate. So I wrote a C compiler.

DDJ: Where did the commercial Consulair C compiler come into the picture?

Duvall: After the Mac was released to the world it became apparent that there was a need for a C language development system. Since we had a C compiler that we had been using internally for five years, it was -- I won't say it was a short step, but it was a logical step -- to put that in a form that could be used commercially on the Macintosh.

DDJ: It was well received. Didn't you get the first MacUser Editor's Choice Award for a development language?

Duvall: It's difficult to answer something like that. I, like many people, suffer from the programmer's dilemma.

DDJ: The programmer's dilemma?

Duvall: Any time you've worked on a program, you realize all of the faults in it. It's difficult to go back and look at it and say, yes, that was really important. Rather, you look at it and say, "Oh my God." But, yeah, I think it played an important role in the early development of the Mac, although clearly it was superceded by MPW and Lightspeed.

Andy Hertzfeld also recalls the development of Consulair C, as part of a larger recollection in which he describes how he developed a resource compiler that ran natively on the Mac, allowing him to ditch the Lisa when writing Mac programs:

I went on leave of absence from Apple in March 1984 (see Leave Of Absence), but I still was excited about writing software for Macintosh as an independent developer, and was full of ideas about different programs to write. But I wasn't happy about the fact that you still needed a Lisa to write software for the Mac; among other things, the recent linker problem had left a bad taste in my mouth regarding the Lisa development system. I had a Lisa at my house, but it really belonged to Apple, and I didn't want to have to buy one. I decided to try to cobble together an entirely Mac-based development system.

Bill Duvall was an old friend of Bob Belleville's from Xerox who we seeded with a Mac prototype in the spring of 1983 so he could port his development system to it, including an assembler and a C compiler, to be sold by his own tiny company named Consulair. His linker even generated Macintosh code resources, but there was no equivalent of RMaker for building the other resources required by a Mac application - you still had to do that on a Lisa. I decided to rewrite RMaker for the Mac, so I could finally abandon the Lisa. I used assembly language, since the assembler was much further along than Consulair C was at the time. In a week or so, I had a new RMaker that was integrated with the Consulair tools, so you finally could write a complete application with just a Macintosh.

In the summer of 1984, I got a call from Dan Cochran, who was the marketing person at Apple in charge of developer tools. He had heard about my new version of RMaker, and wanted to bundle it with the Consulair package. After a bit of negotiation, I sold it to Apple in exchange for a brand new LaserWriter prototype. I drove up to Bill Duvall's house in the Berkeley hills to help him incorporate RMaker into his system. When my reward arrived in October, I thought it was pretty cool to be the first on my block to have a LaserWriter, three months before it was officially announced.

This tells us a couple of neat things. First, Bill Duvall was given a Mac prototype in the spring of 1983 by Apple, which is what allowed him to have his development system available so soon. Also, the resource maker that eventually shipped with Consulair C was written (in assembler) by Hertzfeld himself—one of the original members of the Macintosh software development team.

One significant limitation of Consulair Mac C—at least to our modern eyes—was that it did not include a source-level debugger. You had to use something like MacsBug or TMON (by ICOM Simultations, which was way better than MacsBug, but not free). Consulair C did generate debugging symbols in a standard format that could be imported into either MacsBug or TMON, though, so you weren't totally on your own after a crash dumped you into a sea of object code.

Although you can find later versions of Consulair Mac C for download online (for example, Macintosh Garden and Mac GUI both offer version 5, which I believe is the last version ever released, and includes updates that make it HFS-compatible), I don't see anywhere that version 1 is hosted. Nor, unfortunately, do I have a copy of any of these older versions.

The Halcyon Days

Moving forward in time a bit, by 1986, C had joined Pascal as one of the premier and popular development languages for Macintosh software. (Apple themselves, though, were still heavily invested in Pascal. Macintosh's System Software continued to be written in a mix of 68000 assembly and Pascal up through System 6; System 7, circa 1990–91, was the first to have parts written in C.)

Although Consulair's Mac C was still around, the two principal players by 1986 were LightSpeed C and Apple's own Macintosh Programmer's Workshop (MPW).

Macintosh Programmer's Workshop

Although version 1.0 of MPW was released on September 24, 1986 (according to Wikipedia), with development having begun in late 1985 by Rick Meyers, Jeff Parrish, and Dan Keller (née Smith), this early version did not include a C compiler. Originally, MPW only supported Pascal, which was the language that Apple initially pushed for Macintosh software development. MPW was the official replacement for the Lisa Workshop, and what finally freed Mac programmers from having to cross-develop on Lisas. (Although, I believe you needed at least 1 MB of RAM to run MPW, which naturally limited you to developing on the newly-released [in 1986!] Macintosh Plus.)

C support did not come to MPW until version 2.0, released on July 20, 1987. The C compiler that was included in this version was written by Green Hills' Software, under contract with Apple, with Mike Shannon serving as liaison at Apple. Interestingly, Green Hills wrote their C compiler in C—I'm not sure which compiler they used to bootstrap it, though! Green Hills Software has been around since 1982, and is still around today, still developing compilers and other development tools, mainly for embedded systems.

In version 3.0, MPW finally shipped with a C compiler developed in-house by Apple. Unlike the Green Hills compiler that it replaced, Apple's compiler was written in Apple Pascal and shared its code generator with MPW's Pascal compiler (the one that had been there since v1.0). It was this compiler that became famous for its quirky and comical error messages.

What was unique about MPW was that it offered what was essentially a Unix-style shell (based on csh), running natively on the Macintosh. You could run shell scripts, there were command-line tools, and decidedly un-Mac-like behaviors (such as output redirection) were possible. MPW was really quite an odd duck, since it was not at all Mac-like, but it was also not fully Unix-compatible, either. It was also expensive in these early days (before Apple started giving it away for free, which didn't happen until after the PowerPC transition), so it was really only used by professional programmers.

Again, later versions of MPW are readily available online (although no longer from Apple themselves, who would prefer to forget that the "classic" Mac OS ever existed), but I don't know where you can download any of the early versions.

One last thing to note: while I believe (though I can't find a confirmatory source) that even the earliest version of MPW required a Macintosh 512k, you could run Consulair Mac C on a 128k Macintosh (albeit with a bad case of disk-swapper's elbow, and a host of other challenges, like some of the RAM that was normally set aside for the screen buffer being repurposed for compilation, causing parts of your screen to fill with noise/"snow"—but hey, it worked)!

LightSpeed C

LightSpeed C was really the definitive and most widespread C development environment on the Macintosh. (It was also an extremely popular development environment on the 8-bit Atari machines of similar vintage.) It was developed by Michael Kahl, of THINK Technologies, and released in mid-1986. THINK Technologies was later gobbled up by Symantec Corporation (like so many other independent vendors), who continued to develop and release the tool under the name THINK C (having dropped "LightSpeed" from the name starting with version 4.0, circa 1988).

No matter what it was called, LightSpeed/THINK C was powerful, fast, and (relatively) cheap—a winning combination. BYTE magazine awarded it "Distinction" in the 1989 BYTE Awards, citing its "powerful features and low price". A July, 1986 article in MacTech magazine, by Bob Gordon, recommends LightSpeed C as an excellent way to learn how to program C on the Macintosh, noting:

Its major advantages from our point of view is that it is very fast at compiling and linking and that it places you at the correct position in your source file if the compiler detects an error. The result is that you can edit, compile, link, and run your program very rapidly, make small variations in the code and determine their effect, and generally have the opportunity to make more mistakes in a shorter period of time. If we learn from our mistakes, Lightspeed C is a useful tool for learning C on the Macintosh.

LightspeedC is different from the other available C compilers as it does not use a Unix-like setting [Yea! -Ed.] -nor does it use separate programs in the Macintosh window environment. Instead it creates its own enviornment (that follows the Macintosh User Interface) from which all editing, compiling, linking, and running take place. The integrated editor is roughly similar to the Edit application. Menus available from inside the editor allow you to run, compile, or just check the syntax. As soon as the compiler detects an error, you are returned to the editor with the cursor at the location the compiler found the error. In other words, you get one error at a time.

The link operation is extremely fast.

However, Gordon does go on to disclaim a few problems in LightSpeed C, although most of these do not appear to be actual problems with the development environment, but rather behaviors that he found confusing. A significant criticism, leveled often by reviewers and columnists, was that early versions did not include an assembler. Of course, I'm not sure how much that would have actually mattered to the average Mac programmer. The low-level gurus were probably already using MPW, which did come with an assembler, and everyone else was writing in C because they didn't want to use assembly. If they really needed one, assemblers were available from other vendors. And, THINK C eventually did ship with an assembler; in fact, it even supported inline assembly with the C compiler, in a very easy-to-use implementation.

Although slightly less famous and less renowned than THINK Pascal, LightSpeed/THINK C was really the primary C development environment for Macintosh programmers through the late 1980s and early 1990s, until it was replaced by Metrowerks' CodeWarrior circa 1994 (in part because Symantec had ruined it, but probably more so because of turmoil from the PowerPC transition, but that's getting far outside the scope of this answer). Interestingly, though, much of the development on CodeWarrior was done by folks who had worked on the original THINK C team, and CodeWarrior retained one of the most important features of THINK C: fast compile times.

LightningPaint was famously written in LightSpeed C, from which it borrows its name. This app was essentially a clone of MacPaint, but continued to be distributed as shareware long after Apple dropped MacPaint.

Version 3.01 of LightSpeed C is also available on Macintosh Garden and Mac GUI, along with later versions of THINK C. Alas, older versions are missing-in-action, as for all the other development tools discussed here.