The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

interface for mac os x

i would to develop application for mac environment.
how different it is from create desktop app for windows?
im clueless on this matter....
newbie ash
Wednesday, November 30, 2005
Do you have a Mac?

You'll need to use a Mac regularly for a little while to really get the feel for how its applications should be designed.  If you just copy Windows paradigms and paint brushed metal and Aqua on top of them, it won't fit in with the workflow everyone's accustomed to, and nobody will like it or buy it.
Marco Arment Send private email
Wednesday, November 30, 2005
I tried to look into a dev environment or dev communities like for the mac and it all looks absolutely dismal. Macs are beautiful but Apple seems to be based on the idea of doing most of their own development for major applicaitons (except for Microsoft Word for Mac, and Final Cut Pro). They do provide development tools free, but overall Macs seem more like appliances than PCs and I saw no sign of active communities or source code examples. I know there are smaller 3rd party products for the Mac, many of them free somehow. I don't get it really and I hope someone who knows more responds here.
Anon and anon
Wednesday, November 30, 2005
anon - I've only dabbled a bit into the OS X development community, but I can say that you're mostly (fortunately) incorrect.

There are fewer code samples and tutorials out there, sure.  There are far fewer Mac developers than Windows developers.  But it seems like you haven't really put much time into your research on this topic - it seems like you're looking for a quick reason to dismiss OS X as a platform.  If that's your goal, that's fine - no reason to waste time on something you don't want to be doing.

But if you're genuinely interested, I suggest getting this book:

Play with Cocoa and Objective-C for a weekend.  See if you like it.  Personally, I think the square-bracket-crazy syntax is awkward and I don't like the way memory is managed in Objective-C, but the Foundation classes and built-in OS X libraries are comparable to the .NET Framework (and better in many ways) in breadth and usefulness.
Marco Arment Send private email
Wednesday, November 30, 2005
There are some books out there, specifically I've looked at an O'Reilly about developing for Cocoa.  That, plus the free dev tools, should be enough to get you started.
Windows Developer
Thursday, December 01, 2005
OS X development is a fantastic experience. Be shure to pick up the book by Hillegass, it'll get you up to speed. There are tons of good articles / tutorials at and the mailing lists at are a helpfull resource, too.
Matthias Winkelmann
Thursday, December 01, 2005
There is a very vibrant shareware and 3rd party application community for the Mac, but due to Apple's smaller marketshare you have to make a stellar product to be successful.

Mac users also seem to have high expectations than Windows users if they are going to pay for software.  They expect the application to not only look as good as the rest of the good Mac software out there, but to also be very, very cool.

Want good examples?

Adium (this one is free, and still the best IM client for OS X)
Delicious Library

I've also actually found that the Mac community seems more willing to shell out $20 here and there for small software apps if it's good enough compared to Windows users.  This just seems to be inbred into general Mac culture.  Like the apps listed above, there just seems to be a nice set of "Must Have" 3rd party apps for OS X that people are more than happy to spend money on.
Thursday, December 01, 2005
This site:

Covers a lot of the differences between OSX and Windows.  It isn't just the colors and skins... it's a whole huge UI difference.  Buttons are placed in different orders... they have different names.

Here is a good example of the differences in dialog buttons:

Apple has a human interface guidelines PDF that might be worth reading if you can find it.  It is called OSXHIGuidelines.pdf

I don't remember where on Apple's site I found it though...
Eric D. Burdo Send private email
Thursday, December 01, 2005
One thing you will need to get used to is that Apple has a set of human interface guidelines for Mac OS X.  Applications that don't follow it, stick out like sore thumbs and in a bad way.

Microsoft in contrast allows developers to pretty much define their own interfaces (check out the variety of skins for Windows Media Player).  There are advantages and disadvantages that I'm not going to get into here.

Back to Apple.  All Apple computers (so far) ship with one button mice which means you cannot assume a user will be able to easily left and right click.  The reason for it is because Apple wants to discourage developers from developing context menus (right clicks on Windows), which means you are limited to clicking buttons/icons, drag and drops, and menu commands and their keyboard equivalents.

As an example, if you wanted to copy a file to a USB key, there are three ways to do it out of the box on Windows - drag, "send to" and copy/paste.  Apple very strongly emphasizes the drag, omits the "send to" entirely, and keeps the copy/paste around only because if you can copy/paste one thing, you should be able to copy/paste anything.

That is the hardest part of developing for Mac OS X, simply getting used to the Apple way of interacting with the computer (which IMO, makes for a far cleaner, easier and more consistent interface).
Anonymous Coward
Thursday, December 01, 2005
Anon and anon: I just don't see grabbing code snippets from a web site as being part of the Mac developer style. At least not for Cocoa developers. If you look at something more accessible to novices -- REALbasic -- you'll find a strong community around that.

Keep in mind that the Mac is like an appliance and users have very different expectations, including beauty, minimalism and streamlined productivity. Few Windows programs are developed with beauty as a key goal (!) but you'd better think about it when making a Mac app, because Mac users can smell an un-hip app a mile away.

Due to the small market size, it is harder to make a living as a Mac ISV, and that means the people doing it are really passionate about it.

Recently Daring Fireball had a great article about being a Mac ISV:
Nate Silva Send private email
Thursday, December 01, 2005
To start with motivation, here is a talk by Wil Shipley of Delicious Monster, the makers of Delicious Library:

The book "Cocoa Programming for Mac OS X" gives a solid introduction to the essentials. It assumes that you know quite a bit of C, though. More information here:

For your other needs, the best places to start looking are Cocoa Dev Central, CocoaDev and Cocoabuilder:

Once you get the basics, you'll find Apple's documentation easy to follow, though not always perfectly complete.

