[Solved] Using ARC library in non-ARC project [closed]

Question

The issue is that you are mixing an ARC violating construct into ARC’d files through inclusion. You can’t apply -fno-objc-arc to a single header file because that doesn’t make sense.

Since it is in a header file, you will either need to use an #if pragma to switch between behaviors depending on whether an ARC or non-ARC .m file is being compiled.

A better solution, however, is to eliminate the issue entirely for both ARC and non-ARC. Given that declaration, it pretty much has to be an instance variable (though it could be in a struct).

If it is an ivar, get rid of the declaration entirely. Either expose it through @property or move it to the .m file if it does not need to be exposed in your public API. Given the type, it really should be a private implementation detail with public API that makes accessing the contents a bit less pointer-magic.

In general, using C language arrays — arrays of pointers — to store Objective-C types is highly discouraged. If _controls does need to be exposed as a publicly accessible thing (public to the other classes in your project), then refactor your code to use a collection class (i.e. typically an exposed NSArray* getter with an internal-only NSMutableArray* backing store — like subviews on UIView, for example).

Accepted Answer

The issue is that you are mixing an ARC violating construct into ARC’d files through inclusion. You can’t apply -fno-objc-arc to a single header file because that doesn’t make sense.

Since it is in a header file, you will either need to use an #if pragma to switch between behaviors depending on whether an ARC or non-ARC .m file is being compiled.

A better solution, however, is to eliminate the issue entirely for both ARC and non-ARC. Given that declaration, it pretty much has to be an instance variable (though it could be in a struct).

If it is an ivar, get rid of the declaration entirely. Either expose it through @property or move it to the .m file if it does not need to be exposed in your public API. Given the type, it really should be a private implementation detail with public API that makes accessing the contents a bit less pointer-magic.

In general, using C language arrays — arrays of pointers — to store Objective-C types is highly discouraged. If _controls does need to be exposed as a publicly accessible thing (public to the other classes in your project), then refactor your code to use a collection class (i.e. typically an exposed NSArray* getter with an internal-only NSMutableArray* backing store — like subviews on UIView, for example).