I've got a few emails recently about some of the code I've written in a few plugins. I could write a ton on this subect (it's interesting and I'll cover some of it at CodeCampe) but I found an article that explains it much much better than I could in a post. I'll post that at the end of this post. It's for sure NERDS ONLY. Ha. The general question: "Why does your code use property declarations and NOT iVars in the synthesize statements? This seems like a bad idea and I think iOS would run your code faster if you used iVars." Note: iVars is shorthand for Instance Variables. Meaning, variables held in memory by an instance of a class (sometimes called an object). Interestingly, the few people that have asked this don't really understand the difference anyway. Admittedly they only ask becuase they are so used to see "_iVar" such as "_firstName" or "_lastName" in code others have written. Think Stack Overflow or whatever. My Answer? Because in nearly every case I've ever seen, it doesn't matter and using funky syntax like _myVariable makes it harder to read the code, tougher to understand (if you're new) and far more confusing than one may expect). Laughing a bit here. In the most basic sense, iVars are "faster" than "properties" (for some obvious reasons that programmers understand and that the article explains well) but not fast enough to matter. The difference between 100 NANO-Seconds (not milliseconds, nano seconds) and 500 nano-seconds is nearly impossible to measure. Measure in terms of "slow" Or "fast." It's almost funny to imagine. "Hey, I tapped this button and the next screen loaded to slow, you must be using properties and not iVars." Laughing again. If you're interseted in how memory is addressed (basically) and why properties without iVars are a bit slower, have a read. It's a great article. http://blog.bignerdranch.com/4005-should-i-use-a-property-or-an-instance-variable/

Thanks David, I had always been puzzled by the two things. Frankly, the underscores as a prefix of a variable sends me a signal of "this is for the pros only, caveat emptor". Lately, I've been seeing less and less of the ivars in the Github projects and in the online tutorials. Wandering off to the Big Nerd Ranch for some bedtime reading ... -- Niraj

Odd. I always thought the same thing. I'm usually *never* right, lol! I prefer my own properties. They're very unique and I won't mistake them for anything else but what they are. And the speed loss is negligible at best. I'm not writing anything that requires a cray, and since I was able to store more than 64K of memory, I've always leaned towards readability over efficiency. And no one was the wiser. Cheers! -- Smug

Like David, I enjoy this subject quite a bit and am gonna write a couple things I didn't see in that article about it and re-state some things (In my opinion) that'll hopefully be a little more straight forward. The underscore is actually a C++/general OOP thing, and it simply distinguishes a property from a ivar. Imagine writing myObj and myObj and not knowing which is the ivar and which is the property (the compiler will yell at ya if you do that by the way). The biggest reason and the thing you should always keep in mind when using properties is that properties are not values. They are methods. When you say @property (nonatomic) MyClass *obj; what you're really saying is, "Hey Complier, would you do me a favor and create a couple getter and setter methods for this variable? Thanks toots, you're a doll." So, these two pieces of code are identical: // sample code 1 @property (nonatomic) MyClass *myObj; // sample code 2 MyClass *_myObj; // not visible to other classes - (MyClass *) myObj { // getter (visible to other classes) return _myObj; } - (void) setMyObj:(MyClass *) myObj { // setter (visible to other classes) _myObj = myObj; } This process that is done by the complier is called synthesizing, C++ and many other languages do the same thing in certain situations. Now, the reason why properties are slower than instance variables (and pretty much always will be), is because you're making method calls. Not accessing a variable in memory, which of course, will be much faster. So, why do we use properties if they're slower? Well, because giving another class direct access to your variables can be dangerous. App crash dangerous. Imagine if a Banking program used ivars available to the public. You could do some very dangerous things if someone hacked the executable and used "code injection". Also, it can be awful convenient to make a getter or setter method that does something to a variable before the user accesses it. Also, if we don't provide a getter and/or setter method, the user of the class has no way of setting the variable and/or reading the variable. There's also a number of things that properties provide that you'd have to take care of yourself if you wanted to use an ivar in this way. Think about threads, if I say in my property declaration: @property (nonatomic) MyClass *myObj; This means that if used with threads, myObj will NOT be thread safe, and two objects could access the same property at the same time and result in a crash in the program via "dead lock". If I say: @property (atomic) MyClass *myObj; This means when used with threads, myObj will be written and read one at a time, courtesy of some assembly instructions that insure the myObj's safety. Now for my main point, not using @property isn't necessarily always preferable to using ivars and visa versa. It really depends on the occasion. But, the general rule of thumb is, if another class is going to be using, make it a property, if you're the only one using it, it's more than save to make it an ivar if you'd like. There's a plethora more to properties and could go on for hours about various features, advantages and disadvantages, but hopefully this helped clear the mud ;). LMK if you've got any questions. -tM

Love to see the nerding out on this thread! Good to see theMonster as well - seems like I haven't heard from you in a while. I'm with David-I like properties because they're easy to understand. When I started, this issue alone caused a major roadblock for me. I didn't understand why things were declared in two places, in two different ways. Or more importantly, hoe I was supposed to declare something I was creating from scratch! Now I try to use properties always and avoid ivars so others don't suffer the same confusion. If we weren't open-source and others could only see the .h header files (like Scringo or Facebook), then it would be different. But open-source rules! ;)

@chris I try :). But as usual, I've been fairly busy. Got a job a couple months ago and that's consuming a good amount of my time. And (for the record) I completely agree with david (if you couldn't tell from my novel). 9 times out of 10, you don't need and shouldn't use a ivar. -tM

@theMonster. YES! Love this stuff. Oh how I remember the days of manually creating getters / setters individuall. Ugh. So error prone it was crazy! Today, even in an IDE like Eclipse, "Auto creating getters and setters" is much easier. I'm not a huge Eclipse / Java fan but do appreciate how the getters and setters are "visible" in the editor. I think abstracting this (hiding this) like Xcode does confuses things even more. Hiding it does have it's benefits but I do wish we could "see" what auto-synthesized (or manually synthesized) properties "looked like" - in term of showing the getters and setters int the .m files. Another way to make it "designer friendly" in Apple's sense I suppose.

Very cool. I've had a fringe understanding of the difference, but this helps me connect a few more of the dots. I def see a mix of the two in projects I've played with and turned into plugin screens.