Also, remember that anything you find offensive does not represent the views of Unsanity. They are my views and my personal opinions based on my personal observations. Dislike me because of them if you so desire.

[Digg This] (but comment here).

The sad thing about this entire troll rant informative article is that I've been working on this off and on for two months. Most of the delay has been due to other priorities or researching things for this article. I really wanted to order a 17-inch portable ICBM when I finished with this post. However, it is now too close to WWDC and there's no way it would ship to me before then. I can't buy one at the Apple store either because the Apple store doesn't accept/offer the developer hardware discount. So now I'll be going to WWDC with a laptop that has a busted shift key, among other problems (read the Support:Hardware section below).

Due to the sheer length of this post and the fact that most people won't read the entire thing due to its length, I've written this thing in sections. Each section has a header and sub-headers. You can easily use these to skip to the portions that may interest or amuse you. But please, please, do not read the "Suggestions to Apple" sections without reading the entire section they pertain to. The suggestions to Apple sections are written to be completely in context and are not standalone.

With that said, I really wanted to post this before WWDC. I didn't want people to get the impression I was simply being reactionary to something that just happened. I can also be reactionary to stuff that happened well over a year ago. So there!. I make quite a few comparisons to Microsoft's developer relations in this post. While I have been a member of Apple Developer Connection for over 7 years, I have very little experience with Microsoft's developer stuff. What I do know about it I've only learned by browsing Microsoft's website. However, if I get anything wrong about either, please correct me. The things I say about Apple's various developer programs are based primarily on my own personal experience and may not be anywhere near what other people may experience. And no, I don't actually expect anyone from Apple or Microsoft to ever read this post. This blog just isn't that famous (or infamous).

It's All in the Family or There's Nothing we can't Face… Except for Bunnies

The entire Macintosh development community is like a huge family with the Apple software engineers (née programmers) being the nuclear family. Whereas some unnamed (*wink*) small third party developers are treated more like that weird relative that shows up at family reunions. The other family members all avoid this person due to the vicious rumor that they only come to the family reunions to flirt with and try to pick up the other family members. Even though no one in the family has actually seen me talk to the other family members, they still avoid this person. The avoidance only fuels and gives credence to the rumors. "See, they're all alone over there because they keep hitting on their own family members." It becomes horrible cycle of rumors with not a single person actually witnessing the event. I guess the same goes for repairing permissions. MacFixIt started the rumor, which got passed around the Mac "technical" community. And each time it was told from one person to another it was changed ever so slightly to make the person listening more likely to believe it. Purple Monkey Dishwasher. The anecdote made a full circle back to MacFixIt eventually and they used this as "proof" of what they were saying was true. Even though they're the ones that said it in the first place!

Hmm. Incest>Repairing Permissions>Sheep>MacFixIt. Something is missing. Usually whenever I am involved in or start a conversation implicitly or explicitly mentioning incest it eventually ends up that I start talking about the awesomely awesome awesomeness that is the CoreText API. I wonder what happened this time. The only reason incest comes up "often" is because I am extremely interested in the battle/opposition between things inherent to the system (genetics) and acquired knowledge (mind) and things such as GSA and the Westermarck effect are good examples of this battle in play. It is also why the idea of genetic memory interests me so. This battle really makes me hope the children of Britney and Cletus can overcome their genetics. If humans have any kind of genetic memory, it would better explain those that believe they were someone else in a "former life". Then again, if the ancient Egyptian rulers really were Goa'uld, that'd explain that genetic memory if they interbred with humans. Ack, ok, I need to stop there. I've gone from Incest to Repairing Permissions to Sheep to MacFixIt to Britney Spears to the Goa'uld.

My conversations usually flow like this though. Someone will be arguing about the object-oriented nature of C++. This leads to a conversation about pig-farming which then leads to a conversation talking about how someone has been repeatedly impaled in the foot with pitchforks or repeatedly stepped on nails. Actually, I guess the transition from C++ to "nail in foot" is actually quite logical. A better example would be someone talking about the recent incident in which a Dell laptop caught on fire leading to someone asking if the placenta is acceptable food for vegans. This is actually a rational flow of conversation. Can you guess how?

Okay, I really did have a point to all of this. Namely that the entire Mac development community is like a family. Each developer is not completely estranged from one another. Most Mac developers are extremely approachable. In fact, many of them will give other developers help. This goes double for Apple software engineers. The far majority of them are very nice, helpful, and all-around good people. Although there are a few that constantly curse. Almost as if every other word is a curse word. It's not directed at anyone so there's no need to be personally offended. It's just that they've likely been dealing with C++ for so long that they don't even realize they are cursing at all. This is yet another reason I love going to WWDC. (The direct communication, not the cursing.) I can talk to fellow developers and don't have to worry about filtering marketing-speak (such as various forms of the word "productize"). Heck monkey, even Steve Jobs keeps the marketing-speak in the WWDC Keynote to a minimum (but only compared to his other keynotes and speeches) I am definitely not saying that the same isn't true for Microsoft employees. The ones I've had contact with have been extremely nice. However, being primarily a Mac developer, I have no idea what avenues to explore when I would like to talk to a Windows developer. Then again, I often have no need to contact them. But it is nice when the option is there.

Communication is Key or "It's a Feature, not a Bug. So STFU"

Lists and Forums

That brings me to my next point: Developer Communication. This is also where the post gets a little more negative. The kind of negativity I am known and loved for... Apple has excellent and fabulous mailing lists developers can subscribe to to get answers to various questions or answer questions other developers have. Many of these lists have active involvement by Apple employees (and most often this is on their free time, to boot). Microsoft, on the other hand, has MSDN Newsgroups. Some of these newsgroups require a paid membership to access, however they have guaranteed responses. Personally, I loathe newsgroups. For one, there is the massive spam problem mentioned on that page. Secondly, the majority of Mac newsgroup clients appear to be designed for sex-perverts and do not appear to have discussions as a primary feature. Microsoft also has something called MSDN Forums. I hope Apple never goes this way. There is one exception which I'll mention later. It's extremely difficult to search online forums if you do not have internet access. With Apple's mailing list, each post gets saved directly to my hard drive and is searchable anywhere, whether it be on a plane or whether it be under the sea. Furthermore, Apple is known for deleting posts (last line) that say negative things about Apple. Developers in general (such as LH, RK, and MC) are extremely negative by nature when something doesn't work. Their negativity does not hamper their helpfulness at all, it would just be something Apple Corporate probably wouldn't like and would strike from the record.

Granted, I've never used the Microsoft side of things, but just because Apple and Microsoft have means for developers to ask the community for help does not mean you'll get an answer. In fact, there is no guarantee (from Apple at least) that the posts will even be read. Some of the more "technical" questions I've asked in the past have gone completely unanswered. There are some very, very noticeable surprises, however. Sadly, most of the font-related questions I have go completely unanswered as well. No matter who I ask.

Some of the mailing lists Apple hosts have a list mom that have a no tolerance policy to off-topic posts. By off-topic I mean things like asking about something on the BSD level on a mailing list dedicated to CD Burning or asking about the best way to communicate something, such as an error, to a user. I don't mean completely off-topic like talking about politics or religion, which isn't tolerated on any list. A notable exception is asking how to convert a Muslim calendar date to a Buddhist Calendar date. The tolerance level varies greatly between lists. On some lists, the list mom will complain if there's anything even remotely off-topic. Some "odd" list moms won't even allow asking about determining if a IOKit device reference belongs to a writable CD drive on a CD Burning mailing list, referring you to the IOKit mailing list.

The complaint usually involves an email about how you're spamming the list and to take it elsewhere with no actual suggestion on the elsewhere to take it. Then another email follows almost monthly making an assertion that off-topic posters waste hundreds of dollars for each off-topic post they make. Not sure what marketing school that train of thought is from (probably the same school of marketing that says college students are responsible for seven bajillion dollars of lost sales due to music piracy), but whatever. Especially considering that almost everyone gets tens to hundreds of maliciously sent real spam emails a day. One or two off-topic posts is barely a dent. The only exception for allowed off-topic posts on this particular list is saying positive things about the list mom's day job. If it is negative, you're told to contact Apple off-list.

Granted, I may be taking it just a little bit personal and may be just a little bit spoiled by other lists. For example, one of the mailing lists tolerates almost anything off-topic, assuming it relates to the Mac OS. I really like this method as it allows angry developers to blow off a little steam in a mostly constructive manner especially since other developers chime-in and describe how they have worked around the issue or how they've dealt with it. Then the topic usually never comes up again as everything that could be said about it has been said. In which case, they're just pointed to the list archives. I guess in these cases you're either seeing the same off-topic subject brought up 10 times with 2 posts each (one for the beginning, one for the end of thread notice), or you have it brought up once with 15 posts. Still other times these off-topic threads result in a "mass" of bugs being found in the system when they may not have otherwise been found. However, I've only seen the latter actually once. It is by no means the norm.

Suggestions to Apple: Stay the course. I currently like the mailing list system a lot and find it far more accessible than the forum or newsgroup system. The Apple employees that frequent the mailing lists are usually responsive (except when it comes to fonts...) for most people. And I have nothing but absolute and utter respect for them and I owe them quite a lot. They make the mailing lists extremely nice. My policy is not to name names for good things people do, so I'll give them all hugs at WWDC or teach them never to look the same way at soft-boiled eggs again or something.

I'd guess it'd be super-swell if some mailing lists had less "pissy" list moms, but as I stated above, the perception I have of these list moms may be entirely subjective and based on personal experience. One thing that I seem to remember about the MSDN Forums is that they have employees of each group lurk the forums and respond to any unanswered questions. Apple could benefit from such a policy on some lists.

Bugs: Microsoft

Anywho, Microsoft's Connect allows users/developers to file bugs on software they are participating in the development of. Pirates are not permitted to file bugs on beta software (such as Vista) using this channel. If you haven't joined a product program, you get the default options for filing bugs on products currently out of beta that were released around the debut of the Microsoft Connect site such as SQL Server 2005 and Visual Studio 2005. If a product was released before that, I have no idea how to report a bug. Some people seem to largely imply it isn't possible unless you're a super special customer.

