It is possible to directly access an object's ivars, but you should NEVER do it. Objects are designed to encapsulate their data, and to provide specific designated channels to access these values (accessors and mutator methods). When you're first learning, it's hard to appreciate the value of such a system, because everything seems more cumbersome. Trust me when I say that data encapsulation is critical.
One way to think of data encapsulation is like looking at several stereo components that all get wired together via A/V, HDMI, etc cables. If you think of your Amp as an Objective-C object, it will have many variables exposed to other components, but it may have other variables that are self contained and private to the outside world. I'm not an electrical engineer, so the following example is fictional, but suppose the Amp has a variable that regulates the voltage of an incoming signal from the "DVD-IN" port. Further suppose that it needs to change this based on how strong the incoming signal is, and account for the desired volume output. If you're designing an Amp object you want the inputs/outputs to be "public" but you want the voltage regulator to be "private," since a poorly engineered DVD player that was allowed to manipulate this internal variable could fry a circuit, weaken the signal too much or boost it to the point that it blows the speakers.
Object-oriented programming is designed around the concept of objects managing their internals, and creating a "black box" so that other components in the system don't need to understand how they work, they just have to access things via the designated accessors/mutators, and the object will do the rest of the work.
A major advantage of this is that you can change how the Amp Object's voltage regulation works (maybe because you discovered a bug) and all of the other components will still work fine. Notice how if you have external code accessing this data (from potentially many different components such as a DVD, iPod dock, and an Xbox360, etc. they would all have to change their code too. In a simple example like this, the benefits may seem a bit less clear, but imagine objects that are interacting with dozens of other objects, and every time you made one tweak to the object you had to change your code in dozens of other places (and perhaps that code is written by another team-member, so you could seriously screw things up for him if you make a mistake). Things can and do get quickly out-of-hand without using accessors.
By using the designated interfaces, you can change the internals of how your object handles those inputs/outputs in the future in any way you want as long as you keep the interfaces the same. To the external components, it still looks like the same "sockets" so all code that uses the accessors/mutators will work fine. This happens all of the time with Apple's Frameworks. For example, Apple may change the internals of how NSDate objects work because they found some optimization that makes it faster, but all of the thousands of applications and the millions of lines of code that use NSDate will still work just fine because they're using the designated interfaces. I hope this helps appreciate just how powerful this concept is.
A final point is that accessors and mutators can also do checks to make sure that inputs/outputs are appropriate. Perhaps you don't want to allow others to create a rectangle of negative size, so any attempts at setting a side <= 0 will instead change the side to 1 or some other default value. You do this by changing the logic inside the setter's implementation.