I’m going to discuss how to do so, and why it’s a good idea.

Here’s an example, which I submitted to AFNetworking:

#if !__has_feature(objc_arc)
#error AFNetworking must be built with ARC.
// You can turn on ARC for only AFNetworking files by adding -fobjc-arc to the build phase for each of its files.
#endif

When the user builds the unit, the error will be highlighted. They’ll see the comment just below, explaining how to resolve the problem.

Adding it to every .m file may seem overkill, but there’s two good reasons for this:

1. No matter which file gets compiled first an error will top the list instead of warnings. It’s sufficient to add it only to a central file, but you’ll probably still get support requests that way. You’re better off adding it everywhere; this is all about reducing your work.
2. ARC can be decided on a per-file basis. If you include it in only one file, the user may add -fobjc-arc to just that one file!

But do not add this to your headers. Even if your code requires ARC, there’s no reason to require that the user’s code also use ARC. Apple did the right thing here.

Odds are, the compiler understands Objective-C and Cocoa better than you. I don’t mean this as an insult; it certainly understands it better than me. I think you could safely say it understands the rules better than all but maybe a dozen people worldwide. And it knows tricks to use them to a degree that you and I can’t repeat, even if we understood as well as it does.

The rest is just details, but they’re important:

1. You will write a lot less boring code. Code so boring it’s easy to make mistakes.
2. As a blended compile time and run time process, it has access to tricks that you don’t.
3. It will a better a job of writing memory management code than you can, even if you write the theoretical perfect memory management code.
4. It will reduce “high tide” memory usage (somewhat) without any effort on your part.

If you are starting a new application, stop thinking about it and just use it.

If you have an existing application, you need to think about it. You’re balancing the ease of future development vs. a need to re-test the app. The ARC conversion isn’t awful, but it isn’t painless or foolproof either. You will need to make sure you have no circular references, and you will need to make sure that objects don’t disappear sooner than you think.

If you have an existing application that targets iOS before iOS 5, zeroing weak references are not supported. You can find people who will tell you that zeroing weak references aren’t a big deal. They’re wrong. While it’s true you can use assign to prevent circular references, weak references are what turns ARC from a useful way to write less code to a fantastic way to write stable applications. You should seriously consider requiring iOS 5.

If you have an existing application that targets iOS before iOS 4, you can’t use it at all. What are you thinking, supporting a version of iOS that old?

See also:

• Transitioning to ARC: Apple’s ARC overview. A great overview, but possibly less than you need to know.
• Automatic Reference Counting: The living and detailed ARC specification and rationales. Certainly much more information than you require.