How is it different? There are two APIs to choose from, the procedural Carbon and object-oriented Cocoa, of which I've dabbled with Cocoa. Cocoa is rather opinionated and wants you to use the MVC paradigm. This makes getting started slightly harder than in many Windows programming environments, since somewhat more advanced concepts are necessary to get any results at all. Copy-and-paste programming and 5-minute hacks are much easier in Delphi and Visual C++, for example.

Once you have a firmer grasp of Cocoa, you'll see that things start to click in place much easier than in Windows. Cocoa does quite a lot for you, especially if you use Core Data. Saving and loading documents, my least favorite part of writing an application, becomes trivial in Cocoa.

Next you want to get off the beaten path, and this is where it gets slightly tricky again. You'll want to override parts of default Cocoa behviour without affecting badly the rest of them. This is not impossible but requires care.

Overall, I prefer Cocoa over Delphi and .NET. What I'd like to see eventually is OpenStep for Mono :)
Aapo Laitinen Send private email
Thursday, December 01, 2005
"All Apple computers (so far) ship with one button mice"

This is incorrect. All Apple computers ship with four-button mice that have a two-dimensional scroll wheel.
Friday, December 02, 2005
"Apple wants to discourage developers from developing context menus"

Context menus have been part of the Mac OS since OS 8.6, about 8 years ago. I guess you've not seen a Mac since the Mac Plus? Really strange that you think yourself qualified to give an opinion about Mac development.
Friday, December 02, 2005
Scott, you're being too harsh. Though Apple doesn't really discourage the use of context menus, they "strongly recommend" that the commands there should be also accessible by other means. The poster got his rationale wrong, but he was reflecting a common sentiment. I would argue that an application that requires the use of context menus to achieve efficient operation doesn't have the feel of a genuine Mac OS application.
Aapo Laitinen Send private email
Friday, December 02, 2005
"The reason for it is because Apple wants to discourage developers from developing context menus"

No, you've got it backwards. The reason that Apple ships one-button mice is that multi-button mice are confusing to many users, especially those new to computers. My experience doing phone technical support bears this out. Some users aren't clear on the function of the two mouse buttons, and of those users a surprising number don't know right from left.

Developers are discouraged from relying on context menus because they are not discoverable, especially to users with a one-button mouse. Many Mac applications use context menus, but I've never found a case where the context menu is the only way to perform an operation.
comp.lang.c refugee
Friday, December 02, 2005
Apple doesn't follow the UI guidelines when developing Windows applications. Look at iTunes and Quicktime. Both of those apps act like Mac applications even when run on Windows.

Why should Windows developers take the time to figure out how to do it the "Mac way"?
Wayne B Send private email
Friday, December 02, 2005
Oh yeah and Objective-C is a horrible, horrible language.
Wayne B Send private email
Friday, December 02, 2005
@Scott: Discouraging doesn't mean "force them not to use them". Yes, Apple has had context menus since the early nineties, but they discourage developers to rely on them. In their own applications, there's always a second way to do it without the menus.

Personally, I prefer context menus since it reduces the way my hand has to move. For example, in adress book, there is no "delete contact" entry in the context menu. Instead, you have to use the menu bar.
Friday, December 02, 2005
OK, that's probably true that context menus are not supposed to be the only way to do things, but I think that's true for Windows also.

I say probably because if you examine the context menu on the Finder's Desktop, I think the entire last section can only be accessed through the context window. Or click on a file or group of files and right click and you'll see all sorts of fascinating functions from creating archives to starting slideshows that can not be accessed from the Finder in any other way. So, Apple itself doesn't seem to follow what you are saying are Apple guidelines. Maybe those guidelines were true some years back, but I thik that was a while ago.
Friday, December 02, 2005
It was a while back.  I just reread portions of the Apple Human Interface Guidelines and the specific section on context menus in chapter 16, section 5 no longer makes reference to one button mice.  It's quite probable that they've gotten rid of it ever since they started selling Mighty Mouse.  Possibly sooner than that.

Yes, I worded it badly.  Apple discourages you from making context menus, but doesn't prevent you from doing so.  There's a lot of useful things in the context menus as Scott rightfully pointed out.  The point I wanted to make emphasize is that you should think a little more about how you want the user to perform actions, when you're writing software for the Mac.  Want another example?  The typical way of deleting an application on a Mac is to simply drag it into the trash can.    You can use a uninstaller, but you should not assume the user will use the uninstaller.
Anonymous Coward
Saturday, December 03, 2005
"Apple discourages you from making context menus, but doesn't prevent you from doing so."

I think thats still wrong, they dont 'discourage' it at all, they just dont want it to be the *only* way to achieve something..the idea being that unless the user knows to look there, they will never discover that functionality.

Apple have no problems at all with context menus, they just dont agree with the random way they are used on the windows platform as 'somewhere else to put new features'
Jesus H Christ
Sunday, December 04, 2005
To answer the original question, it's quite similar really.

You have Interface Builder, which comes with the free Xcode development tools. That's the form designer with drag and drop widgets. Xcode allows you to hook that up to Objective-C and Java code in a similar fashion to Visual Studio. As Aapo noted it does try and enforce MVC methodology but that's the only real difference. The latest Xcode even supports such things as dynamic code and data structure diagrams updated realtime whilst you develop.

You can get Eclipse if you prefer for your Java.

If you want the absolute closest experience to the Visual Studio way of doing things then most VB developers would feel instantly at home with RealBasic 2000, which can cross-compile to Linux and Windows (with native controls) and even has in inbuilt SQL database engine - and your whole code has *no* DLL's even on Windows.

In essence, you can drag and drop to create your forms and tie the code into the background just like on Windows. It's all quite familiar (but a little bit nicer looking).
Karl Cartlidge Send private email
Wednesday, December 14, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz