Q:

Back in the late 1980s, how was commercial software for 8-bit home computers developed?

When hobbyists wanted to write software for e.g. the Commodore 64, they either used the built-in BASIC interpreter (with all its limitations) or some native tools, like compilers for other languages or, most of the time, assemblers. This had a lot of drawbacks, like the limited screen size, the slow disk I/O, the limited RAM available for the tools and your own code, etc. So, nowadays, you'd have to be crazy not to use a PC and some nice cross-development tools when targeting these old machines.
There were some nice commercial applications and a lot more nice commercial games available and I wonder how these were developed. Did the programmers indeed work on the target machine with all the drawbacks, or did at least some of the development shops have more powerful workstations with e.g. fast hard disks and cross-assemblers?

A:

It varied. There was no single method. Some people used assemblers on the target machine, others used cross-development tools. 
As an example of a large product for an 8-bit machine, I worked on the BitStik CAD software for Apple II and BBC Micro systems from 1984 to 1986. That used Apple II machines with Z80 CP/M cards for coding (with WordStar) and assembling and linking (with Microsoft's M80 assembler, using its .6502 directive). We had a very simple networked hard disk system for source code, which used ribbon cables to connect machines to the disk cabinet. 
Executables would be written onto bootable Apple DOS disks, and then you'd reboot into Apple DOS and try out your changes. This meant we were using the same machines for coding and testing, but frequently switching between OSes on them. 
We had machines with hardware debugger cards (can't remember the name) for difficult problems. It worked pretty well, all things considered. 
Since WordStar has attracted attention, this was "Classic" WordStar 3.3 IIRC. It has a "Non-Document" mode where it works as a plain text editor, and if you turned off the menus and delays, it was decently fast on a 3.58MHz Z80. Its "Column Mode", which lets you define and operate on a rectangular block of text that doesn't have to contain complete lines, was pretty useful when writing assembler code. 
Source control was entirely manual. There was a big wallchart for developers to claim control of source files. They had the copies they were working on in their personal areas of the hard disk, and would put their changed versions back into the shared area and cross out their initials on the chart. Backups were taken weekly, and before any major changes. More copies than that would have been hard work: the hard disk was only 20MB for five developers. 
There were a lot of floppy disks around, and we had to be disciplined with them. After one new developer was a problem with that, the rule became that any unlabelled disk was subject to summary destruction, by anyone who felt like it. 

A:

This had a lot of drawbacks, like the limited screen size, the slow Disk I/O, the limited RAM needed for the tools and your own code, etc.

Those are just drawbacks of having a slower or less capable computer. As that was the norm, I don't think anyone thought much of it. Even considering that, a lot of that may be alleviated by a simple setup involving a couple of Commodore 64s and a serial connection. 
Consider Prince of Persia, that famous game for the Apple II. It was developed on the Apple II. I think the author had two Apple IIs which were connected; one to type his code up, and the other to test the game.
In these cases, to debug the program, something like an Action Replay cartridge might be used. These essentially send an NMI to the processor, and bank in some kind of monitor ROM, so that you can inspect and/or change variables etc. Then when you're done debugging, the program can (usually) resume.

Did the programmers indeed work on the target machine with all the drawbacks

Sometimes, as I have pointed out. but still, a lot of work was more easily done on paper. Back then, a lot of books were printed that showed how to design sprites on graph paper, and translate it into hexadecimal, and type the hexadecimal codes into the computer. More rarely, a digitiser was used to get the graphical data into the machine. Similarly, maps and flowcharts were a good way to think about a solution before even beginning to type any code out, as they still are.

Did the programmers indeed work on the target machine with all the drawbacks, or did at least some of the dev shops have more powerfull workstations with e.g. fast harddisks and cross-assemblers?

Certainly at least some dev shops used contemporaneous, but more powerful or comfortable computers. For example, the Tatung Einstein was commonly used to develop software titles for the ZX Spectrum or other Z80 machines. And similarly, any PC clone or CP/M computer or anything like that can be used in much the same way. That's advantageous because these machines have more RAM than the ZX Spectrum 48K, so the assembler can more easily reside with (some of) the source code and (some of the) program, all at once. 
Starting from the late 80s, it was feasible to develop on the Amiga for the Commodore 64. Now you have the conveniences of a much faster CPU and storage, even hard disks and version control, and Commodore 64 emulators on the Amiga itself. So that's not really that different from what C64 developers do today, except we're probably more likely to use Linux or Windows or whatever.

A:

So, nowadays, you'd have to be crazy not to use a PC and some nice cross-development tools when targeting these old machines.

To start with, I still like to use my IIgs (or IIc-plus) when coding for the Apple II. Both are quite fast machines with more than enough memory to do the job. After all, editing source text doesn't get faster with a mouse and many colours. And all the 'helpers' of modern IDE are just adding potential errors - like selecting the wrong function, just because it's so neatly presented. Yes, the Google disease of always picking the top entry has reached the programming community.

Did the programmers indeed work on the target machine with all the drawbacks, or did at least some of the dev shops have more powerful workstations with e.g. fast hard disks and cross-assemblers?

The '80s on small computers were an extremely fast changing environment, so there is not a single answer to this, or in other words: It depends :)

In the very beginning cross assemblers where the norm. How else to get a program running on a new CPU? Running them on time-sharing systems wasn't about getting more luxury, but running it at all, thus avoiding assembling from hand. They were not in any way great tools or easy to handle. Don't expect something like an Arduino IDE running on a PC compiling and downloading the program in a click. We talk extremely meagre functionality, clumsy handling at high cost. And the result was just another file on that distant mainframe.
It was common to just dump the result to a TTY as hex (*1) and then key it into a single boarder to have it run - or into a prommer to store it and then run. People with a lot of money would have prommers able to read paper tape, punched by the TTY. Controlling all of this by hand while moving rolls of paper around was considered easy handling and fast development. 
This soon changed when development tools were moved to the machine itself. For example, one of the sales arguments for the JOLT was its "Resident Assembler Program (RAP)" advertised with "costly time sharing services are not needed for cross assemblies" and "The Resident Assembler Program is compatible with the MaS Technology Cross Assembler" in their brochure.
While such a resident assembler was just a small step, more capable assemblers running on the target system (or closely related ones) became available. A notable example was Intel's ISIS systems as professional development tools. Here, an 8080 system was used to develop programs for the whole Intel line from 8023 to 8085.
Now, while these are dedicated developer systems, they were neither comfortable nor any faster than their targets - often slower. Heck, even early 8086 development was done on these. The 8086 boards were just used as target.
Around 1980 and for small developers, it was already a great gain to load an editor from tape, write/change the source code (loaded from tape as well), save it, load a compiler (all from tape), load the source again, compile, save the result, run it. Sure, all of this could be quite sped up by buying a disk drive - but more than doubling the system cost. An original 8KiB PET cost 800 USD, while a 2040 drive called for over 1,000 USD. And that's 1978 prices.
So for a more professional setup (maybe with a printer ... whooohoo) 4-6,000 USD was a reasonable number - in today's money that's 25-30,000 USD. Not exactly lunch money.

At that point (1977-1982) it's important to remember that (Game) Development wasn't driven by big corporations with large development teams, but more often than not by single person or very small teams of 2-4 developers. It's the time soon to be important companies started at the literal kitchen table with the machine itself and a hunger to build. 

As before the question wasn't about how inconvenient using the target machine is, but how great it would be to have a floppy at all.
Considering this, a built-in BASIC with integrated editor and interpreter and debugger in one, so only source/program has to be loaded and saved, had many advantages on early machines. A built-in IDE after all.

No one thought at this time about having a faster machine. There was none. Using a different machine would only complicate the development process.

Soon third party developers released more integrated compiler environments to run on the target machine. One where, for example, the source could be held in memory when switching from editor to compiler.
And for owners of lots of RAM - like 32 KiB or even more - there were integrated programs that did hold both in memory and the source. Who needs disks anyway? :))
When floppies became more affordable, development tools were based around them with automated load of components. Most notably may be the UCSD p-code system (Pascal, Fortran, etc.) offering an integrated menu system to switch between components (Editor, Compiler, Linker, Debugger) with only a few key presses.
Similar integration made Turbo Pascal in 1983/84 an unparalleled success.
With introduction of hard disks to the general public (read: becoming affordable by only doubling the machine's price) around the same time (1984...) development did really speed up. Not so much due to the hard disk speed, but missing the need to swap floppies (*2).
The PC itself wasn't a real fast machine; its advantage was a large RAM configuration and, as mentioned, easy hard disk integration. Once again it wasn't about speed, but the ability to do certain tasks at all - like fast program switching or large compilers without loading of overlays.
All throughout the '80s, speed wasn't a thing of the CPU at all. Speed difference between slowest and fastest machines was not given in the first half and maybe 1:2 throughout the second half of the decade.

For a more general view it's useful to keep in mind that most development until the late '80s wasn't so much about making life comfy as today, but being able to develop at all. Much as the most important feature of the (small) machines back then was to be a computer capable of running arbitrary programs at all. The choice wasn't to compile a program with one click within seconds and get a beautiful output presented, but rather being able to compile at all. Switching a disk 5 times per compile and waiting a minute or two until a 1,000 line program is compiled and linked is fun compared to no tools and no program.
Looking close, it's helpful to follow a rough timeline and different different use cases in mind:

Very early on, ~1973-1978, Crossdevelopment was important and often the only way, as the CPUs to be developed for weren't available in usable machines. Programm sizes where measured rather in pages of 256 Bytes than Kilobytes.
When the first general available machines (Altair, Commodore, Apple, Tandy) where in use(1977-1980), they were, for most users, far more convenient than any (expensive) cross development, not at least due the fact that programs could be developed interactive and tested right away. Still, codesize was measured in single digit KiB, and development environment and runtime were the same. Eventually a developer used additional tools in form of plug in ROMs ( TIM for Commodore or Programmers Aid#1 for the Apple II).
With the advent of dedicated home computers, roughly the time from 1980 to 1984 (The Video Game Crash, *3), they became them self the best development platform for their software. Much of the code was platform dependant, and needed to be tested in place anyway. Also, the difference between these and 'professional' systems in speed where more often than not reversed. And while professional development systems had in general better storage, their RAM offerings where as small. As a result, it was more appropriate to soup up the target system - like adding floppies. Hard disks weren't an issue.
While the PC itself didn't change much here, despite the larger memory, it was the AT of 1984 and more important the 16 bit wave of 1985 that changed the play field with faster machines. Development was done on the target machines itself - after all, they were at the top end of the time again.
While now faster platforms available that could ease development for older generations, it still wasn't until the late 1980s that the needed software to emulate older machines good enough to allow satisfying cross development.
For the top end machines, development was and is done on the machines itself.

It wasn't until the mid to late 90s, when of the shelf hardware could generaly be used as cross development ... then again, it became less and less important as the hardware converged toward today's PC.

*1 - Or a loader format, which is no big difference either.
*2 - In the early '80s, before hard disks were affordable, developers often had 3 or 4 drives at their machines to reduce floppy swapping.
*3 - 1980 (To be strict christmas sales of 1979) is marked by introduction the first (dedicated, mainstream) home computers with the TI 99/4 and Atari 400/800.
*4 - The often cited video game crash of 1983-1984 (With ET being like the tip of the iceberg) was in most parts a US phenomena as Europe and Japan where only indirect influenced.

