OC 中 @private @protected @public @package 的含义

Brief

Directive	Meaning
@private	成员只能在当前类内部可以访问，在类实现部分定义的成员变量相当于默认使用了这种访问权限。
@protected	成员可以在当前类和当前类的子类中访问。在类接口部分定义的成员变量默认是这种访问权限。
@public	实例变量可以被在任何地方访问。
@package	成员可以在当前类或和当前类实现的同一映像中使用。同一映像就是编译后生成的同一框架或同一个执行文件。

Detail

关于 @package 在 StackOverFlow 有一个比较清晰的解答，摘录如下：

Instance variables that are declared under @package will only be accessible by code from the same framework, library or executable. This is most similar to internal in C# and Friend in VB.NET, but other programming languages have similar protections schemes as well (Java has package-private).

For instance, imagine a framework, RecipeKit.framework, for managing recipes:

@interface Recipe : NSObject {
  @package;
    NSString *name;
  @private;
    NSArray *ingredients;
}
@end

@interface RecipeController : NSObject
@end

The recipe controller will be able to access the names of recipes directly. You would be able to write something like this in the RecipeController since it’s part of the same framework:

Recipe *recipe = [[[Recipe alloc] init] autorelease];
[recipe->name autorelease];
recipe->name = [@"The best ever recipe!" retain];

If you were to write the above code in an application linking to RecipeKit, though, it would cause a compiler error since you don’t have access to that variable. Lastly, when compiled for 32-bit, variables declared under @package behave as if they were declared under @public instead, so watch out for the differences here.

This new feature got very little attention because it’s just one more way of breaking you’re class’s encapsulation. As has always been true, you’re probably better off working with @private variables only and having accessor methods for them. In fact, for a while Apple was trying to push this by including @private in their templates. With properties in Objective-C 2.0, sticking with @private is easy enough, and depending on what platform you’re targeting, you can leave out the instances variables entirely.

Images
One thing that a few of the previous answers left a little unclear was addressing the aspect of images from the original question. In fact, the word image as used in the description of @package variables has nothing to do with graphical images. Instead it is referring to images that the dynamic linker is able to load. Generally executables, frameworks, and dynamic libraries are all considered images by the linker (though they are handled slightly differently). You’ll see the word image pop up every once and a while. For instance, a common runtime error is: “dyld image not found”. You’ll also find the use of the word image scattered throughout documentation for dyld. Reading through the man page for dyld could help clear up the ambiguity of this word a bit. UIImage may declare variables as @package, but it has nothing to do with image as it pertains to the original question.

Works Cited

Objective-C Runtime Release Notes for OS X v10.5
What does the @package directive do in Objective-C?