iTunes Connect Crash Report - UINibDecoderDecodeObjectForValue - objective-c

I have a crash report on iOS 5.1 that is caused by UINibDecoderDecodeObjectForValue. To my understanding this generally is due to a value being set improperly in a nib (generally something has been deleted). The crash report gives me two problems:
From the crash report itself I cannot see to figure out which nib is causing the crash. However I have had some review stating that the crash happens on a setting screen for some users so that is the one I am focusing on.
Assuming it is the Settings view, its simply a UIViewController with a table view. It has the UITableViewDelegate and UITableViewDataSource. To my knowledge everything is setup correctly.
So my questions would be:
How can I confirm what nib is causing the error?
Is there anyway I can have XCode give me warning about anything that may be wrong with my nibs?
Stacktrace from the crash report is here.

it would really help if you post the exception you got.
check for IBOutlets, something might be missing or set wrong (IB is not known for it's best integration with XCode)
check for deprecated UI elements which are inside your nib (again, IB is not known for it's compatibility with the target SDK).
Good luck!

The problem was with iOS auto layout. Similar to the issue found here:
presentViewController: crash on iOS <6 (AutoLayout)

Related

subclass of UIViewController is unable to call loadView method

i have a subclass of UIViewController, and when it is called from another class the app just freezes - i used the Xcode debugger and figured that when I'm trying to access the class's view property the app freeze. another weird thing is that when i type in the debugger control panel: "po objectOfTheProblematicClass.view" the debugger stops responding.
the code I used was similar to this:
UIStoryboard *sb = [UIStoryboard storyboardWithName:#"Main" bundle:[NSBundle mainBundle]];
WTStickyViewController *stickyVC = [sb instantiateViewControllerWithIdentifier:#"WTStickyViewController"];
stickyVC.sticky = sticky;
// Setup view controller containment:
[self.parentViewController addChildViewController:stickyVC];
self.containerView = self.parentViewController.view;
[self.containerView addSubview:stickyVC.view];
WTStickyViewController is the subclass of UIViewController. the app freezes when it reaches
[self.containerView addSubview:stickyVC.view];
but it's because this is the first time that stickyVC.view is called.
if for example i would put somewhere in the code
UIView *viewForExample = stickyVC.view;
the app would freeze there.
the exact same app works fine when compiled on a device with iOS 8 but has this problem with iOS 9.
if anyone knows why is this happening and if there is a solution it will be great. thank you.
I was having a similar issue and it was absolutely maddening. The CPU went to around 100% in the resource monitor during debug as the app deadlocked. Printing to console or just generally accessing the view controller's view property caused this behavior. Ultimately, what 'fixed' it for me was removing it from the base localization file. I know that doesn't make sense, but I'll elaborate as best as I can.
I'm maintaining a legacy universal app that has 2 'main' storyboards called Main_iPhone and Main_iPad, which as you can probably guess are the loaded dynamically based on what device you're launching on. I noticed that only the iPhone nib view was deadlocking as described, and iPad was loading fine. The only thing I could tell as that the iPhone storyboard had localization enabled while the iPad storyboard had not. So here's the steps I took loosely to remove it from base localization (you may want to do this in a separate branch/sandbox to make sure this works before deleting project references):
Right click the problematic view and/or storyboard in question, show in finder. For me it was inside the Base.lproj folder as expected.
[Re]move the file to a different directory so Xcode can not find the link the project (file goes red in file browser). Press delete to remove the file from the project file's reference from the project itself.
Add the file back at the new location in your repository/project structure so Xcode picks it up as a new file. Ensure all of your references to the file are updated to the new location.
Verify your storyboard/xib file is not localized anymore, clean project, re-run and see if the issue is still there (see image).
You can also just update the file location using the update location button in the file properties view on the right side (see other image).
Don't know if this will fix it, but I thought I'd share what helped me in the chance that it helps others as well.
A bug report was sent to apple and hopefully it will be fixed soon - the problem is indeed with Xcode 7.
If you are encountering a similar problem, it can be solved by doing one of the following:
1) Use Xcode 6.4, at least until apple fixes this bug.
2) Rebuild the problematic view in the storyboard.
I will post the radar link once I got a chance to speak with my manager about it...

iOS - mysterious SIGABRT

I'm getting a SIGABRT - any suggestions how I catch it?
The only clues I have so far are:
the Exception breakpoint (How to track down cause of SIGABRT) does not seem to be catching it
it only crashes on the iPhone 4 device running iOS7 and not on the iPhone 4s simulator or the iPhone 6 device.
Here's my (pretty useless) stack trace:
UPDATE
A longer (but no less useless) stack trace:
Look in the console log. It will provide some info on the error which caused sigabrt. Also be sure to check your outlet and action connections. You may have deleted a outlet after you linked it up and that way xcode can't find that missing outlet you deleted.
SIGABRT occurs when you accidentally/intentionally change connections of an outlet or an action.
According to you, you deleted a connection by merely deleting it from the code but under the hood, it still exists.
So, what you can do is, click on the attribute which is giving the sigabrt and then click on the connections inspector on the right side of the Xcode.
If you see any stray connections, just delete it. This is how you actually delete a connection.
Hope this helps.

unrecognized selector sent to instance on deviceOrientationDidChange

Right now my app should only supports Portrait. On Summary/Supported Device Orientations I have only selected Portrait so I'm hoping that my app will not rotate. I was testing the app on a device and suddenly I'm getting the following error randomly:
[UIButtonContent deviceOrientationDidChange:]: unrecognized selector sent to instance
It happens when I rotate the device SOMETIMES, is not consistent, and is not always over UIBUttonContent. I supposed that if I only select Portrait, deviceOrientationDidChange should not be called or should be ignored.
Other times my app crashes with an EXC_BAD_ACCESS (code=1, address=something) but it happens when I rotate the device so I'm guessing that both errors are related.
I don't know what to do with this, it's hard to debug because I don't have feedback, the All Exceptions Breakpoint is not being called, so I don't know where and exactly why this is happening. Any idea on how to debug this is welcome.
These are the classic signs of a memory management error. You have over-released some object and it has been deallocated while something else still references it. Later, something messages it. In some cases a new object has taken its place, but that object doesn't understand the messages it's receiving. In other cases, there's no valid object and you get a crash.
Edited to second the advice to use the Zombies instrument to find the over-release.
Do you have a class that should be called with deviceOrientationDidChange:? When this happens, it usually means that you have a dangling reference to a deallocated object. You should try profiling your app with Instruments in "Zombies" mode.
I solved this issue a long time ago, but I think is good to share what actually helped me on this case.
After trying everything with no results with Instruments I started debugging old-school. I had an idea of "where" the error was so I just commented all the code on that section. I was right, the bug just disappeared along with some functionalities. After that I made "binary uncommenting" (uncomment one half) till I got the bug line. It was a third party library, I had an object that was not being released properly.

How do I use a RootViewController when making an app without a ViewController?

I am trying to make a simple app from a tutorial that does not have a viewController at all. All the code is in the AppDelegate. I am on xcode 4.2 and I am getting this error:
Applications are expected to have a root view controller at the end of application launch
I'm not sure how to deal with this. There are some blogs out there with fixes but none of them are working for me and I really would like to understand what is going on here. And, how to fix it.
I do have a view that contains some buttons and labels. But I have no "ViewController". The files contained in my project are: AppDelegate.h, AppDelegate.m, and Window.xib only. There is no ViewController.h, ViewController.m
** edit **
I ended up making the app from a 'view based application' instead and just moving all the logic from the app delegate to the view controller. So, I didn't really solve the problem per se. The app works now though. Thanks for the help
It's not possible to have an iOS app that doesn't have a view controller. You can always create a trivial view controller, i.e.,
[[UIWindow alloc] initWithFrame:UIScreen.mainScreen.bounds].rootViewController =
[[[UIViewController alloc] init] autorelease];
It sounds like you're looking at an old tutorial. UIWindow got a rooViewController property in iOS4. I believe it became required in iOS5 to help keep controller hierarchies and view hierarchies in sync with the addition of custom container controllers (and to fix a corner case where replacing the "root controller" of a UIWindow could stop orientation changes from propagating). There was a WWDC presentation in 2011 that explained this in some detail. I think it was Session 102, Implementing UIViewController Containment.
At then end of the day, there's no good reason not to have a root view controller. Apple wants to be able to assume it's there in their APIs going forward. If the tutorial you're looking at doesn't account for that, it's broken.
While I agree that there may be workarounds, another question to address is: why do you want an app without a view? Even if it's designed to run in the background and present no visual interface, at least make a simple view showing the application name and version, a largeish icon and perhaps a status. This kind of idle screen uses very little system resources, especially when the app is backgrounded, but improves the overall experience of the app.
If you set your deployment target to 4.3 and run on the iPhone 4.3 simulator, you won't get the warning.
To install the iOS 4.3 simulator, go to Xcode > Preferences > Downloads.

What are some reasons that application:didFinishLaunchingWithOptions method could get skipped?

My iPad app was working fine until I opened up IB and started editing the interface. Now, my application:didFinishLaunchingWithOptions isn't getting called. I understand it's an optional function and it gets skipped if it doesn't exist, but in my case it does. What are some reasons that application:didFinishLaunchingWithOptions method could get skipped?
I should note that I'm building with the iPhone OS 3.2 SDK.
Thanks in advance for your help!
UPDATE: I fixed it, please see my answer below
Are you sure that class has been set as the application delegate of the app?
(source: xanga.com)
And also make sure the "File's Owner"'s delegate has been linked to "App Delegate".
(source: xanga.com)
Well it turns out, for an unknown reason, I had a "view" view object as a child of my RootViewController in IB that didn't serve any purpose except to hold my a TableView view object and a DatePicker view object. I thought it was harmless, but when I removed it in IB and programmatically added the TableView object and and DatePicker object, suddenly this problem went away. If anyone has any ideas why this is, I'd would love to understand it.
Thanks, everyone!