Xcode 4.2 Template Changes - UIApplication & MainWindow.xib

Question

Background: Up until Xcode 4.2, new projects created using any of the templates would contain a MainWindow.xib and therefore pass nil as the fourth argument of UIApplicationMain(). Starting in Xcode 4.2 all the templates instantiate the application delegate by passing the class string as the fourth argument and do not build the application's window in a xib.

It is trivial to accomplish this setup in 4.2, and of course it works as expected: create xib setting File's Owner to UIApplication and wire up the delegate, specify it in Info.plist, nil fourth argument in main().

Question: Why is Apple encouraging instantiating the application delegate and building the UIWindow in code now instead of the "old way?" What are the benefits?

Considerations: I would expect this new template behavior if you elect to use storyboarding as a way to manage the UI, but if you uncheck "Use Storyboards" I would have expected the old pass-nil-and-use-MainWindow.xib template.

This question was asked in a roundabout way here, but the answers are a little thin on discussion.

Warnke

Thanks for the tip about setting the File Owner and wiring the Delegate; I was having trouble following a book that is only 12 months old and yet fairly out-of-date, given the rapid tool changes made by Apple. – Eger

Answer 1

You're asking why Apple is doing something? There can be no definitive answer, unless Apple has spoken out explicitly, which they have not done.

Personally I find the new approach considerably more elegant, transparent, and bulletproof. As you rightly say, in the old approach the main nib was loaded automatically by the runtime in response to the Info.plist setting, and everything else that happened was done through the nib, in particular the instantiation of the app delegate and the window and the associated wiring (the app delegate must be made the application delegate, the window must be made the app delegate's window), except that then we come back to the code in the app delegate for final presentation of the interface.

This was hard to understand; it took a great deal of verbiage for me to describe it in my book. It was also easy to break. The nib has to know the name of the app delegate class, so if you didn't like those funny long names that were created by default, you could easily mess everything up when you changed them.

Now, however, the app delegate is simply named App Delegate and is instantiated in code by UIApplicationMain(), as you rightly say; and everything else is also done in code as a direct follow-on: the app delegate is instantiated and didFinishLaunching is called, whereupon we create the window in code, assign it to our property in code, load the nib if there is one in code, set the window's rootViewController in code, and show the interface in code as before.

Thus the bootstrapping is directly exposed to view because it's all code. This makes it easier to understand and to modify without breaking anything. It's almost as if previously the template designer was just showing off as to how much stuff could be made to happen magically and automatically behind the scenes; now everything happens out in the open, explicitly.

Mulford

It can be argued that the template files are "good" or "bad," but generally speaking Apple doesn't put something into the templates without careful consideration. They are well aware the templates set an example for the community, and in this particular situation it is quite a change. While you seem to have a personal affinity for code vs. IB, I'm not sure that fully explains decision to change the template (of course it may - you touch on an interesting point about having to call keyAndMakeVisible from code). – Warnke

I don't agree at all. The templates are remarkably poorly thought-through, especially in view of their importance. The template for split view in Xcode 4 contains a huge bug that is exposed if there's a low memory condition while in portrait orientation. The template for utility application in Xcode 4.2 declares the FlipsideViewController's delegate property as an IBOutlet, wrongly, for no reason. The empty application template in Xcode 4.2, if used as is, causes a runtime warning! I could go on and on. The templates are not gospel by any means; they are more like "serving suggestions". – Mulford

You've got plenty of valid points that I hadn't considered about the other template files. I (naively) presumed that such a significant change from previous versions of the templates had to be because of sound reasoning and not carelessness. I thought that the most likely reason was the change in IB's (new) default behavior of using weak outlets. – Warnke

I don't see what that has to do with it. The weak outlet generation has nothing to do with templates. It has to do with ARC. If a view is contained by the view hierarchy there is no reason for an outlet to retain it. And if the view unloads and the view pointed to no longer exists, the pointer will not dangle, because wonderful ARC sets it to nil. (Before ARC you could get a dangling pointer, and hence a possible crash, in that situation.) – Mulford

Sorry, allow me to clarify... I had figured that leaving the templates as-is might be confusing to those reading the documentation on the new IB outlet behavior. They would read exactly what you spelled out, but then see Apple's templates not follow that pattern (File's Owner needs to retain the App Delegate and Window outlets). But, as you pointed out earlier, not all the template files reduce confusion! – Warnke

It would seem that the answer for the template change is due to storyboarding. Seems that UIApplicationMain sets up the storyboard by calling the window property's accessor on AppDelegate's. There isn't a "File's Owner" in storyboarded apps like in previous NIB'd apps. – Warnke

@e: That's obvious enough for apps that use storyboards, and I thought of saying something about that in my answer. But it doesn't explain the change in the case of non-storyboard templates, which are completely different, and are what I was talking about. – Mulford

Agreed about the non-story boarded templates! Which, goes back to your original comment: the templates are not as thoughtful as I was originally giving them credit. This discussion and discovery has been invaluable to providing me with enough of an answer. Thanks, Matt. – Warnke