Website Loader
Fork me on GitHub
Homepage Top Icon


A new dependency injection container for Objective-C

Status? It's ready to use!

Homepage Bottom Icon


Read More About Us

Get ready!
You’re about to be blown away


What is Dependency Injection?

Dependency Injection

Many people have trouble getting the hang of dependency injection, at first. And I think part of the problem is that it is actually so simple that we’re inclined to look for something more complicated. “Surely that there has to be more to it?!”, so to say. So, with that in mind, imagine that you’re writing an app that gives weather reports. You need a cloud-service (excuse the pun ;) )

to provide the data, and at first you go for a free weather report provider, but in future you’d like to integrate a weather service with better accuracy and more features. So, as do all good object-oriented developers, you make a WeatherClient protocol and back it initially with an implementation based on the free, online data provider.

Without dependency injection, you might have a View Controller like this:

-(id) init
 self = [super init];
 if (self)
 //The class using some collaborating class builds its own assistant.
 //it might be one of several classes using the weatherClient. 
  _weatherClient = [GoogleWeatherClientImpl alloc] initWithParameters:xyz];
 return self;

The thing with this approach is, if you wanted to change to another weather client implementation you’d have to go and find all the places in your code that use the old one, and move them over to the new one. Each time, making sure to pass in the correct initialization parameters. A very common approach is to have a centrally configured singleton:

_weatherClient = [GoogleWeatherClient sharedInstance];

With either of the above approaches, in order to test your view controller, you now have to test its collaborating class (the weather client) at the same time, and this can get tricky, especially as your application gets more complex. Imagine testing Class A, depends on Class B, depends on Class C, depends on… Not much fun! Sure, you could patch out the singleton with a mock or a stub, but this requires peeking inside the code to find the dependencies. Besides taking time that could be better spent else-where, this ends up becoming “glass-box” testing as opposed to “black-box”

testing. Isn’t it better to be able to test the external interface to a class, without having worry about what’s going on inside? And you have to remember un-patch again at the end of the test-case or risk strange breakages to other tests, where it’s difficult to pin-point what the real problem might be. So with dependency injection, rather than having objects make their own collaborators, we have them supplied to the class instance via an initializer or property setter.

And now, it simply becomes:

-(id) initWithWeatherClient:(id<WeatherClient>)weatherClient
 self = [super init];
 if (self)
     _weatherClient = weatherClient;
 return self;

Is that all they mean by ‘injected’?

Yes it is. Right now, you might be thinking “Geez! That’s a pretty fancy name for something so plain.” Well, you‘d be right. But let‘s look at the implications on our application architecture: If you do this with significant collaborators throughout your app, it means that the GoogleWeatherClientImpl is now declared in a single place – the top-level assembly, so-to-speak. And all of the classes that need to use some kind of id<WeatherClient> will have it passed in. This means that:

  • If you want to change from one implementation to another, you need only change a single declaration.
  • Classes are easier to test, because we can supply simple mocks and stubs in place of concrete collaborators. Or the real collaborators, but configured to be used in a test scenario. (One of my design goals).
  • It promotes separation of concerns and a clear contract between classes. Its easy to see what each class needs in order to do its job.
  • Your app is easier to maintain and can accommodate new requirements.

Your Dependency Injection Options

If you proceed with the Dependency Injection pattern (assuming you’re not one of the remaining “flat-earthers”, who believe that Objective-C somehow magically alleviates the need for common-sense: “Oh, I don’t do DI, I use swizzling class-clusters!”), then there are basically two options:

You can do dependency injection without a framework to help you. It is simple after all, and in fact I recommend you do this, at least as an exercise in software design. And yes, it is certainly possible that this will be adequate. But, I think its good to have help, if you can get it. You can also write tests without a test framework, mocks with out a mock library, and software without a compiler.

So, going down the framework route, there’s been quite a lot of action in Objective-C land, over the last three years. In fact, there are now around 15 Dependency Injection frameworks, many following in the footsteps of Google Guice. The authors have done a great job (Objection is especially good). However, I wanted an approach that allows the following:

