Slashdot Mirror

Yes, I develop apps for both platforms. Both OS X and iOS are brand names for an Apple-augmented version of Darwin—a POSIX-compliant UNIX OS. It's the same OS with a different face.

They share so much that they even use the same drawing layer. In Linux terms, that would be sort of like if Android ran X Windows, and it was the same flavor of X Windows as Ubuntu. (In fact OS X and iOS share way, way more than Android and Ubuntu.)

The biggest difference is between OS X and iOS is obvious: the UI. The reason for the difference is also obvious: one of them is touch-based. The UI layers (think window managers) are named AppKit and UIKit, and they share many similarities. Many of the APIs are nearly identical.

About the only thing they don't share is binary compatibility, because iOS is made for ARM as opposed to x86. However, this is not a technical hurdle; Mac and iOS applications are designed to handle multiple architectures. Technically, Apple could allow Mac applications to include an ARM64 binary, or iOS apps to include an x86 binary. Practically, the differences in input devices wouldn't be ideal, so Apple hasn't done it yet.

But make no mistake; it's the same OS, and they could ship truly Universal apps tomorrow. In fact, there's currently a rumor circulating that Apple wants to consolidate slightly, and produce MacBook Air notebooks running ARM. Given the performance of the 5s, they may be on to something.

Disclaimer: I'm an Objective C Programmer by day

The LLVM compiler suite is tremendously powerful with Apple's billions advancing many select features, but key to it's success from a users prospective the core use of reference counted object graphs (of type 'id') and reflection (RTTI - via 'isa' and 'Class'). Obviously this means the entire language is dynamically typed at runtime, but with express qualification in 99% of the code you'll use there's absolutely no performance hit despite the ubiquity of the core object.

I worry that many C programmers will remember RTTI was once considered an unportable disaster in C++ because of the the many differing implementations owing to a spec that left the implementation up to each compiler... Don't let this kind of talk scare you! Although objective, objc is contained to a well defined spec, single inheritance and nary a template in sight.

I consider my programming work to be relatively easy. 50% of my ease comes from the object system above. The other 50% from the fast messaging system used in place of raw ADTs: In the objc world a nil object doesn't fault when messaged (in a C world dereferencing a NULL pointer, common if a struct fetching function fails and then passes NULL on failure) leads to all manner of crashes, or as seen recently, kernel exploits. The messaging system can even push around primitive values, not just nasty objects.

If you program in C, you may have missed Automatic Reference Counting, if you have, low and behold, it's amazing: at *compile time* the compiler adds lifetime qualifiers to the IR that automatically inserts retain and release messages (retain is +1 on alloc, -1 on dealloc - release occurs at 0). In other words the lifetime of an object in objective-c is now exactly the period of acquisition to last use. Yes, last use. ARC's use of a new 'weak' reference means that dangling pointers are a thing of the past: a __weak object is automatically nil'ed after last use: in all local instances of that object (did I say nil objects don't fault on message?).

Admittedly most of what I've mentioned is thanks to the advances in LLVM's Clang compiler, in particular it's static analyser, therefore much objc analysis also benefits C (LLVM's IR is quite specular ).

I could go on: methods can be heap objects with cblocks, objc encourages abstract programming with delegates, you can method swizzle at runtime, extend existing classes and link to C/C++ code.

But I'll grant you any day that Obj-C could do with some modernisation, in particular w/r to namespaces.

In the end namespaces are very little more than appending more characters on a name. You can get most of what namespaces do just by adding a unique string to part of your class name. Yes, there is a possibility for clashes if someone chooses a string which is the same as yours but how often do people use outside classes other than the ones in the Cocoa frameworks?

At best there should be some sort of prefix directory where developers can register their class prefixes and make sure that they have a unique string. Apple already uses NS and CF so most developers know do avoid using them.

Here's some good reading on the topic:
Cocoa Style for Objective-C: Part I
ChooseYourOwnPrefix

I'm sorry to hear that. I use FPC for my 'amusement' coding quite a bit, having been a huge TP fan back in the 80s and early 90s. FPC is some fun stuff.

Glad to hear that :)

Incidentally, the whole C++ library name hashing issue (that was my understanding of the issue), that prevented use of things like wxWidgets with FPC appears to have been conquered at some level. Or am I interpreting the Obj-C interface wrong?

C++ and Objective-C are quite different beasts. The main problem with interfacing with C++ is that there are about as many C++ ABIs as there are C++ compilers (and then some, since a C++ ABI can change when a new version of a C++ compiler comes out). This concerns name mangling, but also VMT layouts, exception handling, etc. In general, you cannot even use C++ code compiled by different compilers together. A person has been working lately on adding support for the current G++ ABI to FPC though, and simple class importing and (non-virtual) method calling already works.

