macOS First time in Xcode, and stuck!

[Nermal]

Hi all,

I've been developing for Windows for years, using Visual Studio since its first release, and now I'm trying to make a simple Mac app in Xcode 4. However, I'm having great trouble with finding documentation. Lots of the beginner stuff is outdated (I've heard that earlier versions of Xcode are completely different), and most of what I've found for Xcode 4 expects you to already know your way around version 3.

I've tried to get started by myself but I've hit a wall, and can't help but think that I'm overlooking something simple. I've used the Cocoa Application template and have dropped a Button onto the window, but I can't figure out how to attach code to it.

In Visual Studio I'd just double-click the button (which would open the Click handler), but in Xcode that's only for changing the text. Right-clicking opens a black menu and one of the options is "performClick", is that what I want? It doesn't seem to do anything; I've clicked, right-clicked, double-clicked... and nothing happens. I get a little "+" in the circle when I hover over it, but clicking it does nothing.

I'm obviously missing something simple here. How do I attach code to the Click event? And does anyone know of any "Xcode 4 for Visual Studio users" documentation? I've found many articles on how to make certain parts of Xcode function more like VS, but I'm really after something more "beginner friendly" before I get into trying to customise it.

Thanks

 

[lloyddean]

<http://developer.apple.com/library/mac/#documentation/General/Conceptual/Mac101/Articles/00_Introduction.html>

Please go through the WHOLE document. It walks you through building a simple application using the current version Xcode.

 

[Catfish_Man]

Hi all,

I've been developing for Windows for years, using Visual Studio since its first release, and now I'm trying to make a simple Mac app in Xcode 4. However, I'm having great trouble with finding documentation. Lots of the beginner stuff is outdated (I've heard that earlier versions of Xcode are completely different), and most of what I've found for Xcode 4 expects you to already know your way around version 3.

I've tried to get started by myself but I've hit a wall, and can't help but think that I'm overlooking something simple. I've used the Cocoa Application template and have dropped a Button onto the window, but I can't figure out how to attach code to it.

In Visual Studio I'd just double-click the button (which would open the Click handler), but in Xcode that's only for changing the text. Right-clicking opens a black menu and one of the options is "performClick", is that what I want? It doesn't seem to do anything; I've clicked, right-clicked, double-clicked... and nothing happens. I get a little "+" in the circle when I hover over it, but clicking it does nothing.

I'm obviously missing something simple here. How do I attach code to the Click event? And does anyone know of any "Xcode 4 for Visual Studio users" documentation? I've found many articles on how to make certain parts of Xcode function more like VS, but I'm really after something more "beginner friendly" before I get into trying to customise it.

Thanks

'IBAction' is the search term you're looking for. You declare an IBAction in the @interface of one of the objects in your nib (typically a "controller" in the MVC parlance), then ctrl-drag from the button to that object and select the action in question.

This may seem a bit clunkier, but the separation is a quite intentional way to reduce coupling. XIB files aren't code, and don't compile down to code, which is different from the code-behind style of doing things. More fundamentally, the programming model is different, not just the IDE (i.e. Cocoa, not Xcode). There will be things you're used to that simply don't have equivalents in Cocoa, and vice versa.

 

[Nermal]

<http://developer.apple.com/library/mac/#documentation/General/Conceptual/Mac101/Articles/00_Introduction.html>

Please go through the WHOLE document. It walks you through building a simple application using the current version Xcode.

Thanks, unfortunately I'm struggling with that and just can't believe how bad this is. It doesn't help that the document contradicts itself (such as an instruction to not change any options followed by a screenshot with some of the options changed) but frankly after getting to the "Adding a Track Object" chapter while still not knowing why I'd done half of what's listed, I just closed Xcode and decided to rant on here instead

This may seem a bit clunkier, but the separation is a quite intentional way to reduce coupling. XIB files aren't code, and don't compile down to code, which is different from the code-behind style of doing things. More fundamentally, the programming model is different, not just the IDE (i.e. Cocoa, not Xcode). There will be things you're used to that simply don't have equivalents in Cocoa, and vice versa.