Design Goals & Features


Non-invasive. No macros or XML required.

Spring-style XML or Guice-style macros are fully supported, but focus is on a powerful Objective-C approach.

No magic strings – supports IDE refactoring, code-completion and compile-time checking.

Provides full-modularization and encapsulation of configuration details. Let your architecture tell a story.

Dependencies declared in any order. (The order that makes sense to humans).

Makes it easy to have multiple configurations of the same base-class or protocol.

Supports injection of view controllers and storyboard integration.

Supports both initializer and property injection, plus life-cycle management.

Powerful memory management features. Provides pre-configured objects, without the memory overhead of singletons.

Excellent support for circular dependencies.

Lean. It has a very low footprint, so is appropriate for CPU and memory constrained devices.

Battle-tested — used in all kinds of Appstore-featured apps.

Mod Productions and The Australian Chamber Orchestra release the Typhoon-powered ACO VIRTUAL, and are awarded AppStore Best New Apps


Read More About Us

Explore how an app is built with Typhoon
Code is so much neater

Pocket Forecast

Take a look at the code in this example app.


Returns weather reports from a remote cloud service.

Caches weather reports locally, for later off-line use.

Stores (creates, reads, updates deletes) the cities that the user is interested in receiving reports for.

Can use metric or imperial units.

Running the sample

Clone this repository, open the Xcode project in your favorite IDE, and run it. It’ll say you need an API key.

Get an API key from WorldWeatherOnline

Using your API key, set the application configuration.

Run the App in the simulator or on your device and proceed to the exercises here.

Start using Typhoon! Check out the User Guide.

Typhoon is nice on Xcode, even better with AppCode



Read More About Us

“My passion is to present complex requirements in a way that is simple and intuitive to the user.” — Jasper Blues

Meet The Contributors

Typhoon — The Dependency Injection Framework for Objective-C and Cocoa

Our Team


Founder / Proj. Lead

Engineer. Artist. I enjoy the creative utilization of technology to achieve solutions in business.

Our Team


Core Team Member

I'm passionate about software craftsmanship, automated testing and the design of dependable systems.

Our Team


Core Team Member

I spend most of my time between Cocoa and Ruby, but I always love learning new things.

Our Team


Core Team Member

I feel great satisfaction in building structured and elegant software. You can't build a great app on a weak foundation.

Our Team


Core Team Member

Perfectionist. I like challenging performance problems — optimising code until it achieves the best possible speed.

It’s Q&A Time!

Read More About Us

Got any questions?

Frequently Asked Questions

Something’s not clear? Check Below!
We tried to answer any question you might have.

Q. Madrid, Manila, Omsk, Phnom Penh, San Francisco. . . What do these cities have in common?

A. We get this one all the time.

These are the cities where the Typhoon core team members live. It goes to show: you never know where you’ll find a ninja coder lurking these days. They’re also the default cities in Pocket Forecast - the Typhoon sample application. Incidentally, as I’m writing this its +41° celsius in Phnom Penh and -30° in Omsk!

Q. I’ve started using Typhoon, now I’ve got a technical question. Where can I get help?

A. There’s a Typhoon tag on StackOverflow, which is monitored by Typhoon users and contributors.

Alternatively if you’d like professional consultation, please get in touch. While Typhoon is open-source, free and volunteer-based we do maintain a network of skilled consultants, so chances are that we can put you in touch with an expert or company who’d be willing to help you out on a professional basis. For example, Typhoon’s original founder, Jasper Blues, currently works on a freelance basis. And if you need a larger team, perhaps try Al Digit.

Q. Compatibility

A. Typhoon can be used with OS X and iOS. It has not been tested with GnuStep. It can be used with or without ARC, but not with garbage collection.

Internally, Typhoon relies on some weak references which where introduced in iOS 5.0 (iPhone3gs and up, iPad 1st generation and up) and OSX 10.7 (most Macs built since 2009).

