If you're on Tiger, great. Get Xcode 2.1 and go from there. Since you already know C and OO programming, learning Objective-C shouldn't be a problem. For a good book, there's Stepen Kochan's Programming in Objective-C, though it'll cover a lot of what you already know. Then there's Hillegass' Cocoa Programming for Mac OS X (2nd Ed.), which should be a good intro to the Cocoa API. That'll probably be your hardest problem. Cocoa is so massive, it may take you a while to be able to use all of it. Of course there's also Cocoa Dev Central and CocoaDev as online resources, and all of Apple's documentation.

Probably the hardest concept you'll run into are bindings, since they don't really have an equivalent in Windows. But they're awesome, and you should start using them as soon as possible.

Other than that, it's hard to know how to help you unless we know more about what you want to do.

I did this by first running through Apple's Currency Converter tutorial (on Apple's dev site). I made sure that I understood completely what every part of the tutorial was doing, how it worked, and why. I did this by referring regularly to Apple's objective-C specification, the document that covers how the language itself works, and why. I also referred to the Cocoa API docs regularly, which gave me an idea of how Cocoa is structured, and generally, how cool it is.

There were a couple of nice "eureka" moments. Figuring out that objective-C messaging is not equivalent to c++ method calls or C function calls was one. Figuring out that runtime introspection was something I both could and should rely on was another.

I'll echo the other comments here.

Obj-C is refreshing compared to C++. It'll take you about 2-3 hours to get a handle on it. (Granted, I like C# and Java better, but for Mac development you are better off with Obj-C.)

The currency converter app is a reasonably good tutorial. Go through the Hillegass book. It's valuable.

Learn bindings. I'm still trying to get my head around them. As Thinine pointed out they are VERY powerful. (I'm currently exploring CoreData .... something else that we don't have anything similar to in Windows ... ADO.NET is great, but this seems to be better thought out.)

Welcome to the club.

Thanks guys for the suggestions - I appreciate it. It's helpful to know some of the key differences between the Windows C++ world and Mac Obj-C ahead of time.

As far as what I want to do, there isn't any particular answer at this point. There are a couple random and simple apps I want to try out, but other than that I'm just looking for a good foundation - which sounds like understanding the currency converter app top to bottom, getting familiar with Obj-C, Xcode 2, interface builder, etc.. This should help ease me into learing more complicated stuff as my inspiration heats up.

Let us know how you make out.

Forget a lot about what you know about Visual Studio. It will hold you back.

Hi Flatcatch,

Glad you're getting back to Mac. I wrote a few small things in Objective-C but could not get myself motivated to write anything big in it. After being a Java guy, I had a very difficult time adjusting to the concept of developing for just one platform. I spent quite a bit of time exploring different options, including Objective-C using OpenStep, Python, Ruby, Mono, GUI kits for Java, and ultimately GUI kits for C++....

I found the last category to be the most promising of all. It would be an absolute DREAM to develop in Objective-C for all platforms. Unfortunately, the OpenStep stuff requires alot of compromises for your Windows/Linux versions...

Check out:

http://www.wxwidgets.org/ - An open source cross platform toolkit with a VERY large user-base. There are bindings to this toolkit in a HUGE number of language. In fact this is the default GUI toolkit for Python developers. Borland's C-BuilderX is based on this toolkit.

http://www.trolltech.com - A commercial GUI toolkit that has a dual license for open source developer. This toolkit is also well established. There are a large number of commercial applications built on this toolkit. The KDE desktop for Linux is built on this toolkit, as is the empire of k*.* open source alternatives (koffice?, kdevelop, konquerer, etc).

Not to discourage Objective-C. But I would rather point out the alternatives than have developers walk away from Mac development, like I almost did.

Screw other platforms and their inferior GUI development tools.

Obviously a diplomat in a previous life. <GRIN>

Yes but,

Applications built using these toolkits on the Mac won't FEEL like Macintosh applications. If an application doesn't FEEL like a Mac application (i.e. feels like something that was written for Windows first or Linus first), then I won't use it.

And I know many other Mac users won't either.

