What Do People Find Challenging About Cocoa?

I sent out a general request on Twitter, asking what specifically the biggest obstacle was when you first started learning Cocoa. Out of the roughly 118 responses I got back, no one topic completely dominated.

This obviously isn't a strictly scientific study. I had to glean intent from some of the responses, and didn't include anything that came up less than twice. Also, I counted many responses for two categories. So if someone said "Objective-C was confusing at first, coming from a Java background", that would be counted as both "Objective-C" and "Used to Java and C++".

Objective-C: 19%

A lot of the votes here were broken down into other sections as well, so this is sort of an umbrella category. Many specifically cited how things were different from Java or C++ on Windows. The syntax itself was frequently mentioned, as was reference counting to manage memory.

Overall, this is the least surprising result since the Objective-C syntax is the single biggest difference from most other programming environments. If you asked PHP programmers what they found odd about learning Rails, Ruby would certainly be one the most common answers.

Worth noting, though, that very few said that they still hold a poor opinion of the language. It was just the initial introduction that was rough.

I Didn't Know ANSI C: 12%

Veteran programers may be surprised by this, but this is actually pretty close to what I expected. I've run into countless people in the last few years who had just started to learn Cocoa and had never even flipped the first page of K&R.

In the NextStep era, the big deal was convincing people to switch from pure C to higher-level objects, but now things have flipped. A lot of people coming to Cocoa today are used to web scripting languages, and have often never even used malloc before. Cocoa may be the sole reason they have any contact with gcc.

Cocoa is Really Big: 11%

Even just sticking to AppKit, UIKit, and Foundation, Cocoa is quite big. There are hundreds of classes in the core frameworks, and more than 80 entries in Leopard's /System/Library/Frameworks/ directory. That count doesn't even include the clusters of API buried in umbrella frameworks.

It can take quite a while to learn what's available to you, and then from there learn the pros and cons of each API so that you know when to use which one. This the is meat of what "learning Cocoa" actually is.

Memory Management: 10%

Relatively low on the list. This was mostly people who had come from Java or a scripting language and suddenly had to deal with reference counting — knowing how to use retain, release, and autorelease correctly.

Interface Builder and NIBs/XIBs: 10%

If you're used to seeing all of your program literally in code, Interface Builder and NIB/XIB files can be a bit jarring. The biggest complaint was that it feels like "magic" because you dont't know what Interface Builder is actually doing. Some said using Cocoa Bindings in Interface Builder enhanced the feeling of not being completely in control of what's going on.

Personally, I was immediately sold on the idea of using a visual layout tool to get all of the basic infrastructure up, and thrilled that I didn't have to type all of that out by hand each time. I admit I've never really understood the resistance to Interface Builder, but clearly not everyone feels that way at first. Just as with Objective-C, though, most said that now know their way around Interface Builder.

I Was Used to Java or C++: 10%

No big mystery here. Cocoa has pretty different view of life than Java and C++. You can learn the Objective-C syntax in a week, but you still might be trying to find the Cocoa equivalent of a particular class, and trying to still do things in the Java or C++ way. It takes a while to get familiar with not just the what of Cocoa but the why and how.

Delegates: 8%

I was surprised how many people specifically called out delegates as a stumbling block in learning Cocoa. The overall feedback was that it wasn't always clear how delegates fit into the big picture or when you should use them.

I think this might just be learning part of of bigger Cocoa philosophy: waiting for the framework to prompt you for data rather than actively going out and setting values on things. My guess is delegate callbacks seem more natural to Rails folks, but it's apparently not as common in other frameworks.

Overall Cocoa Model: 8%

These were the cases where the individual bits and pieces made some sense, but it wasn't clear how everything fits together. I see a lot of variations on the question "how do I pass information from one class to another?"

Cocoa has a few key techniques are used over and over again throughout nearly all of the frameworks, and once you learn those, the curve flattens out. But until then, it may seem like you're just doing a series of random things that seem to have no overall meaning. If so, take heart — you're in good company. Very bright, experienced programmers feel this way at first.

I Didn't Know Object-Oriented Programming: 8%

I think this is one of the biggest shifts since NextStep. Decades ago, this would have been much higher on the list. The interpretation of object-oriented patterns varies between languages, but nearly all popular languages today feature classes and objects in some way. It's rare to see strictly procedural programming patterns for desktop or web programming.

Learning How Documentation is Structured: 5%

Some did express a learning curve in reading the official documentation, but there seemed to be a general feeling that it has improved a lot over time.

Cocoa Bindings: 5%

A few specifically called out challenges with learning how Cocoa Bindings or Key-Value Coding and Key-Value Observing work, some specifically cited the overlap in "magic" with Interface Builder.

