Beginning Mac Development
Building A Solid Foundation
05 May 2005 Justin Williams Skip to comments
31 Comments
(
Closed)
If you have ever been interested in writing your own applications for Mac OS X, read Justin Williams' getting started guide for new developers. He will outline a brief history of Mac development, lay out what options you have, and then set you on the right path to developer enlightenment.
A request we have gotten a few times in our inbox concerns how to develop software for the Mac. Usually the person writing is a switcher from the Windows world who has dabbled in Basic, C# or maybe some C++. Once they get their first Macintosh, they realize that they can't use Visual Studio on the Mac, and pretty much have to start over.
Others are people that have no experience with programming or development but are interested in exploring a new area. A Google search can be intimidating. Opening Xcode for the first time can be as well.
This article is meant to be a general overview of the Mac development environment. I want to explain what some of your options are, how to get started, and where to look for help. I won't be explaining Objective-C syntax, reference counting or any other type of specific programming topics. There are plenty of other great resources out there that can do a far better job at that. I'll link to those later in the article.
Why Develop On The Mac?
Before we begin, let's examine why anyone would even want to develop for the Mac platform. It's less than 5% of all computers, after all.
Back in 2001, Apple released Mac OS X. The interface and user experience of OS X was a major departure from Macs of the past; the same could be said for the Mac development environment. Most of the code written for pre-OS X systems was obsolete and would need to be ported or completely rewritten for Mac OS X. At the time, it was frustrating, but it solved a lot of problems with Mac development.
Way back in 1984 when Apple released the first Macintosh, it created the Toolbox. The Toolbox was a set of resources, drivers and APIs that allowed developers to create Mac software. It was in charge of the menus, events, windows and pretty much everything else involved in creating applications. As the Mac matured and its OS grew over the years, Apple kept upgrading the Toolbox. Fast forward fifteen years, and Apple is still using the Toolbox. As you can imagine, after over fifteen years, it had become somewhat unruly.
With OS X, Apple was given a clean slate. The Toolbox was no longer in use. Instead, Apple used the technology it inherited from Steve Jobs' NeXT, which is also the muscle behind OS X. These technologies make it much easier for new developers to get their feet wet in OS X development.
Apple also makes it easy to get started because each copy of Mac OS X has included a copy of the developer tools. Apple did this to help draw developers to the platform. With Microsoft, you have to pay to make software, but not with OS X. Instead, you are given a fully functional development environment free of charge. Apple's thinking was if you make the barrier to entry minor, it will bring in more people.
What it all comes down to is that developing on the Mac is fun and innovative. It requires you to use both sides of your brain. Windows and Linux there is little to no thought put into how an application looks and functions; that is an integral part of the Mac development process. It's not uncommon for developers to spend days or weeks slaving over their interface making sure it is perfect.
That's where Mac and Windows developers will never see eye to eye.
Experience Required?
Many beginners want to know if they need any experience to begin developing software in Mac OS X. I usually tell them that knowing the basics of programming in general is a good foundation, but they don't need a deep understanding of C or C++ to become a successful programmer. More important than that is understanding the underlying foundations of good programming practice.
You can gain that from almost any programming language. I knew C before I moved to OS X and had done several projects in PHP and Perl as well, but knew nothing about C++, Java or anything object-oriented for that matter. I learned it as I went. Some may disagree with this practice and insist you get a good foundation in C and objects before even touching code, but I believe more in trial and error than theory.
Depending on the route you take in development, there are different resources you can reference.
A Fork In The Road
If you want to develop for Mac OS X, there are three routes you can take. Technically there is a fourth in AppleScript, but my thoughts about AppleScript Studio are inline with its acronym. The first one that is not commonly used anymore is Carbon. Carbon was created as a bridge between Classic and Mac OS X. Carbon supports about 70% of the classic Mac OS APIs and then adds new OS X specific APIs. While there is nothing wrong with developing with Carbon, I wouldn't recommend it for new Mac developers. While you may need to use some Carbon in your applications, I think all new Mac developers should use Cocoa. You can develop applications in Carbon without any problem (OS X's Finder is Carbon for example), but Cocoa is "the" language for OS X in terms of new development. That's my opinion at least. Development with Carbon involves much more heavy lifting in terms of learning and work compared to Cocoa as well.
Another option would be the cross-platform Java language. Java is taught now in many college classrooms because it teaches good object-oriented principles. Java also has the promise of write once. run anywhere. This is not necessarily true if you are developing native OS X applications though. Java can take advantage of the Cocoa frameworks, but your application will run slower than if you are using Objective-C and you can't take advantage of all of the niceties of Cocoa: bindings anyone?
The final topic, and the one that this article will cover the most is Cocoa. Cocoa is an object-oriented set of frameworks made exclusively for OS X development. Cocoa is accessed mainly via Objective-C, a small extension of the C programming language. Cocoa is the development language of choice for OS X in terms of innovation and groundbreaking new features like bindings and Core Data. At a high level, Cocoa is two frameworks: Foundation and Application Kit. These are the two base frameworks that are required of all Cocoa applications.
Foundation is the base layer of classes used. As its name suggests, it provides the foundation for which all Cocoa apps are built upon: object behaviors, memory management, notifications, persistence and other OS-centric behaviors. Application Kit, on the other hand, is in charge of the graphical interface for your application. When you are working in Interface Builder, you are dealing with Application Kit features. Hand-in-hand, these two frameworks make it easy to get started in Mac OS X development.
Cocoa also let's you take advantage of the coolest technology to hit Mac OS X developers in ages: Cocoa Bindings. Bindings let you elimate a lot of the "glue" code that keeps your application together. For example, prior to Bindings, developers had to implement several methods in order to get a simple table view or outline view to function in Cocoa. With bindings, a few connections in Interface Builder let you bind your model class to your application's interface. You will want to learn more about bindings.
The only caveat to Cocoa development is that you will need to learn a new syntax: Objective-C. Developed in the 80's by Brad Cox, Objective-C is an extension of the C programming language. It is a very thin layer that is on top of C. This means that you can compile any C program with an Objective-C compiler.
Learning Objective-C is nothing too difficult. You can pick it up in an afternoon if you have experience with C. Teaching you the language is beyond the scope of this article. As we go along, I will list a few resources that can help you get started.
Tools of the Trade
Like any good craftsman, you are only as good as your tools. Luckily, Apple has bundled an excellent set of tools for OS X developers to take advantage of. At the center of it all is Xcode. Xcode is the dashboard of development allowing you to write code, model your data, compile and debug your code. As a Mac developer, you will spend most of your time in this application.

