class-dump now parses extended types (available only in protocols), so you get more precise type information on protocol methods. It also recognizes the “arm64” architecture. For a complete list of changes, see the class-dump Release Notes.

You can send but reports to me at nygard at gmail.com, or add it to the project’s Issue Tracker at github.

Mac OS X 10.8 adds a few new load commands, and now class-dump doesn’t log warnings about these. Two of these load commands indicate the minimum Mac OS X or iOS versions required, and these now appear in the class-dump output. class-dump also recognizes the new ‘armv7s’ architecture.

The project now uses ARC, properties are synthesized by default when possible and instance variables are declared in the implementation. There are several other changes to the coding style.

You can send but reports to me at nygard at gmail.com, or add it to the project’s Issue Tracker at github.

class-dump now handles two more types:

• _Complex, which fixes a parse error on Grapher.app that has been a problem for a long time
• long double, encoded as ‘D’; this is only used in a couple of frameworks/apps

And three more load commands:

• LC_DYLD_ENVIRONMENT
• LC_VERSION_MIN_MACOSX
• LC_VERSION_MIN_IPHONEOS

You can see the rest of the changes in 3.3.4 on that page.

This version is built as a 64-bit Intel executable, supporting 10.6 or later. (10.6 means no more PPC support, and there’s not really any reason to support a 32-bit version any more.)

I’ve switched from Mercurial to Git, and moved the source repository to Github. The latest source is now available at the class-dump git repository at github.

As always, you can send bug reports to me at nygard at gmail.com

You can download this version from the class-dump project page. It is built for Mac OS X 10.5 or later.

As always, you can send bug reports to me at nygard at gmail.com

Version 3.3 adds support for Snow Leopard, improves property handling, improves structure/union handling, fixes a bunch of bugs (including two crashers), and no doubt adds some new bugs.

Snow Leopard

There is a new load command (LC_DYLD_INFO) that contains a byte stream of information that dyld needs to load an image. This replaces the relocation info from the old dynamic symbol table; otool -rv outputs nothing for files built for 10.6. class-dump needs to understand this to correctly look up references to external class names. Version 3.2 shows a blank name for many superclass and category class names. This is fixed in version 3.3.

Snow Leopard also adds a new version of protected segments. These are recognized so that class-dump doesn’t spew out a bunch of garbage. Encrypted iPhone apps (indicated by the LC_ENCRYPTION_INFO command) are recognized for the same reason.

Bug Fixes

There are a lot of bug fixes. First of all, Mac OS X prefers 64-bit executables over 32-bit executables, so there was no need for a separate 32-bit executable. Now there is just one 32/64-bit universal executable. I’ve improved the parsing of C++ types, and class-dump can now make it through Safari and WebKit without complaint. Also fixed a crasher when trying to dump the 10.5 Finder.

Properties

More property attributes are now supported: dynamic, weak, strong, and non-atomic. Thanks to Joe Ranieri for sending a patch to handle these. Objective-C 2.0 categories and protocols now show their properties. Properties are now emitted when the first accessor method is encountered, and those accessors are not shown. Any remaining properties (usually dynamic ones, but there seem to be other cases where this can happen) are shown at the end of the method list. Properties declared in the optional section of protocols appear there in the output. The result is shorter, more readable output.

Property type strings can contain commas (for example, T^{map<int, int>=...},V_task), so we can’t just split the property attribute string on commas. Now class-dump parses the type, and then splits the rest.

Structure Handling

This is the process of trying to make sense out of all the structure and union definitions found in the files, and then to present it in a meaningful way.

