Alan Quatermain

Alan Quatermain

The Tumblog of one Jim Dovey, iOS Software Chief Architect at Kobo in Toronto, Ontario.
He Twitters, he has an , and can occasionally be found on LinkedIn or Facebook.
If you have a query, you can ask it here.

This blog contains personal opinions, and is not endorsed by any company.

496829666
So, Pages uses 100% public APIs does it? I think not— at least, not in the ‘everyone else could write the exact same app’ way it’s been interpreted. The thing which caught my eye was the appearance of the ‘Definition…’ item on the word menu. Double-tap a word and tap ‘More…’ on the menu which appears, and you get a ‘Definition…’ option, which pops up the dictionary definition window you see above. I’ve been looking for a way to do the same thing in the Kobo e-reader application, since it was available in iBooks, and noticing it in Pages, which ‘uses 100% public APIs’ I figured I’d just missed something. Sadly, I was mistaken. Opening up the Pages.ipa file to look at the app’s resources initially led me to Pages.app/en.lproj/DefaultDictionaries.plist, reproduced here: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>DCSDefaultActiveDictionaries</key> <array> <string>/Library/Dictionaries/New Oxford American Dictionary.dictionary</string> <string>/Library/Dictionaries/Oxford American Writer's Thesaurus.dictionary</string> <string>/Library/Dictionaries/Apple Dictionary.dictionary</string> </array> <key>DCSDefaultDictionaryPath</key> <string>/Library/Dictionaries/New Oxford American Dictionary.dictionary</string> <key>DCSDefaultThesaurusPath</key> <string>/Library/Dictionaries/Oxford American Writer's Thesaurus.dictionary</string> </dict> </plist> Those are the standard OS X dictionary files. On OS X, you access those using functions such as DCSCopyTextDefinition() in the Dictionary Services API, but that API isn’t available (or isn’t public) on the iPhone. The files, however, are present, noted by Chris McKay and confirmed by the property list used by Pages. Pages, however, doesn’t use that function. Instead, it would appear to inline the functionality directly. My reason for believing this (in the absence of any means of disassembling or class-dumping an encrypted ARMv7 binary) is that these files are essentially ‘black boxes’ whose contents are mostly only known to Apple. The word descriptions are in there, but the search index is in a private binary format. And the data is most likely inside a binary ‘Body.data’ file, with others in binary ‘Something.index’ and ‘Something.data’ So, while everyone else on the iPad gets to look at the dictionary files and go ‘buh-huh?’, Pages actually gets to use them, by virtue of copying the reader code from CoreServices.framework into their own app. But they didn’t call any private functions, so that’s all right then.

So, Pages uses 100% public APIs does it? I think not— at least, not in the ‘everyone else could write the exact same app’ way it’s been interpreted.

The thing which caught my eye was the appearance of the ‘Definition…’ item on the word menu. Double-tap a word and tap ‘More…’ on the menu which appears, and you get a ‘Definition…’ option, which pops up the dictionary definition window you see above. I’ve been looking for a way to do the same thing in the Kobo e-reader application, since it was available in iBooks, and noticing it in Pages, which ‘uses 100% public APIs’ I figured I’d just missed something.

Sadly, I was mistaken. Opening up the Pages.ipa file to look at the app’s resources initially led me to Pages.app/en.lproj/DefaultDictionaries.plist, reproduced here:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>DCSDefaultActiveDictionaries</key>
    <array>
        <string>/Library/Dictionaries/New Oxford American Dictionary.dictionary</string>
        <string>/Library/Dictionaries/Oxford American Writer's Thesaurus.dictionary</string>
        <string>/Library/Dictionaries/Apple Dictionary.dictionary</string>
    </array>
    <key>DCSDefaultDictionaryPath</key>
    <string>/Library/Dictionaries/New Oxford American Dictionary.dictionary</string>
    <key>DCSDefaultThesaurusPath</key>
    <string>/Library/Dictionaries/Oxford American Writer's Thesaurus.dictionary</string>
</dict>
</plist>

Those are the standard OS X dictionary files. On OS X, you access those using functions such as DCSCopyTextDefinition() in the Dictionary Services API, but that API isn’t available (or isn’t public) on the iPhone. The files, however, are present, noted by Chris McKay and confirmed by the property list used by Pages.

Pages, however, doesn’t use that function. Instead, it would appear to inline the functionality directly. My reason for believing this (in the absence of any means of disassembling or class-dumping an encrypted ARMv7 binary) is that these files are essentially ‘black boxes’ whose contents are mostly only known to Apple. The word descriptions are in there, but the search index is in a private binary format. And the data is most likely inside a binary ‘Body.data’ file, with others in binary ‘Something.index’ and ‘Something.data’

So, while everyone else on the iPad gets to look at the dictionary files and go ‘buh-huh?’, Pages actually gets to use them, by virtue of copying the reader code from CoreServices.framework into their own app.

But they didn’t call any private functions, so that’s all right then.