Question: There are multiple examples of `@private` instance variables all over the Foundation, UIKit and other framework headers. Here are some examples:

```
//CLLocationManager.h
@interface CLLocationManager : NSObject
{
@private
    id _internal;
}
<...>

//NSAutoreleasePool.h
@interface NSAutoreleasePool : NSObject {
@private
    void    *_token;
    void    *_reserved3;
    void    *_reserved2;
    void    *_reserved;
}
<...>

```

etc.

These instance variables are `@private`, so it's not possible to access them from anywhere except the class itself. What is the point of exposing them in the headers?

So why not

```
//CLLocationManager.m
@interface CLLocationManager<>
{
    id _internal;
}

```

Or even, considering modern Objective-C syntax:

```
//CLLocationManager.m
@interface CLLocationManager<>

@property(nonatomic, assign) id internal;

```

Why did apple used private instance variables in headers, exposing the internals of the class instead of hiding them in the implementation?

Answer: 
Changes Apple have made over the years are to the API (Application Program Interface) but removing members from structures and classes changes the ABI (Application Binary Interface) which cannot be done without forcing all programs in existence to be recompiled or else they will crash.

The `void *_reserved` members in fact are very likely to be old deprecated symbols that have been removed from the API, but removing them from the class definition would have changed the ABI, and so the space they took up has been padded with `void *`.
Many of these headers have been created in ancient times, when instance variables *had* to be declared in a header. And you don't want to change working code unless there is a good reason to do so - after all, it all works fine and you are just curious. 

Apple cannot just update the header files; they would have to update the implementation as well, which means a *huge* amount of testing (or do you think you could make that change in dozens of files without making any mistakes? )