It doesn't seem a bit clunkier, but rather a LOT clunkier. Maybe I've just been spoiled with Visual Studio but from what I've seen so far I just can't believe how people manage to put up with Xcode. From this experience, it honestly looks like I should just stick with Windows development.

Thanks for your help anyway, but this just seems to be far too different for me to get my head around. When I have more time I might approach it again from a "fresh slate" but at this point I just can't afford to relearn from scratch.

 

[lloyddean]

Welcome to the broader programming world!

It's no longer just what you know but how well you adapt to change that matters.

 

[Nermal]

You will be pleased to know that I subsequently got a "hello world" app up and running - click the button and a textfield changes to "Hello World"

You will be less pleased to learn that I did it in C# through MonoDevelop

But the point is that I now have a system up and running that I'm (mostly) familiar with. Of course, I'll need to do some testing to see what works in Mono and what doesn't, but I'm feeling a lot better about it now!

 

[Catfish_Man]

Thanks for your help anyway, but this just seems to be far too different for me to get my head around. When I have more time I might approach it again from a "fresh slate" but at this point I just can't afford to relearn from scratch.

Understood that you don't have the time right now, but it's important to recognize that it's not that you're "spoiled" by Visual Studio, it's that you don't understand Cocoa.

I would be similarly lost and frustrated were the situations reversed and I was trying to do Windows development.

 

[mfram]

Thanks for your help anyway, but this just seems to be far too different for me to get my head around. When I have more time I might approach it again from a "fresh slate" but at this point I just can't afford to relearn from scratch.

I downloaded a trial copy of VS for Windows and was equally frustrated. Couldn't get it to do a single thing useful. How does anyone use that crap?

The fact is, XCode works just fine. It's just different. The Cocoa design paradigm has evolved from the days of NextSTEP in the early 1990s. Programming for Mac and iOS are new skills that you will have to learn if you want to use them. But don't try to think of it in terms of "how do I get it to work like Windows?" because that will just lead to frustration. They don't work like Windows.

 

[Nermal]

Using C#/MonoDevelop, I'm still having to learn bits of Cocoa. I've had to set up outlets and actions (and I think I know when to use each now) and I'm learning new property names, such as .StringValue instead of .Text. The key difference is that I understand my way around the language so it's not totally unfamiliar like yesterday's attempts. Once I'm used to how Cocoa works in Mono, it could end up being a stepping-stone to a "pure Apple" environment

 

[knightlie]

In order to learn XCode and Cocoa you're going to need to stop comparing it to Visual Studio, otherwise you'll just keep getting more frustrated. Programming isn't about the IDE, it's about the language and the API. Everything you've done in Visual Studio and XCode can be done at the command-line with a text editor without even starting an IDE.

I find Visual Studio as frustrating as you're finding XCode, and I've been through Basic, Turbo Pascal, Delphi, Java, C# and Objective-C. Take a step back and start at first principals.

 

[themacster298]

Watch these tutorials:

http://www.youtube.com/watch?v=1Xqn5IHbusA&feature=list_related&playnext=1&list=SP640F44F1C97BA581

They might not be the best in the world, but it teaches you the basics.

 

[displaced]

I went through the exact same experience as the original poster (albeit back with Xcode 2 or thereabouts!).

VS.NET development is my day-job. Specifically, .NETCF smart device development. Quite a while back, I wanted to start Mac development so fired up Xcode...

... and was utterly, profoundly lost.

But I was absolutely determined to figure this stuff out. My thinking was: "Look at these great apps using great abilities of OS X. Xcode/Cocoa/Objective-C must be good if that's what it can produce. The problem's not with them -- it's with me.".

So having stuck at it, I can really say it's worth it. I'm nowhere near as competent in ObjC/Cocoa as I am C#/VB/.Net Framework (hell, I can almost recite the .NET class hierarchy), but that'll come with time.

