Wednesday, August 04, 2010

Apple AppStore feedback

This morning the AppStore on my iPod Touch pointed out that the Twitter app had an update. I installed it and launched the app to see what was new. Crash! After 5 crashes in a row without a successful launch, it was obvious that a bad build had snuck into the App Store.

Incident Identifier: 61EE3335-1AD0-4099-8EC6-FAB4B6160A43

CrashReporter Key: 001e29bd4aa2ef81d42701ce5325da94b364e27b

Process: Twitter [8470]

Path: /var/mobile/Applications/8E13E345-CDD3-4CA4-899D-8E38BA6661C5/

Identifier: Twitter

Version: ??? (???)

Code Type: ARM (Native)

Parent Process: launchd [1]

Date/Time: 2010-08-04 07:58:35.994 +0100

OS Version: iPhone OS 3.1.3 (7E18)

Report Version: 104


Exception Codes: 0x00000001, 0xe7ffdefe

Crashed Thread: 0

Dyld Error Message:

Symbol not found: __NSConcreteGlobalBlock

Referenced from: /var/mobile/Applications/8E13E345-CDD3-4CA4-899D-8E38BA6661C5/

Expected in: /usr/lib/libSystem.B.dylib

Dyld Version: 149

Binary Images:

0x1000 - 0x14ffff +Twitter armv6 <43ca857e309a61ba8c5da3ab83e42218> /var/mobile/Applications/8E13E345-CDD3-4CA4-899D-8E38BA6661C5/

As an iPhone app developer, I think I know what this problem is. We saw this problem in one of our apps. IIRC, the new, preferred llvm compiler has a bug with the new blocks language construct, and gcc doesn't, and the bug only shows up at runtime, in certain environments. To fix it, Twitter are going to have to recompile and use gcc rather than llvm, and then wait for the wheels at Apple to turn.

Other people have talked about the frustration of not being able to iterate at web speed or do continuous deployment, but that's part of the ecosystem that you operate in with Apple.

Testing, either by the Twitter team, or by Apple when they review the app prior to approving it, should have caught this issue. But these things happen.

We had a similar thing happen with an update to one of our apps recently. An update went live and thanks to the apparent difficulty in doing your own testing of the binary that gets sent to Apple, an issue only became apparent when the new version was available through iTunes. To me, this is where the ecosystem is broken. If I have a webapp and I deploy an update, then find an issue (via my cluster-immune system - one day!), I roll it back.

iTunesConnect has no rollback, even though it seems like a highly desirable feature. I know in our case, we would have liked the option to rollback to the last known good version and then wait for Apple to review an update, rather than having the world upgrade to a version that we didn't want them to be running. I imagine Twitter would appreciate a similar feature right about now.