• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: question


  • Subject: Re: question
  • From: Karl Kuehn <email@hidden>
  • Date: Tue, 2 Sep 2003 14:49:00 -0400

I think before going any farther you are going to have to decide/tell the list which route you are going to use to mac a "native MacOS X" application. Your basic choices are:

Obj-C Cocoa: considered the most "native" MacOS X application. Basically non-portable to any other operating system (not completely true... but good enough for this conversation).

Java Cocoa: you can use your understanding of the Java language and library of java code, but the interface is done with Apple's classes, and you often use Apple frameworks because they are available. Can be slightly more portable.

Carbon (MacOS X only): In this form of Carbon you get to use your old code, but re-fit it with many of the new technologies in MacOS X: Core Graphics, Large Files, New Frameworks, ObjC++. Problem is, it will not run in MacOS 9.

Carbon (Compatible): This is the route that many of the big name apps have gone (more or less). It is using a subset (loosely defined) of the old Macintosh Toolbox, and is almost always a C or C++ application. You get to run on MacOS X or 9 and get the memory protection in 10. But you miss out on most of the other advantages.

AppleScript Studio: Small applications written with snippets of AppleScript, often used to glue other small tools together to get some work done. Very easy to make an interface to a faceless background application (and looks and behaves like a MacOS X app... because it is one). Useable only on MacOS X, and there are some caviets as you look at different versions of MacOS X.

Cocoa bridged applications: These include a number of other languages that are bridged to Cocoa, language such as Perl (CamelBones), Ruby, Python, etc. These applications usually are written to allow already written applications in those languages a nice GUI in MacOS X. These are semi-native.

These are the big, "native" choices. Then you get a bunch of other choices:

Unix apps. Here I am grouping all of the command line and X11 applications that have been ported to (or written for) MacOS X. The command line group includes some massive applications such as the Apache web server, and as small as shell scripts. And there is a similar range in the X11 apps with the GIMP topping off that list for me.
These applications don't generally have a nice Mac look or feel to them, but are very powerful tools available on MacOS X.

Java applications: very cross platform, but there are some performance issues when it comes to user interface, as well as not having the same look and feel of a MacOS X app.

QT, WebApps, Revolution, etc.. there are a whole number of small cross-platform methods of programming that are available. Each with strengths and weaknesses.

Classic Applications: as the name implies, classic MacOS 9 applications that don't directly touch hardware. They work, but with all the down sides of MacOS 9.

Now... care to ask the list a more specific question?

Karl Kuehn
email@hidden

On Tuesday, September 2, 2003, at 01:00 PM, Tehrani, Henry wrote:

I am creating a native application under OSX and have some problems that I
did not have under OS9.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Prev by Date: Running NSStatusItems At Startup
  • Next by Date: Re: plug-in problem
  • Previous by thread: Re: question
  • Next by thread: Re: question
  • Index(es):
    • Date
    • Thread