Apple Launches Reference Library

andy55 writes "If you thought Apple's online dev resources were already the best out there, they just got better. Apple has announced the launch of their new ADC Reference Library. Named features are: powerful search options, added navigation, 'Getting Started; docs on key technologies, and a more consistent organization. Impressively, the first search I ran in their search engine on a painful Mach-O dev issue I've been fighting for the last week turned up the key obscure tech info I needed!" Meanwhile, skrysakj writes "Apple has launched a new Reference Library. I always thought their help/references for Developers was spotty (either non-existent or dead on) so this should be a welcome change."

Paranoid

[Anonymous Coward]

Even though I have no prior reason for distrusting Apple, I get the feeling that eventually this information will be accessible to developers paying a premium rather than those of us who signed up for the free account.

Anyone know if the ADC is going to replace the current /Developer/Documentation that comes with OSX? 6 years ago I used to sit and while away the hours reading man pages and HOWTOs in Linux, and since I bought a PowerBook I find I'm doing the same kind of thing with their docs which I have locally installed. The ADC (that's Apple Developer Connection, not the monitor connector ;) looks awesome, but a local, offline copy would be even better.

I guess I could always buy a printer...

Re:Paranoid

[Anonymous Coward]

after looking at the way the directory is set up, maybe you could try wget

good for beginners

[bodrell]

Apple has done everything in their power to make developing software for OS X as easy as possible. There's the tutorial for the "Currency Exchanger" program, to get started with Project Builder, and there is always to option to throw together a shell script if the whole build process is too scary.

I don't know shit about programming, but I'm learning. And having a bash shell, with actually useful commands, is really helpful to that goal. So many people don't understand the appeal of a command line, or think that you have to pick a nice GUI or a nice CLI, but that's bullshit. Someone actually asked why I would care about the GUI if I spend so much time with the command line. It seems obvious to me--I can carry on everyday operations with apps familiar to me, but can craft more and more complex helper apps/scripts in my free time. Much simpler than rebooting into Linux when I feel like experimenting, then getting frustrated that I can't burn a CD because the procedure is too complex and having to reboot into a more idiot-proof OS. I welcome any enhancement that makes development easier for the ignorant (like me), and avoids rebooting.

Oh, and I don't want to hear anyone try to compare Windows' cmd.exe with a bash shell. I do use the Windows command line, but it's a total cripple compared to any UNIX shell. Sure there's Cygwin and Mingwin (or something like that), but they aren't very integrated.

Things I miss.

[BibelBiber]

Some of the things I miss from ADC is that documentation updates that seem to be on a regular basis are not downloadable. I don't have access to the net all the time I develop so it would be nice to have it completely offline. As well a search function would be nice. I have it aliased in my apache so a simple php search would be convenient.

cmd.exe or bash? Hrm. 3+3 = 2+4

[mactari]

Boy, if this isn't a case of, "I know what I know," I'm not sure what is. But then I just said that. ;^)

Folks, it's all zeroes and ones. All we're really talking about here is running & interacting with programs from standard input and reading from standard output. I imagine you could gentoo together a nice, bare version of Linux that had as few (or many, as your half-filled glass may appear to you today) applications available as there are by default in Win2k.

Personally I quite enjoy cmd.exe and use it as much as I do the Terminal (or iTerm or X11 with xterm (with an "&" no less)) in OS X. You can get vim [vim.org] running from cmd.exe very easily with syntax highlighting and full integration with the Windows clipboard.

To sum quickly, I can... change active directories, view directory contents, copy, delete, & move files, edit text, create scripts, call any app I want, interact with anything that has a standard in/out interface, print, schedule repeated/timed tasks, reboot other machines on your network, find & replace strings in files, and install any app I dang well please from either cmd.exe or bash or tcsh or whatever you prefer.

And hey, in any event, it's a far cry better than the command line in Mac OS 9-. (Which, for those who didn't know, you could get in the Mac Programmers' Workshop (MPW), but sure wasn't installed by default.)

One thing that's missing

[Anonymous Coward]

Apple documentation does not specify what goes with which version of what operating system, nor does it mention what other dependencies use might entail. Microsoft documentation always states clearly which function calls require what - and what OS. Developers can adjust their code accordingly and at least leave the user with 'graceful failure', ie 'Sorry, this application requires Microsoft Windows blah-blah and Internet Explorer 14.0.'

The Apple stuff does none of the kind. Oh it's there all right - it's just not exported/documented properly. There are so many quirks in this development environment that what usually happens is that users see a bouncing icon and then it disappears. They have no inkling of what went wrong - and the developers don't either. All anyone knows is 'this doesn't seem to work with OS X version blah blah', and that's not good enough.

It's a mess, because adding instance variables to a class in either the Foundation Kit or the AppKit is going to screw up the offsets to the class methods, and if the client (application) is prebound then you can get lots of nice stuff like crashes and that.

So what do you have, for all the ease of use of Cocoa? You get forced to provide different builds for different versions of OS X, are never sure exactly why the one works and not the other, nothing is properly documented - you're walking on ice all the time.

And identical code built with identical compilers on different boxes with different resident versions of the operating system produce different application behavior despite their executables being identical - figure that one out. But it's happening all the time.

Apple need to explain what is going on. They can and must do better.