For Objective-C, there are basically only two ABIs: NeXTStep/Apple's and GNUStep's. Currently, we only support Apple's (we do support it on all Mac OS X platforms though, both past and present). And we also created an Objective-Pascal dialect around it.

Yeah here's the API. http://www.cocoadev.com/index.pl?ABAddressBook

I use the API in a couple of my apps actually to allow the user to select an e-mail contact.

What the hell do you think I/O Kit is written in?

A subset of Embedded-C++.

There's probably an interesting story behind why that one library is C++ when practically everything else is C or Objective-C, including its predecessor...

There are many resources available for iPhone/Cocoa programmers. The earliest versions of Cocoa shipped commercially in 1988, and the most used features and patterns haven't changed much. Here is a good place to start: http://www.cocoadev.com/index.pl?CocoaPrerequisites

Why does Objective-C use BOOl and YES,NO instead of bool and true/false? One reason is that Objective-C predates the addition of the bool type to standard C by 11 years.

If you don't like dynamic languages, you won't like Objective-C. Bruce Eckel makes an interesting argument for dynamic languages at http://www.mindview.net/WebLog/log-0025.

I think the ability to seamlessly use and intermix the world of C and C++ software with Objective-C outweighs and criticism that Objective-C includes C.

You must keep an open mind - There are an infinite number of different ways to solve every programming problem. Many programming languages and reusable software libraries use different approaches to solve common problems. There is a good chance that Objective-C and Cocoa use a substantially different approach from other languages and frameworks you may have used. That doesn't make either approach better or worse automatically. Every commercial software development technology has advantages in at least some cases or the technology would not exist. Cocoa is renowned for enabling very high programmer productivity without constraining the set of problems that can be solved, but programmer's opinions will always vary and software development environments are subject to aesthetic judgments irrespective of abstract technical merit. Many programmers are enthralled by Objective-C and Cocoa. You might be enthralled too. Or, you may never like Objective-C and Cocoa from an aesthetic standpoint, and there isn't really anything anyone can do to change that without affecting the aesthetics for others.

Here's what I got, so far. Sorry it's not tabbed and cross-referenced...

http://ask.slashdot.org/article.pl?sid=08/09/17/224230 -- in case anyone wants this page, too
http://www.quickref.org/
http://gotapi.com/
http://www.regular-expressions.info/ -- regular expressions
http://www.perlmonks.org/
http://www.rosettacode.org/wiki/Main_Page
http://perldoc.perl.org/
http://www.perlbuzz.com/
http://java.sun.com/reference/
http://forums.sun.com/index.jspa
http://developer.mozilla.org/ -- javascript
http://www.w3.org/MarkUp/Guide/
http://www.w3.org/MarkUp/Guide/Advanced.html
http://www.w3.org/TR/html4/
http://www.w3.org/TR/xhtml1/
http://www.w3.org/Style/Examples/007/
http://www.w3.org/Style/Examples/011/firstcss
http://www.w3.org/Style/CSS/learning
http://en.wikibooks.org/wiki/Programming:Tcl
http://www.acm.uiuc.edu/webmonkeys/book/c_guide/
http://cprogramming.com/
http://www.cplusplus.com/
http://cm.bell-labs.com/cm/cs/cbook/
http://www.parashift.com/c++-faq-lite/
http://en.wikibooks.org/
http://developer.apple.com/
http://cocoadev.com/
http://www.cocoabuilder.com/

Almost 300 replies and no mention of Objective-C ?

developer.apple.com - Apple documentation, good reference but sometimes lacking in details
cocoadev.com - Cocoa wiki
cocoabuilder.com - Cocoa mailing list archives

"you insist on writing everything in horrible languages like Objective-C and AppleScript to hideous APIs like Cocoa and Quartz. Makes it hard to port Apple crap to other platforms, you know."

It's actually fairly easy to write Cocoa apps that can be ported to Linux and the BSDs via GNUStep (it has a few extensions to Cocoa, but these can be installed on Macs without the rest of GNUStep). It doesn't support AppleScript, but Objective-C is part of GCC (which Apple themselves use), so there isn't any need to install extra compilers on Linux / BSD systems.

"Unfortunately, Apple refuses to support nice languages, like Python, Smalltalk, or C#"

Apple doesn't need to support everything itself. Here's a list of Cocoa bridges for all the languages you list, as well as various others you didn't mention:

http://www.cocoadev.com/index.pl?CocoaBridges

"or nice APIs, in order to keep the Macintosh platform separate and proprietary"

Apple support POSIX, X-Windows, and OpenGL (to name but three), none of which is proprietary, and as as GNUStep proves, there's nothing preventing third parties from writing Cocoa-compatible systems for other platforms. After all, why should Apple do all the work when Open Source supporters keep telling the rest os to write stuff for ourselves if there isn't a FOSS solution that does what we want?

