iOS App crashes when Archived using Release but works fine with Debug...

[dbramhall]

I am developing a tab bar-based application for iOS and I have submitted it to the App Store however it has been rejected because it crashes when one presses the second and third tab (there's four tabs) however this was not the case when I was debugging the application for two iOS devices and the iOS Simulator and I have Archived the application, installed it on an iOS device using iTunes and it does indeed crash... I was therefore wondering why it doesn't work when it's built with Release and why it does work flawlessly when built with Debug...

Anyway, here's the crash log: http://cl.ly/A13A and I was wondering if anyone could have a look and let me know because I'm rather stuck right now and cannot isolate the problem...

 

[PhoneyDeveloper]

It crashes because there's a bug.

Before submitting an app to the app store you need to test adhoc builds. These are most similar to the app that apple will test and your users will use. As you've discovered, it's always possible for there to be bugs that are only revealed in your release build, or only revealed when running on the device without the debugger, or with the device untethered. It's essential that you do some testing like this. It's best if you have beta testers who will test for you as well.

Looking at your crash log what I see is an assertion failure, or SIGABRT. It happens at LingoTableViewController.m:220 where you alloc/init a label. The assertion failure occurs after the frame or bounds are set for the label or its layer. There is a common assertion failure if you set the frame and one of the fields in the frame is a nan or otherwise is an invalid floating point value.

When an app is killed due to a SIGABRT there is some text in the device console that describes the cause. You should be able to find that text.

You may be able to debug this simply by changing your Run scheme to use the Release build instead of the Debug scheme or by using log statements. Debugging release builds can be awkward.

Most likely there is a bug in your code that is revealed by the optimizer. Something like an uninitialized variable. Does the static analyzer report anything?

 

[dbramhall]

Sure, but The first tab bar view is a tableview that contains the same code as the other two tabs and that's works fine.

 

[PhoneyDeveloper]

What's your point?

There's a bug that's causing your app to throw a SIGABRT under some circumstances. Your job is to find it.

 

[chown33]

Sure, but The first tab bar view is a tableview that contains the same code as the other two tabs and that's works fine.

Maybe you can use that fact to help you find the bug. If the code is the same, but only one crashes, what can cause the fatal difference?

Maybe the data is different. Maybe some other resource is different.

Don't get too obsessed following this path, because it could be worthless. The real cause could be an uninitialized variable in some other place in the code, and it's the timing of when the code executes that causes the crash. Or a variable is under-retained. Or other things.

 

[adjwilli]

Ad Hoc distribution to check

I recently had a similar problem where my app crashed in distribution builds but not in development builds. I'm still not sure why it happened but I fixed it and here is what helped me.

First, you need to test your app with ad hoc distributions. This is the only way to troubleshoot you app like it will appear in the App Store. With XCode 4.3 this is now a lot easier to do that before.

Second, make sure all your variables that need properties and typedefs have those. This was the problem with my app. I was passing around a block variable from one view controller to another, then inside the second view controller. In the interface section of my header file I had:

void (^DoneCallback)(NSString *file);

But what i needed was this outside the interface:

typedef void (^DoneCallback)(NSString *file);

@property (nonatomic, copy) DoneCallback doneCallback;

Then afterwards in the .m I could set the block variable as such:

 self.doneCallback = callback;

And call it in another method like:

 self.doneCallback(file);