First, I wanted to name this article Correct program crashes at Apple, but then I realized that this was not a story about the APPLE review team but a story about the apple REVIEW TEAM. And of course about a bug, but mentioning that in the title would spoil the milk before the end of the story. So let’s get started.
I had submitted a new version of Regattakalender. As a sailor, one of my hobbyist side-projects had been this iOS app, that lists all sailing regattas of Germany that want to get listed in order to help me or other sailors plan their sailing season. Of course, the app is only available in German due to it’s regional character.
When the app got rejected because of crashing on an “iPad3,3” I was shocked. I had tested all available hardware versions EXCEPT the “new iPad” – simply because I do not own one. So was there something different? I had used parallel processing, synchronization with semaphores and other tricks to make sure that the customer gets the quickest possible response. And when this crash message came, my immediate reaction was: Let’s search for the race condition. This machine is faster than anything I have – this may have revealed a race condition in my parallel programming, that I simply hadn’t been aware of. I have seen so many examples of this problem pattern, that I spent a whole night looking through my code. I found nothing.
Some days later, when an iPad3 crossed my paths, I pulled out my Laptop and tested for the bug. The party guests at this birthday party where not amused of me showing my “nerdiest face”, but, hey, iPads from party visitors come and go, so you better use your time while you can. It turned out – in no way I could reproduce the error. It just did not fail. No crashes. It ran better than on the other apple products I had tested it before. So much for my theory.
In a very depressed mood, I wrote the apple review team, that I could not find any error and that I had no idea what to do. I had corrected an error that the iPad showed a different icon than I wanted, but this was very likely not the reason for the crash. Unnecessary to say that this message from me was not helpful, but I obviously wrote it for personal relief. After a few minutes a message arrived from the review team. They had made a video of the app trying to start and crashing on their iPad. You could see the person filming it with a black iPhone 4 / 4S running the app on the iPad and being reflected in the iPad screen. And you could see that he (it looked more like a male person) had a cubicle with a bookshelf. I was positively motivated to try harder to find the error – much to the discomfort of all the other party guests.
When I had corrected the icon error, I was getting aware of the configuration being different for the iPad than for the iPhone. So I went through all the configurations and configuration files to check whether they contained some things that were “looking suspicious”. Since an iOS configuration consists of so many details, there is a lot to be looked at, but I was trying to find something that would be different for the iPad or for the review version, when compared to the version I was using for testing.
When I stumbled over the optimizer settings, some hope returned: The crash logs that the review team had sent me had strange numbering for the lines, may be the optimizer had mixed something up? I tested with the optimizer settings turned the same for testing and distribution: Nothing, still everything was working. I put the settings back to original settings (always only change one parameter at a time for testing, else you will never know which one was the reason for the cure) and scrolled down.
And then it hit me: The setting for automatic reference counting (ARC) being applied was different for distribution! I could resist my urge to test the corrected settings, because I know the law of error testing:
- You can not prove the absence of an error. You can prove its existence. And when the error is gone after the change, then it is plausible, that the change made the error go away. But it is only plausible, not proven.
And in order to see the error go away, you have to be able to reproduce it first. You have to. Else you have no reason to believe that the error was fixed. So I changed the setting for “Objective-C Automatic Reference Co…” (so I had to guess what this means until I saw the help text at the right hand side: “CLANG_ENABLE_OBJC_ARC”) to: “NO” for testing as well. And guess what? It crashed! Yippie!
So I corrected me settings, recompiled submitted and … started to party again.
So I am happy that the review team exists and I did not ship a broken app to my customers. And that they took the time for the video, which motivated me.
So what did I learn from this?
– When I agree to upgrade my project to whatever “new”, I will double check the settings afterwards to find any glitches
– When I prepare my program for submission, I will now test the distribution version and not only test the debug version and then compile for distribution. Anyone any ideas how to run the .app file in the .xcarchive file?
– The guys from the app store test team are not only useful (I knew that before), but actually helpful.
When you want to publish your app in the Apple App Store, you have the choice in which countries you want your app to be offered. I have not counted the number of countries lately, but hey, it is a long list, so you probably rather click on “all countries”.