Assuming that the product is available to the public on Microsoft Connect, their bug reporting is very interesting. Basically, you click on the product you wish to report feedback on from the "Available Connections" link, search for the pre-existence of the feedback (which is a nice touch), and, if no results are found, file a new bug report.

Let's go back to the search for a second. Microsoft actually allows you to search all existing bug reports for an "available connection" (does MS have to have marketing come up with names for everything?) that were not explicitly marked as private by the reporter of the bug. I think that's extremely awesomely awesome. For example, this bug or this bug in Visual Studio 2005. I chose both for the amount of comments and the fact they were still open. But as you can see, both have public comments from the creator and public comments from Microsoft. The creator of the bug in the former actually got quite livid. I appreciate this a lot.

The point is, not only can the reporter of the bug clearly see feedback on the bug, the general public can as well. For programs (like Vista) that are not available to the public, anyone that is a member of the program can also view all bugs marked as public for that program. Someone actually made some pretty graphs based on the public bug data for Windows Vista. How sweet is that? Although it does show a slight case of major OCD. Oh well.

Filing bugs using Microsoft Connect is free. Presumedly, as are all the program memberships that are offered via Microsoft Connect. However, membership in the betas require either an invitation of some sort or you need to request membership via a link on the Available Connections page. In order to login to Microsoft Connect, you need a Windows Live ID, which is free. It was formally called Microsoft Passport but appears to be have been renamed by marketing to distance it from the failed "single sign-in" idea that Microsoft originally planned Passport to be. However, a Windows Live ID will sign you into almost all sections of Microsoft's website that require a free sign-in.

Bugs: Apple

For the love of all things holy in this world and the next, if you're not a developer or just filing a general feedback item on an Apple product, use the Mac OS X feedback form (which also has links to the feedback forms of other products).

Now, on the other sad hand, we have Apple's bug reporter which has two advantages over Microsoft's: it covers all products Apple makes and has been around much, much longer. In order to sign into Apple's bug reporter, you must have an ADC Account. The online account is free and can be had by going to the ADC Member Site. If you have a .Mac account, you can login using your .Mac email address and password. ADC will then ask you if you wish to join using that account. Otherwise, you can click "Join Now" to create a new account. The ADC Member login can be used every where on Apple's site. From the online discussion forum to the iTunes Music Store. Once you have an ADC Member login, head on over to Apple's RadarWeb website (also called the Apple Bug Reporter).

Once you have an account and have logged into RadarWeb, just click on the "New Problem" link near the top. Filing a bug is pretty straightforward. The hardest part is choosing the component. Like, if it's an iTunes or iChat bug, do you choose "iApps" or "Mac OS X"? It's all pretty ambiguous once you get down to it. Either way there are about 50 brazilian components in Mac OS X and choosing "Mac OS X" doesn't exacly narrow it down. I've started prefixing my bugs with the title of the component such as "Fez", "Finder", or "Processes.i" depending on the component I think the bug belongs to (I am often wrong, which probably makes the limited choice of components a good thing). It really, really, really, really helps if you can upload a simple Xcode project that clearly shows the problem in the smallest amount of code possible if this is an API bug. Apple allows files up to 50 megs to be uploaded along with a the bug report. Microsoft allows up to 200 megs. But I don't think that really matters.

Bugs: Apple, Feedback (or lack thereof)

Once a bug is filed, the happy people at devbugs (or something) shift through the bugs and actually forward them to the correct team/component... or so the rumors on the Internets go. You will likely never see any kind of feedback whatsoever for most bugs other than "Behaves Correctly, STFU" or "Duplicate". If there is any feedback required, the feedback from the Apple software engineer first goes through a DTS/devbugs "filter" to remove excessive profanity, changes internal references to external ones (e.g. "MacBuddy" to "Setup Assistant") and to clean it up for the person reporting the bug. Unlike Microsoft Connect, the person reporting the bug doesn't get to see any comments from the people working on fixing and/or ignoring the bug at Apple unless their feedback is marked as "public" and goes through said filter. So if you get a reply as completely clueless as "There's no way to track files as they move," do not blame the messenger. The name you see on the email you get saying you received feedback from engineering on the issue is not the name of the person that sent the feedback.

This disappearing bug problem has become a huge issue for me, personally. When I log into RadarWeb and click "My Reported Problems" I only see 123 bugs listed. I've filed way more than that. If that number scares you, realize that most of those bugs were documentation bugs, font bugs, feature requests, me intentionally filing a duplicate bug, or me being dumb. And sometimes I swear I've filed a bug before but have no record of it whatsoever because it "fell off" the listing. Some of these bugs that disappeared I'd really, really like to know the current status of them like that bluetooth menu extra bug (since I spent so much time reversing the problem). There doesn't appear to be a consistent rhyme or reason why some bugs disappear. Some have speculated that closed bugs disappear after an amount of time, say six months. However, I've got some closed bugs that I've filed six years ago that I can still view.

