Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There are a lot of methods like this in iOS/Objective C:

- viewDidLoad
- viewWillAppear:
- applicationDidFinishLaunching

I've just been having a discussion with some colleagues about this design choice and why they would choose to be so verbose in preference of the more "standard" ways of event propagation for instance:

- onViewLoad
- onViewAboutToAppear
- onApplicationFinishLaunching

I didn't have an answer and rather put it down to just personal preference of the team designing the language. However, I'm wondering if there's more to it - whether this is a preferred option. Or whether the team just wanted to differentiate themselves from other languages, or from the norm.

If anyone has any insight that would be very interesting.


share|improve this question
Maybe it's a carryover from some Smalltalk conventions? I'm not too knowledgeable about Smalltalk so I can only speculate. – Mark Rushakoff Apr 22 '13 at 14:48
Historical nit: Objective-C was invented in the early 1980s at a small company called Productivity Products International which later became called Stepstone. – Blrfl Apr 22 '13 at 14:55
@dan1111 viewWillAppear: sounds more awkward than onViewAboutToAppear? Not to these ears. – Caleb Apr 22 '13 at 16:25
My issue is that "viewDidLoad" is true any time after the view has loaded. The callback name should emphasize it occurs just after the view has loaded, not at some arbitrary point later. In the same manner "viewWillAppear" is a statement which is true any time before the view appears; the name should make it obvious the view is about to appear. – Joseph Earl Apr 22 '13 at 17:21
@JosephEarl Perhaps, but there are dozens, maybe even hundreds of should/will/did methods in Cocoa and Cocoa Touch classes. You learn the convention once and they all work the same way. Also, you really shouldn't make any assumptions about exactly when you get those messages: all you should count on is that the view is available after -viewDidLoad and it hasn't yet appeared in -viewWillAppear. – Caleb Apr 22 '13 at 18:14
up vote 5 down vote accepted

I think the rationale is that in Objective-C, selectors are supposed to be messages sent to the objects. Sending [viewController onViewAppear:] makes it sound like you're going to pass it a lambda telling it what to do, whereas [viewController viewWillAppear:] is better under the "I am sending this message to that object" paradigm. (I find it weird that the animated flag isn't in the selector in this case though.)

From there it makes sense to reduce length and extraneous particles by preferring future tense -viewWillAppear: over -viewAboutToAppear:.

share|improve this answer
This sounds like a really reasonable and logical explanation. It does sound much better to call [viewController viewWillAppear] than [viewController onViewAboutToAppear]. – Thomas Clayson Apr 23 '13 at 8:13

Or whether the team just wanted to differentiate themselves from other languages, or from the norm.

First, I'll point out that the names in question come from frameworks, not from the programming language (Objective-C) itself.

It's impossible to say what the team was thinking unless you were part of it, but I'd imagine that the names come from the fact that the methods are called before or after a given event has happened. For example, -viewWillAppear is called just before the view is shown on the screen, and -viewDidAppear is called just after the view is shown. Together, these methods let you prepare for something that's about to happen and respond to something that just happened. I don't think these names were chosen just to be different from other frameworks (indeed, the frameworks from NextStep that became Cocoa predate many of today's object frameworks), but more likely were just meant to be descriptive.

Note that the ...Did... and ...Will... methods aren't the only ways that events are communicated to your code. For example, touches have a more complex lifecycle, so you have methods like -touchesBegan:..., -touchesMoved:..., -touchesEnded:..., and -touchesCancelled:....

share|improve this answer
Its likely one of those things where they started to write the touch events first and by following the proper convention they were tasked to used they decided to apply it to all events. They also could have thought it was funny and wanted somebody to post this very question 4 years later on a Stack Exchange website. – Ramhound Apr 22 '13 at 16:20

The only comparison to go on that I have experience with is Microsoft's event patterns.

Microsoft frameworks use two styles for these events one in Windows Forms and ASP.NET Web Forms, the other appears in WPF/Silverlight/WinRT.

In Forms based applications, the framework uses imperfect tense for (something's happening) and perfect tense for (something happened). One example is INotifyPropertyChanging/INotifyPropertyChanged interface pair (which provide the PropertyChanging and PropertyChanged events, respectively).

For WPF et al, the framework uses Preview[EventName] and EventName. No past tense is used here for example PreviewMouseClick and MouseClick are the event pair for a mouse click event.

I think the choice between the three naming methods is subjective as long as they are consistently used within a given framework.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.