Apple's documentation is wonderful..... if you already know Objective-C. It is pretty bad otherwise. Okay, It's really horrible otherwise, and not that great if you do.

I tend to use http://www.cocoadev.com/ more than anything else. You really should do the basic Apple Currency Converter tutorial first though, as it walks you through the interface. In general, trust the C that you know, but throw out the C++. Things tend to be done with a different approach, so if you can find other code that does a similar thing, the C part of your brain will understand it, but the C++ part will get angry. Eventually, I realized that the C++ part of my brain was also extremely masochistic, so it became easier to ignore it.

Did that help at all? More than anything else, just jump right in. Build and test often, and have fun with it.

As a current Mac OS X developer (somewhat) active on http://cocoadev.com/, I can tell you that iPhone development probably won't be significantly easier than OS X, particularly not from being a "smaller" environment. The existing iPhone framework is much like the existing OS X AppKit framework, and they use the same Foundation framework underneath. An iPhone app seems like it would take about the same amount of code but would be harder to get right, as in feel like an iPhone app. On a concept-based PDA like this, an app's UI has to be one of the most important things the developer does, not an afterthought.

I would guess that the only thing that would make writing iPhone apps easier is the fact that the really simple, stupid, everyday apps haven't been written already. So for a while anyone will be able to put their product out on the market and have a pretty good chance of success, rather than being overshadowed by existing giants.

By the way, Objective-C still seems to be the language of choice for native Mac OS X and iPhone apps. Reverse-engineered "documentation" of the iPhone's UIKit framework is available on http://cocoadev.com/. Still, all the existing ObjC bridging technology on OS X will probably work on the iPhone as well...but developers will have to take into account the greatly reduced processor power.

As a current Mac OS X developer (somewhat) active on http://cocoadev.com/, I can tell you that iPhone development probably won't be significantly easier than OS X, particularly not from being a "smaller" environment. The existing iPhone framework is much like the existing OS X AppKit framework, and they use the same Foundation framework underneath. An iPhone app seems like it would take about the same amount of code but would be harder to get right, as in feel like an iPhone app. On a concept-based PDA like this, an app's UI has to be one of the most important things the developer does, not an afterthought.

I would guess that the only thing that would make writing iPhone apps easier is the fact that the really simple, stupid, everyday apps haven't been written already. So for a while anyone will be able to put their product out on the market and have a pretty good chance of success, rather than being overshadowed by existing giants.

By the way, Objective-C still seems to be the language of choice for native Mac OS X and iPhone apps. Reverse-engineered "documentation" of the iPhone's UIKit framework is available on http://cocoadev.com/. Still, all the existing ObjC bridging technology on OS X will probably work on the iPhone as well...but developers will have to take into account the greatly reduced processor power.

You could try something like: this.

The "designated location" is actually one of several: /Library/InputManagers/ or ~/Library/InputManagers/. In other words, it doesn't take special privileges to make an InputManager bundle active on a given system for a specific user. You do have to have admin privileges to place the bundle into /Library/InputManagers/ so that all applications executed by all users are touched, but that's it.

Objective-C lets objects of one class "pose" as objects from another class. Posing is like dynamic subclassing; method dispatch happens against your class first and then on up to the original class if you didn't implement it or if your method specifically calls the "parent." This is where code injection comes in. You write a new class that poses as some class in the application and intercept the calls; your code starts executing.

Figuring out the application's classes isn't difficult. A free utility like class-dump can be used to grab an OS X application's class and data structure definitions, and from there it's easy write your own posing classes. Lots of bugs arising from injected code is due to sloppiness on the part of the programmer, and some of it is due to an InputManager modifying an application's data at the wrong time (which is easy to do, because the application rightfully believes that it owns its data).

I was going to write something about the security issues this entire scheme raises, spelling out how a nefarious programmer could hijack passwords and the like. I'll leave that to your imagination, though.

Shameless plug: While I didn't use APE, I did use InputManager technology in order to create Concierge (a bookmark manager for Safari, in the form of a drawer).

I would say that Apple would be better serve their own self interests by writing an application compatibility service for Windows XP

Agreed. In fact, Dockapps (usually called Docklings) are being deprecated in newer versions of Mac OS X. There were quite a few Docklings in 10.0 and 10.1 (including SlashDock), but there's very, very few Docklings left for 10.2 and later.

This article at CocoaDev has a tutorial on making Docklings. Really easy.

Dockapps aren't exactly the same as Docklings though, it seems... they have animated icons. Doing that is very easy as well, you just call NSApplication's -setApplicationIconImage: method every second or so. I don't need a framework for that.

This is actually a great time to discuss this with Xcode 2 on the horizon. Xcode 2 is the newest version of Apple's free IDE that comes with their developer tools and can also be downloaded from Apple Developer Connection [Free Registration Required].

Along with GCC4.0 and new UML-graphing utilities, this next revision that'll be available on the 29th looks like it's really packing some enhacements.