Merging member names and types: Not all occurrences of a structure have member names, so it needs to merge member names when possible. For example, there might be both {_NSPoint="x"f"y"f} and {_NSPoint=ff}. Of course, there are exceptions where structures with the same name have either the same underlying type with different member names, or a different underlying type altogether. An example of this is ^{?=@ii{_flags=b1b1b1b1b12}} from @category NSApplication (NSWindowCache) and ^{__NSRowHeightBucket=fi{_flags="equalRowSizes"b1"reserved"b31}} from the _NSTableRowHeightStorage class. Anonymous structures can collide in the same way. It is common to have a structure of bitfield flags, and these can easily have the same layout but different member names. Types in methods never have member names, but worse still is that they reduce object types down to ids. That is, @”NSObject” appears as @ instead. Sometimes the compiler generates different names (such as $_2531) for multiple instances of the same union.

Determining how named and anonymous structures are declared: Named structures are generally declared at the top, unless they are only referenced once in an ivar or another structure, or if they are a special case (such as _flags), in which case they get expanded at the point where they occur. Any top level anonymous structures that are referenced by a method, or referenced from more than one place, need to be typedef’d and referred to by that name. And there are a few more special cases that should be handled.

Hmm, when I put it that way it sounds easy enough… But my specification was more like “Take a bunch of types, mix ‘em all together, and generate something pretty”. So there’s a lot of details and special cases to get right, and I ran into them one at a time. When I wrote that code, years ago, it took a lot of time to get it working on all of my test cases. I was tired of tweaking it, happy that it mostly worked, and ready to move on to something else. So I didn’t document it, and now I fear that code. I’ve made a couple attempts to figure out what it was doing and document it, but they didn’t get far.

I was working on the code after 3.2 was released. I decided to cache the parsed types, and pass the parsed types to the type formatter instead of passing a type string. Easy enough, but it introduced a bug, and that led me to the code that I feared. I ended up removing most of the old code and writing it from scratch. By the time is was mostly working again I was tired of tweaking it and ready to move on to something else. But this time I’ve documented it, so that I can remember how it works next year. Or next week.

What’s the result of that effort? Some structures get an actual object type, instead of just an id. Some structures pick up the correct member names, which were missing previously. Some structures have member names generated where they weren’t before. Some of the special cases (like _flag) are handled better.

I have also changed how typedef names are generated. Previously I just added an index to the name. This worked, but was extremely fragile. Unrelated changes to the code could alter the order that structures were processed, and change their name. Updates to frameworks could lead to large diffs in the output. The author of class-dump-z, kennytm, rightly criticized this (and other things!). Now I generate a hash based on the type string (after it’s been filled out with member names, and before the generic _field names have been added), and use that to create a unique typedef name. The results are great. There were only 6 diffs between the 10.5.5 and 10.5.8 AppKits with the new version, compared to 78 with the old.

The named structures are sorted by name and printed first, followed by the special cases. The anonymous structures are next, sorted by nested structure depth and then by the type string, followed by the special cases. #pragma marks are added before each section, and a #pragma mark - before each mach-o file, to make it easy to search for the next section.

As always, you can send bug reports to me at nygard at gmail.com. There were a lot of changes, and I haven’t tested it as thoroughly as I normally do.

This release includes support for Objective-C 2.0 on both 32 bit (iPhone) and 64 bit (Mac OS X). It shows class properties and handles all documented property attributes. Unrecognized property attributes are noted in a comment following the property declaration. class-dump also shows optional protocol methods. The Objective-C garbage collection status of each file is included in the output, as either “Unsupported”, “Supported”, or “Required”.

To support 64 bit files, class-dump is built as a 64 bit executable. A 32 bit executable (class-dump-32) is provided for 32 bit systems, but it doesn’t handle 64 bit files.

Internally, class-dump now stores the architectures as a cpu type, cpu subtype pair, instead of a string. This was necessary to handle unknown architectures such as the iPhone. For architectures without a recognized name, you can specify them as <cpu type>:<cpu subtype>, values are hex with an optional “0x” prefix. For example, you can use --arch 0xc:0x6 or simply --arch c:6. The –list-arches option will also list unknown architectures in this format.

If you find class-dump useful, I am now accepting donations to support its development. There is a donation button next to the download link on the project page. Thanks!

As always, you can send bug reports to me at nygard at gmail.com

2009-07-05: I’ve fixed the .tar.bz2 packages. Ever since 3.1, my packaging script has been creating a .tar.gz, then bzip2 compressing the result and calling it a .tar.bz2.

New Features

My favorite new feature is the -f option. This lets you search for methods and display them in context, showing the class, category or protocol that contains the matching methods. Before this, I would just class-dump a framework and search for the method in the output. In classes with a lot of methods, though, I’d have to scroll up to see what class contained the method, and it was difficult to get a good picture of the results. Now you can just use the -f option and get a nice short summary. This is great for discovering what classes implement some bit of private API. For example:

1

% class-dump /System/Library/Frameworks/AppKit.framework -f leed

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

/*
 *     Generated by class-dump 3.1.2.
 *
 *     class-dump is Copyright (C) 1997-1998, 2000-2001, 2004-2007 by Steve Nygard.
 */

@interface _NSBrowserScrollView : NSScrollView
- (id)_focusRingBleedRegion;

@interface NSButton : NSControl <NSUserInterfaceValidations>
- (id)_focusRingBleedRegion;

@interface NSTableView : NSControl <NSUserInterfaceValidations>
- (id)_focusRingBleedRegion;

@interface NSView (NSPrivateFocusRingSupport)
- (id)_focusRingBleedRegion;

@interface NSWindow : NSResponder <NSAnimatablePropertyContainer, NSUserInterfaceValidations>
- (void)_setLastFocusRingView:(id)fp8 bleedRegion:(id)fp12;
- (void)_getRetainedLastFocusRingView:(id *)fp8 bleedRegion:(id *)fp12;

The string is case sensitive and doesn’t support regular expressions. I just needed something simple, and it works quite well.

The -H option now generates protocol header files. These are named <protocol-name>-Protocol.h, which differs from the imports generated by the previous version. The extra dash in the name helps make them stand out against regular classes that end in Protocol, such as NSURLProtocol.

I’ve also added a –list-arches option that prints the architectures contained in the given file. I added this for my regression testing, so that I can dump all architectures that are available. Unlike lipo -info, it only lists the architecture names, which makes it easier to use in shell scripts.

Bug Fixes

I’ve added several fixes for files that use C++, so a bunch of old warnings should go away. This version of class-dump also recognizes Apple protected binaries, and won’t spew a bunch of garbage when you try to dump these files.

The Code

There are two big changes in the source code. First, I’ve implemented a visitor pattern for going through the Objective-C data to generate output. When I first implemented the -f option, I just copied the old generation code and added the pattern check. It was a quick and easy proof of concept, but it wasn’t maintainable. With the visitors most of the actual output is contained in one or two classes, instead of being spread out among many classes. I like it a lot.

The other change was converting the unit tests from ObjCUnit to OCUnit/SenTestKit. It makes sense to use OCUnit since it’s bundled with the developer tools, and ObjCUnit was crashing, so it was just as easy to switch. After converting the unit tests it was apparent that the two frameworks were practically identical in usage. Just import a different header file, subclass from a different test case class, and use slightly different asserts. My main reason for picking ObjCUnit originally was that it was easier to control the order of the unit tests, but I’ve managed to get that working with OCUnit.

Next Version

The next version will be 10.5 only so that I can start using some of the new features that are available. I think I can add support for @rpath, and supporting 64-bit files is on my list of things to do.

As always, you can send bug reports to me at nygard at gmail.com

You can download class-dump 3.1.1. This version is built against the 10.4 Universal SDK and will not run on Mac OS X 10.3 or earlier.

You can download class-dump 3.1. This version is built against the 10.4 Universal SDK and will not run on Mac OS X 10.3 or earlier.

It’s been a little over seven years since I released class-dump version 2. It now has a new home—I’ve set up this website to distribute the software that I create. At the moment there’s only class-dump, but I’ll probably add some new, smaller projects, and maybe even some of my older code once it’s been updated to work with Mac OS X. (I said it was old!)