Xcode: 3%

Very few complaints about the learning curve in using Xcode to build projects. For the most part, people seem to get it.
Design Element
What Do People Find Challenging About Cocoa?
Posted May 16, 2009 — 51 comments below


Guy — May 16, 09 6736

Since a big part of learning every new system & framework is getting to know the APIs, it might be useful to have a small app / widget that lets you type in a function / class name you know from .Net or Java and have a name of a class / function roughly related to that in Cocoa.

Obviously, the systems and frameworks don't have much to do with each other - but still, if I'm familiar with .Net and know a lot about it already - just having somewhere to type in a word I know from that world that can give me something related to that in the Cocoa world would be a huge help.

Thoughts anyone?

Steve Weller — May 16, 09 6737

Language, environment, customs, currency, food. Cocoa sounds like a foreign country based on these responses. I'd say that is about right.

A similar survey asking what people found easiest about learning Cocoa would be very interesting too.

lakshmivyas — May 16, 09 6738

When I started learning Cocoa, I was fascinated. Stuff that would take a lot of code in other worlds was so easily accomplished. My first escapades with Cocoa were not that hard at all.

When I wanted to do a little bit more, it started taking me more time & research than I anticipated. A lot of material available through Google(many thanks to you as well, Scott) helps with getting started on Cocoa. However, both the API and the available supporting documents do not make the transition from developing play apps to real apps(from using magic to creating magic) easier.

Jesse — May 16, 09 6739

I'd have to say my biggest problem is just learning the classes and best practices of Cocoa.

Sometimes I wish Xcode could support JAVA IDE style inline API reference pop-ups. Having to flip to the documentation and back again can be quite irritating. Having instant access to a reference can really speed up learning the individual class interfaces and just streamlines the workflow in general. Also, having a firm grasp of design patterns (and how they are modified in Objective-C land) is also a must.

Kevin Walzer — May 16, 09 6740

I use Cocoa to write extensions to a scripting language (Tcl). It is a different beast; memory management is a bit tricky, as well as figuring out how to call into Cocoa from Tcl's C API. Finally, it's a bit hard to get my head around writing 200 lines of Objective-C that boils down to two Tcl commands. Still, I'm glad I'm learning it. Also, for what it's worth, it's easier to call into Cocoa than Carbon...

Mike Rundle — May 16, 09 6741

I fall squarely into the "never knew C before" camp as I came from a web programming background and Java in college. I had only heard about header files and memory management but never ran into them in any code I wrote before learning Cocoa.

Scott Stevenson — May 16, 09 6744 Scotty the Leopard

@Jesse: Having instant access to a reference can really speed up learning the individual class interfaces and just streamlines the workflow in general.

It's easy to miss, but Xcode has Help > Show Research Assistant.

Philippe — May 16, 09 6745

Regarding IB, the best way I found to explain it is that IB stores entire "frozen" objects and "thaws" them when the nib is unarchived. It's the same as an alloc+init, essentially.

It's my experience that if you show this along with -awakeFromNib, people get it much faster.

Scott — May 16, 09 6746

I've found that there aren't that many resources for learning how to design your project from scratch. Specifically, there several great tutorials out there (many of which you have created--thank you for that), but all that I've come across take the strategy of walking someone through a project and explaining why the author choose to do things the way she did. The existing tutorials are great if you want to copy their basic architecture, but it can be difficult for a newbie to have the confidence to design something on his own.

I would love to read a tutorial that outlines a problem that a developer wants to solve, and then walks the reader through the various ways they might want to structure the project to accomplish his solution to that problem. The tutorial could explore several different directions at various stages of the project and explain the pro's and con's of each path. I think learning why this project was designed the way it was (vs. some of the other ways it could have been implemented) would be incredibly valuable to people teaching themselves Cocoa.

Nice to see you are still posting here too. I'm not much on twitter, and I find your insights invaluable. Thanks for all you have done/still continue to do for the Cocoa community.

Chris L — May 16, 09 6747

Of the iPhone questions on Stack Overflow, quite a lot are actually beginner C questions. Kids are leaving school having learned only Java or C#; some professionals have only worked on web apps before. The iPhone is getting these people to leave their comfort zones.

Jerry Fan — May 16, 09 6748

@Guy - I agree, the information on the Internet is relatively sparse for someone looking to get into Objective-C development from another popular language such as C#/.NET.

I've also noticed a trend among more experienced Cocoa developers is the practice of 'avoiding sub-classing'. I'm not experienced enough to fully grasp why this is the case, but it seems to be the result of a rather primitive IDE (XCode), compared to a product like Visual Studio or Eclipse.

