The Early Days
The very first C compiler ever released for the Macintosh was Consulair Mac C, 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.
I know that Consulair Mac C was released 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. I'm not sure how long it took after the January 24, 1984 introduction of the original Mac for it to become available, though.
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 operating system and ROM were themselves programmed in a mix of assembler and Pascal. C was merely a niche language in 1984, and I doubt that Consulair Corp. sold very many copies early on.
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!
Thre's also a March 1991 interview with Bill Duvall, conducted by Michael Swaine, available on this site. It looks like this was originally published in Dr. Dobb's Journal. 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. 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.