Technote 2034 is one of the most ridiculous things I've read from Apple. As a Mac developer I find it insulting to what I've done, and my mind is blown by what it advocates. Whoever wrote this policy statement should be fired. > Binaries should be Mach-O. That's nice to know. > Mach-O code gets the most efficient access to all Mac OS X technologies and the best possible integration with system software. Code that isn't Mach-O doesn't. I know that. There are many ways around that, and those of us who actually care about our customers enough to give them the best solution we can will use them. > You now have all the tools to move to Mach-O. Why, thank you for caring. As if the only reason we haven't moved to Mach-O is lack of tools. (Which, by the way, is still true. Project Builder is pathetic compared to CodeWarrior, and CodeWarrior's Mach-O support is so bad I have to do debugging via printf()s.) > If you have a Carbon application that you want to run on both Mac OS X and Mac OS 9, you should package your application as a bundle that contains a CFM binary optimized for Mac OS 9 and a Mach-O binary optimized for Mac OS X. Oh, come on. Some of us actually _care_ about the sizes of the downloads that we offer. Some of us actually have to _pay_ (gasp!) for bandwidth. > Avoid using resource forks Wow, the magical advantage over Windows is bad. Saving app-specific data in the resource fork so that the data fork can hold plain data (e.g. window positions in a text file, previews in a jpeg file) is bad. Crock, crock... > Mac OS X is intended to be an excellent Web citizen And Mac OS 9 was an excellent Web citizen. What am I missing here? > Use file extensions Mandatory file extensions isn't funny. Why must I put metadata into the file name? It doesn't belong there. Hiding the extensions is a solution, but that creates other huge problems, like multiple files with (what appears to be) identical names. > Your application may use type and creator codes as an additional means of document typing, but extensions are essential May use them? Come on. A small percentage of the files that I create actually leave my computer. The rest live on my hard drive peacefully. Proper document binding _requires_ type/creator codes, and the statement "may" only encourages lazy Cocoa developers to not bother, saddling me with their problems. > Carbon pays attention to the underlying volume format and shields your application from volume format specific issues. Good! Then it should shield me from the fact that not every volume format can hold the metadata that I expect. Oh? > But in turn, your application needs to be a good citizen and avoid writing out meta file information Crock, crock. 99.44% of my users are running HFS+ drives. 99.44% of their files will never leave that hard drive. To tell me not to use the metadata that provides a clean Mac experience is ridiculous. > Investigate using path-based file-system APIs OK, I did. I don't like them. They're fragile, unwieldy, and provide a bad user interface. Oh, I'm supposed to agree with _your_ opinion on them? > All other mechanisms, such as FSRefs and FSSpecs, are built on top of paths and therefore incur some performance cost. Maybe you don't, but I've always been willing to sacrifice a few milliseconds here and there to provide a better interface to my users. Any developer who isn't willing to make that trade-off shouldn't be writing code for the Mac platform. > Additionally, you can pass CFURLs around without incurring any I/O cost until the moment disk access occurs. Omigod, disk access is holy. I'm sure that the I/O required for dealing with FSRefs will absolutely dwarf the I/O of the demand-paged virtual memory system. > Be judicious using C++ for new development Ah. You're right. I should be using a platform-independent language to make sure that my investment in time and effort isn't wasted. Hmmm. Where do I find an Objective-C compiler for Windows? > C++ specifies a number of language features that are not universally supported across different compilers. Yeah, so you have a shitty compiler? Upgrade. Any compiler that can't handle the C++ standard shouldn't be used. CodeWarrior ranks pretty well in that regard. gcc/Project Builder doesn't. > Exploiting all the features of C++ in your code can make porting your software to new platforms and new compilers difficult. Where you must use C++, be careful to restrict your use of the language to the absolute basics. Crock, crock. If you use non-shitty compilers, your language use can be as verbose as you want without a problem. Technotes are supposed to deal with "complex issues related to programming for the Mac OS". I want to give my customers a great user experience. This technote does not give any advice on programming the Mac OS, only a laundry list of things to do that would definitely hurt the ease of use of my apps. This technote is a joke that should be withdrawn. I'd be embarrassed to be caught doing any of these practices. You should be embarrassed for promoting them.