Can someone fill me in?

Lukhnos — May 16, 09 6749

@Jerry The practice is not avoiding subclassing. It is utilizing the delegate pattern wherever you can. That's how Cocoa projects tend to have a "flatter" class hierarchy than their equivalents in other languages. It doesn't have too much to do with the IDE.

Craig Demyanovich — May 16, 09 6750

@Jerry Fan: Avoiding sub-classing almost certainly has nothing to do with tooling. Rather, you can think of it as favoring composition over inheritance. I was first exposed to that idea in Joshua Bloch's book, Effective Java, but it can be found in many other places.

Kenneth Barber — May 16, 09 6751

I fall into the coming from C/C++/ box. I haven't had any trouble with the language syntax or the memory management technique. My 3 big gotchas came from:

A. The IDE took a bit of getting used to.

B. The objective-c runtime and its dynamic nature had me intrigued, confused, and worried all at the same time. I thought of all of the things I could do with it and how easy somethings are in the language. I thought a little too much about it. My productivity dropped quite a bit as a started looking at the whole thing academically. It took me 6 months to bounce back although I am still prone to relapse.

C. Cocoa is yet another large api I have to come to grips with. This means yet another round of "which way is the best way to do ???". This has been the most time consuming part of learn to develop for either Cocoa or Cocoa Touch.

I code professional in C/C++ and C# using various libraries and IDEs. Going back and forth between them is sometimes frustrating. I must be getting old....

Adrian — May 16, 09 6752

Jerry - I think avoiding subclassing is a trend of many modern framworks, not just Cocoa. Aggregation vs inheritance is a trend that started with the gang of four book and has been gaining ground ever since.

Joshua Pennington — May 16, 09 6753

@Jerry - It's an example of object composition vs. inheritance. Subclassing requires in many situations a more intimate knowledge of a class's implementation. Therefore, it can break encapsulation.

Michael Buckley — May 16, 09 6754

@Jerry As Lukhnos pointed out, Cocoa developers prefer to use delegates pattern in situations where others might create a subclass and start overriding methods.

Objective-C's largest strength is arguably its dynamism, and in most cases, delegates allow for greater dynamism. Class hierarchies have rigid structures, which can cause problems in complex systems. Delegates, on the other hand, are flexible, and can even be changed at runtime. There are many tools in other languages to deal with these kinds of problems (e.g. multiple inheritance) which become unnecessary when using delegates.

Taz — May 16, 09 6755

I suspect delegates can be confusing because they're not used particularly consistently. When designing an Objective-C class, how do you know when you should you use a delegate, a data source (which is a specialized delegate), or a notification? There's no particular rhyme or reason to their use within AppKit itself. Yes, I, with 10 years experience in Objective-C can give you general guidelines, but it's no help when you're actually learning the framework.

Cocoa Kid — May 17, 09 6756