Undeniably XCode/Cocoa asks more of the developer than VS. VS will let you stick all your logic, objects, etc. in the same class as the form. It will not guide the structure of your program, nor will it do anything to prevent you writing with every anti-pattern under the sun. It'll let you tie your logic directly to the UI. It'll let you put data access code in button-press events. Heck, there's loads of sample code that shows exactly that.

But XCode/Cocoa has some expectations and some rules. The Model-View-Controller pattern is pretty intrinsic to OS X and Cocoa, and XCode's approach really pushes this. You're still free to do nasty things like mix model and controller code (and sometimes that's right), but the separation of the View from the rest of the application is pretty baked-in.

Although my Cocoa/Xcode skills are still pretty weak, I can hand-on-heart say that my Cocoa projects just feel cleaner than my VS stuff. Do anything non-trivial in Cocoa/Xcode and the logic behind it all rapidly becomes clear.

The first time you do anything with CoreData I guarantee you'll have a grin on your face. Also, NSString is insanely powerful (initWithContentsOfURL:, for example), even if it takes a while to get used to things like [myString isEqualToString:anotherString] instead of a straightforward '=='.

My best advice would be to get used to Objective-C, play with a trivial app just to get the concepts down, then think of an app you'd like to write and go for it. Be prepared for many false starts until things click into place.

 

[jared_kipe]

Undeniably XCode/Cocoa asks more of the developer than VS. VS will let you stick all your logic, objects, etc. in the same class as the form. It will not guide the structure of your program, nor will it do anything to prevent you writing with every anti-pattern under the sun. It'll let you tie your logic directly to the UI. It'll let you put data access code in button-press events. Heck, there's loads of sample code that shows exactly that.

But XCode/Cocoa has some expectations and some rules. The Model-View-Controller pattern is pretty intrinsic to OS X and Cocoa, and XCode's approach really pushes this. You're still free to do nasty things like mix model and controller code (and sometimes that's right), but the separation of the View from the rest of the application is pretty baked-in.

Although my Cocoa/Xcode skills are still pretty weak, I can hand-on-heart say that my Cocoa projects just feel cleaner than my VS stuff. Do anything non-trivial in Cocoa/Xcode and the logic behind it all rapidly becomes clear.

While you are correct about not being able to write code/logic into view/nib files, there is nothing preventing you from doing the opposite. You can certainly build and display views 100% in 'code'.

I do agree with you about the projects feeling cleaner. Ive been into both big C#.NET programs and big Xcode/Cocoa projects and it is very easy to get lost and have a hard time navigating around those .NET projects.

EDIT: Also this might be more Windows related, but the Unicode compatibility seems poor. I had a bunch of problems with encoding problems and version control in a certain .NET project. Had to go so far as taking files out of windows, into MacOS and converting their character sets and moving them back.

 

[Nermal]

I went through the exact same experience as the original poster (albeit back with Xcode 2 or thereabouts!).

(etc)

Well, that gives me hope and I'll certainly take a good look once I can devote some time to it

Also, rereading my earlier posts, I apologise for the frustration showing through in my posts!

 

[displaced]

While you are correct about not being able to write code/logic into view/nib files, there is nothing preventing you from doing the opposite. You can certainly build and display views 100% in 'code'.

Oh, absolutely. Also, I like the way that Xcode handles custom subclasses of UI objects. Write the code, drop the object on the view in Interface Builder, then just set its class name to your custom class. Bam!

I do agree with you about the projects feeling cleaner. Ive been into both big C#.NET programs and big Xcode/Cocoa projects and it is very easy to get lost and have a hard time navigating around those .NET projects.

Not to mention how slow VS gets when solutions grow. My current project at work is approx. 200,000 LOC across 15-or-so projects. Builds take a daft amount of time. And don't even mention deployment - debugging a Smart Device project on a physical device over ActiveSync requires Zen-like patience and a high tolerance for spates of random 'Connection to remote device lost' messages. Doing the same with an iOS device and Xcode is orders of magnitude faster and more robust.

EDIT: Also this might be more Windows related, but the Unicode compatibility seems poor. I had a bunch of problems with encoding problems and version control in a certain .NET project. Had to go so far as taking files out of windows, into MacOS and converting their character sets and moving them back.

Bleugh. Not run into that myself, but I can see how it'd happen!

Well, that gives me hope and I'll certainly take a good look once I can devote some time to it

Also, rereading my earlier posts, I apologise for the frustration showing through in my posts!

Hehe. No problem. I only replied because I knew exactly what you meant

 

[jared_kipe]

Not to mention how slow VS gets when solutions grow. My current project at work is approx. 200,000 LOC across 15-or-so projects. Builds take a daft amount of time. And don't even mention deployment - debugging a Smart Device project on a physical device over ActiveSync requires Zen-like patience and a high tolerance for spates of random 'Connection to remote device lost' messages. Doing the same with an iOS device and Xcode is orders of magnitude faster and more robust.

OMG don't get me started. The first time I ever saw VS I was in a conference call/screen sharing session with the lead programmer on the project and he was showing me how to duplicate a class/view to change some specifics and he goes to rebuild/compile and it took ages! I couldn't believe it, I was like "does VS not do incremental compiles in the background or something?", and he says "oh I think it does, this isn't so bad". Yeah right, while working on that project was the first time I got to experience this myself. http://xkcd.com/303/

 

[PatrickCocoa]

Huge Mountain to Climb

To the original poster, you have a huge mountain to climb. The mountain is there not because the new Apple way is WORSE, the mountain is there because the new Apple way is DIFFERENT.

As several other posters have noted, it's those differences that cause the problem. To clarify, there are several sources of differences:

Operating system (OS X vs. Windows);
IDE (Xcode vs. Visual Studio);
Language (Objective-C vs. whatever you're using now);
API (Cocoa vs. the Windows APIs, whatever those are called).

You will have a multitude of problems with each of the above areas. For example, once you get the current IDE issue you're having (how to hook up a button) fixed, you'll immediately run into an API issue - you may need to use NSString to do something with some text, and you're not familiar with NSString or how to reference the documentation. Then you'll get that figured out after a few days and have some Objective-C issue - you may want to append some text to your text string, so you'll try something like Append(textstring, additionaltext) when Objective-C and Cocoa demand textstring = [textstring stringByAppendingString:addionaltext];

After having spent three or four frustrating days just trying to get a damn button working, you'll either give up or relax and enjoy the ride. Others have done it. You can too, if you want.

 

[knightlie]

To the original poster, you have a huge mountain to climb. The mountain is there not because the new Apple way is WORSE, the mountain is there because the new Apple way is DIFFERENT.

As several other posters have noted, it's those differences that cause the problem. To clarify, there are several sources of differences:

Operating system (OS X vs. Windows);
IDE (Xcode vs. Visual Studio);
Language (Objective-C vs. whatever you're using now);
API (Cocoa vs. the Windows APIs, whatever those are called).

You will have a multitude of problems with each of the above areas. For example, once you get the current IDE issue you're having (how to hook up a button) fixed, you'll immediately run into an API issue - you may need to use NSString to do something with some text, and you're not familiar with NSString or how to reference the documentation. Then you'll get that figured out after a few days and have some Objective-C issue - you may want to append some text to your text string, so you'll try something like Append(textstring, additionaltext) when Objective-C and Cocoa demand textstring = [textstring stringByAppendingString:addionaltext];

After having spent three or four frustrating days just trying to get a damn button working, you'll either give up or relax and enjoy the ride. Others have done it. You can too, if you want.

Again, you're making comparisons where none should be made. Don't compare apples with oranges, just learn how your new coding environment works. Forget how VS or Windows does it because that's no longer relevant.

 

[hatzinik]

I 've recently started programming in Xcode, after being in the Windows programming paradigm for many years. It is indeed very different. A new (for me) point of view.

Certainly, a good programming book (like Cocoa Programming for MAC OS X, by Aaron Hilleglass) will make the transition easier.

However, after only some code been written, the whole experience seems smoother and more structured. Exactly, as the whole MAC experience feels smoother and structured.

Don't give up!!! Learn a few things at a time. Study again and again, write code, and try to get in (some) deeper waters each time.

As far as i am concerned, there is no way back. Everything seems better now.
To mention, that I am a hobbyist programmer, and i don't expect to earn any money soon, although i certainly will be playing with the app store, once i have enough skills to make something worth posting to the store.

Good luck!!!

 

[Nermal]

<http://developer.apple.com/library/mac/#documentation/General/Conceptual/Mac101/Articles/00_Introduction.html>

Please go through the WHOLE document. It walks you through building a simple application using the current version Xcode.

I have some time at the moment so I've been working though this. I've been taking it very slowly and have been sure to get an understanding of each concept as it comes up so that I know exactly what I'm doing.

Having said that, I've run into a minor issue.

On this page, the first step is "In Xcode, in the project organizer select the Classes group folder."

Presumably it means the "Project navigator"; the list of files on the left. Is that correct or am I looking in the wrong place? The only Organiser I can find is a documentation viewer. However, even in the Project navigator there's no folder called "Classes". I used the TrackMix folder, but is that what I'm supposed to be doing? I just want to make sure that I'm putting the files into the preferred location

 

[chown33]

Do you see a Help menu in Xcode? Open the reference docs for Xcode itself, and search for keywords organizer or project organizer.

Or google search terms: xcode project organizer

 

[whooleytoo]

But XCode/Cocoa has some expectations and some rules. The Model-View-Controller pattern is pretty intrinsic to OS X and Cocoa, and XCode's approach really pushes this. You're still free to do nasty things like mix model and controller code (and sometimes that's right), but the separation of the View from the rest of the application is pretty baked-in.

Excellent post, my experience was much the same. Xcode does 'force' you (or at least, prod you with menace) into doing things in a structured, thoughtful way. That can mean there's a steeper learning curve with Xcode/Cocoa than with many other development environments, and it can mean some 'simple' tasks take longer than you'd expect; but the benefits are your application is better structured and more scalable as a result.

There still are quite a few things I dislike.. Xcode is very unstable for me. The Storyboard view is still a bit awkward to work with. Some things (like 'undoing' a segue) that you'd think would be a simple option for a button instead require creating an action and a protocol. Etc.. etc...

 

[ForkHandles]

Hi Nermal

I too have just started working on projects in xCode, coming from a Flash AS3 background I have probably found things even more challenging as you can program with objects with worrying too much about MVC.

The best way I have found to start getting a handle on how the code works is to forgo a lot of built in functionality. The projects I have completed have been written entirely in code avoiding any inclusion of built in objects such as Buttons, NavigationControllers, ViewControllers, split views, table views etc etc.

By doing this I have avoided concepts which at first look appear to be confusing. If I want a button, I create a button, place it in my view and create a Handler for it. In this respect it works in a very similar way to Flash AS3 projects. The only downside is that the visual appearance sucks!! It has, however, given the breathing room to get used to syntax and operational requirements.

Now I can create games and apps which are similar in functionality to Flash I can move on to learning how to use inbuilt Big objects such as those found in a storyboard.

The Xcode interface itself is incredibly helpful, although daunting at first, I have found it to be very useful.

Best of luck

 

[Nermal]

Do you see a Help menu in Xcode? Open the reference docs for Xcode itself, and search for keywords organizer or project organizer.

Or google search terms: xcode project organizer

Yes, of course I've searched, although I made an error in my previous post; although I did find the Projects button under Organiser, it still doesn't have a "Classes group folder" anywhere to be found.

 

[ArtOfWarfare]

Yes, of course I've searched, although I made an error in my previous post; although I did find the Projects button under Organiser, it still doesn't have a "Classes group folder" anywhere to be found.

Im not at my computer right now so I can't be certain about this...

I think the "Classes group folder" was just the name of a group automatically set up by many different templates in Xcode 3.x... I feel like as of Xcode 4.x, the names of the groups automatically set up changed... Why not just expand all the groups on the left panel and look for whatever is supposed to be in that folder?