We've pushed new versions of our public framework source to github, featuring a bunch of work from our iPad apps, OmniGraffle and OmniGraphSketcher. Some of the highlights include our document picker, inspectors, a bunch of controls, and a start on a CoreText-based text editor, but there is much more.
For a quick iPad example, open up OmniGroup/Frameworks/OmniUI/iPad/Examples/TextEditor and build it. The text editing bit of this sample is a little rough, but this shows off some of the document picker.
Even if you aren't interested in adopting the frameworks directly, there are a bunch of little gems that you can use. One such feature is our Objective-C runtime sanity checker (in OmniGroup/Frameworks/OmniBase/OBRuntimeCheck.m).
The runtime checker helps avoid problems with mismatched method signatures between classes and their superclasses and between classes and conformed protocols. These can creep in as ABI changes from 32- to 64-bit support is added, or as subtle shifts in API happen in the system frameworks or your own class hierarchies. Some of these clang will check for you, but not all.
For example, having built OmniBase (with the Debug configuration, which enables this checking support) we can run Xcode with checking enabled (not to pick on Xcode, lots of apps have these problems):
% OBPerformRuntimeChecksOnLoad=1 DYLD_INSERT_LIBRARIES=/Users/Shared/bungi/Source/PROJ/Products/Debug/OmniBase.framework/OmniBase /Developer/Applications/Xcode.app/Contents/MacOS/Xcode?
... <br />
2010-05-13 13:36:10.205 Xcode[19717:903] Method scriptWorkingDirectory has conflicting type signatures between class and its superclass:<br />
signature i16@0:8 for class XCUserScript has imp -[XCUserScript scriptWorkingDirectory] at 0x100874d40 in DevToolsInterface.framework<br />
signature @16@0:8 for class XCUserScriptNode has imp -[XCUserScriptNode scriptWorkingDirectory] at 0x100c8f870 in DevToolsInterface.framework<br />
?...
?
Here we can see that a method's signature has changed — in one case it is returning an integer and in the other an object. Probably not a good sign.
By default, we silence problems where both sides of the conflict are in system frameworks (since we can't do anything about them). We've logged Radars on the in-system conflicts, but if you'd like to see them, you can also define OBReportWarningsInSystemLibraries in the environment:
2010-05-13 15:19:05.652 Xcode[21608:903] Method hash has conflicting type signatures between class and its superclass:
signature I16@0:8 for class CIVector has imp -[CIVector hash] at 0x7fff81e27e84 in QuartzCore.framework<br />
signature Q16@0:8 for class NSObject has imp -[NSObject(NSObject) hash] at 0x7fff84862e80 in CoreFoundation.framework
