I've spent a fair bit of time working on safety-related software. People die if the software fails, kind of safety.
The first thing to note is that we had 100% test coverage of requirements. However that didn't have to be automated, sometimes because it wasn't practical, and sometimes because it wasn't physically possible. No safety-related standard requires 100% automated testing even for the most critical of systems, so the idea of doing it for an iPhone app is pretty ludicrous.
The next thing to note is that there are various sorts of coverage which you might want for unit testing. Statement coverage is a nice start, because it guarantees that at least all code is reachable, but it doesn't say anything about whether it's been tested for correctness. Branch coverage is better, but you still can't be sure about why it branched. Condition coverage is more thorough and checks that for a comparison you've given it less than, equal and greater than conditions, but now your testing is expanding. Add combinatorial logic testing to check one of each condition true, all conditions true and no conditions true. Add boundary coverage to check for maximum/minimum value inputs and outputs. And so on.
On an average project, we reckoned on around 5-10% of our time being spent on coding, 10% on requirements, and 20% on design. The rest was testing. And that was for lower safety levels. For serious safety stuff where we had to unit test like that, we reckoned on doubling that test time.
We actually analysed this and decided to abandon function-level unit tests for most things. We found that the defect-to-cost ratio was not justifiable, and many of the bugs could not in fact manifest in the system because of limits higher up. Instead, we ramped up the amount of module-level and system-level testing, because evidence showed that this was where the majority of customer-visible bugs were found.
So your boss needs to decide why he thinks this is a good idea. He needs to define what "100%" measurements you should be aiming for. And he needs to justify a 10x increase in the time to complete your project, because that's what your estimated delivery date should now say.