When testing in the iOS6 simulator, I am getting the following error when clicking a disclosure indicator:
Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UIViewController _loadViewFromNibNamed:bundle:] was unable to load a nib named "LocationDetail"'
It runs perfectly fine in iOS5.
I do NOT have the LocationDetail nib anymore, nor need to use it. I have looked in my entire project for references to it, as well as in my MainWindow nib and all connections looking to see where it could be used, but I find none.
How would XCode still be wanting to load this, and why only the errors in iOS6?
The problem is not in Xcode, but in the iOS Simulator. If you've removed all references to the .xib in your project, and cleaned everything as you described, the problem is that the .xib file still exists in the app bundle in the Simulator. You should try deleting the app from the Simulator (or better yet, Reset All Content & Settings on the Simulator). This will fix it.
what i know is that initWithStyle:UITableViewStyleGrouped will call the initWithNibName:Bundle: method...
your class had the same name as your nib file, so when you called the initWithStyle:UITableViewStyleGrouped it tried to load that nib file.
when you renamed your class, it didn't find an nib with the same class name so no errors showed up as before.
I decided to just rename my class and .h and .m files and that fixed the issue.
Who knows why.
Related
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...
Today I learned that #import statement actually can help to link frameworks automatically.
Okay, I created a project, added a WebView. It was throwing me an error that WebView is undefined. Okay, I wrote #import WebKit — and the error was gone and all the WebView methods were available to me.
...I ran the application and it crashed with
*** Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: '*** -[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of class (WebView)'
Then I've added the WebKit.framework manually and... it worked. So what's the point of this #import statement? The automatic linking is turned on...
import imports headers. Thus, the name WebView becomes defined, along with the methods and other stuff in WebKit, and your code can compile. Linking links code - the code in which WebView actually lives and breathes and has its being - and so your code can run.
Normally, if you import a framework using #import, both things happen. You can compile your code because of the import, and you can run the code in the framework because the import also performs automatic linking.
But you are instantiating a WebView from a nib. Therefore you also have to link explicitly or you'll crash when the nib loads. The same is true if you were to use a MapView in a nib — you'd need to link MapKit explicitly or you'd crash when the nib loads.
My project built and ran completely fine. (it's rootViewController is a TabBarController) So I added two new view controller to my storyboard and connected them to my rootviewcontroller. In storyboard, the tabs were added just fine and everything looked okay. So I added the ViewController classes to my project and hooked them up to the correct viewControllers in storyboard. However, when I ran the project my new tabs were not visible in the simulator. So I ran "clean" on my project, deleted my application out of the simulator, reset the simulator to its original settings, and my new tabs still would not appear in the simulator. So i quit everything and restarted my mac. This time, when I ran my project it gave me the "Thread 1:signal SIGABRT" So i became frustrated and deleted my new viewControllers, both from the storyboard and the classes menu. I sent the classes to trash. But STILL I get the SIGABRT error. Even now that I am back to my original project, I am getting the error. I can't figure out what is wrong. Since it won't let me post a picture of my screen, just let me know if you need any additional debugger output or anything.
this is what its giving me in the debugger.
2012-07-05 09:22:33.336 NewsomeBand[265:15203] ***
Terminating app due to uncaught exception
'NSInvalidArgumentException', reason: 'Could not
find a storyboard named 'MainStoryboard' in bundle
NSBundle </Users/tammyscheele/Library/Application
Support/iPhone Simulator/5.1/Applications/
1B3E088D-23A6-4B77-8CBB-390A9720818A/
NewsomeBand.app> (loaded)'
*** First throw call stack:
(0x152b022 0x30d2cd6 0x5179f2 0xecd60 0xecff8 0xec17f 0xfb183 0xfbc38 0xef634
0x16beef5 0x14ff195 0x1463ff2 0x14628da 0x1461d84 0x1461c9b
0xebc65 0xed626 0x202d 0x1f95)
terminate called throwing an exception(lldb)
From the debugger output that you posted it looks like you may have accidentally also deleted a reference to your main/root story board. I'm guessing this based on
'NSInvalidArgumentException', reason: 'Could not
find a storyboard named 'MainStoryboard' in bundle
Either that or did you accidentally rename it somewhere or misspell it? It looks like its something simple in any case.
I solved it! I went into the info tab inside my project and set "Main storyboard file base name" to "MainStoryboard", and also made sure that my storyboard was named "MainStoryboard". That seemed to fix everything
This is a weird crash I am getting. The crash happens when I press a button that goes to a certain ViewController. The line which it crashes on is:
DestinationInformationViewController *info = [[DestinationInformationViewController alloc] init];
[info setModalTransitionStyle: UIModalTransitionStyleCrossDissolve];
[self presentViewController:info animated:YES completion: nil]; // CRASHES HERE
[info release];
The crash trace is:
*** Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate class named NSLayoutConstraint'
*** First throw call stack:
(0x3758288f 0x35287259 0x37582789 0x375827ab 0x3153d54d 0x3153d6bb 0x3153d423 0x314ce001 0x3143c3c7 0x31319c59 0x3128fc17 0x3129a267 0x3129a1d5 0x3133959b 0x31338367 0x84091 0x374dc3fd 0x31271e07 0x31271dc3 0x31271da1 0x31271b11 0x31272449 0x3127092b 0x31270319 0x31256695 0x31255f3b 0x33c9822b 0x37556523 0x375564c5 0x37555313 0x374d84a5 0x374d836d 0x33c97439 0x31284cd5 0x82bb3 0x71200)
terminate called throwing an exception(gdb) Could not instantiate class named NSLayoutConstraint
NOTE: This crashes on my iPhone 4 iOS 5.1 but not on my iPhone 4S iOS 6 Beta 2
I believe this is an issue with Xcode's new interface builder. Did you happen to build your .xib using Xcode 4.5's interface builder? I've run into this same problem just now, and I think that's the problem. My app runs on iOS 6, but not anything older.
And you need to make sure you turn off Use Auto Layout for your xibs.
That can be done by:
Open your xib.
Go to the File Inspector tab.
Find the Interface Builder Document section on the right toolbar.
Uncheck the Use Auto Layout option.
I had the same problem when I downloaded new XCode update and IOS6 SDK. Here's how I solved it:
Select the Interface builder file (whether xib or storyboard file) where your error occurs.
In assistant editor on the right in XCode, select the first tab from the left, and there is a checkbox for option "Use Autolayout" like on the screenshot above.
Uncheck the checkbox.
Nagaraja asks "How to resolve the same if we are not using xib? I ran into exactly this problem. I created a controller with a xib, and then I decided to remove the xib file. The crash did not go away. The problem was that I needed to implement
- (void) loadView
in my controller class. Once I implemented this method the problem got solved.
Another possible reason for a crash with presentViewController is having something in the nib connected to a variable that is no longer there - the variable either having it's name changed or it was deleted.
Hey all. Something which has been bugging me quite a bit recently is this custom movie player I've put together. It's largely based on a working one, NGMoviePlayer.
The issue is this: I have the .xib in a UIKit-friendly resource bundle. When I call:
[MyMoviePlayerViewController initWithNibName:#"MyMoviePlayerViewController"
bundle:[NSBundle bundleWithPath:
[[NSBundle mainBundle] bundlePath]
stringByAppendingPathComponent:#"MyMoviePlayerViewController.bundle"]];
..on my custom class, and then access the view (thus calling loadView) it doesn't throw any errors, but nor does it actually load the outlets properly. I am presented with a white screen, and debugging shows that all visual elements are 0x0, but there was no error as would be expected.
EDIT: I've also now tried just loading the .xib outside of a resource bundle in my target app, and the same thing happens (white screen).
The particular ones I was looking for was either:
Could not load NIB <nibname>... if it wasn't found at all, or
...loaded the <nibname> NIB but the view outlet was not set if it was found but not connected properly
The xib is in the local app (I understand that static libs can't contain xibs). I've tried using this same resource bundle with the NGMoviePlayerDemo project provided by the author of NGMoviePlayer, and it does throw an error:
Could not load NIB in bundle:
'/Users/.../MyMoviePlayerViewController.bundle (not yet loaded)'
with name 'MyMoviePlayerViewController'
I have navigated to the path it displays for the bundle and there exists a MyMoviePlayerViewController.xib file at that location.
I've also tried using bundle:nil in case Xcode combined the resources of bundle directories with the main one for some reason. Both cases throw no error and display a white screen in my actual project. Both cases throw a Could not load NIB error in the NGMoviePlayerDemo project.
EDIT: I have tried the same .xib separate from a resource bundle in the NGMoviePlayerDemo app and it works fine.
All input is greatly appreciated.
Solution: Pay attention to Unknown class <classname> in Interface Builder file. messages.
I had the code for the movie player in a static lib, and the parent view controller for the movie player was being included in the project as an external header, but the subviews weren't included as headers, so they weren't being located properly. Because the only place they were being referenced in my target app was within the .xib file, there were no compile errors to do with those subclasses, but when it came time to load the .xib those classes could not be found, so none of their properties were set. And that just so happened to include all of the controls for the player, which probably then made the initialisation code silently fall over.
I merged all of the code and ivars from the subclasses into the parent movie player class, and it's working fine now :)