My main shakers were core design patterns used in cocoa (delegation, kvc/kvo) as well as cocoa bindings (i'm still learning them). Language syntax got me frustrated a bit as well. Must admit - it looked ugly at first too, but then i just fell in love with it.

Richard — May 17, 09 6757

Coming from a C++ background, the "infix notation" that is used for Objective-C methods takes a while to get comfortable with. But now that I have used it for a while, I am beginning to appreciate it a bit more. It enables the developer to write code that is a bit more self-documenting.

ssp — May 17, 09 6758

Recalling my first steps in Cocoa years ago, I'd certainly say the big philosophy was the biggest obstacle. It simply takes time and a few attempts to grasp that because Cocoa is neither small nor simple. The fact that Apple's documentation is far from perfect and their examples are mostly trivial doesn't help either.

My impression is that documentation has improved a little since (but still is far from good), so that may have become easier. On the other hand additional non-trivial 'magic' technologies like Bindings or Core Data have been introduced which can be very powerful but which will make first steps much harder. I always find those the most problematic these days as they very easily leave you in situations in which you don't fully understand what's going on but would need to have that understanding to get the behaviour you want. And getting the behaviour you want will likely require more code than not using those advanced technologies (which smells a bit of FAIL if you ask me). An example may be something which should essentially a trivial one-click affair as setting up a combo box with bindings.

I also keep wondering how much easier Cocoa could seem if XCode's documentation browser weren't a POS that seems to be designed to make navigating documentation as hard as possible. The research assistant seems like a nice idea, but are you really using it? I found it to be so poorly implemented that XCode can't keep up with my typing.

Martin Pilkington — May 17, 09 6759

@Jerry: I've also noticed a trend among more experienced Cocoa developers is the practice of 'avoiding sub-classing'. I'm not experienced enough to fully grasp why this is the case, but it seems to be the result of a rather primitive IDE (XCode), compared to a product like Visual Studio or Eclipse.

The idea with Cocoa is that you should be able to use existing classes to create new ones rather than subclassing. There are some classes intended to be subclassed a lot (NSObject, NSView, NSWindowController etc) but for the most part you are encouraged to use existing classes.

The other plus of this is you end up with fewer, but more powerful classes. Whereas Java has JButton, JToggleButton, JRadioButton, JCheckBox, Cocoa just has NSButton which does all of these.

@Taz: I suspect delegates can be confusing because they're not used particularly consistently. When designing an Objective-C class, how do you know when you should you use a delegate, a data source (which is a specialized delegate), or a notification? There's no particular rhyme or reason to their use within AppKit itself

Actually they are very consistent. When designing a class it's easy to decide what you need. A data source is when you need to supply data to populate a view. The "hard" thing is delegates vs notifications but it is a simple answer. Delegates are 1 to 1 relationships, notifications are 1 to many. If you want multiple objects to know about an event then use notifications. If you only want one object to know about it, or want something returned then use a delegate.,

Benjamin Dobson — May 17, 09 6760

Interesting. The one thing I really found difficult (and still do) is using it alongside the CG APIs. The whole structure is so different it always confuses me.

Ulai Beekam — May 17, 09 6761

Scott, personally I think you are asking a relatively uninteresting question. No offense intended, of course—it is a perfectly valid question, especially for those who want to teach Cocoa. But let me explain my viewpoint below.

I already knew some C, C++, Java, PHP, HTML when I started learning Cocoa about a year ago. I had studied those other languages only for the sake of fooling around, and had never worked on any real projects (save for a website I did for someone). So again, it had only been playing around doing random, but mostly useless, things out of interest since I was like 13 years old.

When I came to Cocoa a year ago it was different. I had a real Mac application in mind that I wanted to do. That was a different experience than before. I therefore, picked up a copy of Hillegass' book, read the first 20 chapters, then read some Apple docs to more solidify my knowledge.

At this point I can answer your (uninteresting but valid nonetheless) question: The biggest hurdles to learning Cocoa, I found, were indeed a mixture of this normal stuff everybody is mentioning around here, like "different Obj-C syntax", "seems like magic", "bindings", "Nib files", "Xcode", etc. etc. But why does this question even need to be asked and answered at all?

First of all, when you learn something new, you come across new things—that's just the way it is. Second, if you read about it often enough (I had to read some chapters in Hillegass many times over to understand them), you will get it in the end. So is it just me or am I missing something? Because to me it seems a bit trivial that people will have troubles with certain things, but are bound to get them in the end. I'm sure you even guessed many of the replies you received, before even receiving them, Scott.


The biggest hurdle to overcome is to actually finish and release your first application. The very last challenge in the end of Hillegass' book, "Write a Cocoa application and get someone (not yourself) to use it", it by far the hardest exercise in the book. And this is after supposedly having learnt Cocoa!

So the question you should rather be asking is: After learning the basics of Cocoa—which you will do after a few months by just reading and practicing the material often enough—what are/were your biggest stumbling blocks for working on your first real application?

This question can lead to much more interesting answers, I think. So can you do another Twitter post asking that question instead, and write a similar blog post about the answers you got? :)

Anyway, I conclude by giving six answers/thoughts to this question for myself:

1) Finding that Apple's docs have their limitations, and that you have to constantly Google/Cocoabuilder/Cocoadev things up to figure out how to do things.

2) Get around occasional bugs (believe it or not, they are there) you come across in Cocoa.

3) Spending a month writing something that you ended up not using at all. Even if you ended up learning a lot, it still was an obstacle in getting the app released on time :)

4) Finding out that you forgot what you read months ago and had to read it again. This time, though, you know where to look. Also you more solidify your knowledge because you are instantly using what you are reading.

5) Not knowing what makes Cocoa so great. Since one has not written any real applications in any other framework, one has nothing to compare oneself to, and cannot really understand why everybody is saying Cocoa is so great. One is just using it because one wants to write some Mac app :) (In fact, can someone answer this? Is Cocoa really that great compared to say .NET in Windows?)

