title: Reverse engineering iWork '13 formats
body: <p>Prior versions of Apple's iWork suite used a very simple document format:</p>
  
  <ul>
  <li>documents were Bundles of resources (folders, zipped or not)</li>
  <li>the bundle contained an <code>index.apxl[z]</code> file describing the document structure in a proprietary but fairly easy to understand schema</li>
  </ul>
  
  <p>iWork '13 has completely redone the format. Documents are still bundles, but what was in the index XML file is now encoded in a set of binary files with type suffix <code>.iwa</code> packed into <code>Index.zip</code>.</p>
  
  <p>In Keynote, for example, there are the following <code>iwa</code> files:</p>
  
  <pre><code>AnnotationAuthorStorage.iwa
  CalculationEngine.iwa
  Document.iwa
  DocumentStylesheet.iwa
  MasterSlide-{n}.iwa
  Metadata.iwa
  Slide{m}.iwa
  ThemeStylesheet.iwa
  ViewState.iwa
  Tables/DataList.iwa
  </code></pre>
  
  <p>for <code>MasterSlide</code>s 1…<em>n</em> and <code>Slide</code>s 1…<em>m</em></p>
  
  <p>The purpose of each of these is quite clear from their naming. The files even appear uncompressed, with essentially all content text directly visible as strings among the binary blobs (albeit with some like RTF/NSAttributedString/similar-related garbage in the midst of the readable ASCII characters).</p>
  
  <p>I have posted the unpacked <code>Index</code> of a simple example Keynote document here: <a href="https://github.com/jrk/iwork-13-format">https://github.com/jrk/iwork-13-format</a>.</p>
  
  <p>However, the overall file format is non-obvious to me. Apple has a long history of using simple, platform-standard formats like plists for encoding most of their documents, but there is no clear type tag at the start of the files, and it is not obvious to me what these <code>iwa</code> files are.</p>
  
  <p>Do these files ring any bells? Is there evidence they are in some reasonably comprehensible serialization format?</p>
  
  <p>Rummaging through the Keynote app runtime and class dumps with F-Script, the only evidence I've found is for some use of Protocol Buffers in the serialization classes which seem to be used for iWork, e.g.: <a href="https://github.com/nst/iOS-Runtime-Headers/blob/master/PrivateFrameworks/iWorkImport.framework/TSPArchiverBase.h">https://github.com/nst/iOS-Runtime-Headers/blob/master/PrivateFrameworks/iWorkImport.framework/TSPArchiverBase.h</a>.</p>
  
  <p>Quickly piping a few of the files through <code>protoc --decode_raw</code> with the first 0…16 bytes lopped off produced nothing obviously usable.</p>