At that level you're talking about framework api's (in this case NextStep and derivatives), not the language itself. Drop me into some Haskell or Java or OCaml or Python or Ruby framework, I'm going to have to reach for a reference as well.
It's not uncommon to conflate Objective-C conversationally with its most common use case, but Objective-C is not NextStep and other Apple-ecosystem friends.
Sure, putting on my layman hat: "Add the observer 'self' to some centralized place get a notification of some kind for when the app becomes active. Something to do with a 'shared application' and a 'selector', maybe they are some additional context?" Of course, the latter two are things you'd know if you have used Objective-C even a little bit, with the former being a fairly standard nomenclature for a global and the latter being a crucial part of the language.
AppKit has this concept called a Notification Center, which, duh, sends notifications. You want to observe the notification called NSApplicationDidBecomeActiveNotification. The way you want to observe this notification is by being sent the message * appDidBecomeActive:. The "object:" parameter tends to be nil, so I did actually have to look that up: it means I only want to receive this particular notification when sent by that object. It is almost certainly redundant in this case, because nobody else has any business sending NSApplicationDidBecomeActiveNotification, and it is usually precisely what you do not* want, hence it is usually nil.
In the old NeXTstep days, before our editors had code completion and other conveniences, you could very often just type a phrase describing the operation you wanted and magically the code would compile and do what you expected. Hard to both describe and probably believe if you haven't experienced it yourself.
In addition, the semantic consistency of the frameworks combined with the verbosity encouraged by the language makes it easy to jump into a new-to-you part of a 25+ year old codebase and start making useful changes very quickly.
This is much more difficult when you have to be careful about what every single operator dispatches to, or when more than just the receiver’s type determines the method that’s called. You can look at code in isolation and get a pretty good idea of its intent and the routes that its implementation will take, both of which are necessary to start making changes.