Simple, just don't give it a chance to fail to start due to 1) sudden power loss, 2) cable disconnection, uploader PC sudden reboot during bootload etc.
1 - it's quite obvious that bootloader should be not touched and kept unmodified during update. If you really need to make bootloader modified, do it something like modern Android phones do: at least one working bootloader/configuration at time in memory. Update only one of two working copies, so that if one fails, switch to another one. Two copies still would require you to have one very small subbootloader kept unmodified during updates, which should check which one of two big bootloaders are OK and if two are OK start one with higher version number.
2 - bootloader should not jump to application unless update is really complete. Instead, if update is incomplete, it should wait until you send complete image again. It could be as simple as non-FFFF application start vector, provided app start location is always send as a last program location. Of course you may have better protections against start of incomplete application image. If you can provide hidden microswitch or some smart keypress combination or something to force bootloader not to jump to application. This would also help in case some unlikely and hard to repeat condition makes your application stuck. Bootloader switch would let switch back to working version and wait for fix..