Q. Isn’t Objective-C a dynamic language?

A. Yes, and I love categories, method swizzling, duck-typing, class clusters, associative references in categories, and all that cool stuff. None of these are replacements for DI.

Q. Doesn’t Dependency Injection Just Shift Coupling Elsewhere?

A. If by elsewhere you mean from everywhere to one place, and (in the case of statically compiled languages) from compile-time to runtime … then yes! That is the purpose of dependency injection.

Q. Doesn’t XML suck?

A. No, not really. It gets the job done (depending on what its being used for). But what does this have to do with Typhoon?

Not that much, actually. You might have heard that the first release of Typhoon was called Spring for Objective-C? Quite a few people took that to mean XML. This is not what we meant, at all.

What we did mean, was that like Spring, Typhoon takes a two-step approach to dependency injection. It first parses all of the component definitions into an internal model, with hooks for post-processing. We followed the Spring Framework’s example here, because it is a powerful and versatile approach, and affords the opportunity to define many styles of dependency injection, as well as an easy way to have several components of the same type (class or protocol) configured in different ways.

Like Spring, we do support a range of DI styles, including Spring-style XML, and auto-wiring macros. You can use these if they suit you. But we’d really like you to try Typhoon’s powerful native approach.

Q. Is this all of Spring in Objective-C?

A. No, its just a light-weight, Spring-style DI container. I personally think that Spring is an excellent DI container, and it’s huge popularity and availability in several languages says a lot. With regards to other Spring Portfolio products: some I like, and some I don’t.

Update: Objective-C's dynamic/runtime method dispatch makes it very easy to implement the intercept pattern and provide runtime augmentation of classes, however we've observed that there's still an unmet need for a formalized AOP-framework. Specifically, being able to modularize cross-cutting concerns and identify the places where these should be applied using a point-cut expression language. To this end, we've started some work on Typhoon-AOP. More news to follow!

Q. Does Typhoon work well on resource-constrained devices?

A. Yes! At start-up Typhoon consumes about the same resources as parsing a JSON response from a network request. Also, Because Typhoon allows the use of prototype-scoped components instead of singletons, components that aren’t required can be deallocated when they’re not being used.

In fact, the award-winning ACO Virtual’s controller app was deployed on iPad 1s, because these represented very good value for money at the time hardware was being purchased. We received a lot of compliments about this app’s stability.

Q. Can Typhoon inject view controllers?

A. Injecting. Others might consider it banal and somewhat of a drag, but Typhoon actually gets-off on it. Typhoon lives to inject. Once while travelling through a rough-part-of-town in a foreign city, Typhoon and I happened upon a psychopath-gangster-singleton from the 80s. This thing was seriously intimidating and widely reported in the press as being ‘uninjectable’. Well Typhoon injected the shit out of it without even breaking a sweat.

View controllers? This is child’s play for Typhoon. Initializers and properties, xibs or no xibs and with or without Storyboards. You can also use it to build complex views, if you like. Take a look at the sample app.

Q. What other customizations have been done for applying DI in a mobile or desktop environment?

A. Quite a few — we’ve worked hard on this. One example is Typhoon's memory management. Another is transitioning from one use-case’s object-graph to another with TyphoonFactoryProvider.

Q. What’s with the name Typhoon?

A. Over the 2012-13 new year, I had a family holiday booked at one of our lovely beaches… but it turns out there was a late-in-season Typhoon. So I stayed home and wrote this instead… Also it was inspired by the Spring Framework. In temperate climates we have Spring, Summer, Autumn & Winter. But here in the Philippines we have hot-season, sizzling-hot-season and Typhoon-season ;).

Update: Since then we have had the incredibly destructive super-typhoon Haiyan, which has been very sad. Our sincere condolensces to all those affected.


Read More About Us

Help build this community
Get in touch with me below!

Get In Touch

Feature Requests and Contributions are very welcome!

We have received your message.
Contact Name
Contact Email
Phone Number
You're interested in?
How did you hear about us?