I'm developing my applications on a Mac, from the viewpoint of a Mac user. But competition in the software industry is difficult enough, even when you target 99% of the market. It is even more difficult to earn a living when only 2% of the market is targeted. I am unwilling to compromise the performance of my applications. Thus they are native Mac executables. But unfortunately, I cannot commit professional suicide by locking my application into Mac. I know, I know.. Separate the GUI code from the logic (it is, btw) and write two GUIs... But hey... Guess what? That takes significantly more development and testing resources. Resources I don't have.

It is not professional suicide to create real Mac-native applications.

Applications written in these tookits are no more difficult to make "Mac-like" than any other Carbon app, particularly if you start out with the intent to make them good Mac citizens.

Minor nitpick: the default GUI toolkit for Python is Tkinter, not wxWidgets. Both toolkits come standard with Tiger, though neither one comes with previous versions of OSX.

Tkinter is a Pythonic wrapper around Tk, the default GUI toolkit for Tcl. Tk has two main advantages: it's very simple to hand-code a GUI in it, and it's been ported to many scripting languages. It's the default in Perl and Ruby, for example, and there's even a version of ksh that lets you write GUI shell scripts.

This is not to say that I encourage developing apps in Tk. Many GUIs are not hand-coded these days, and if you don't use a language to which Tk has been ported then that advantage also disappears. It's also extremely bare-bones by modern standards; although you have all the basic GUI elements -buttons, menus, frames, and so forth- you don't get anything like tabs, combo-boxes, or other advanced GUI elements which we take for granted nowadays.

There is no doubt in my mind that there ARE successful companies that make exclusively Mac software. But unfortunately, I cannot provide you with links to all the dead companies that did, or wanted to be successful Mac-only software shops.

Also, I have searched for a Mac shop all of my career. I'm sitting here typing this at work on my Windows box, with Visual Studio open to my C# code in the background window. Its a dream that I wish I could persue, but it, like my dream of being a rock star, is dead.