Xcode has several features that make it so great. One of these is Fix and Continue. Using this feature, you can make modifications to a running application while you are debugging it without having to recompile. On larger projects this can be a major time saver.
Fix and Continue is made possible by another Xcode feature called ZeroLink. Normally, when you compile an application it will compile the source files into object files and then link them using a linker of some type. Using ZeroLink, Xcode skips the linking step at compile time and instead creates a small stub that does all the linking as the application is running.
Xcode also includes distributive building which lets you push some of the workload of compilation off onto idle Macs on your network. Using Bonjour, Xcode will search for other Macs on your network that have Xcode launched and will use their processing power to help compile your application. This can save you time when compiling your application because you will be using the collective power of multiple machines instead of a single one.
As I said, Xcode deals with the source code of your Mac OS X application. Interface Builder is in charge of designing and testing your application's user interface.

Interface Builder lets you drag and drop controls on your application's windows and arrange them as you see fit. It will also help you follow Apple's Human Interface Guidelines, a document that establishes how a Mac application should look and function. IB will put guidelines on the screen to help you space your interface's controls in adherence with the HIG.
Interface Builder is also where you connect your application to the classes you create in Xcode. This simply involves dragging a line from your instantiated class to the control. You can also subclass your objects and establish default values from within the application.
The great thing about developing on OS X is that all of these technologies take advantage of Unix behind the curtain. Apple knew it didn't need to reinvent the wheel in terms of writing its own compiler, so it began to work with open source projects to use their tools. When you are compiling your code in Xcode, you are most likely using the gcc compiler that has been in development for decades. When you are debugging your application, you are using gdb, another open source project.
You can run all of these open source applications from the command line, but Xcode harnesses their power in an easy-to-use graphical interface, so why would you want to?
The Starting Line
Now that we have established what options there are in terms of developing for Mac OS X and the tools we can use, you are probably wondering where to even start. If you do a quick Google search on Cocoa or visit the ADC website, the results can be dauting. I think there are three key steps to becomming a successful Mac programmer. You first need to learn the language you are using. Next, you need to master your tools. Finally, you need to use your skills and just make something. There is no 100% correct way to reach OS X development enlightenment, but you will definitely need to get a good foundation in your base programming language.
For Cocoa programmers, that language is Objective-C.
Step 1: Become An Objective-C Jedi
If you have no knowledge of C whatsoever, you should take a step back first. In my opinion, you don't need a deep understanding of C to understand Objective-C, but you do need to know just a little bit. Scott Stevenson of CocoaDevCentral wrote an excellent tutorial that will teach you just enough C to be able to function as a Cocoa developer. Scott covers C syntax, the gcc compiler, typed variables, function prototypes, and several other topics.
You can pick up Objective-C's syntax in an afternoon. This is assuming you already have experience in another programming language. Most programming languages make extensive use of curly braces, but Objective-C is the land of the square-bracket. Let's look at a bit of sample code from one of my applications.
-(NSArray *) names {
NSMutableArray *array = [NSMutableArray array];
NSEnumerator *enumerator = [[self exporterArray] objectEnumerator];
COExporter *currentExporter = nil;
while (currentExporter = [enumerator nextObject])
[array addObject:[currentExporter name]];
return array;
}
Like I said, Objective-C is a little bit different in terms of syntax. If you understand programming in any language, you should be able to decipher this code from its variable types and methods. Apple has a great book on the Objective-C language that any new Cocoa developer should become familiar with. It will not only explain syntax, but Objective-c specific feaures such as categories.
With a solid foundation in the language, you can start learning about the various Cocoa classes. Become familiar with the methods and features of some of the frequently used classes. This is just a small sampling, but its' a good starting point.
Step 2: Use The Tools, Obi Wan
The second part of the success formula involves knowing your tools. You need to have a firm understanding of how Xcode and Interface builder work. The best way to get that understanding is to just use the programs. There is no replacement for real-world experience.
The learning curve on Xcode is somewhat steep because it is such a powerful tool. Luckily, Xcode includes an excellent manual in the Help menu. It will teach you about several of the features in the application that you will want to become familiar with. Read the topics for understanding and then try and use them.
Interface Builder's learning curve is not nearly as steep. Aside from dragging interface objects onto your windows and panels, the only other difficult thing is understanding all the options in the inspector. You can read about all of these in Interface Builder's manual as well.
Learning the graphical tools is not the end. If you want to be a successful developer, there are a few more tools you need to become familiar with. The main one is the debugger, gdb. No application exists without bugs, but gdb will make it much easier for you to squash them. Once again CocoaDevCentral has a great article that can give you a quick introduction to the power of gdb.
In Xcode there is a debug menu. Under that menu, you will find many options dealing with gdb and a menu called Launch Performance Tool. This is where you can run your application in Shark, Sampler, MallocDebug, and ObjectAlloc. The coolest of the four is Shark.
Shark is a performance optimization tool that helps you identify where your application could use improvements. It searches for bottlenecks in your application that could be improved. This is a tool that you will want to take advantage of after the initial development of your application. Any code that is not optimized to perform the best it can should not be released. Apple has written an excellent tutorial on Shark that you should read.
The other three applications have their uses as well. Sampler is for examining the way your application runs, MallocDebug is for finding memory leaks and ObjectAlloc is for watching how memory is allocated in your application. You should become familiar with all four of these applications.
Step 3: Become A Jedi
Having knowledge of core Cocoa classes and how to interact with the developer tools is essential, but without any experience applying the concepts you know, they won't do you much good. Because of this, the only way you will ever succeed in developing for the Macintosh is to actually make something. It doesn't matter what you make as long as you learn something from it.
When making something there are a few things to keep in mind.
You should create something that you will use. If there is a tool or utility that you wish there was on the Mac, make it. If you are designing something that you want to use, you will go the extra mile to make it accomplish everything you want and need. You need to eat your own dog food.
Also, the biggest thing you need to keep in mind is that you need to finish the project. If you get stuck, ask for help. Make friends with other developers who are willing to help you. If you can't find help from them, there are several other resources you can take advantage of in the developer community.
If you follow these suggestions, you should be in good shape. There are a few more resources we should cover though.
The Cowboy's Book
Christians have the Bible. Cocoa Developers have Aaron Hillegass's book, Cocoa Programming For Mac OS X. This is the book that taught me Cocoa. It gives every new Mac developer a great foundation through its instruction and projects. Aaron is a great teacher and makes complex topics seem accessible. Even to this day, I use the book for a quick refresher on topics that I have not dealt with in a long time.
The second edition covers Mac OS X Panther, but it is still very much relevant for Tiger and beyond. Though not announced, I am sure a third edition will be released in time to cover new Tiger-specific topics.
Aside from the Hillegass book, there are several other Cocoa books that we hope you may find useful:
- Cocoa Programming by Scott Anguish, Erik Buck, and Don Yacktman.
- Programming in Objective-C
- Learning Cocoa with Objective-C
- Building Cocoa Applications
I own all four of these books and they have their benefits. Head to your local bookstore and thumb through each of the books and see if they will be useful to you. Keep in mind that these books may not be nearly as up-to-date as the Apple Developer Connection website. The benefit of books is that they make the topics more accessible because they teach them to you.
Rescue 911
Every developer runs into trouble at one time or another. Knowing where to find help is essential to resolving your problems. There are several Apple-sponsored help solutions as well as community-driven solutions. Taking advantage of the benefits of each will help you become a better developer.
The main source of information is the Apple Developer Connection. ADC is home to up-to-date documentation and sample code. ADC posts new content almost everyday that is beneficial to the developer community. Just recently, they posted all of the information on the Mac OS X Tiger technologies like Core Data, Core Image, and Dashboard.
The Developer Connection also has a membership program. These membership programs give you access to developer seeds of beta software, support from Apple engineers for your code and access to the development labs in Cupertino. The most useful of these is the code support. If you are having trouble finding a solution to a problem in your code, you can send a support request to an Apple engineer and have them help you with a solution. For more information on Apple Developer Connection memberships, visit their website.
A solution available on your computer is the library of sample code Apple provides with the developer tools. Looking at others code is a great way to learn how to implement things. You can find the code in the /Developer/Examples/ folder. Apple has divided the folder topically so that you can search through it easily. If you are using Spotlight, you can find examples even easier. Just type the topic you are looking for information on and Spotlight will give you results.
The final Apple sponsored resource is the cocoa-dev mailing list. Apple hosts several mailing lists on its site. These lists allow groups of like-minded users to gather and dicsuss a topic that interests them. The cocoa-dev mailing list is very active with discussion of beginner and advanced topics related to Mac OS X development. You can usually get your question answered relatively quickly at it.
Before submitting a question, you should search the archives of cocoa-dev. Every message ever posted to the list is available on the CocoaBuilder website. While the people on the cocoa-dev list are happy to help you, it can be frustrating to have to keep answering the same questions over and over. If you do a little bit of research and show initiative before posting your question, your question will be much better received.
The final resource you should take advantage of is the Cocoa wiki. Run by Panic Software's Steven Frank, the Wiki lets Cocoa developers from around the world create a great reference for developers. Not only does it contain hints and tips on the Cocoa classes, but it provides sample code on certain topics that developers commonly implement. If there is a topic that you need help on, create a page on the wiki and watch as the other developers help you build it.
Go Forth Young Soldier
After reading through all this, you should have a fairly decent grasp on how to get started with your OS X development and where to get help when you get stuck. Now what? Get your hands dirty anyway you can. Contribute to some of the open source Macintosh development projects like Cocoalicious or Adium. You can also start your own project if you have a good idea. Either way, just write some code.
If you want a few more tutorials to go through, Apple has a tutorial on its website that is great for teaching a few of the basic principles of Cocoa. The Currency Converter tutorial is available in two flavors: bindings and no bindings. Run through the no bindings tutorial first. Once you begin working on the bindings tutorial, you will respect what they offer to Cocoa developers even more.
You won't learn these topics overnight, so try not and get too frustrated. Programming is not easy, but it is very rewarding. Have fun learning these new technologies. The feeling of shipping your code to thousands of users is great.
If you have any tips or advice for the novice OS X developer, leave them in the comments.
Justin Williams is founder and chief author for MacZealots. He switched to the Mac almost five years ago hasn't looked back since. When not blogging or coding, you can find him watching copious amounts of TV. Justin can be reached at