Notice how I said I have intentionally filed duplicate bugs there? According to various people in Apple and other people, bugs/feature requests/whatever are assigned a priority of sorts based on how many duplicates there are. For example, if a thousand people file a bug requesting a CFLog() function, then it is more likely that a CFLog() function will actually appear. (I do think that there have been over a thousand requests for that function but it still isn't public as of Mac OS X 10.4.7.) However, as I just implied, more duplicates do not mean any particular thing is going to change. Especially when it's a management decision from on high that they have no intention on changing (see Metal). It's up to the person in charge of the component to escalate it. Oh well, I've been told to file bugs even if they're duplicates so I will continue to do so unless someone tells me otherwise. And since there's no search mechanism even for your own bugs, you have no way to tell if a bug is going to be a duplicate unless you were told so beforehand.

A good example of people using the "power of duplicate reporting" for evil is the Mac Maintenance Quick Assist document. When it was first brought to my attention, I was pissed off at its very existence for some odd reason. Much like the reaction to Technote 2034, mine was initially overblown to the Quick Assist document. So I waited five minutes and took some deep breaths, then filed my bug. I tried to be calm and mention point by point what I disagreed with. A lot of other developers did as well (either by filing a bug on the "Documentation" component or by clicking on the feedback link in the article). Amazingly, just a few days later the article was updated. Although sadly it still recommends the useless virus option and for some reason says "make a backup and delete the original". If you have only one copy of something, it isn't a backup, is it? Oddly enough, the bug I filed is still marked as being open. However, I guess that my particular bug had nothing to do with the change.

Now, let's say that you've filed a bug and/or feature request that wasn't marked as a duplicate or closed as "Behaves Correctly, STFU" as odd as that may be. In the rare case someone at Apple makes a comment on your bug such as, "your callbacks are wrong. Correct them and it works as documented," and the comment is marked as external (sometimes engineers write comments meant to be external but forget to mark them as such), then you'll probably get an email from devbugs saying that they have received feedback from engineering on your bug. A relatively recent addition to RadarWeb is the fact it also marks in red and bolds any bugs that have such feedback. Usually, I've received an email at the same time this reddening has happened. Other times, if the bug is left for red too long without being read then devbugs will fire off the email. I guess it'd be better if Apple put the bugs that needed attention at the very top of the bug listing in a section above your filed bugs since it may not be noticed if it isn't on the first page of the bug listing. Perhaps I should file a bug requesting that...

After you've made a comment on the bug in response to Apple's external comment, even if your comment is just, "OMGWTFBBQ?! I'm such an idiot," it'll either be closed, if it was resolved but waiting for your comment to confirm closure, or engineering will get your comment and proceed from there. Run on. There have been a few bugs in which I have had multiple back-and-forths with Apple. Perhaps two like that out of the 119+ I've filed.

The almost complete lack of communication from Apple on bugs has other issues as well. Sometimes bugs can be marked open for many many months because they are fixed in an upcoming software release. Perhaps they are marked as resolved in Radar. However, since Apple is so freaking secretive, they won't tell you anything until you personally have access to the release that fixes it either via a seed release or because the update was released to the public. Once you do get access, you'll get an email for every single bug that is in that state. I remember when Tiger was first seeded after WWDC, I was getting an email about every other week until it was released telling me engineering could not reproduce the issue with this release and see if I could confirm the issue. More on the future later.

On a small side note: If you want to ask about a bug and end up emailing devbugs or someone at Apple that asks about a bug you've filed, it's best to do it in the format of a link such as radr://4318699 (or if you have multiple issues, you can separate each problem ID with an ampersand (&) such as radr://3204961&4318699&3664624). This makes it super easy for the Apple employee to look up the status of the bug since they can just double-click it in Mail.app. I guess I'm saying that if you want any information from Apple it helps if you can go the first step and make it easier for them to get the information. You'll see these types of links all the time in Mac developer communities and mailing lists. They're useless to losers like me and are targeted to Apple employees. After a while, it just becomes customary to write problem IDs in this format.

Bugs: Apple, What They See versus What I See

The only thing losers like me get to see when filing a bug is a title, the severity (in our minds), the version of the product it affects (does it apply to the subcomponent you can't set or the Mac OS X version?), the reproducibility, two file upload buttons (one for a system profiler report, one for other things), and a text field to describe the problem. That's it. I have no idea what the cool people see. At WWDC, I sat right next to someone at Apple as they were filing a bug for me but I refused to look at what they were doing since the UI of the interface they see may be NDA'd. I wouldn't even take a peek. I do take NDA's very seriously and anything told to me privately will stay private with me if there's any hint it should remain private. It won't be mentioned at all. This is true even if keeping it private forces me to lie through my teeth. Point is, I don't know what Apple sees and many there don't know what I see.

Seriously, I think the devbugs team should force every single Apple employee to take a monthly or bimonthly class that shows them exactly what losers, such as I, see when filing a bug. Otherwise it just causes confusion when external developers are given "orders" to file bugs by Apple employees and the instructions don't match at all what they see. Alternatively, they could make sure all incoming and existing employees are shown the loser interface during orientation/training.

*Some external developers have their ADC Account marked in such a way they can see all the comments and can see the interface that internal Apple employees see. I wasn't even aware that this was possible until someone on one mailing list accidently had their account marked in this manner. Someone told him to file bugs on stuff if he had so many complaints about Mac OS X. He responded that Apple's bug reporting interface was extremely confusing. Everyone was aghast and wondered how someone could find such a simple interface to be confusing. As the conversation continued, it was clear what he was seeing was not meant for him. He was told to contact Apple and Apple fixed his account. No one was sure how it happened and there have been no other instances of this accidental marking in the four years since that I've seen. Personally I'd never want such power as I'd just end up choosing the wrong component. I'd rather have someone with better judgment handle it.

Bugs: Apple, What Benefits?

Quite a few people have stopped filing bugs due to the lack of communication from Apple. They just don't see the point in it. "Why bother to file bugs if they're just going into /dev/null anyways?" Their bugs either stay open indefinitely or are closed with "Behaves Correctly, STFU". Some people consider a simple non-automatic acknowledgment to be enough. Others would like to know that their bug was actually fixed because they filed it. As it stands, if one is fixed we're told it's "no longer reproducible in the current version". This statement doesn't connect your bug to the outcome of the current situation. It sounds more like marketing took over. It's obvious Apple acknowledges that bugs exist based on their release notes (especially for Security, where they actually give credit to the person that reported it).

Other times bugs may be filed on the current version of some piece of software and will be fixed in the next one. This becomes a problem if you don't have access to the fixed version. For example, when I first got my Developer Transition Kit, I figured I'd go ahead and test what would most likely break under Rosetta. I chose QuickTime Player as my target as I figured most people would need to run it under Rosetta for a while in order to watch their porn since the codecs used would take a while to be ported to x86. I tried a DV encoded movie and a movie encoded with the Animation codec. Both failed miserably with two separate problems. I filed bugs (and attached the files) and it was quickly fixed. I got the software and confirmed that it was fixed but found a different problem, QuickTime Pro no longer worked under Rosetta. I filed a bug on this as well. I also cited my reasons for choosing QuickTime Player as my first test target. This bug was fixed. However, it was fixed in the version of Mac OS X that came with the official ICBMs. I was told it was "no longer reproducible" when I received my exchange ICBM. I responded and told them I did not have a QuickTime Pro key to test it with (the DTKs came with QT Pro keys installed as part of Mac OS X). Devbugs or the engineer then closed the bug. No reward.

I've had various success with bugs based on the type of bug. Here are a few personal observations:

Documentation bugs: These are almost always fixed. Sometimes I have to scream and yell and give examples of why another document with correct information doesn't excuse a document from having the incorrect information even if the correct documentation is linked from the incorrect documentation. Most of the changes get made. Usually not resembling anything I've suggested, but they do get addressed. There are a few exceptions such as the word "species" being used as a verb instead of the word "specifies". Another example is the fact the *ResolveAliasFile* calls are not thread-safe despite being marked as such. If the main thread is playing with GetResource() while the other thread resolves the alias file, it can cause a crash since the Resource Manager is not thread-safe. The problem is, it's exceedingly hard to reproduce.

Feature/Enhancement Requests: I think these have always been marked as duplicate or they're left open indefinitely. I cannot remember a feature request that has been implemented. But then again, I don't ask for feature requests often.

Actual Bugs: I've had various luck with these. Sometimes they are fixed. Sometimes they are not. I think I've filed a bug on every single API and concept in FontPanel.h. Only one of these have been fixed. I started filing these bugs when 10.3 was released and after the WWDC in which 10.4 was announced. So many are quite old. I guess I just have bad luck with fonts.

The RadarWeb Itself: Usually the RadarWeb interface works just fine, no issues. However, I've had it totally die on me a few times. Once, it just completely died and gave me an error message. I sent the error message to devbugs but I couldn't give any more information than the error as I could not reproduce it. Another time, RadarWeb appeared to eat my attachment. It looked like it uploaded it, but it wasn't there. Which made me look the fool as I was getting visibly angry while commenting on a specific bug because the engineer was asking for information I had already sent. I didn't find out about this until I emailed someone at Apple asking for the status and they told me it looked as if I was yelling about something I had thought I uploaded, but didn't. RadarWeb gave me no feedback that the file did not upload correctly. Once you upload a file, you can never download it.

Bugs: Apple, The More Things Change^W Stay the Same

In the seven years since I've started filing bugs there have been very little changes I've noticed to RadarWeb or the bug process in general. Sure, the reddening was added. They also made it so the bugs are spread out across many pages. After a while, it was taking ages for people to log in as RadarWeb formatted every bug on one page. With these changes, something was lost. Now we can sort bugs by problem ID, date, or status. But the default sort of "activity" is gone. RadarWeb used to move bugs to the top of the listing if someone at Apple had modified any part of it. Devbugs or someone tried to remedy this by sending out an email every time any part of a bug was changed, but people were soon inundated with emails and they couldn't even see which part of the bug was modificated which just created more complaints.

Granted, the bug reporting form is now much simpler than it was before. The old form used to look like the non-account form. Except it autofilled the name and address fields. I never liked this form since it had separate fields for Summary, Steps to Reproduce, et cetera. It was annoying filling all of these out for each bug when they were often superfluous. Let's look at the "species" example above. Summary: "Uses species instead of specifies." Steps to Reproduce: "Read the sentence." Results: "Use of wrong word, species" Expected Results: "Using the correct word, specifies." It just gets very annoying after a while. Good riddance.

The lack of communication has remained a constant as far as my fuzzy memory will allow me to remember.

Suggestions to Apple: Take a cue from Microsoft. Allow the developer filing a bug to mark a bug as private or public. During the transition, mark all bugs reported prior to the transition as private as they may contain source code, but allow the reporting developer to change it. Allow developers to search the public bugs. Allow developers to see certain comments on their bugs.

I know that Apple is super secretive almost to the point that it's hurting them. However, Apple doesn't have to compromise security in order to increase communication. After all, Microsoft doesn't seem to find it an issue and they're many times larger than Apple, make a lot more money than Apple, get sued more often than Apple, and lose a lot more often than Apple. In fact, Microsoft seems to lose or settle every lawsuit brought against them. This hasn't stopped them from allowing comments. Simple comments such as "To be addressed in Chablis," are not considered something that should be kept secretive.

When an Apple engineer makes a comment on a bug, they could have a checkbox/popup that marks whether the comment itself is private or public. This checkbox/popup should have no state by default (to prevent an accidental choice) and it should be after the comment text field so the engineer can properly determine which status it should have after the comment has been made. Even if the comment is marked as private, it should say "Comment added by Apple engineer" to the losers viewing the bug (whether the loser be the reporter or the public if it is a public bug). Then at least they'd know that their bug was being loved (in the way a man loves a puppy) and wasn't being sent to the bit bin.

It would also be exceedingly nice while being very unlikely for developers reporting a bug in a piece of software to automatically get the next version of the software that fixes the bug they reported so they can confirm it was fixed. Of course, this would only apply to software that is not a simple update like the above mentioned QuickTime Pro key issue.

Finally, let's not forget the fact the Apple engineers themselves need to be schooled on the bug reporter and what losers like me see compared to what the cool people see, nootch.

Microsoft: Crash Reports, Getting Access to

Microsoft has a built-in crash reporter tool in Windows called Dr. Watson. This creates a log file (Drwtsn32.log) when something bad happens to an application. Windows XP has something called the "Error Reporting" service. This allows end users to send crash logs to Microsoft when an application crashes or stops responding (and you have to force the dang thing to quit). These reports are anonymous. If you want to file a bug with Microsoft (see above) or a Microsoft employee asks for it, you may be required to send the Dr. Watson log to some location on the internets.

Microsoft also offers an Online Crash Analysis website but I am unsure how this thing functions. However, it does appear to use the Dr. Watson logs. The Online Crash Analysis privacy statement says that they may send "error reports" to third-parties if a third party product is involved in the crash. However, the third party must abide to the privacy policy as well. In this case, Microsoft initiates the contact to the third party developer.

Alternatively, third party developers (henceforth, ISVs) can sign up to retrieve crash reports on a special Microsoft website. Instructions for signing up are available online. The "WinQual" website has many instructions on how to proceed. Basically an ISV just heads on over to Windows Quality Online Services website (which will not load in Safari unless you change your user agent to MSIE 6). Once there, the ISV just creates an account (which also has a list of all companies currently signed up). Note that in order to get a company account, your company needs a Verisign Class 3 Certificate which costs about $500/year. This same certificate can be used with other Microsoft programs and services that have code signing requirements. The certificate does not say anything about the quality of a company or the products they create, it just says the company officially exists. $500 a year is easy for most developers to afford that would be willing to sign up for Windows Error Reporting services. The hardest part in getting some signing certificates is they might require you to prove your business has been around for a certain amount of time, which may be impossible for start-ups. Note that I am not advocating code-signing as it needlessly locks out the little guy while doing nothing to make software better nor does it prevent malware. After all, malware companies can afford to buy certificate after certificate and create multiple faux companies in Brooklyn.

Once the WinQual account is created and the account is confirmed by Microsoft, you just sign into the account and map your program files to the company. How this is done, I do not know. I don't have anything to map so I don't have a reason to get an account or wait the days while VeriSign verificates that Unsanity does exist. It's interesting, but the instructions seem to imply that you'll automatically get everything Windows Error Reporting has captured before you signed up. This makes sense, but it is odd that it is retroactive like this. I am not sure how Microsoft verifies the binaries you choose are indeed your binaries. Especially if you never sign your code. Actually signing code does not appear to be a requirement to signing up for this service or reaping its benefits. Microsoft says it has over 1900 developers signed up for Windows Error Reporting services.

Microsoft Windows Error Reporting Service also has another really neat feature. Developers can send feedback to the user. Such as telling then an upgrade is available that fixes the crash they just experienced. I'm guessing this is automatically sent back if the crash contains binaries the company signed up for. I've never seen it, but I imagine this appears instead of or along with a dialog that says "we've received your report". That is, just a simple confirmation that the report was sent with additional default information provided by the server.

Apple: Crash Reports, Not Getting Access to

Apple gives various reasons why it doesn't give third-party developers crash reports, most of them lies. I've been told they're proprietary information although I'm not quite sure how a stack trace and some state information from a PowerPC or x86 processor that came from an end user's machine is considered "proprietary," especially to Apple. After all, nearly identical information can be gathered from Windows. The only thing close to "proprietary" is the symbol names Apple chooses to use. If that were the case, then the symbol names third parties use would definitely not be proprietary to Apple. Another common reason is that the crash logs contain personal information. Now, this is where the lying comes in. After all, the Crash Reporter application clearly says (emphasis mine):

Your report will help Apple improve this software. Your personal information is not sent with this report. You will not be contacted in response to this report. For Apple product support, visit www.apple.com/support or contact your Apple dealer.

Now, if someone representing Apple is saying they can't send the crash reports to third-party developers because they contain personal information and an application, also representing Apple, clearly says no personal information is being sent, then one of them must not be telling the truth. Which is it? The crash logs are shown to the end user before they submit them, so the end user is free to not send it if they think it contains personal information for whatever reason. However, even assuming the application is correct, it's still not good as Apple has been the target of some privacy concerns lately. I'd imagine getting two different stories about what the Crash Reporter sends would not help ease those concerns.

Now's a good time for a little side rant. The reason I've repeatedly asked various people at Apple for crash logs is because they'll often publicly blame (he said he'd go on record) haxies for a large number of crashes. Which used to involve someone at Unsanity having a knee-jerk defensive reaction asking them to prove this accusation by sending us crash logs. We've since found out that in none of the cases that they claimed this was it actually true. I mean, it wasn't true at all. I'm definitely not saying that haxies haven't caused a crash here or there, but we've fixed them almost as soon as we became aware of them and found a way to reproduce them. What I am saying is that haxies have not been responsible for the dire circumstances these extremely few (as in four people total) but extremely loud people have said they have been the cause of. Such as "causing the majority of crashes in 10.4" or "making the computer kernel panic". However, haxies killing pet goldfish is a known problem that we're currently looking into.

I said that we've since found out what was really happening. A few months after all these original claims were made, another Apple developer claimed this privately as it was one of his family members with the problem. We were able to get specifics from him since it was a family member's computer he had on hand. It turned out it wasn't a haxie at all (in the definition that all haxies are made by Unsanity and use APE). No, they were using haxies as a generic term. They were specifically referring to, in this case, a Safari "extension" that didn't even use APE at all. It had nothing to do with our company. See, the "problem" is that many of these Safari "extensions" are written using Objective-C method swizzling which is completely supported by the Objective-C runtime. In fact, it's a feature that will be made easier to use in future versions of the runtime. The real problem is that so very often these Safari "extensions" swizzle private methods, which is most definitely not supported. Even worse, very often these developers find that method swizzling won't get them where they want to go and use mach_override (again, not an Unsanity technology) to patch private/internal C/C++ functions. This is so not supported that it's not even funny. There is a special place in Hell reserved for those that mess with vtables.

I say it's even worse that they use mach_override because they write it with the "Cocoa mentality". The mentality that no error can ever occur and even if one does, the Objective-C runtime will handle it with no ill-effects (except in the case of struct returns on any architecture or float returns on the PowerPC, although that was often 0.0, but talking about the exceptions to the no ill-effects assumption is another 10 pages...). You cannot have the typical Cocoa mentality when changing the default behaviour of something by patching. You must error-check for every single thing. In fact, a third to a half of all my code is just error checking. However, since these Safari "extensions" don't often have much error checking and either patch or swizzle private functions/methods, then they are very likely to cause crashes when the private interfaces change. The kinds of changes are made very often during a system update. If these plugins properly checked for errors, they'd just stop working with no problems instead of crashing. Mail.app plugins also seem to be a large cause of these crashes blamed on haxies but completely unrelated to haxies.

It's easy enough to observe that these things were a problem for yourself. It eventually became such a huge problem with buggy Mail.app plugins that didn't error check in the initial Mac OS X 10.4 release that Apple not only had to release a knowledge base article about it but they also disabled all the current ones in the Mac OS X 10.4.1 update. There has been no such thing done about Safari "extensions" as of yet. Probably because there is no standard way to make such a piece of software, while there is for a Mail.app plugin.

Sadly, various people at Apple incorrectly refer to these types of plugins as haxies (they are not haxies) and people unfamiliar with the term "Haxies" will immediately Google it and see Unsanity as the first listing. They'll then contact us via email where we inevitably have to explain and try to convince them they weren't talking about our software at all. Not an easy task to convince someone that an Apple employee was wrong or mistaken. It really doesn't help at all that the other links in the search are from zealots with a very, very vocal anti-APE agenda. None of which have actually had concrete issues with Haxies. After all, they state they won't even run them at all in the first place. That and the fact many of them are just parroting others. But I already made a post about that a long, long time ago.

As you can see, I clearly have personal motivations for wanting to access Crash Reports. One, to handle these claims. Two, to fix any kind of crashers that manage to sneak by our extensively extensive error checking procedures. Sadly, no amount of begging or suggesting certain favors to be performed seems to get those crash reports out of Apple's grip.

This is ultimately why Slava created Smart Crash Reports (SCR). We needed these crash reports and Apple wasn't about to send them to us. There are some other methods to get crash reports from users, but they don't tend to have the benefits SCR does. Namely they require developers that want to use them to modify their code, link in new code, or make some other drastic changes. They also either end up adding an additional dialog to the crash experience or completely suppress sending the crash log to Apple. Users tend to be less likely to send crash reports if they get a bunch of dialogs appearing when a crash occurs, especially a dialog they don't recognize as being the standard one. Further more, if one of the crashes occur during first-run of an application and your application only checks to see if crashes have occurred at launch, then you'll likely never find out about these crashes as people tend to toss applications that crash the first time they're ever used.

While developers can link to an object file and install SCR, it is not required. All they have to do to get the benefits of SCR is add two entries to their Info.plist file. Then if the user happens to have SCR installed and their application unfortunately crashes, the crash log will be sent to the developer if the user so chooses to send it. SCR is seamless as it just modifies the existing Crash Reporter application user interface with another button. This allows the user to send a crash log to the developer and Apple from one interface, by clicking on one button.

However, SCR has two limitations. One, because of the way InputManagers are handled, SCR is loaded into every Cocoa process, even though it does nothing in those other processes. Even if there was a massive memory bug in the host application, the loading of SCR is unlikely to trigger the bug in the host application. SCR gets the bundle identifier of the host application by calling [[NSBundle mainBundle] bundleIdentifer] which uses already allocated statics/globals allocated by NSApplicationMain() (the first line of code in 99% of Cocoa applications). Furthermore, SCR is loaded long, long before most applications even run any code at all. So even a hideously buggy application would be extremely unlikely to run any code before SCR is loaded. Two, in order to keep the amount of code SCR runs in the Crash Reporter application itself, SCR isn't all that bright in narrowing down the cause of a crash when a plugin is involved.

Let me elaborate a little. SCR does know which thread crashed and does know which binary was the likely cause. However, it does nothing to weed out false positives. It'll stop looking at the first registered code image in the crash log. While this doesn't affect application developers at all, it does affect us at Unsanity a great deal as we get a lot of crashes misidentified as being a haxie crash. Since it mostly affects us, we didn't see the need in creating an advanced AI just for our case.

Since we get a lot of false positives and read every single crash report that comes in, we've been able to determine some common issues in various applications and we have contacted the application developers when we discover these. Most of the false positives involve various APE Modules installing state and/or context patches. Patches that only exist in order to get data about the current state of the program for later usage. Patches that do nothing else but store a variable. Quite a few of the actual culprits are Contextual Menu Modules. Oddly a very, very high number of them call CFBundleGetIdentifier() and then release the result, which is a strict no-no. Yet, the CMMs do it so they only modify the context menu in the Finder. We've notified the developers of these CMMs as we find them. Some have fixed it very quickly, others still haven't. A different semi-often crash we've seen is the Windows Media Player plugin for Safari causing Safari to crash, but that's no longer being developed. Another common issue is application developers over-releasing memory when a window is closed. Usually because they don't realize the system will release the memory for them. This is often due to developers not understanding that while HIViewAddSubview() does not bump the retain count of the view, the owning window will release it anyways. Due to this misunderstanding of the object's ownership changing when the window is released, many developers tend to double-release the view, leading to a crash (often a crash on quit, which most users do not notice). Heck Neko-chan, even QuickTime itself has this bug. If you actually manage to create a/an HIMovieView, the application will crash as soon as the owning window is closed. Even the sample code exhibits this behaviour. On a side note (...), someone on QuickTime owns HIMovieView, the HIToolbox team does not. As it stands, HIMovieView is completely unusable and hasn't been usable since it was introduced in 10.4.

What does Apple do with these crash logs? Now that I'm finally done talking about how great SCR is, I figured I'd actually speculate on what Apple does with all these crash reports. After all, they obviously don't send them to third-party developers and they likely get more than thousands of crash logs per day. So what is their use? Some say Apple aggregates all the crashes together and then determines from those which ones are caused by bugs in Mac OS X. However, I do tend to doubt this. There's been a very annoying, very sporadic crash in CoreText since 10.4 was released. It's not very reproducible and happens entirely within Apple's code. Deep within Apple's code. It seems to be fixed in 10.4.7, but I am not sure it was due to the massive amount of crash logs on the subject or if it was because the crash was discussed on an Apple hosted mailing list a few months ago. If it was due to the massive amount of crashes, it shouldn't have taken over a year to fix it (if it is fixed). Post hoc ergo propter hoc? Maybe.

Another very common crash involves CoreImage and the various graphics drivers. Namely, some graphic drivers are extraordinarily crashy when being taxed heavily with CoreImage. Especially the ATI drivers. I've seen these crashes happen more often in Keynote recently when people are using the various neat, but ultimately useless, effects Keynote provides. guiTweak also triggers these crashes. Even more disturbing is that all machines using PCI Express graphics (regardless of video card) suffer from kernel panics when using CoreImage semi-heavily. Not good. Sadly, neither of these are fixed on the latest versions of Mac OS X and the application crash with ATI drivers has been there since 10.4. It's hard to use CoreImage to its full potential due to these crashes. The workarounds usually involve slowing CoreImage's effects to the speed of cold molasses running down a clown's leg. Clowns hate tangelos.

I actually have an amusing anecdote about the CoreText crasher. Some user of a particular application suffered a crash. He sent the crash log to the developer of said application. The developer responded, "No idea, it must be some Unsanity haxie you have installed." The user then sent us the crash log. The user and crash log both confirmed that none of our software was installed on his computer. That was the first time I think we've ever been blamed for something when our software had never been on a user's computer.

Suggestions to Apple: Give third parties access to crash logs for their applications! Then we wouldn't need things like SCR in the first place. And definitely allow plugin developers (like Unsanity) to get crash logs for their plugins. However, please do it without the code-signing requirement that Microsoft has. But if code-signing is required, even that's better than the current state of affairs. Especially since many users have the incorrect assumption that third-party developers have access to the crash logs they are sending to Apple. Which then leads to very angry emails from customers based on this false assumption.

Blogs

I guess it's best that Apple does not have corporate blogs for their developers. I mean, who would trust a blog entry where the post was so full of Kool-Aid you had to assume the writer had a BKC of 0.73. You also can't trust blogs full of marketing speak. After all, this is what the .Mac "blog" appears to be. And Apple would definitely not want someone that works at Apple to say a third-party should be shut down because of their own personal beliefs. Nor do I think they would want one of their developers insulting a third-party by calling them "soulless profiteers and taking a private email conversation public (he never did send those crash logs).

Suggestions to Apple: I guess I don't really have any. It would require a massive corporate policy change to even hope to get Apple to support developer blogs and even more of a change to allow comments. What, with all the secrecy and Apple's reputation for removing anti-Apple stuff from their hosted servers. I mean, there's no way in the world anyone from Apple could every write something as harsh as this and hope to keep their job. Apple would probably even go far enough that they'd sue the Negative Nelly for "leaking trade secrets" rather than address their complaints.

Microsoft: Future Windows Versions

Microsoft doesn't seem to have any kind of mandate about what their employees can say about Vista either. I mean, you've got posts that clearly show how bad the audio stack is in Windows XP and the low-level changes being made for Windows Vista. In fact, Microsoft hosts countless blogs containing posts about low-level changing in Windows Vista. Just recently, they even posted a long list of changes post-Beta 2. And this is all long, long before Windows Vista is to be released to retail.

I guess my point here is that Microsoft most definitely has a very open and public dialog with it's ISVs about Vista. It does not appear they are hiding any aspect of Vista from the ISVs and the ISVs are free to communicate with each other about their difficulties or solutions to developing for and on Vista. Microsoft also takes feedback from ISVs seriously. This allows reports like this to be made. It can ultimately also lead to a reduction in bugs for the final release of Vista as developers can collaborate better on new APIs which means they will get more use which means bugs can be found sooner. An API that is never used will never have bugs found for it until it is used.

Apple: Future Mac OS X Versions… Shh!

Now, Apple on the other hand… They're completely tight-lipped about everything. I'm talking about what's happened in the past when Apple has "previewed" a then future release of Mac OS X. There is no public documentation after the future version of OS X has been previewed. The third-party developers attending WWDC are allowed to talk about it amongst themselves at length. However, that's about it. They couldn't talk about it or ask questions about it outside of WWDC unless the people were in the same company as them and had seed keys. Even all the happenings and sessions at WWDC are NDA'd except the keynote.

The only way to ask for help with some new API or some quirk in the new version of Mac OS X is, officially, to contact DTS. However, I do not know if contacting DTS and asking for assistance for an unreleased Mac OS X requires a DTS incident or not. If it does require one and you don't have one available or you've used them all up, then that's $195 per question. If you are in the student ADC program, you can't even purchase an incident at all. You cannot ask for assistance on any Apple hosting mailing list. If you try it, you'll just be told you're under NDA not to talk about it.

At the last few WWDCs that had previews of a future version of Mac OS X, Apple employees have repeatedly said they would try to get an NDA mailing list started for third-party developers that want to discuss the APIs in that future Mac OS X release. (They already have some NDA mailing lists for other projects but they are invite only.) Even after WWDC is over and people ask about the status of said list(s), they're told "we're working on it". No such list(s) has/have ever been formed.

Compounding this problem is the fact that Apple doesn't give third-party developers the final (GM or RTM) release of the future Mac OS X version until long after the consumers get it. With Tiger, it was about a week after most consumers got it (but later in the evening on the "official" release date). For Panther, it was a few days after the "official" release date. This causes a massive problem for third-party developers as they cannot test on the final version until after consumers get it. And then consumers wonder why third-party software breaks on the new Mac OS X release. Probably because the third-party developer never had the chance to test it on a production system with the final before the consumer got it. At least then they could issue a warning before consumers started to complain.

Actually testing software on different versions of Mac OS X is also incredibly tedious and difficult. Microsoft has Virtual PC for free, so developers can easily test their applications with multiple versions of Windows on one computer box. To test an application with multiple versions of Mac OS X, you need either a separate partition for each version of Mac OS X or a different computer. The latter may be required if one computer cannot run all the versions of Mac OS X an application should be compatible with. So it's either rebooting back and forth without being able to debug easily or having multiple computers connected via something like Timbuktu. This difficultly is why most developers (including Unsanity) only support the current major version and the immediately previous version of Mac OS X.

Suggestions to Apple: Actually follow through with these NDA lists we developers have been hearing about for the last 3-4 years. Not allowing developers to discuss pre-release Mac OS X versions with other developers just leads to far buggier initial retail Mac OS X releases. Adding to the issue is that developers can't even really write code for the new APIs until the version of Mac OS X is finally released from NDA. Well, they can write code for it, but if they have any issues they might have to create really nasty workarounds that defeat some of the benefits of the new APIs. A great example of this is Core Image. It was practically unusable in Mac OS X 10.4.0. It had simple but massive problems that could have been found and addressed before 10.4.0 was released if third-party developers could work together to understand the new API rather than each one starting from scratch and having the acquire the same knowledge themselves. Fifty developers all having to work from scratch to develop the same workarounds differently just leads to slower adoption of new APIs.

Documentation or Description Forthcoming

Microsoft's online developer documentation has often been considered the pinnacle of documentation for a consumer operating system. One of the biggest benefits the Microsoft documentation has is how an API reference links to or shows an example, in code, of how to use the function. A good example is the GetMenu() which links to a document about using Menus. Apple's documentation for the "same" function has no such reference to sample code.

Actually, Apple's documentation has gotten a lot better over the years. It's hard for me to find things to complain about now. When Mac OS X was initially released, almost every single function said "description forthcoming". My, how times have changed! It's actually exceedingly difficult now to find this kind of documentation. Most of it has been fleshed out with the biggest problems with the actual documentation is the lack of consistency. The documentation for GetMenuRef() has one documentation style whereas what I just pointed out has a completely different style. Personally I'm fond of the GetMenuRef() style.

Other than almost the complete lack of example code in Apple's documentation, many third party developers have wanted to edit the documentation themselves in order to fix any lacking caveats or "gotchas". Thinking, "If Apple won't do it, I will!" Well, Microsoft actually has an MSDN Wiki that allows anyone to edit or add to the documentation. It's probably meant to be like Wikipedia in nature. Anyone can edit it and submitted content and existing content is covered by a Creative Commons license, which is pretty sweet. However, I have no idea how to edit existing content, the beta site doesn't appear to work well in Safari or Vista. If you look at the documentation for menus you can see that the documentation contains the kind of sample code Apple's documentation should have for each function.

Apple has recently added almost monthly documentation downloads for offline viewing in either Xcode or in PDF format. Xcode automatically checks for new versions of the documentation at a settable duration. The most recent download is the June documentation. With WWDC right around the corner, I don't imagine there will be a July release. For some very odd reason, you must be an ADC member to download the documentation even though Xcode comes with Mac OS X. Granted, registration is free, but you have to be at least 18 years old to download the most recent documentation which seems like an odd requirement. Microsoft also has full offline documentation downloads. They used to only be available for MSDN memberships, the kind that cost money. But now, they are free. The most recently available is the May edition with future releases to be free. Microsoft does not require any kind of registration to download and thus has no age limit. Sorry AngusD.

Sample Code

Apple has a semi-massive amount of sample code. Both on their website and installed in /Developer/Examples/ with the Xcode tools. The latter also has source code for TextEdit, SimpleText, and Sketch. SimpleText being a sample that developers had been yearning for when Mac OS 9 was the main release. Apple's license to their sample code almost seems to be public domain. You can use it in any way you want. Some developers have even just taken some sample code, recompiled it, and sold it as their own. Sony Ericsson's website actually uses some Apple sample code (search the source for "sample"). However, if you modify Apple's sample code, you cannot say the source code is from Apple. Which makes total sense.

Comparatively, Microsoft seems to not have much web-accessible sample code. Visual Studio includes various sample code pieces as does the Windows Platform SDK. Microsoft says you can "modify, copy, and distribute the source and object code form of code marked as 'sample'". However, I am unsure if you can take Microsoft's sample code, recompile it, and sell it as your own. Although I'm not sure if the ability to do that is a good thing.

Suggestions to Apple: Give me more to complain about. But seriously, they could create a wiki-like system for outside people to edit documentation. Granted, I can't imagine they'd allow anyone in the public to do it. It might be better if they granted a few people at a time that ask for it. I mean, I don't think I could be trusted to edit Apple's documentation without screwing something totally up. I do know they currently allow third parties to create technotes but I don't know the procedure for writing such a document. I also know that these documents can be woefully out of date. (As Mac OS X 10.4, FSRefs are guaranteed to be valid across processes.)

Apple could also implement some kind of automatic inlining of sample code. For example, someone from apple could write a sample using a host of functions like GetMenuRef(), AppendMenuItemTextWithCFString(), and ChangeMenuItemAttributes and the documentation for those three functions would have that sample code right below the function. Granted, you'd need some way to exclude very common functions like CFRelease(). You'd also need some way to make a specific sample as being the preferred sample for an API. But doing it automatically is a good way to start.

The HIG, or Do As We Say, Not As We Do

Ah, the Apple Human Interface Guidelines. What a sweet, sweet document. This is the document that causes Mac users en masse to email Mac developers just to complain about every nit-picky thing that violates the Mac "standard" (standard meaning HIG). In fact, there are many beta testers out there in the world that only email HIG violations.

It's easy to determine which applications (like Word) try to fake conformance by including their own graphics inside their application that "look" like the standard Mac OS X/Aqua graphics. However, Apple has updated the way OS X looks in every single major release so far. Sometimes slightly, sometimes by a large margin. This makes applications that fake it look horribly out of date. For example, Office v.X has all these weird striped lines everywhere and 10.1 style buttons. The Adobe applications have the same problems as well. It's funny, Mac OS X has an extensive Theme API which developers can use to make sure they are drawing the correct theme patterns, colors, fonts, and brushes for their custom controls or custom content. In fact, there are many developers that have installed ShapeShifter and changed the theme in order to make sure they are actually using the APIs correctly so when Apple changes the main theme of Mac OS X yet again, their application doesn't look completely retro.

Let me say this flat out: The HIG is a good thing. It keeps Mac applications consistent and consistency is good. It's designed so anything that works in one application, works the exact same way in another and this reduces the learning curve for new applications. The very first page of the HIG lists eight reasons why developers should follow them. But there's a slight problem with this Gospel of Mac™, Apple itself completely ignores it. Not only do they ignore it, they make gross violations and then they'll make changes to the HIG to accommodate the violations and make them the new "standard". I won't mention the obvious problems with the metal (or textured as it is called) windows.

This means that you can use different strings for different languages. Now, Cocoa already has localized strings for the "untitled" name. For example, "Untitled", "Sie können angeben, wo das Dokument gesichert werden soll", "名称未設定", and "무제". In other words, if a language has no concept of case (like Japanese and Korean there), then you obviously cannot make a lowercase string. However, for languages that do (like English), it's as simple as changing the "Untitled" = "Untitled"; string in /System/Library/Frameworks/AppKit.framework/Versions/C/Resources/English.lproj/Document.strings to "Untitled" = "untitled";. Also, thou shalt not disagree with the Chicago Manual of Style.

Apple used to have a mailing list dedicated to questions about the HIG and commenting on the HIG. However, shortly after Mac OS X was released and the "new" decision makers came into power, the amount of complaints on this list skyrocketed. The complaints started to decrease as Mac OS X evolved, but it's hard to tell if that was because the problems were resolved or just because people became complacent. Anywho, after a few years of complaints, the higher-ups got sick of it and rather than address any of the complaints, they just shut the mailing list down. The way it was closed seemed kind of petty, almost as if Apple was saying, "Don't want to praise our play? Then we're taking the ball home!" or something. But my memory of that time is foggy and rereading the list archives (which are not on Apple's website) I don't feel the same rant-inducing "outrage" I felt when it was initially posted.

The Apple Design Awards

I'm sorry, but I tend to find the ADAs to be more of a joke now days. I don't disagree with awarding application developers that have taken the time to carefully use Mac OS X technologies and make sure their applications conform to every detail of the HIG. However, some applications (but not all, of course) that are awarded an ADA just don't do either of these well. It seems they are awarded for initial prettiness rather than for use or conformance. If we look at the list of previous winners, I see one that I couldn't disagree with more. STX (Salon Transcripts) is an application I've had nothing but problems with. If you look at their various features, they all seem to show completely different views. All these views come from one single application. What's worse is the install procedure. You get a CD that contains about 6 disk images. Some disk images are optional but others require you to install the private frameworks inside the disk images in a specific order before you can install anything else. And then if you want to upgrade from a previous version of ST Pro, you have to actually open ST Pro (which runs only under Classic) on the computer, hope you have a serial number for the old version that is still valid as they tend to expire, go through about 14 pages of detailed instructions in order to clean out NULL entries in the databases, and then hope the final export program (which also runs under Classic) actually succeeds. I could not get it to succeed on some of the computers. If you're upgrading from an old computer that runs Mac OS 9 and upgrading to an ICBM, you're in for a world of hurt.

I've been wanting to complain about that for over a year… The other issue I have is with the fact that Delicious Library won two awards with one being the "Best Mac OS X User Experience". I know I can be hard on Delicious Library at times, but I cannot agree with this. It's interface is completely non-standard (with regards to the HIG). For example, there's no real way to tell which pane is focused so doing a select all may or may not select all the items you meant to select. Another small violation is the fact the cursor changes to a copy cursor when you drag something into the info pane but you can't actually usefully drop it until you're over the little image well inside the pane. Delicious Library also has flaws due to the Cocoa mentality (the one that says the system does everything for you and you don't have to optimize anything). If you have more than a handful of items, DL takes minutes to launch and minutes to quit. And I can't seem to reload information for every item without DL first eating a bunch of memory and then crashing. Perhaps I am being too harsh on DL and am only mentioning it because ranting about one program (STX) makes me look like a loon.

Actually, it almost seems like the winners of the ADAs have become predictable. So I'd like to make some predictions. Let's see, The Omni Group seems to win a lot of these awards. So I'd imagine either OmniPlan (which is beta) or OmniDazzle will win some award. The latter possibly winning best use of Mac OS X technology. Videator might get a special mention for Mac OS X Technology. Sandvox will probably get a runner's up award if it doesn't get anything else and the author will make some quip about Apple stealing it. Growl might win for open source software. If Delicious Monster has any major new version or new software, that'll win. Then the author will make some quip about Apple stealing all his talent. It would be nice to see NetNewsWire and EyeTV win an ADA, however.

Suggestions to Apple: FOLLOW YOUR OWN BLOODY HIG! I don't know how else to say it. When Apple doesn't follow the HIG (as they often don't, look at any iLife application) then third party developers will try to do as Apple does. This just makes horribly inconsistent applications, as often the things Apple does are hand-rolled and have no system API. Mac developers basically follow the leader.

Developer Support

Software and Code

Microsoft offers between 2 and 4 technical support incidents. I cannot seem to find much information about how to use these since I don't have an MSDN subscription. However, Microsoft seems to prefer you use the managed newsgroups to get your support but that won't work if what you need help with is proprietary to your company and you have to use a support incident.

Now Apple's support, I do have experience with that. A lot of experience. The technical support incidents that Apple offers are code-level support incidents. Meaning if you have problems with writing source code, you use an incident. It cannot be used for general use software problems. With Apple's programs, you get either 2 or 8 technical support incidents, depending if you are a premier or select member. If you run out of incidents and need to purchase more, they are available from the ADC Store for $195 each or $9000 for a pack of 50 incidents which expire after one year of non-use. I swear that Apple used to offer more than eight incidents for the premiere account and more than two for the select account. To use an incident, you just email DTS from the email address attached to the ADC Account with the incident.

Technical support incidents are usually used when a developer has lost all hope and exhausted all methods such as asking on the mailing lists and asking the Mac developer community at large. When you contact DTS with some issue and the issue you are having turns out to be a bug or is better done by another API, Apple will return your incident to you in most cases. Most of my incidents have turned out this way. The other times they've mostly just been really dumb mistakes on my part.

I file a lot of technical support incidents as I often do the "researching" for the company. Researching how to do some features or how to best implement some features that may be a long time off. Sometimes I just do incredibly stupid stuff to see if it can be done. Most of the times when I do contact DTS, I get a response back rather quickly. If the answer to the question necessitates code being written, then the lovely people at DTS will often write the code for you. They'll write it in a manner so that the code can be copy and pasted easily into your project without too much setup. Often, the code they write will become official Apple sample code for others to enjoy.

Granted, not all my DTS experiences have ended so nicely. Once I filed an incident trying to figure out how AppendResMenu() was getting the name of some fonts. The names didn't appear to be in the font file at all. No matter what I did, I could not reproduce the name some of these fonts had in the font menu. Someone at DTS responded a few days later telling me they'll have to contact engineering to get further information. A month passed, no response. I emailed back again and was told they were still awaiting a response. Two months passed. Eventually I was just given back the incident and I never got an answer.

After downloading the various font technotes from Adobe's website, I was able to figure out I needed entry 18 in the font table. The SNFTTypes.h header file stops at name code 14. I have no idea why I never could get a response from DTS on this issue. It took me quite a long time to find the answer and the answer turned out to be something entirely simple that could have been found by running some old Apple sample code.

Hardware

What happens if AppleCare doesn't do the repair properly? If a machine used for programming fails and needs repaired then that means you'll be without it for multiple days while Apple fixes it. This kind of makes it hard to get a second repair done since you need to schedule downtime in advance. For example, my PowerBook's arrow keys have died twice. They just stopped working. This makes it nearly impossible to navigate code without using the mouse. The first time it was repaired, mostly everything was fixed. However, the '?' key lost its backlighting for some odd reason. Not exactly the biggest problem.

The second time the keys failed, whoever did the repair did a not so very good job. As you can see from the photo on the right, the keyboard now "slopes". The left and right sides of the keyboard are not flush with the case. At first, I thought it was just a cosmetic issue but then I started typing a bit of text. I then noticed it was nearly impossible to use the shift key without applying an excessive amount of force. This makes it extraordinarily hard to write code, which is case sensitive. Not to mention my code contains a lot of sad faces, which are hard to type without a shift key.

However, I do plan to order a 17-inch portable ICBM before WWDC just so I can have something to use and code on for WWDC.

Suggestions to Apple: While having general software support isn't exactly necessary, it would be nice if you offered express, confidential hardware support to developers that have purchased computers from the ADC Hardware Store. I just can't go without a laptop for the 5-7 days it takes to fix the computer.

Developer Membership Programs

MSDN Subscriptions

Microsoft has various levels of MSDN Subscriptions which range from $199 to $10,939, depending on the features needed. The "useful" ones start at $1,199 as that is the price when the developer tools start to be included with the membership. The "full" developer tools are available separately for $299 to $799, depending on the level and features needed. If you only purchased the absolute minimum, it would cost $998 total for the operating systems subscription and the developer tools. The prices are much lower for renewals and upgrades but the prices I list are the initial prices for people that have never had a membership before.

So what do you get aside from the developer tools with the different levels? Well, if you go with the subscriptions that include MSDN Premium (which starts at $2,499), you get the current versions of Windows (XP, Media Center, Tablet PC Edition, 2003, et cetera) shipped to you with the ability to download previous versions of Windows from Microsoft. Without listing otherwise free software or the core developer tools, you also get SQL Server Developer Edition, Visual FoxPro, Visual SourceSafe, the entire Microsoft Dynamics Suite, Microsoft Office Professional Edition 2003 (along with Visio for Enterprise Architects), and pretty much every single Windows Server product (including Virtual Server 2005). Sadly, it does not come with an Xbox, that's how they get you. It also includes four technical support incidents.

The MSDN Professional subscription has one price, $1,199. It only comes with the various versions of Windows, SQL Developer Edition, Visual FoxPro, and Virtual Server. It does not come with Microsoft Office, Microsoft Dynamics, or any of the Windows Server products (other than Windows 2003). It does include two technical support incidents.

If any of the products you get with a membership get updated, you also get those shipped to you. And the licenses you get for these products are perpetual and are still valid after your subscription has lapsed. While the amount of products that come with the membership may seem high, the devil's in the details. The licenses are per user, not per PC and you are prohibited from using the included software for day-to-day (production) use. For example, you can't use the Windows versions included with your MSDN Subscription to play games on Windows XP. Nor can you use the Exchange server included to set up an e-mail server to send personal or business related emails. There is one exception, however. There are two licenses included for the Microsoft Office Professional Edition 2003 that comes with MSDN Premium. One is for development related use and the other is for personal use, completely unrelated to development. In other words, you can legally use Word 2003 to write all those romance novels you've been dreaming about involving William Shatner and the Plutonians (ATHF).

ADC Membership

Apple has basically two paid levels for membership. The two levels are Select, which costs $500/year and Premier, which costs $3500/year. There is no renewal pricing or benefits for renewing. Apple also offers a free Online account and a $99/year Student account for college students. The members of the Student account do not get Mac OS X seeds and cannot purchase or be transferred additional assets (such as a seed key). You must be at least 18 years old to sign up for any of these and the developer tools are free for any account level.

Both paid accounts come with the same amount of software Apple also mails out the full retail versions of Mac OS X as they get released. This includes any retail updates Apple makes such as making Mac OS X 10.4.6 the version included in the box at stores. This is really nice as it can take hours to go from 10.4.0 to 10.4.7 after installing all the updates. Apparently full licenses of Mac OS X with no restrictions on use. I can't really find any use limitations or other information. This may be due to the fact Mac OS X doesn't require a serial number to use. I kind of expect the serial number requirement to change and become more like Microsoft's activation requirement. If nothing else than to prevent people from installing it on generic PCs.

Aside from Mac OS X itself, both paid account types come with Mac OS X Server using a development use only serial number. Apple used to include a full version of Mac OS X Server with premier accounts, but that "benefit" was recently removed. This version has the same restrictions as Microsoft's software. You cannot use it for production work. Unlike Microsoft's programs, the Mac OS X Server serial number automatically expires. Usually this is before your account lapses and then you have to go to the ADC Connect Member Site and get the new serial number. They both include an Xsan Developer's Use serial number as well. No other software is included with the ADC Accounts.

One thing interesting about Apple's program is that they include free access to Apple's Compatibility Labs. There is a rather neat feature that allows you to go to one of Apple's three world-wide lab locations and test your hardware or software with various Mac models and Mac OS X versions. It's a really neat benefit. Sadly, I've never had the occasion to use the labs. There's one in Tokyo which may be interesting to use next time I am in Japan. However, the page is in Japanese…

Apple's programs also include two or eight technical support incidents, one or ten seed keys to make sure other people in your organization can get access to the pre-release versions of Mac OS X, and physical mailings of the latest documentation and sample code. One of the absolutely nicest things about the developer programs is that they include either one or ten ADC Hardware discount keys per year of membership. These discounts can be very significant and covers most of Apple's hardware. The discount can be well over $500 depending on what you buy which would make buying a Select account basically "free" if you buy it to get the discount. Sadly, the discount does not apply to any of Apple's software. With the Student account, you get one discount key that can only be used once. If you use your one Student discount key, you will not get a new one even if you renew your student account. However, students can get a discount on Apple software just by using their normal student discount, which can be substantial.

Suggestions to Apple: Ya know, it'd be super nice if Apple would include more free software with the Select and Premier accounts. Namely, QuickTime Pro, which is a joke in of itself. I mean, Apple charges $30 on top of the cost of OS X and everything else just so you can watch full screen movies. Disgusting. Granted, there are free QuickTime players that allow full screen, but you won't be able to play back protected video.

Let's not forget about .Mac. This could be a very useful developer tool for storing files for beta testers and whatnot. The benefit with .Mac is that it is also a yearly term so Apple could make the account last only for the term of the ADC Membership. It might also help adoption of the .Mac Sync APIs if developers could have a free account to test the stuff they are using to sell .Mac accounts for Apple. On a side note, I've been paying for an unassigned email-only account on my .Mac account for 2-3 years now and I have no idea how to remove it.

It'd also be nice if Apple re-included Mac OS X server with the Premier account. And probably iWork, iLife, and Apple Remote Desktop. Due to the fact you can't test multiple OS X versions from the same box simultaneously, the least Apple could do is include ARD with the Select and Premier accounts even if it was just with a limited developer's use serial number. Then developers could at least fake the experience. Until then, there's always Timbuktu which is cheaper for just two computers (sadly the cost starts to get higher than ARD if you need more than three computers but three should be more than enough for most developers). What also perplexes me is the fact Apple doesn't give ADC members discounts on first party software. Sure, I can get a discount on a wireless Mighty Mouse, but I can't get one on Final Cut Pro (software I actually need desperately for development work).

It'd also be nice if Apple seeded more software to developers than just Mac OS X, Mac OS X Server, and Xsan. In order to get seeds for other pieces of software, you must separately contact the team in charge of the piece of software (like QuickTime) and beg them for love. I am told dry humping the lead's leg may work in some cases.

Apple should also mark which software on the ADC Member Site is under NDA and which isn't. There's a note at the top of each page that says, "Pre–release software is Apple confidential information." However, there is absolutely no way to tell which pieces of software are pre-release and confidential. I mean, Xcode 2.3 obviously isn't. Nor is the June ADC Reference Library Update. Same goes for the .Mac SDK. There's no clear individual marker whatsoever. Maybe even a finger icon next to a download to indicate it is under NDA would be enough.

Which Comes First, the Consumer or the Developer?

And now we come to the reason I wrote this huge rant in the first place. How does Microsoft or Apple assign importance to their developers and their normal consumers? It's always been my opinion that developers deserve more importance than casual consumers. After all, if there are no developers for a platform making nifty applications, there won't be any consumers. I mean, just look at OS/2 which failed partially because it ran Windows applications so well, there was no reason for developers to write software for OS/2 which then drove consumers to Windows because it ran their Windows applications better. This means first parties should coddle and gently stroke their third parties so they will continue to write the applications that keep the consumers on the first party's platform. For example, if Adobe suddenly dropped Mac OS X support, how many people would immediately switch to Windows?

If you actually read all of the above (see the Future Releases section), it's extremely clear that Microsoft gives more importance to their developers than they do their consumers. This is a good thing.　They give developers more resources sooner, they give the developers earlier access to seed/pre-release versions of their operating systems, and they give developers access to the final releases of software long, long before consumers have access to it. Apple, on the other hand, gives developers access to the final releases long after the consumers have gotten a hold of it.

Hardware

The massive delay itself was annoying, especially as I heard repeated stories of end users getting their machines well over a month before I got mine. Apple was even filling the channel with computers that no one had paid for yet, waiting for potential sales. Whereas a developer like me, which was a confirmed sale, was waiting. But no, the wait wasn't the worst part of it. The worst part was the fact I used my debit card which, at the time, had a $3000 daily spending limit. After the first month of waiting, Apple started "pinging" my card every week to see if I had the necessary funds. Since the price of the G5 was very close to my daily limit, I was unable to use my card until the authorization "fell off" my account. This meant for three days a week (sometimes all week) I was unable to use my debit anywhere but at an ATM (Automated Teller Machineyolamatrolamaton). This led to a very embarrassing set of events. I went to Todai with a friend and when I went to pay, my card was rejected with "insufficient funds". So the bastard that was with me (photo at left) had to bail me out. Very embarrassing and he won't let me live it down.

This problem really came to a head while Slava was patiently waiting for his DTK Exchange iCBM to be delivered. Yes, it is super-neat that Apple actually gave something to developers for free and that they were shipping it to Russia. The problem is that when WWDR called Slava back (since his machine was in the queue for what seemed to be months), they flat out told him he wouldn't be getting his iCBM until they filled the Eastern European channel with iCBMs. In other words, they were shipping to consumers and stores before they were shipping to developers.

Slava not having his iCBM caused major problems. We couldn't release a fat APE to the world at large because we hadn't been able to properly test it on production hardware. And there is no way we were going to release software that was untested. We were 90% sure it wouldn't do anything bad (like blow up a user's computers) but we couldn't be 99.99999% sure your dog wouldn't catch on fire until we could test it on a production machine. (As stated above, APE killing goldfish is a known problem we are currently looking into.) Some of our users absolutely refused to either purchase or use their ICBM until we had the products they had to have to work ready. I'm not spreading hyperbole here. A few users flat-out told us this. If the lack of our software is preventing some purchases of ICBMs (no matter how small) imagine what the lack of software from the big names is causing.