Thats good to know... I am going through lots of work and $3000 out of my pocket to use a toolkit that will 1) Allow my applications to work on a Mac, and 2) that I trust.... (I don't know enough about WxWidgets to be willing to risk my product... I've invested alot of money at this point and I'm unwilling to take another risk)...

I plan to release my applications first on Mac. Mac is my favorite environment. I have done extra work simply out of that love. So I don't want to hear that Mac users are not going to use my product simply because I didn't write it in Carbon or Cocoa. It would be my dream to develop all my applications in Cocoa. But reality sometimes sucks.

Ditto for the ones that wanted to be successful software shops of any kind. It's not as though the phenomenon of developers failing is somehow special to the Mac.

There are pros and cons to both approaches. With Mac software, you could only reach about a sixth of the total PC user base. With Windows software, most of the users are much less likely to ever find and buy your app. With generic, cross-platform software, you have the advantages of both platforms, but a decent, native-feeling Mac app could probably annihilate you on that front. I'm just saying, the set of sacrifices you chose isn't the only reasonable one. I don't want to scare people away because of it.

Separating the UI from the back end is a bit more labor intensive, but it does future proof your application. For anything but the trivial it's not only a good idea, but mandatory IMHO.

ok. What follows is an oversimplification... But I think you can extend this out in a number of ways and come to essentially the same conclusion.

(# of PC users in the genera of your application) * (% of PC users who BUY in the genera of your application) = (Total potential PC market)

(# of Mac users in the genera of your application) * (% of Mac users who BUY in the genera of your application) = (Total potential Mac market)

If you choose a genera with a Mac user base that is nearly as large as its PC counterpart, then you can make the argument that Mac users tend to buy more. But if your application has a very broad genera, then you can start approximating your userbase based on platform sales.

In my case, I do have a broad genera. So I start looking at target markets and conclude that my PC market is more than 10x as large as my Mac market.

One must also consider competition too. If you have 1/10th the market to yourself, that may be better than competing with 10 others for 9/10ths the market. This is especially true if you are attempting to penetrate a market with established players.

So if you want to make this discussion about a particular genera, then we will discuss the merits of a Mac-only product. But if we are discussing REALISTIC, generalized development strategies, then I think its very difficult to argue a case for developing Mac-only products.



You are right. One always must consider their market when determining what tools to use. I have been writing my application for several months, and I haven't yet written one line of GUI code. I will do everything within my ability as a developer to avoid being locked into any particular technology or platform. There are constraints that we MUST work in. That is a reality.

BTW, if I could write code in Objective-C and deploy it on Windows as a second-class citizen to my Mac version, I would. But it doesn't require a vast amount of evaluating to come to the conclusion that Objective-C on a PC is not a viable direction. I could be wrong. I would love to get in contact with a developer that has successfully ported their Objective-C application to a PC and gone on to market their product as a cross-platform application. If it was easy, we wouldn't be seeing the Mac-only compaines listed above. They would be offering PC versions, even if they were second-class.

That's a pretty crappy attitude, and an insult to the developers that spent their time making them. They could have just as easily ditched the Mac market and made those application soley for Windows. You should be thankful. But don't worry, even you will use an application that doesn't "feel" Mac-like if you really need it and there are no alternatives.

Actually, only one of those companies I mentioned (Omni) primarily uses Objective-C, to my knowledge.

My biggest recommendation would be to start with the Hillegass book - excellent way to learn cocoa, bindings, xcode, and just about all the other basics that you'll need.

Actually, your app will be written in Carbon, as most of the cross-platform GUI toolkits simply wrap around it. It's good to hear that you plan to do extra work to make your app Mac-like, though, because you're going to need to do that. You can save yourself a little work by basing your UIs on other platforms around the one you've created on the Mac. Users of other platforms will usually tolerate this, whereas the reverse isn't always true.

There are quite a few zealots who avoid apps written in cross-platform toolkits on general principle, and there are even some who avoid apps written in anything but Cocoa. That said, there's not likely anything you'll be able to do to appease them. The best you can hope for is to not mention what toolkit you used. It's a shame that this would be necessary, but what can you do in the face of zealots? Fortunately their numbers are decreasing as time goes by, so it shouldn't be too much of a problem for all that much longer.

By the way, I do suggest that you learn Cocoa and play around with it, even if you don't plan to do much with it. Aside from being a good mental exercise, you can use it to get a feel for what Mac users will expect of your apps.

...

I'm not a zealot by any stretch of the imagination, and I DO use cross-platform applications with crappy GUI implementations, but ONLY when there is no truly Mac-native alternative. (Oh, and I won't pay money for anything unless it uses a proper Mac interface. If there is no alternative and I need it, I'll either do without or use it on a PC).

The INSTANT a PROPER Macintosh implementation (whether cross-platform or not) comes out, I switch to it.

I don't have a problem with cross-platform development per-se... I prefer that it be done correctly, by desigining the interface SPECIFICALLY for the OS it is run on, which means separating out the GUI from the background implementation and coding it for the platform it's intended for.

The Mac user base may be small now, but it IS growing. Eventually you will need to be able to do it properly. Might as well learn how to do it now, even if you won't be using it in actual practice anytime soon.

Well, I consider myself a Mac guy at heart... But I'm starting my own business and I was having too many issues trying to develop on my powerbook. For one, I kept having to borrow my wife's PC Laptop to make sure my web pages looked okay in IE... Then there was the shared folders issues I was having.. They should just work.. but they just weren't. Next, we've got a Canon MultiPass F60 that doesn't have Mac drivers. I blame Canon and I never would have bought it had I known it didn't support Mac.... But alas, we're stuck with it.... Next, we were thinking of buying a Vinyl cutter, else an embroidery machine for doing promotions... You guessed it, very few choices in the Mac world.

Sooo... To make a long story short. I got sick of fighting the system and bought a VAIO. I'll probably buy one of the new Macs in a year or two.. The old powerbook is going on ebay as soon as I'm confident that I've got everything migrated over....

Anyway, I'm not as optimistic about the growing Mac market as others here. I think its a superior product and I root for it. But I've got bills to pay now.

The nice thing about wxWidgets is that on each platform, it's is a layer between the program and the native GUI. Qt, on the other hand, uses its own widgets, IIRC.

It just so happens that I'm using wxWidgets now. I prefer Cocoa, but wxWidgets seems pretty well designed. If you use Cocoa (or Carbon), you get to use Interface Builder. If you use wxWidgets, you don't.