Status updated Saturday, May 30 at 10:00 AM CDT. Updated items are highlighted.
We have discovered significant problems with version 3.2.0 which was approved for the App Store on May 29. As a result, we have pulled it from the store. Apple provides no way to revert to an earlier version. Our only choice is to pull the app while we work on a fix.
Here is what I can tell you as of Saturday, May 30 at 12:15 AM:
The primary problem is on the iPad. Many menu items don’t do anything. This is especially bad because the new version requires you to go to Manage My Data to download some updated information from our server in order to continue sync’ing your user data, but you can’t get there.
I haven’t taken time to check thoroughly, but the iPhone should be OK. So far nobody is reporting problems with PocketBible running on the iPhone.
It should be the case that if you leave the program on your iPad, when we issue an update, 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!
How do I revert to the old version? We tried uploading 3.1.0 back to the App Store but that doesn’t work because the version number is “old”. In order to change the version number we would have to rebuild 3.1.0, which would insert this same erroneous Apple code into 3.1.0. So that wouldn’t fix the problem. If you sync your iPad to your PC or Mac, it’s possible an older version of PocketBible is in iTunes. I can’t help you with that, but that’s where I would look if I wanted to revert to the older version. That being said, I recommend you just wait for the fix.
It may take a long time to fix this. The problem with getting to Manage My Data (or getting just about anywhere from the menu) was a fairly quick fix last night. About 15 places in the code were affected. These will need to be tested. Unfortunately, while we were fixing that problem, two other major areas of the code were found that also exhibit a similar problem. This is complicated by the fact that Apple is changing its approval requirements on Monday and we will be required to submit only 64-bit apps. PocketBible builds fine for 64-bit, but the text-to-speech code we use is 32-bit only. I have resisted updating it because it requires completely replacing all the voice databases and installing a new version of the TTS engine. I literally have no idea what will be involved in that. So IF I can get this fixed before Monday, Apple MIGHT accept a 32-bit program and MIGHT expedite the approval.
We can’t respond to each of you personally to address your particular situation. Time I spend responding to email is time I’m not spending fixing the problem. I’m taking a few minutes to start this blog article so I have a place to direct everyone for more info. Please don’t send an email to tech support. Just check back here.
This is my highest priority for the foreseeable future. I’m not ignoring the problem; I’m just ignoring your email.
This is my fault for inadequate testing. I’m sure I ran 3.2.0 on the iPad simulator using various configurations and I never ran into any trouble. It is difficult to comprehend how I could have missed this. I haven’t taken the time to try to figure out when the problem was introduced.
But this is also Apple’s fault for changing behaviors in their code. What it boils down to is that they changed the order in which certain things occur. The easiest way to explain it is this: They tell us we have to dismiss the menu before we pop up a modal dialog in the center of the screen. That has always worked just fine. But they recently made a change so that when we dismiss the menu it doesn’t actually get dismissed until later. Then we pop up the modal dialog in the center of the screen, but before you see it, Apple finally gets around to dismissing the menu and while they’re at it, they dismiss our modal dialog, too.
The solution is to wait until the menu is actually dismissed before displaying the modal dialog. Normally, iOS notifies us through a “delegate method” that it has finished its work. But in this case, it does not. It doesn’t provide any way for us to be notified. So our only choice is to tell iOS to dismiss the menu, then sleep for a while. When we wake up, we check to see if the menu has been dismissed. If not, we go back to sleep and repeat the process.
Needless to say this is a major change from the way the code is written, so it involves some testing.
We’re discovering that all the little pop-up choice dialogs like alerts and action sheets work the same way. We expect them to be dismissed when you tap “OK” but they actually stick around long enough to interfere with what we’re doing next. There are dozens of these in the code, and they all have to be rewritten and tested. Before Monday.
I’m pretty sure this is the worst thing that has happened to me in 27 years of writing commercial software. I’m sorry I didn’t see this before the product shipped. It’s inexcusable.