|Home » Industry Watch » The Technological
THIS LINK GOES NOWHERE
Who's bringing up the rear? Who's sitting on the back burner?
Apple just sold 300,000 iPads on opening day. They have a new gadget out there. Running its own operating system. Apple haven't been supporting a single operating system since before the days of the iPod. And that's a long time ago.
Today they have Mac OS X, Mac OS X Server, the iPod OS, iPhone OS, pretty soon an independent iPad OS too. They have Safari for Mac OS X, Safari for the iPhone, for the iPad, for Windows. They have WebKit.
That's a lot of irons on the fire. All of these irons are niche products but their flagship computer OS continues to enjoy a worldwide single digit market share. And as Steve Jobs has gone on record against recruiting more programmers each time a new product is planned, what gives?
Objective-C is a breeze. But only for radically seasoned C programmers. And preferably C programmers who are not simultaneously C++ programmers or Java programmers. Where do you find such programmers?
And who gets to jump over to the new projects as they're announced?
The iPhone was a radical departure from anything Apple had done previously. The iPhone APIs use the same Objective-C language and the same type of class system but they're still completely new. Where do you get programmers to create these new APIs for the first time? Off the street? Out of a Starbucks?
Hardly. You take them from your best Mac OS X teams. Those people have to be the best you have. They have to be the programmers who understand the frameworks well enough that they can create an entirely new environment on their own - from scratch.
Maintaining existing code is another - and much easier - matter. You get specs to change one line of code here or there. You get a ticket from the bug reporting team. You get told the entire program/framework you work on has to migrate from 32-bit to 64-bit.
Mail.app into its fourth Snow Leopard iteration still can't remember to underline hyperlinks.
These people can come off the streets. And given that Apple were working full throttle up to the time the iPhone was conceived, where else would you get your backup? These are programmers who by their very nature are not well versed in a code base they've never before seen. (Some say they don't seem to be well versed in much else either.)
Or you could just work your existing programmers to exhaustion - make them straddle several projects at once, have them furnish their offices with futons, make them work 12 hours days seven days a week. That's another formula for success.
Third party houses were unanimously shocked the day 10.5 Leopard was released. All the pent-up Tiger bug tickets were summarily vomited back on them the very hour Leopard went on sale.
'Purchase the new Leopard version and report back if your bugs persist there.'
There's nothing wrong with closing the book on one iteration of an OS. That's not the point - the point is there were so many Tiger tickets still open when Leopard was released. Why weren't they taken care of? Where were the programmers who normally took care of them? That's the point.
There are a great many tickets that are pure nonsense. Someone might actually report that their TextEdit keeps misspelling text. You can't know. Anything can come in. But a great number of the bug report tickets are genuine and really do need to be addressed. Yet they seemingly never are.
The above screen shot shows a fresh session of Mail.app receiving a single mail message. The message contains a hyperlink. The idea is this hyperlink is supposed to be underlined and clickable. Yet starting with the first Snow Leopard release 10.6 and continuing through the recent 10.6.3 upgrade, this is not the case.
Anyone can test this by purging their mail folders, rebooting, and sending a single message from a different source.
Mail.app for 10.6.3 begins behaving better after a while. But exactly what makes it come to its senses is not known. There is no workaround. Four iterations with a really embarrassing bug and it's still not fixed.
Mail.app still leaves 'orphans' in its on-disk drafts folders. This still hasn't been corrected either. You once again start with an empty copy of Mail.app and play a while, receiving and sending mail, and removing all messages after each session. Sooner or later the orphans will start appearing - more often than you'll find comfortable. You use this command to find them.
find ~/Library/Mail -name *.emlx
Be patient - they'll turn up. Speculation has it they're related to autosaves. So if you keep a new message you're composing open long enough for Mail.app to save a copy to disk by itself...
Whatever. It's an easy bug to identify and should be even easier to eradicate. It's a programming error. But who's doing the testing in Cupertino?