The announcement of the release date of the first ICBMs really shocked quite a few developers. They were only expecting the ICBMs to be announced at MWSF. They weren't expecting them to be available on the very day they were announced. If Apple had pushed the release date back a week or two, many higher-level developers could at least prepare to release beta versions of their software. It takes time to fix the blockers and package software up for the public, even if it is just a very public beta. Since Apple released the iCBMs on the first day of exhibits at MWSF, it seemed most booths were being asked about compatibility from what I could tell.

Exceptions to the Lack of Love

I've already mentioned the DTK Exchange exception. Most of these treatment issues disappear if you are a sufficiently big company like Adobe. I hear that if you have enough users, Apple (and WWDR) will basically coddle you. I don't know if this only applies to really large companies or not. If so, how many users does a company have to have to be considered large? 2,000? 20,000? 200,000?

Suggestions to Apple: It'd be absolutely positively lovely if Apple would move developers ahead of consumers and definitely ahead of retail. In order to make the priority list: Education, Developers, Consumers, Retail. I really have no idea why retail is ahead of developers as it is. It's just perplexing.

Conferences!

Microsoft Technical Developer Conference Marketing Events

I've never been to any of Microsoft's conferences. I'd like to go to one just to see what it's like, but the cost of that curiosity is too high. Microsoft has quite a few technical conferences. They have the Professional Developers Conference (PDC), which appears to cost $1700. it comes with various free swag and some heavily discounted swag (70-80% off) was/is available in limited quantities. There are also free drinks and snacks, it appears. Microsoft only seems to have a PDC event every other year.