6) A general feeling that one is taking too long time to code a seemingly simple app :( In the sense that if I showed a relative the current state of my app and told him how long it has taken me, he wouldn't be too impressed. (Any words of reassurance would be appreciated here.)

jon — May 17, 09 6762

the biggest problem are the bugs, the ones from Cocoa being so big...

for instance, simply taking the example project "miniBrowser" that exists on your Development directory, and changing it to use Garbage collection in the build settings, no other changes, that simple change, will produce a browser that doesn't load all of the page at "www.ebay.com"...

why is it? because of some conflict in an unbelievably complex interaction between parts of the system...

they need to find these things and get them figured out FAST, as it is, i put in this bug report, but i don't expect to hear anything for years about it... (like another bug report i put in last year, with no word) that is infuriating...

and i'm a brand new Cocoa user. I am figuring out everything, except the most complex, but my biggest stumbling blocks are copying code directly from some example that should do something, and it doesn't do it through no fault of my own, the fault being complex bugs in how one part of the system acts with another part, it is amazing how often i've found this...

i can give even more examples of this very thing if you wish...

Todd — May 17, 09 6763

Since I am not on tweeter and doubt that I will be anytime soon, the following is my response to the questions: what specifically was the biggest obstacle was when you first started learning Cocoa.

1. Objective-C and having to go back and deal with header files. Come on, now

2. The nuances of UI widgets and interface builder. This was very different from Swing, Winforms, gtk and frankly everything else known. Of course the simple GUIs with handful of elements was very ease to pickup, but once I started needing multiple tabs, custom controls and advanced coordination between element...whoa.

3. Lack of 3rd party cocoa libraries. Without these I had to write stuff from scratch...ugh

4. No datagrid for displaying/sorting/filter database data.

devnull — May 17, 09 6764

Great question and I would agree it's Objective-C I think with 2.0 it becomes more approachable. Watching the free Stanford Podcasts for iPhone development gives you a better understanding.

XCode and Legacy code is straight forward http://macateeny.blogspot.com/2007/08/xcode-running-3d-opengl-classics-there.html

Enjoyed the post /devnull

Todd — May 18, 09 6768

Coming from a swing and Visual Studio background, I am definitely having trouble with interface builder. It is not so much the "magic" of it, just that it works backwards to how I am used to. In all the other IDEs I have used to do GUI work, you create your screens and then use the screens / methods on the GUI items to "dive into" your code and set up what you want to occur for onClick() and the like.

In XCode/IB it seems that you do the exact opposite, in that you write the code that you want to happen first and then connect it back to the GUI.

I'm sure part of this is that I am rusty, in that I have been doing mostly SQL and scripting for the past few years, but it definitely takes some getting used to.

Philippe — May 18, 09 6769

@Todd The first time I used the App Wizard in Visual Studio, and the first time I looked at all these handlers (OnClick, OnPaint...) I understood that VS does not promote the separation of model-view-controller. It makes it all too easy to intermingle "business logic" (the model) in the view, obviating the need for a controller.

You can do MVC with Visual Studio. And you can put all your business logic in your IBActions. But my experience has been that VS makes it all too easy to do the wrong thing, which quickly leads to an unmaintainable mess of an application.

Kenneth Barber — May 18, 09 6770

I've done quite a bit of MFC based development. The file that you edit with the event handlers on it is the dialog/view controller. The actual dialog/view is specified with the RC file. The model is the document class. The document class (should) maintain all of your applications model data. I tended to create CObject based classes to group manipulation of the document object (a Business logic layer if you will) and then created another class to instance those objects for the dialog controller (a business services layer) . The whole thing is bit archaic compared to cocoa (lots of macros, handles, and compiler tricks) but it worked well for what it offered and was much better than the alternative available at the time when it was a popular solution.

In fact the MFC coupled with some COM/ActiveX and WIN32 knowledge was pretty powerful and there is still lots of legacy dev work out there for it.

Zach — May 18, 09 6771

My biggest challenge once getting past the basics of knowing the language, and learning the framework is how to create advanced user interfaces. There doesn't seem to be info much out there for for the GUI end of Cocoa apps beyond the standard widgets. For example, how to create apps with a UI that can't be created in Interface Builder, something like Boxee on the mac or ConvertBot on the iphone. Should I use Quartz or OpenGL or Core Animation or just a hierarchy of NSViews? I'd love to see some articles on the best practices for creating these kinds of user interfaces.

Paul Collins — May 18, 09 6773

@Todd (2nd): I do use Interface Builder to create the GUI first.
Then, in the controller header file, declare IBObject ivars for the GUI objects I need access to from code, and the IBAction methods I want to call from the GUI. Wire them up in IB, then write the actual methods in the .m file. There's a little bit of back and forth, but now that IB auto-updates from .h file changes, its easy.

When I (long ago) learned Cocoa, learning good memory management was the main early hurdle. Oh, and figuring out how to design my 2nd app after CurrencyConverter. Then I got to learn gdb so I could attach to and debug a root process (still have trouble getting Xcode running as root (using sudo open)).

P.S. @Todd(1st): might as well embrace headers, they are here to stay, and get comfy with cmd-option-up-arrow.

Davide — May 19, 09 6776

I'm studying Cocoa right now, and I don't see any big obstacle to pass at all! I came from Delphi (unfortunately there is not yet Delphi for Macs, only freepascal & Lazarus) and of course it's a new world for me, but even if different I see a lot of analogies with Object Pascal.
Just for the records, I'm not a professional programmer, I do it just for little requests, personal needs and passions for macs!.


Preston — May 27, 09 6781

"Personally, I was immediately sold on the idea of using a visual layout tool to get all of the basic infrastructure up, and thrilled that I didn't have to type all of that out by hand each time. I admit I've never really understood the resistance to Interface Builder, but clearly not everyone feels that way at first. Just as with Objective-C, though, most said that now know their way around Interface Builder."

The resistance has to do with not understanding what Interface Builder is creating in a Nib file since it doesn't generate code as one might expect.

Steve — May 28, 09 6782

Motivation, too much time since the last time doing Cocoa, time, and getting stuck every step of the way and not knowing what to do.

MySchizoBuddy — May 28, 09 6783

I'm holding on to learning Objective-C and Cocoa after I saw the presentation of MacRuby and Hotcocoa. Macruby is ruby 1.9 written in Objective-c and Hotcocoa is Cocoa written in Ruby. Together they will greatly simplify making cocoa applications

Dave Jewell — Jun 03, 09 6800

For me, the biggest stumbling block was Interface Builder. Scott points out that for some people, laying out an app using a visual layout tool seemed like magic. But really and truly, visual layout tools have been around since the dawn of time, especially if you're coming from a Windows dev environment. All the .NET dev languages (C++, C#, Java, VB), etc, have a well-integrated visual layout designer. And then there's Delphi. And then again, there's the original (pre-.NET) Visual Basic development system which has been around for a __long__ time.

All these tools have a well-integrated visual layout designer. Did I emphasise well-integrated? Yes, because IB ....errr.... isn't. It just about plays ball with Xcode, but there is a world of difference between (say) Delphi's polished IDE on the one hand, and the Jekyll / Hyde combination of Xcode / IB on the other.

In C#, if I want to resize a control, I just do it instantly there and then - I don't need to call up another app to do the job. If I want to add a button and have some code execute when I click the button, I just drag the button onto a form, double-click the button, and there I am writing the code in the code editor. I love Cocoa as a framework, but the Xcode / IB partnership can trace its history back to Nextstep - and it shows. And don't get me started on all the weird and wonderful idiosyncrasies in IB. It's time IB was put out to pasture, and Xcode had an integrated, extensible layout designer of its own.


TerranceOXP — Jun 15, 09 6811

Well, definitely a good language to venture in. Maybe it's time to learn more about it.

Bill Coleman — Jun 17, 09 6812

I've developed for the Mac off and on since 1984, so I don't have the problems of younger developers not knowing ANSI C, etc. I've developed with MacApp using Object Pascal, and C++, Think Class Library and PowerPlant. Here are some of my impressions of trying to master Cocoa.

1) Objective-C. I think the biggest problem with Objective-C is that it is an odd mix of old ANSI C and Smalltalk features. There's not a lot of internal consistency between the two -- it's not a very "pure" language like Smalltalk or Java. It's certainly a whole lot simpler than C++, and developers ought not to have too much trouble with it, other than the unusual syntax for sending messages. I certainly understood the language ages ago.

