How we do iOS apps

At AppFoundry we love crafting software that fits the needs of our customers. Since all apps are different, they often require different solutions for different problems. There are, however, some basic principles and solutions that we apply in almost all of our apps.

In this series, we’ll describe some of those solutions and how they help us deliver maintainable software, which in turn keeps our customers happy.

Dependency Injection

Ever since we started developing iOS apps, we felt the need for Dependency Injection. At that time, existing dependency injection frameworks felt too intrusive in our code. We decided to create our own Dependency Injection framework called Reliant. We’ll cover the advantages of using dependency injection and will showcase its usefulness throughout this series.

Test Driven Development (TDD)

We’ll also talk about how test driven development helps us discover bugs very early on in the development process, and how it influences our application architecture. The result is better, more maintainable software and (contrary to what many people think) faster delivery times.

Debug Drawer

[bscolumns class="two_third"]

Testing is awesome, but a machine cannot test things like user experience and app consistency. These require human interaction. To help both testers and developers while manipulating the app, we often use a debug drawer. The debug drawer allows us to simulate certain conditions. It is also capable of:

• manipulating where the apps get their data from
• simulate memory warnings
• mimic incoming notifications, etc…

We’ll cover how to set this up, and how we make sure its code doesn’t end up in production builds

Continuous integration (CI) and Continuous Delivery (CD)

Since we do Test Driven Development, we also need a system that makes sure that all of our tests run regularly. Especially, when a team of multiple developers is working on an app, this becomes indispensable. As code integrations happen often, we need a Continuous Integration system that builds the app and runs our tests. This allows us to detect problems early, even before we pass it to our testers. The time gained using these systems always pays off.

Furthermore, CI opens the door to Continuous Delivery. Whenever the CI system ends up with a successful build, it triggers a deploy to our distribution channels. We’ll talk about our setup, and how we keep improving it, as these principles get more and more friction in the developer community.

Design Patterns

We’ll also cover some commonly used software design patterns (other then DI). We’ll talk about how they help us create maintainable and easy-to-adapt code.

Hope you’ll enjoy the series!