We’ve just been notified that our latest update to PocketBible (version 2.0.2) has been approved by Apple. It should become available in the App Store over the next 24 hours.
This update mostly affects people at either end of the range of supported iOS versions. For those of you still running some version of iOS less than 3.2 (primarily those of you with first-generation iPod touch devices running 3.1.3) you’ll finally get to see what PocketBible 2 looks like. Both the initial release and the 2.0.1 update had problems that prevented them from running on those devices. We had been relying on our development tools to tell us if we were using features of iOS that were not present on those older devices. Unfortunately, it turns out they are very silent on that issue. We’ve learned our lesson and have “downgraded” an old iPhone to 3.0 for testing. (Previously we were limited to running 3.2 in the iPhone emulator.) As a result we’ve been able to identify the issues that were preventing PocketBible from running on 3.0 and 3.1 devices.
On the other end of the iOS version spectrum we ran into an interesting bug in iOS 5. When we put verses on the pasteboard (that’s “clipboard” everywhere else but in Apple Land), we always store both a plain-text version and an HTML version. This allows applications that understand HTML to paste nicely formatted text, including superscripted verse numbers, words of Christ in red, and bold headings. Simpler applications expecting only plain text have the option of requesting just the plain text from the pasteboard.
When an application pastes data from the pasteboard, it specifies what format it wants. Unfortunately, in iOS 5, when an application asks for the traditional “utf8-plain-text” that has worked in all iOS versions since the beginning of time (OK, since iOS 2), the operating system will not give it the “utf8-plain-text” version of the pasteboard text, but instead will substitute something else — in our case, the HTML text that is also there. Since the pasting application neither expects nor understand HTML, it treats it as plain text and pastes it, tags and all, into your document.
To get around this, we have to add a third form of the text to the pasteboard, which is identified simply as “text”. This version is identical to the more correct “utf8-plain-text” that has worked on previous iOS versions. Doing this tricks iOS 5 into supplying plain text to apps that request it, so that pasted verses no longer include HTML tags.
On the subject of iOS 5, it introduced some new fonts and some new ways of identifying old fonts. Since iOS makes it very difficult to determine if a font provides the bold, italic, and bold/italic versions that PocketBible requires, we use a somewhat fragile technique to try to make that determination by looking at the names of the fonts. This didn’t work exactly right in iOS 5. The result was that Helvetica Neue was displayed as condensed and bold, and both Optima and Hoefler Text were missing from the list of available fonts. This has been fixed and the code reinforced so that hopefully it will do a better job identifying fonts in the future.
Some of you have had the unfortunate experience of selecting two or three verse and when you ask PocketBible to highlight the selected verses, it highlights the rest of your Bible. This happens when the end of your selection is right on the little gap between paragraphs. This is fixed in version 2.0.2 so that your entire Bible isn’t highlighted when you only want to highlight a couple verses.
Finally, probably because of the load that PocketBible 2 has put on our servers, many of you ended up with corrupted book files. Since PocketBible can’t read the file (the were corrupted during download) it can only identify the book by its 8-character alphanumeric file name. So you would see a message that “0065001d.lbk” was damaged, but there was no way to know what book that was so that you could re-download it. This message came up every time you ran PocketBible. The new version deletes damaged books automatically so that you won’t be nagged by warning messages.
For all the complaining we do about the App Store approval process, this update was approved in about 24 hours. Hard to complain about that!