2) Cocoa Frameworks. There's a whole lot to these frameworks. While it's not difficult to get a basic understanding of certain components, it's hard to wrap your brain around all the facilities embedded in Cocoa. Some components are very powerful and not very obvious (eg Key-Value Coding / Observing, Binding, CoreData). Developers trying to learn Cocoa face an enormous learning cliff to scale, because there's just a tremendous amount of material. The Hillegass book is the best I've seen.

3) Proper Technique. Even after you think you understand Cocoa, or are even able to write useful programs with it, there's always the issue of proper technique. This includes such subtleties as when to use a custom classes versus the standard classes, when to use delegates and which object is the right target of those delegation calls, when is it appropriate to use binding versus the old-fashioned push/pull from controls, when you could really benefit from Key-Value Coding / Observing, etc. There's an old saying on the CocoaDev list that if you having to do a lot of work to get something done with Cocoa, you are probably doing it wrong.

This last bit comes easy to the old hands at Cocoa, and is the hardest for them to express. To a newcomer, it looks like "magic" because it wasn't obvious why they made that choice. It may be a level of understanding of the frameworks that only comes through long practice.

John Joyce — Jun 20, 09 6815

Ruby (and Ruby on Rails) people will definitely have an advantage with the Objective-C object model and are already open-minded about syntax.
Their only problem should be retain/release and using semicolons again.