Microsoft also has the Tech•Ed conference. TechEd appears to cost between $1800 and $2000. TechEd also has free swag (running list). You also appear to get free drinks and snacks as well. Actually, it just might be better to read these accounts of TechEd. Microsoft also has regional TechEds they put on throughout the year.

Microsoft also has some other conferences like WinHEC. WinHec appears to have all the same deals and swag as TechEd. Each of these conferences have DVDs produced post-event that contain the various sessions given at the shows. The standard price is $495 unless the show is sold out beforehand. If it is sold out early, then the DVDs are discounted. I am not sure if attendees get the DVDs for free when they are available or if they get the discounted price.

Worldwide Developers Conference (WWDC)

I guess I should first mention that a person should not go to WWDC and expect to find romance. If you're a straight male looking for someone to connect with that shares your interests, you won't find it at WWDC. The far majority of females at WWDC are in marketing or have a manager position. The majority of the female programmers there were physically born male. Granted, that's really not much of an issue for a lot of people. If you're a male gay, and you like fat, smelly, pasty geeks, then WWDC is heaven. Then again, there really isn't anyone at WWDC that is that fabulous to begin with (excluding Slava). If you are a female (physically born that way or not) then I have a warning for you: You will be hit on by every guy at that conference. There is no exception to this. It doesn't matter your age, race, or body type. You will be hit on. This is probably what keeps all the female programmers away from WWDC. After all, women tend to be smarter than men. By the way, this is the kind of thing I was talking about in the very first paragraph. This paragraph has been completely tongue-in-cheek.

