As previously stated, you should hand the customer the HEX file and they would program it in the PIC. In fact that's the only way you can program a PIC (with the exception of the bootloader). Thus the whole reason for compilers, you compile from ASM to HEX, or from BASIC->ASM->HEX (or from C->ASM->HEX), but the end result is alway HEX.
With that said, you will always need some sort of screen, cause you always need the PC. Now if you created some sort of interpreter (like STAMP), you could program a memory and would not have to reprogram the PIC. But you still have to program the memory with guess what, a HEX file (or binary in some cases). You could even create a wireless interface, but the requirement for the HEX file is always there.
So in short, HEX is the way to go. Unless you have some previous arrangement where you're required to hand in the source code, you only give the compiled code (i.e. HEX, just like an EXE for Windows). Sure there are HEX->ASM dissasemblers. But if your customer is that desperate, and they have the will and resources to go through a bunch of odd looking assembly code after it's been dissasembled, let them go at it. I would not worry. If you just created a super-duper PIC application, you should be doing the upgrades and not the customer.
Bookmarks