C programmers, not experts, just a little exposure, will certainly get it.

Combination of Rails and C background? Almost home free except Rails docs are miles beyond just about anything else out there.

MacRuby shows this combination meaning a lot.

Coming from C++ or Java? You're definitely in a new land. Basic C++ is not so terribly different from C, but the STL is a lot more terse than Cocoa and the terms for things are certainly worlds apart at times.

Delegates. Yes. These can be mysterious at first. For lots of people. Not more than understanding "callbacks" in C or C++ or any other C-like language. This is where some sort of experience with a good framework / API will benefit people. PHP is often used Ad Hoc without frameworks. Not the best path to come from. Java... so different in terms of conventions from everything else (other than the basic C-like syntax) that this causes some stumbling.

Delegates are more conceptually clear if you've worked with other frameworks that are well thought out. Just saying...

Python? You'll do as well as Ruby folks for sure.

Doing Audio/Video/Graphics?? Well, if you came from a strong C++ or C background with that, you'll fit right in in that realm.

dev — Jul 03, 09 6823

Develop mac application using either Objective-C or
XCode right? Is cocoa the other language to develop mac application?

goosesensor — Jul 31, 09 6842


xCode is a program that organizes your source files and a GUI for the GCC compiler (it's called an IDE, Integrated Development Environment)

Objecticve-C is an OOP language that is the mechanical means by which frameworks are used - it's the glue.

Cocoa is the set of frameworks that are your pre-made resources for doing stuff.

I suppose you could re-write your favorite procedural C program with Obj-C, using all the same frameworks and functions as before, but just organizing it in an OOP pattern.

Maven — Aug 13, 09 6847

I recently came to Objective-C/Cocoa after over two decades of developing C and C++ and for the past several years programming in large scale enterprise Java.

Here are my impressions to date. These are just my opinions. I could be wrong.

XCode: Its adequate for development but my productivity has dropped significantly since using it. I'm sure it will get better but the whole environment just seems like I've stepped back in time. They are in serious need of catch up with the rest of the industry. Its about the little things that make an IDE feel polished.

Syntax: I do not find the objective-C message passing syntax hard to understand but I do find it a bit cumbersome to work with. Having to go back and add [ while you code a line is a pain. Also the aligning of : on method calls is a pain when you change the name of a selector you have to go back and realign the :s again. Perhaps XCode will get with the program and start handling those things for me. Note: Yes XCode does help a little by allowing you to align with a simple tab. They could do more however. I hear that the next version balances the [] for you. A welcome addition. Keep it coming!

Interfaces: The @interface keyword is misnamed. It should have been @class since you are basically writing an implementation. Interfaces do NOT have instance variables. Actually you forward declare an interface with @class so this is even more evidence that something wasn't thought out very carefully.

Protocols: The @protocol should really be @interface and @protocol should just go away. A protocol is really what an interface is. Just a collection of methods and or properties with no implementation. Also it would allow you to code to just Interface rather than id<Protocol> which is just needless syntax.

One small nit for the compiler. Since all Obj-C objects are pointer based then why not just allow the Class var syntax? Why must I always supply the * when the only choice is a *? Again this is just needless syntax the compiler can infer. It does it with "id" it can do it with any Obj-C class. Another symptom of its un-pure origins of being grafted onto C.

Categories: A cute idea but in the wrong hands can be utterly deadly. Talk about being able to shoot yourself in the foot. I can just reopen a class at any time and change an existing method or add a new one. Please. Do I really have to go into all the reasons why this is bad?

Delegation: I've been using delegation in other languages for years. I use inheritance for strictly "is a" relationships. If all you are doing is changing the behavior/look/feel of an object then delegation is the preferred method.

Memory Management: I really thought we were past this. I mean really. Manual memory management is an endless source of bugs. Garbage collection has come to Cocoa finally but not across the board. The iPhone doesn't support it so again you are forced to code to the LCD and deal with memory management yourself. Again another way it feels like I've stepped back into the past.

Stack based objects: I've found myself using Obj-C++ rather than Obj-C to get access to stack based objects to hide alot of the manual memory management. I've made classes that deal with the retain/release cruft and automatically perform those within the scopes I choose. Not perfect but better than all the manual retain/release/autorelease cluttering up my code. It also makes the code more portable from the iPhone to the garbage collected environment of the desktop.

I am finding Obj-C++ far superior than Obj-C. I can utilize the best features from 3 languages rather than 2.

Cocoa: As a framework it is adequate. What it does it does fairly well but I find myself writing so much more code in this environment than in other environments. Perhaps this will improve with experience. The availability of 3rd party libraries is also next to non-existent when compared to other environments.

Portability: There are objective-c compilers available for other platforms if you can find them but nothing main stream. So in order to reuse your code on other platforms you end up writing most of your non-ui code in portable C or C++ and then writing only a thin interface layer in cocoa that puts up the UI and calls into the backend code so you lose all the benefits of coding in Cocoa/Obj-C. Whatever happened to Cocoa on other platforms?

I am still new to Cocoa and I'm sure some of my pain points will lesson as I learn workarounds or alternative ways of doing things but so far I must admit that I am not so impressed as all the hype would lead one to believe.

Hopefully things will improve with time.

RobInNZ — Aug 24, 09 6853

My background is a lot of perl scripting for work, a little bit of VB, and a little bit of hobby java coding. Not having had any academic background in programming is probably my biggest hurdle when it comes to learning Cocoa / ObjC.

One of the earlier posters echo's my major issue, in that there is no real guidance on best practise of how to lay out and structure a larger app in terms of classes, data objects etc.

EG I understand the basics behind OOP, but most of the examples you find on the net are usually related to conceptual ideas (eg a Car has a X doors, a certain size of engine, etc) as opposed to concrete programatic examples of a problem to be solved and the approach someone has taken, and why.

Memory management is certainly another issue, and one that I still havent really gotten my head around properly. And the interaction between IB / Xcode is a little confusing at times, especially when you are trying to figure out how to hook up bindings etc.

And bindings / coredata seem to work well when it does EXACTLY what you want, but when it doesnt, it becomes a bit of a confusing quagmire to figure out how to make it do what you want.

An example of this would be that I have an array of doubles (laptimes) that I want to do an average for. Bindings gives you the ability to do a @array.avg in IB, but I want to round that average to 3 decimal points (to prove milliseconds). Adding a number formatter to the label in IB causes an exception, and I dont seem to be able to make the display format field in IB do anything either.

And finally, yes, the size of the Cocoa frameworks, as well as seeming duplications of behaviour across multiple classes in the framework (eg only very slight differences).

Mitoman — Sep 14, 09 6865

Both Eclipse and Visual Studio are so much easier to use than XCode, and there are a lot of applications on iphone that requires you to use drag and drop. In C# I can build something really fast and show that off, but I am still having a hard time doing that on iphone.

Objective C is not a language thats easy to learn, such as Java or C#, even for a senior developer it still requires some adoption time.

Thats just my 2 cent

SomeDude — Sep 23, 09 6880

IMHO, this is the single best resource for navigating the Cocoa APIs: AppKido.


Jon H — Sep 30, 09 6922

"but the STL is a lot more terse than Cocoa"

Yet somehow, STL code, (and C++ in general especially with templates) in the wild often looks to me like an ugly, confused, wordy, jumble of line noise, compared to Objective-C code.

Maybe you can do a lot more with a given language token, but those tokens bring with them a lot of cruft.

Jon H — Sep 30, 09 6923

"If I want to add a button and have some code execute when I click the button, I just drag the button onto a form, double-click the button, and there I am writing the code in the code editor."

That's what I hate about Windows editors. They're so restrictive. "You'll put the code HERE." What if I don't want it there?

I'm not a fan of UI builders that generate source code. And of course IB lets you wire objects together directly, obtaining useful behavior without any stops in source code at all.

Emo — Jan 05, 10 7074

Coming from a C++ background, the "infix notation" that is used for Objective-C methods takes a while to get comfortable with. But now that I have used it for a while, I am beginning to appreciate it a bit more. It enables the developer to write code that is a bit more self-documenting.

Michael — Feb 16, 10 7459

I've been trying to figure out how to write Space Invaders in Coca for going on 3 years now. I am familiar with K&R C as well as ANSI, and dabbled with Smalltalk a long time ago. And by extension Objective C is not hard to read.

Systems I have wrote space invaders with no problem:

C64 - 6502 assembly - around a month

Amiga - 68000 Assembly - about 3 months

Macintosh (System 6) - Quickdraw 1 week using Think C

UNIX - text curses lib - 3 days

Cocoa, I have found the documentation a complete nightmare. The documentation explains so little of what it is doing. The auto-magicness of Interface Builder, What does this stuff actually do?

hlborg — Feb 19, 10 7611

The problem I seem to have and the reason for why I took a break in learning Cocoa is bindings and Interface builder. I can't grasp the idea of magical bounds that are invisible in the source code and I don't know how to get a good overview over all bindings that have been mase. When looking through the source code of small applications like svnX, I can read the functions, I can see the interface, but I don't see how everything is connected.


Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.

Copyright © Scott Stevenson 2004-2015