the last of the bugs

%#$#@# It took all last night, but I’ve finally fixed the crashes on 3.1.x devices, and uploaded new versions of gravilocity, ibeams and ibeams lite.

the various reasons the apps have fallen apart:

• Too too long to load, detailed in the previous post below.
• Use of flurry for usage tracking. Flurry added ios 4 support but I missed some not particularly well documented flags that needed to be added to the build to make things happy on ios 3.x devices. Not having these flags set caused a run time error.
• External display screw ups – external display code caused 3.x to crash

Lets talk about the external display stuff. At one point the hook ups were behind guard code that only triggered on the iPad. But then the iPhone 4 came out with external display support, so I removed the guard. Following apples instructions, build with ios 4.0, target the 3.0 sdk. seemed to compile fine. I just assumed it would no opt on older devices.  They were just notification requests not actual executing code.

This sounds like a simple thing to track down.. It would be if apple hadn’t made it rather difficult to test 3.1. When ios 4 shipped, xcode stopped including support for the 3.x simulator, the older xcode wouldn’t compile my code anymore since there was bits of 4.0 used. So the only way to test 3.x support was with a 3.x device. I’ve got a phone, a touch and a iPad. Recently apple stopped allowing downgrades back to 3.1.3. ios packages have a signature that apple gets a chance to check before installation, and apple decided to stop allowing 3.x installs, even for developers.

After 2 hours of reading jailbreak message boards and getting nowhere trying to downgrade the touch. I borrowed an old iPhone 3G from a friend that just upgraded to a iphone 4, installed my apps and watched things go boom.

A new guard that actually checked the ios version number seems to have done the trick and I’ve submitted new versions of all my apps.

At no point has apple ever bounced my apps back due to crashing, and they were all crashing on 3.1.x, and there’s I never been a crash log from apple at any point indicating this problem.

So that’s the story 6 weeks of angry customers, long nights and a baffled gedalia, now I’m going to go hold my breath and hope it’s all fixed now.

Advertisement

The Ticking Time Bomb in Your App?

In the last few weeks I’ve started wondering if it was worth working on iPhone apps anymore. The iPad is easier to build an user interface for, at least in terms of real estate, and more fun to test on. More significantly all of my iPhone apps started to break down. Gravilocity did in a rather explosive manner, taking down a thousand dollar marketing attempt. But gradually I started to see complaints about iBeams too. “crash on launch WTF”, “stopped working after last update.” Occasionally iTunes Connect, apple’s app management website for developers, would report a timeout on launch, but without a stack trace, description of what it meant, or explaining anything about the devices it was happening on.

I’ve now updated Gravilocity 3 times trying to figure out these unexplained crashes. Every time I optimized and sped up the init code, fewer people reported a problem. But it never really finished off the crash. Over the weekend I think I finally realized that this was happening:  http://stackoverflow.com/questions/169470/does-the-iphone-timeout-if-a-function-takes-too-long-to-execute Apple has left a wonderful little gift for the unsuspecting coder. It will never go off while debugging in xcode. On the other hand, every time you increase the resolution of your assets to make the latest iPhone 4 user happy, you’re raising the likelihood you’re going to blow up on older devices. Now once you know about this issue, it’s fairly easy to fix. Just make sure you aren’t doing lots of loading in your application delegate init code.

In my case the default openGL sample code, which I bootstrapped my infrastructure off of, creates the openGL context and then immediately draws a frame. Gradually the amount of things I do as part of the initial draw frame code got much more elaborate, (even turning on the sound detection code can take a couple of seconds). I’ve broken up what happens so that more things happen after the application “finishes launching” and now we wait for apple to approve the app to see if this really was the bug.

Free app a day and Gravilocity go boom

This weekend was very very bad.  I paid to get featured by Free app a day true to their word  over 10000 people downloaded the app.

However due to a unforseen bug Gravilocity was a completely dead in the water on the iPod touch.

After a few hours of debugging I traced this to two problems.

• The Sound Meter
• New External Display support.

the sound meter was pretty dumb, Gravilocity shares a code base with iBeams, and iBeams has a sound meter that shows up visually. This requires that I listen to the mic every frame. Now Gravilocity doesn’t have a sound meter but it does have the option to tie some of the parameter controls to the mic. So there was no reason to disable the code. The gotcha came when there was no mic, and suddenly the audio code started consuming a ton of CPU time trying to open the mic input, all it really needed was to return early, one line change. Presumably this is a bug in iBeams as well, and I just assumed it was the touch running slower then my 3GS.

So the meter didn’t turn the universe against me… But the external display did. I got external display support working for Gravilocity 1.1. You plug in the VGA out cable and poof neat party trick. Since, I make heavy use of Frame buffer objects to do the motion blur effects, it was fairly simple to pipe those dynamic textures to the external display, it was actually too simple. Since all I needed to do was draw 2 triangles per frame, there was almost no performance hit on the iPad or iPhone 3GS when the external display code was active.  I stupidly left it running even if you didn’t have the display connected, in my own defense it’s pretty hard to debug Apple’s Objective C initialization framework. I had just pattern matched off of the standard OpenGL view. So I just didn’t realize when the initializers got called.

Now we get to the disaster, the iPod touch doesn’t seem to have the memory to handle the creation of a second rendering context. So one frame was drawn to the screen, and then the app became completely locked up. The fix was fairly simple, move the context initializer to the the screen got_connected function, which never happens on the touch. 3 lines of code

And now we’re all caught up to speed. 4 buggy lines of code, 10000+ downloads, 200-300 angry review trolls, fun fun fun.

What are my take aways:

• People who download busted things are a lot more vocal then the 20% that gave Gravilocity 5 stars, presumably 3gs/4g and iPad users.
• Angry reviews are depressing, especially when you’re paying for them
• Apple’s review process is just busted… At one point they were getting towards 24-36 hrs for a review. They are back up to a week. They’ve never spotted a crash in my code even though I’ve gotten a bunch of stuff through review with hard crashes in them, (usually buttons that were incorrectly wired in interface builder.) They’ve given me flack for UI choices, the attempt to give money to charity, But never a crash. If they are going to hold up an app for a week, at least test the thing on all the available devices. If they aren’t going to bother really testing the app, then give the developer a way to get a hot fix to the customer… I had a fix for the app within 3 hours of the complaints rolling in. It’s going to take a week for it to actually show up on the app store.
• iPad/iPhone universal apps… While it’s nice to support both in one app. It really increases the testing burden. Price points get locked together, mistakes in one target can drag down your ranking in the other. Even without the iPad, you can now expect to have to worry about 3-4 devices with various capabilities. not to mention OS versions.

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!