Reader Comments (31)
DISCLAIMER: The views expressed below are those of their authors and not necessarily endorsed or supported by MacZealots.com. In all cases, the comments provided here are offered as a courtesy and will be moderated. Any content deemed off-topic or offensive will be removed without notice. Posting a comment here boils down to two things: 1.) Think before you type 2.) Respect the thoughts of others. See our commenting guidelines and/or privacy policy for more information.
#1) On May 6, 2005 4:26 PM
About a few weeks before Tiger came out I started getting dissapointed because I saw some real potential with dashboard widgets but thought “I’m not a programmer I cant make anything” but then I found out if you can build a website then you have the basic knowledge to build one. Now I’m about a week from releasing my first widget and couldnt be more excited and the whole time I have been thinking about how great it would be to start developing OS X software, but I didnt know were to begin so THANKS! I’m going out the the bookstore tonight and starting!
#2) On May 6, 2005 4:46 PM
A great introductory article, Justin!
The only thing missing is a link to CocoaDev, though it’s mentioned in the body text.
#3) On May 6, 2005 5:08 PM
Great overview. i’ve been dabbling with RealBasic but I think I’ll try and give Cocoa a college try. Thanks!
#4) On May 6, 2005 5:24 PM
Great article. I disagree on one thing, however:
While there are many crappily-designed user interfaces on Windows and Linux, there are quite a few on the Mac as well, one egregious example being Quicken for Mac, which is quite an abomination in terms of both UI and performance.
At any rate, developers who “spend days or weeks slaving over their interface” can be found working on many types of systems, not just Macs. Designing a good user experience is central to writing good software no matter where it shall be used.
#5) On May 7, 2005 2:06 AM
java: write once, debug everywhere
#6) On May 7, 2005 2:19 AM
If you don’t like Objective-C syntax, you can write your Cocoa apps in python using the pyobjc bridge. This makes cocoa programming the absolute bee’s knees!!!
#7) On May 7, 2005 3:35 AM
RubyCocoa and F-Script are some of the other available bridges. The later even lets you explore the Cocoa object tree and any running Cocoa application with the help of an interactive object browser.
The best thing is that a bridged scripting language is usually on par with Objective-C in terms of performance and you can mix optimized C code later on if you need speed.
#8) On May 7, 2005 3:59 AM
Scott Peterson said:
While there are many crappily-designed user interfaces on Windows and Linux ….
Totally!!! Like that new music thingy on Windows, what was it called….. iTunes or something like that??? What a piece of crap. What were they thinking? I bet the Mac has something way nicer….
Just kidding… ;)
In truth, it’s pretty cool. Just couldn’t resist heckling a bit.
#9) On May 7, 2005 5:37 AM
Foobar suggested “java: write once, debug everywhere”. This used to be true but hasn’t been for some time.
I’ve followed java for five years and have had no problems with java transitioning across platforms. “Write once, debug everywhere” did used to be true of the awt interface system that Sun endorsed for writing applications in java 1.1 and referred to the way that the interface would render significantly different on a Windows machine than it might on a mac. However - swing was introduced to remove these problems in the java2 release in 1999. There were performance problems with swing, however these were resolved in the 1.4 release. That was three years ago.
Java is a fantastic language language to develop for. The bundled libraries are powerful. There is a huge range of third party libraries. The virtual machine lets you do things with threads and distributed computing that would be far more compicated on most systems. It is an elegant abstraction (as compared to something like Windows programming where you are encouraged to operate through wizards and thick layers of confusing macros). On the macintosh you even get automatic intergation if you use the right libraries thanks to the work Apple. And the language is easy to develop from basic tools like the command line and your editor of choice if you’re that way inclined - you’re not compelled to use a particular IDE in the way you are with many platforms.
When I’m working on java products, at the end of the day, I can copy the project from whatever platform my employer supplies (Windows until recently, my new company is on linux) on to my laptop (mac), work on it on the bus, and then continue at home on my linux workstation without any complication. Consider how much “debug everywhere” you’d have with most platforms in that situation. With python you’re more prone to library complications. With basic C applications you may have compiler problems and are likely to have library problems. With Cocoa or MFC you wouldn’t be able to do it at all.
Cocoa’s pretty cool in its own way though, and I agree with dan-h that the python bridge is exciting (if only I didn’t have such a taste for strongly-typed languages! :( ).
#10) On May 7, 2005 6:31 AM
Well, I’m a “recent switcher”. I do use Visual Studio to develop my game products on Windows, and I do use Xcode on Mac.
Why develop on Mac? Well, with less than 5% of the market share (as the article claims), I make just over 50% of my sales on MacOS X. It did take effort to make “real” Mac applications and not just quick ports of PC games; the games were planned from the start to work on both platforms and then were adapted to MacOS specifics like Apple-Q and bundling. I can say first-hand that for a business like mine, it’s really worth the effort, both in terms of sales and in terms of satisfaction: the Mac community of gamers is fantastic. I get e-mails all the time suggesting valid features. Even support e-mails are very courteous.
I was already familiar with gcc on linux, so Xcode was a breeze and is a welcome addition to working with gcc, that sorely lacks on other platforms now that I got addicted to it.
Best regards,
Emmanuel
Cartoon-like mini golf game for mac: http://www.funpause.com/gardengolf/
#11) On May 7, 2005 10:08 AM
What about C++? Remember, Xcode uses GCC for compiling and linking.
#12) On May 7, 2005 11:12 AM
“With Microsoft, you have to pay to make software” - this is not true anymore. Microsoft has released their C++ compiler for free some time ago, although it doesn’t have any GUI. It’s available from http://msdn.microsoft.com/visualc/vctoolkit2003/. The article also doesn’t take into account the availability of other free C/C++ compilers such as Intel’s C/C++ compiler or GCC/MingW. There is also the DevC++ IDE. Not to mention Python, Java, C# and other languages which can also be used for free on Microsoft’s platform.
My personal opinion is that once you learn to properly write software, it doesn’t really make a big difference what platform you are using. It’s easy to write portably with all the appropriate portable libraries available.
#13) On May 7, 2005 11:40 AM
Yeah, but Objective-C is the ugliest language I’ve ever seen. I have my choice of about 20 languages on Microsoft, Isn’t there anything else for Mac OS?
#14) On May 7, 2005 12:33 PM
Wayne said:
Yeah, but Objective-C is the ugliest language Ive ever seen. I have my choice of about 20 languages on Microsoft, Isnt there anything else for Mac OS?
Yeah, of course there is.. you can develop in C/C++/Java/python/Ada/RealBasic/Fortran/Pascal/COBOL and many many more.
Obj-C is the best if you want to write applications that can fully utilise all the lovely things that the operating system supplies.
#15) On May 7, 2005 1:56 PM
Don’t discount RealBasic as a very viable, powerful, and easy-to-learn development system. It’s fully OOP, has a really, really nice IDE, and lets you develop very rapidly. It certainly has been a source of a lot of crap, but that’s the case with a lot of easy-to-learn languages/tools (PHP is a very good example of that). In the hands of people who actually know what they’re doing, it’s a really nice option.
#16) On May 7, 2005 2:17 PM
Carbon seems to be very ‘satanized’ in the apple world but to be frank, it’s easier to learn it than start with objective C (which is not learnable in 1 afternoon). Now, granted, Cocoa gets some bonus but nothing major. The article also feels like Carbon is a dead or mostly dead API which is of course not true. It is developped in parallel with cocoa (i bet than both shares the same code base). Also Objective C has some performance hits due to its architecture (that’s why most of games are still done in C) which could be annoying for some kind of applications.
#17) On May 7, 2005 3:36 PM
“Carbon seems to be very �satanized� in the apple world but to be frank, it�s easier to learn it than start with objective C (which is not learnable in 1 afternoon).”
Maybe for you but for me, since having no experience in programming, and learning straight from C to C++ then to Java, and lastly Cocoa/ObjectiveC, I have to say the feeling was that I was getting to a better way of doing things with each progression. In fact, I got a hold of Objective C far faster than with C; about an afternoon was all that was needed to understand it.
TBO its really the frameworks that take more time to learn than the language.
Carbon is OK, but it doesn’t let you subclass apples’ “Opaque” objects, which is a real downer.
#18) On May 7, 2005 8:31 PM
Brilliant. I’ve been waiting for something like this for a long time and I’ve just bought Learning Carbon and Learning Cocoa. A great threesome!
#19) On May 7, 2005 10:32 PM
I’ve been wanting to program something on my Mac ever since I bought it. So after I write something
in RealBasic I’m going to try to learn Cocoa. Thanks for this info. Also a big thanks to Apple Computer
I truly hope the new OS brings them back to the forefront of personal computing.
#20) On May 8, 2005 1:21 AM
Many thanks for this article, I’m currently a Computer Science FInal Year student at Uni and writing a thesis on “The Conceptual Representation of Video Mosiac.” What this basically is is a video version of photo mosaics (www.photomosaic.com). No one has really attempted this before apart from a group of people at Princeton and Microsoft. At the beginning I was really tempted to develop on the Mac but was intimitaded by the learning curve of Xcode and Objective-C (I’m competent in C but have never dealt with video input and ouput streams in the language). So I chose Matlab the language. Big mistake, although my algorithm is more or less bruteforce, it only has to compare pure numberic data. Even with this it takes me 1hour to analyse 1seconds worth of data.
Now if I had had this article at the beginninng of my project and also tiger was released then, I would be able to implement my project in a much faster language and also used many Core * techniques to help with computational power (XGrid anyone??).
Once again, many thanks for this article!!!! I won’t be able to port my program to Cocoa in time for my thesis hand-in but hopfully I will be able to port it in my own spare time. MANY THANKS!
#21) On May 8, 2005 12:29 PM
Danny Wan: if you have Tiger, you might want to try out something new with the developer tools called Quartz Composer. It’ll give you an idea of what those Core technologies can do, and if your algorithm is sufficiently simple (just numerically intensive), you might even be able to implement it in time. Also, XGrid isn’t quite what it’s made out to be (my own simulation algorithm is too tightly coupled to use a grid model, so I would have to use something more like MPI on a fast network).
#22) On May 22, 2005 5:44 PM
Another good starting point to develop software on Mac OS X is Perl (man perl; learn.perl.org). The great thing with Perl is that it is seamlessly integrated into the Unix subsystem of Mac OS X. Running shell scripts from Perl scripts is no problem at all (cf. system in man perlfunc). And to give your Perl script a Cocoa touch you may use such GUI design tools as cocoadialog.sf.net.
#23) On May 22, 2005 6:04 PM
Thanks Justin, after 8 years of using Macs (only) you’ve piqued my interest in programming. But as I have no experience (apart from creating websites, mostly in Dreamweaver) first things first: in the article by Scott Stevenson that you link to he says he assumes the reader has a little knowledge of php. I think this is where I’ll start. Can you make any similar recommendations as you have above but for php, particularly a good book to get me started? Thanks.
#24) On May 24, 2005 1:35 PM
I’m a software developer and mac user who writes exclusively for Windows. I started picking up software development for the Mac a while ago, but hit the dual walls of not really understanding, or liking, Objective-C (It’s two — two — two syntaxes in one!) and not really having any good ideas for what to write.
Now that I have the latter (a program to index removable media for Spotlight searches even when the disk isn’t inserted), I’m willing to put more time into the former. This article has provided me with positive jumping off points…thanks!
(Incidentally, I’ve found that using my mac afterhours has seriously increased my passion for decent interfaces with my daily work. I’ve started making EVERYTHING drag-drop capable, started using a lot of colour and imaging, and keep having to prevent myself from ripping off the Drawer concept.)
#25) On June 3, 2005 7:18 PM
Nice intro, I’m a Win32 / C++ / MFC developer who may soon be managing the porting of a couple of Windows apps to the Mac and this helped me understand the Carbon vs. Cocoa differences.
Two questions other n00bs may have, since C++ is the langauge of choice for most non-Mac commercial application development:
1. Can Carbon be used in a C++ application, as the Win32 API can be in Windows?
2. For Cocoa, are there any automated C++ to Objective-C filters out there? How reliable are they?
#26) On June 14, 2005 5:16 PM
Justin, thanks for this wonderful article. It is very informative.
Any comments on Code Warrior? - good or bad.
#27) On June 14, 2005 6:12 PM
Code Warrior BAD BAD BAD. No support for Universal Binaries, so at the moment it’s obsolete. Whether or not that changes in the future remains to be seen.
#28) On June 16, 2005 3:31 PM
I doubt that Codewarrior is anything but obsolete on the Mac. They sold their Intel compiler and Apple is going to drop Freescale chips in short order. The rate of progress on new versions of CW has been glacial before this announcement. Don’t put any more investment in this compiler, it’s gone baby.
#29) On June 21, 2005 8:31 PM
I don’t like the Code Warrior too. The keynote made clear that porting a Carbon app to ix86
is going to be significantly more difficult than porting a Cocoa app
especially if that Carbon app is being maintained under CodeWarrior
as so many legacy Carbon apps are.
#30) On July 29, 2005 12:38 AM
Many thanks for this article. It’s useful for getting started. However, I have a specific need - I have a multi-platform application written entirely in C++. However there’s no Mac OS X version, and that is highly desireable for this program.
I have lots of experience in UNIX and Windows environments, but am having problems getting XCODE to work nicely with the C++. Are there specific tricks to port such code to XCODE?
Note that the program involves 3-D computer graphics, and currently has a GUI developed on GLUT and OpenGL. Since these are available on Mac, I’m hoping that much of the GUI work will also compile and run. Then I can make update the GUI do Aqua as a separate task.
Any hints will be appreciate.
#31) On December 21, 2005 3:30 AM
I am very confused to get XCode to work with C++ too. I am learning to become a programmer for OS X in my own time by reading books. I have written some very simple C++ programs that compiles in Xcode, but it does not produce useable binary.