It appears this story is old news now. 3.2.3 is available on the App Store. A few of you are still upgrading, so I’ll keep the article here for a while.
On May 18 we submitted PocketBible 3.2.0 to Apple for approval. On Thursday, May 28 they approved it and by Friday night it was being downloaded by our users.
When I saw it was available for me to download to my iPad, I updated my personal copy. I got the message I expected, that my data needed to be updated. I went to Manage My Data as instructed but there was no response from the program. I quickly hooked my iPad up to my laptop and ran the program in the debugger. It turned out the Manage My Data screen was being built, but as soon as it was displayed, it was being dismissed by iOS so the user never saw it.
I tried deleting and re-installing to no avail.
During this process, Facebook notified me of some messages from a couple people who I know to be active PocketBible customers. When I visited Facebook I found there were several users having the same experience I was.
I posted a status update to our Facebook followers instructing them not to download the update to their iPads (the program was working fine on my iPhone). After a few more minutes of testing I realized there was no way to work around this and that I was going to have to stop it from being distributed. Unfortunately, Apple does not offer an immediate “off” switch. I pulled the app from the App Store but it would take 24 hours to fully take effect.
I posted a message on the home page of www.laridian.com and wrote a blog article to explain what I knew about the problem. I set up a response on our tech support ticket system that pointed affected users to the blog article for more information. I pulled the update announcement I had made on Thursday from Facebook and our blog. I posted a status update on Facebook pointing to the blog.
Over the next five or six hours I tracked down two related problems in the Apple code. I was able to fix one of them fairly easily because the 15 places in the code that were affected were all in the same file (or, for you programmers, the same class).
Other problems were related to UIAlertView (messages that pop up in the middle of the screen, usually with an “OK” and a “Cancel” button) and UIActionSheet (windows that pop up from the bottom of the screen and contain a simple caption and a column of buttons). I found these to be used in 294 places in the code. Each of these instances had to be reviewed to see how to best work around the problem. In some cases, I changed the implementation to use an alternative method of doing the same thing. But in most cases there was no better alternative.
After doing some research on the Web (programmers use a site called stackoverflow.com to confer, converse, and otherwise hobnob with their fellow wizards) I found a good work-around that required only a simple change to the code in about a dozen places.
By Saturday afternoon I was ready to put the program in the hands of some beta testers. I posted a call for testers on the blog and on Facebook. I knew this would be tough going into Sunday morning, but I got a small number of testers from around the world to run the program through its paces. (I apologize to my fellow church members for taking a few minutes during the announcements to pull out my laptop, add three new beta testers to the provisioning profile, re-sign the program and upload it to the website.)
Interestingly, the only problems they found were bugs that have probably been in PocketBible since version 2.0 or maybe earlier. I made some effort to fix those but under the circumstances didn’t want to take more time than necessary to get the program back up on the App Store.
By Sunday evening, about 48 hours after discovering these debilitating bugs, I was ready to upload the program to the App Store. At the same time, I filed a request for expedited review with Apple. It took them 10 days to review the last version; they’ve taken as little as 2-3 days in the past. I was hoping they’d agree to expedite it, because even after it was approved it would take 24 hours to propagate to all of Apple’s servers. Apple approved the expedited review on Monday morning and an hour later the app itself was approved.
By Tuesday morning everyone was seeing the update (version 3.2.3) and reporting that it was working.
I apologize for the inconvenience. Here are a few FAQs:
What are the symptoms? “Manage My Data”, “Shop for Bibles and Books” and many other menu items don’t do anything. This is especially problematic, since the program tells you that you need to go to “Manage My Data” to update your data due to the program itself being updated. But Manage My Data doesn’t work. Other selections, such as “Copy Passage” and “Register Now” cause the program to crash.
Version 3.2.0 seems to be working on my iPhone. Should I be worried? The problem seems to be limited to the iPad.
Should I remove the program from my iPad? No. When you download the fixed version (3.2.3), it will overwrite the bad version and everything will still be there (books and user data). It is OK to leave it installed and even run it. It’s just that certain functions are disabled. You might also have it crash if you interact with any pop-up choice boxes like the registration prompt. Just leave it installed for now.
Why does PocketBible require you to go to Manage My Data anyway? Previous versions of PocketBible tried to maintain the integrity of your user data (notes, highlights, bookmarks, etc.) by detecting when you have logged into a different account, then asking you to say how you wanted to handle your existing data with respect to the new account (i.e. replace your local data with the data on the server or merge your local data with the data on the server). Unfortunately, it assumed that simply changing your password meant you were logging into a new account. This new version of PocketBible uses the same technique as PocketBible for OS X, which records the customer ID you use when you sync your data, then compares that customer ID to the one you are logged into. That way you can change your password or even log out and log back in, and PocketBible won’t get confused. Since the old version did not keep track of your customer ID, and since you may have logged in with your email address instead of your customer ID, PocketBible has to log into your account and ask the server for your customer ID. This is quick and painless — unless you can’t get to Manage My Data to do it!
I’m a programmer. What’s really going on? Apple changed the way that UIPopoverController, UIAlertView, and UIActionSheet dismiss their views. In each case, we previously could assume that after dismissing those views we could display another modal view or otherwise act as if the view was gone (whether it was actually gone from the display at this point is irrelevant — I know that takes another cycle through the run loop). But some recent update to the SDK made it so that dismissing UIPopoverController resulted in any modal view displayed after that to be dismissed along with the requested UIPopoverController.
UIPopoverController does not notify its delegate when it is programmatically dismissed, only when it is dismissed by a tap outside its view. So we have no way of knowing when it is done. There are various techniques to discover whether or not the view has been dismissed. I chose a very simple polling technique that doesn’t make assumptions about whether or not it takes only one pass through the run loop, as other solutions do. For UIAlertView and UIActionSheet, I changed the delegate method I use to act on a button press from the “button pressed” delegate method to the “dismissed with button press” delegate method. This assures that the view has been dismissed before we continue.