July 13, 2012
Jul 18 Update:
Apple has approved the latest release, and it will be available again world wide later this evening.
Jul 17 Update:
Apple has approved our request for an expedited review, so we hope to see the app available again tonight or tomorrow. The new app version is 2.1.1 and there will be an updated plugin to match (also 2.1.1).
July 14 Update:
We have submitted the update to the App Store for approval and requested an expedited review (which may or may not be granted). We’ll let you know something as soon as Apple tells us.
A big thanks to all of our users who have left comments below! We waffle sometimes on how much information people really care about, so it’s good to get feedback!
July 13 Update:
After piecing together situations, reports, and some arcane error codes, we were finally able to track down the problem.
If we were a regular company, we’d tell you that it’s due to “technical difficulties”, but we do try to be a little more open than that: In short, we screwed up the release by missing an updated version number in one of the files. The file in question was the database definition file. Each database has a version associated with it. If iOS detects a new version, then it will automatically update the database in question.
In the case of 2.1, we had modified the database structure to support some new things coming down the pipe, but didn’t update the version of the definition. So when existing 2.0/2.0.1 users tried to update, the app freaked out because the database and the database model didn’t match, and thus the crash happened almost immediately on startup (the first time we accessed the database).
How did we miss this?
Good question – that was part of what sent us down wrong path for a while. We have a couple branches in the code for internal testing vs a live build (so, for example, we get a lot more debug information while testing). As part of this branched code, if the testing versions detected the situation above, it’d simply delete the database and start over from scratch without an alert (hey- it’s meant for testing!). The test versions are supposed to mimic the final build, but didn’t in this case.
In short, we missed it because the code we were looking at was working ok for testing but not the final release. Apple missed it because (presumably) they installed fresh. It wasn’t until that final code made it into the hands of users that we saw the error. It’s unfortunate that we can’t test the final Apple released app before it goes live, but it’s currently not an option.
We’ve since changed both that conditional code and the build process so it won’t happen again.
So what now?
We’ve fixed the problem and are submitting to Apple shortly. It’ll come as a 2.1.1 update. We can’t say when – the review process is of course up to Apple. There are a couple scenarios for users:
- If you start fresh with the 2.1.1 version (or delete and reinstall), you’ll of course be starting with a new database and be fine
- If you are currently running 2.0 or 2.0.1, then just install the update and things should run as normal
- For the approximately 300 users that upgraded in the ~30 mins that the update was available:
Due to the nature of the problem of the error, we are not able to automatically upgrade your database. We recommend that you sync all your changes and then delete the app before installing 2.1.1. If you happen to have a backup on iTunes from a week or so ago, you could restore that and then update to 2.1.1. We sincerely apologize for the problem. We’ve screwed up, and we’ve done everything we can to try to fix the problem, but there’s just not much we can do at this point.