You only write code that is needed: Following the rules, you have to stop writing production code when all your tests pass. If your project needs another feature, you need a test to drive the implementation of the feature. The code you write is the simplest code possible. So, all the code ending up in the product is actually needed to implement the features.

More modular design: In TDD, you concentrate on one micro feature at a time. And as you write the test first, the code automatically becomes easy to test. Code that is easy to test has a clear interface. This results in a modular design for your application.

Easier to maintain: As the different parts of your application are decoupled from each other and have clear interfaces, the code becomes easier to maintain. You can exchange the implementation of a micro feature with a better implementation without affecting another module. You could even keep the tests and rewrite the complete application. When all the tests pass, you are done.

Easier to refactor: Every feature is thoroughly tested. You don't need to be afraid to make drastic changes because if all the tests still pass, everything is fine. This point is very important because you, as a developer, improve your skills each and every day. If you open the project after six months of working on something else, most probably, you'll have many ideas on how to improve the code. But your memory about all the different parts and how they fit together isn't fresh anymore. So, making changes can be dangerous. With a complete test suite, you can easily improve the code without the fear of breaking your application.

High test coverage: There is a test for every feature. This results in a high test coverage. A high test coverage helps you gain confidence in your code.

Tests document the code: The test code shows you how your code is meant to be used. As such, it documents your code. The test code is sample code that shows what the code does and how the interface has to be used.

Less debugging: How often have you wasted a day to find a nasty bug? How often have you copied an error message from Xcode and searched for it on the Internet? With TDD, you write fewer bugs because the tests tell you early on whether you've made a mistake. And the bugs you write are found much earlier. You can concentrate on fixing the bug when your memory about what the code is supposed to do and how it does it.