I've been using Xcode 1.5 (the current iteration) to work with Cocoa Objective-C (see above for tons of info on the language) and coming from a platform neutral C++ and PHP background have found it very intuitive, and if coded correctly Objective-C is a pleasure to use. I can say that Aaron Hillegass' book Cocoa Programming For Mac OS X is a great utility, along with CocoaDev and Cocoa Dev Central.

Good luck!

Visit these sites:

CocoaBuilder for the Mac OS X and Cocoa developer list archives.

CocoaDev is a Cocoa developer Wiki.

I find that 99% of the questions I have can be answered by these two resources (especially newbie type questions -- which you're bound to have in a new development environment.)

-ch

Pretty good links. I found the tips and tricks on the CocoaDev Wiki invaluable in my work on the Objective-C port of FIT.

You'd be suprised how many computers still exist out there with Windows '98, or even Windows '95, or in some pathological cases Windows 3.1.

In fact, I think that in the Windows world, it's safe to say that the OS is the _least_ important part. It's there just so the applications will load. We'd run just as happily (or actually happier) without any OS, if the same apps could be booted directly without an OS. Hence, the lack of Windows people creaming their pants at the thought "woo, we can pay for a new release."

So in a nutshell that's why we're wondering about it. Because over here on this side of the fence, sticking to an OS for 4-5 years is really the norm. Seeing people getting all excited at the thought of buying yet another yearly remake of the same OS is, well, a bit strange.

So, pray tell, just for my curiosity: _what_ applications didn't work with the old release? Was there some killer-app or killer-game announced that requires Tiger to run?

Is there some much needed functionality comes in this release and was sorely missing in Panther? I'm just, you know, curious.

It looks like Tiger will be great for Cocoa developers, with many new powerful APIs covering new functionalities. And, indeed, CoreData looks very promising. I found more info about it here.

More info on core data can be found on CocoaDev

Because there was no documentation, this is a hack. He had to reverse engineer the protocol and build a client which worked without any documentation or reference implementations or any of that, so it's definitely a hack. But it isn't a crack. He didn't defeat any cryptographic or DRM system (which also means that the DMCA is a non-concern). What happened was that there was an undocumented cryptographic protocol and he wrote a client which implemented it. I applaud him, but calling it a "crack" is just plain old bad reporting. Keith Irwin

"Ours will be just like Apple's, only better."

Xcode? ahem, Visual Studio.
Appleworks? ahem, Office. (arguably, Keynote is nicer than PPT)
Pippin? Xbox ;-)
Newton? PocketPC or Smartphone ;-)
WebObjects? ahem, ASP.Net.
iSync? ActiveSync.

I could go on and on. There are definitely some things that Apple does better than Microsoft: Mac OS X is a lot nicer to look at than Windows XP in many respects. Apple definitely has a certain mystique and cool-factor to it that MS does not have right now. But to categorically dismiss the software that Microsoft produces is shortsighted at best. Heck, just in terms of documentation for software development Microsoft does tons better than Apple. Secret APIs? Apple has 'em in spades. Go take a look at all of the work people have done to reverse engineer their method prototypes on CocoaDev. MS used to have private APIs in Win32, but that hasn't been the case since the consent decree.

The evilness of MS is greatly overstated ;-)

http://www.cocoadev.com/index.pl?AutoReleasePool

http://www.macdevcenter.com/pub/a/mac/2001/07/27/c ocoa.html

http://www.cocoadev.com/index.pl?FileID

He's right on target about developer training & documentation. It sucks big-time: poorly categorized and there is lots of missing information.

When I'm looking for an answer to a technical problem, I typically find answers at sites like Mamasam or CocoaDev. The Cocoa Dev Central site is a good source of sample code, too. Many more resources are listed here

Historically, Mac developer's have been very picky about this: Inside Macintosh is wonderful. It's an excellent technical reference presented in a consistent and easily readible format.

I tried writing a utility to keep an icon to show when I have mail. The SystemUIFramework that is used for DockExtras and MenuExtras is in fact private, which means that there is no usable header file against which to link an application. However, some intelligent hacker has created a SystemUIPlugin.h that works, but there is basically no documentation other than that file.

There is a public header in the AppKit framework (NSStatusItem.h) that will allow you to create an icon that is displayed in the menu bar while the application is running, but this isn't how Apple's icons (like battery, volume, etc.) work: they directly use the SystemUIFramework.

Reference:

• NSStatusItem documentation
• Instructions for getting a header file from a private Framework(sorry, couldn't find the actual .h file with Google)

Apple was going to release a version of Cocoa for Windows called Yellowbox that would be free. That way developers could write Cocoa apps and be assured of a large target market by bundling Yellowbox for Windows customers. When the iMac started selling gangbusters, Apple quietly killed Yellowbox for marketing purposes.