I absolutely love WWDC. I've gone to every WWDC since the last one they held in San Jose. When I went to that one I was lucky enough to be a student and I got the student scholarship. I bet someone at Apple regrets that decision now. Semicolon, Hyphen, Right Parenthesis. I love what I can learn there and the people I get to meet and talk to there. It's all very arousing.

Sadly, this is no longer the case. There's very, very little snacks other than some cookies and some fruit. No chocolate. There's almost no soda. It's been replaced with various canned iced teas. The Krispy Kreme doughnuts were completely missing last year. And the Jamba Juice was replaced with something called Odwalla. The Odwalla drinks aren't nearly as tasty as Jamba Juice was. The amusing thing is Odwalla couldn't keep up with the demand for the drinks and near the end of WWDC there were no Odwalla drinks left. Odwalla.

Update: Okay, I was very slightly wrong about the chocolate thing as a kind person has reminded me in a kind manner. One day after a session had just ended, I saw the the Moscone event staff unpacking some lovely Ghirardelli chocolate bars. These things aren't the cheapest brand of chocolate. I snapped up 3-5 bars while trying to avoid the bitter dark chocolate. These bars did not last long at all which is probably why I completely forgot about them.

However, last year was the first year with some actual decently decent food. They has some decent lunches each day. They would have been perfect if not for the lack of good drinks. Canned iced tea and canned lemonade just aren't that tasty. The canned nature of the drinks seemed to make them far more acidic and bitter than you'd expect tea or lemonade to be. But the lunches were good. They also had vegan and kosher options available. Some days WWDC even had alcohol available (it was heavily guarded and with people checking IDs).

Aside from the consumables, I didn't like the lack of free swag. There was the standard bag full of stuff last year, a t-shirt or two, and well, that's about it. The number of freebies have gone down significantly. The first year I went, I got an iSight camera for free, which I love. The second year, it was a license to Apple Remote Desktop 2.0, along with a 10% discount on anything at the Apple store. I bought a FireWire hard drive. Last year, bupkis. We got nothing free at all but what was in the standard bag. I like free stuff. It makes me feel loved.

The sessions themselves were fun. I like going to the various sessions covering HIToolbox, Cocoa in Carbon, and the fancy new APIs in the new release of Mac OS X (CoreText! CoreText! CoreText!). I also just love going to the feedback forums and the DTS Labs. I especially love the labs as it allows me to take a years worth of programming problems I've been having and get help with them all at once. Very nice indeed. Sadly, I have no such issues this year. I do plan to cry myself to sleep every night during WWDC. I cry myself to sleep almost every night when I'm at home anyways.

Apple used to send DVDs out to all the attendees containing videos of all the sessions for those that could not attend them all. Some sessions are either packed to the brim or they conflict with other sessions. They no longer offer these DVDs. They do offer what appears to be every session video online. However, the session videos only show the display as shown on the video screen the presenters used, they hardly ever show the presenters themselves. Not that the presenters are the point of the session, it's nice to put a face to the audio. The most annoying part is the fact they don't have the videos from the Q&A part at the end of each session nor do they have any of the feedback forums. I find these parts to be the most valuable as it answers the questions the sessions themselves didn't. Whether some points were ambiguous in the session or whether some just needed more explanation, the missing parts clarified it all. Oh, you also have to pay $30 to watch the sessions full screen.

WWDC also has some very interesting events such as the bear bash. This is an event in which everyone hunts nature's godless killing machines . Err, I mean the Apple Campus Beer Bash. Everyone gets bussed down to the Apple Campus is nice air conditioned busses. Apple then has some musical event, serves free food, and serves free beer from different places in the world. There's also a freakishly huge line at the Apple Company store.

Suggestions to Apple: Well, bringing back Krispy Kreme doughnuts, the junk food, and the soda would be very, very good. After all, the stereotypical programmer tends to live off junk food. Also, a few other freebies would be nice. One year Apple gave away a leather Mac OS X coat that I always see jcr wearing at every single Mac event. That's really neat. Just getting the same old bag without chocolate every year is not as awesome. Oh, it'd also be lovely if Apple would send out the DVDs again (closer to WWDC to boot) and included the Q&A along with the feedback forum sessions with the DVDs. Finally, if Apple could lift some of the NDA requirements, that'd be nice. Especially the one that says we can't take any photos at WWDC. Sometimes some people are just acting so weird at WWDC, a photo desperately needs to be taken. Speaking of photos, I see tons of photos from WWDC on Apple's developer website, yet I don't appear to be in any of them. What's up with that?

It's either this or imagining Phil Schiller in a thong

I guess my point of this entire rant was to point out some of the areas where Apple's communication with third party developers could use some improvement. There are some areas where Apple absolutely excels like their public mailing lists. And some where Apple could take some cues from Microsoft, such as bug reporting and hardware support. While I may complain about Apple a lot, please realize that I still believe that Apple is bar-none the best computer company and they have hands-down the best operating system to develop applications for. And I don't think that anyone is making a mistake by purchasing a Mac. Especially since Macs are usually the best choice for the job whether it be because of software Apple or a third party made.

Remember, anything you have a problem with in this article is only my opinion and my observations and no one else's. If you like something I've said and think it is really wise and insightful, then give credit to Unsanity. I'll gladly personally take all the flames on my shoulders.

Digg This (but comment here).

 Posted by rosyna at August 02, 2006 03:51 AM

Trackback Pings:

TrackBack URL for this entry:
http://www.unsanity.org/mt-tb.cgi/379.

Listed below are links to weblogs that reference Developers! Developers! Developers! Developers!, Caring For: Microsoft vs Apple:

Proper Care and Feeding of ISVs from Aaron's UI Design Blog
Alright, so this post has nothing to do with UI Design, but it has everything to do with Experience (yeah, with a capital 'E'). That is, it has everything to do with the Developer Experience. You see, developers create software....[Read More]

Tracked on August 2, 2006 7:21 PM

Software should improve by fixing crash reports from users from WPF Team Bloggers
Guideline: Software should use a feedback loop to fix problems that customers are running into. If you[Read More]

Tracked on May 29, 2007 3:47 PM

Related:

• Spectacular Catastrophe: WindowShade 4.2b2 - Sep 20, 2008
• Feel the Heat That's All Around You; Flashing Lights and Ecstasy Surround You: The Silly Effect and John Gruber - Sep 15, 2008
• Purified Chicken Embryo Cell, The VUF, and Menu Master Beta - Aug 25, 2008
• New Releases: APE 2.5, SCR 1.5, FruitMenu 3.7 - Aug 18, 2008
• Dear APE, I want you inside me. Love, Leopard #2: APE 2.5b2 - Aug 06, 2008