Introduction

If a mostly ARC-enabled Xcode project contains one legacy Objective-C file that still uses manual retain and release calls, you do not need to disable ARC for the whole target. Xcode lets you turn ARC off for a specific source file by applying a per-file compiler flag.

The Xcode Setting That Matters

The file-level compiler flag is:

-fno-objc-arc

This tells the Objective-C compiler not to apply Automatic Reference Counting to that one file.

How to Set It in Xcode

Open the target, go to Build Phases, expand Compile Sources, and find the source file that should stay non-ARC. Then add -fno-objc-arc in the Compiler Flags column for that file.

That is the standard way to keep one .m file on manual memory management while the rest of the project stays on ARC.

Typical Use Case

This is most commonly needed when importing older Objective-C code that was written before ARC and still contains explicit retain, release, or autorelease calls.

A file like this will not compile cleanly under ARC:

1- (void)dealloc {
2    [_name release];
3    [super dealloc];
4}

If that file must remain unchanged for compatibility reasons, disabling ARC just for that file is often the least disruptive option.

Keep the Boundary Clear

Mixing ARC and non-ARC code in one project is supported, but you should treat the boundary carefully. Manual-memory-management files still need correct ownership rules, and ARC-managed files should not be rewritten to mimic manual memory patterns just because one legacy file exists.

The goal is usually containment: isolate the old code, keep the exception narrow, and avoid spreading non-ARC assumptions through the rest of the app.

When Not to Do This

Do not disable ARC casually. If the file can be migrated to ARC with a reasonable amount of cleanup, that is often better for long-term maintenance. File-level ARC disabling is most valuable when:

• the code is third-party or vendor-owned
• migration risk is high
• the file is stable and isolated
• the rest of the target benefits from staying under ARC

In other words, use it as a compatibility tool, not as a general coding style choice.

That mindset keeps technical debt contained. The more deliberate you are about where ARC is disabled, the easier it is to migrate or replace the legacy code later without affecting the rest of the target.

That is usually the real engineering goal behind this setting.

The compiler flag is just the mechanism.

The maintenance boundary is the real decision.

That is what keeps the project understandable later.

Common Pitfalls

• Disabling ARC for too many files instead of isolating the true legacy boundary.
• Forgetting that manual-memory-management code still needs careful ownership correctness.
• Mixing ARC and non-ARC assumptions across files and making the boundary harder to reason about.
• Trying to use -fno-objc-arc on files that should really just be migrated properly.
• Editing target-wide ARC settings when the need is only file-specific.

Summary

• To disable ARC for one Objective-C file, add -fno-objc-arc to that file’s compiler flags in Xcode.
• This keeps ARC enabled for the rest of the target.
• The usual reason is compatibility with legacy retain and release code.
• Keep the non-ARC portion isolated and explicit.
• Prefer migration to ARC when it is practical, and use file-level disabling when it is the safer compatibility choice.