About | Buy Stuff | Industry Watch | Learning Curve | Products | Search | Twitter
Home » Learning Curve » Developers Workshop

Apple's iCake

Trying to forget what we can't help remembering.


Buy It

Try It

Things are looking good in Cupertino. AAPL passed MSFT in market cap, then passed everyone else too. They're increasingly seen as the 'great hope' of all the refugees from Windows and Microsoft technology in general (and an unpredictable CEO in particular). They're even seen as the 'missing link' in the world of open source where nothing ever seems to be ready for prime time.

Apple literally invented new markets and turned old markets topsy-turvy. They upset the old power balance in the telco market, replaced the old 'smartphone' with a new one that was really smart, and they opened the tablet market and made it really work. Their attention to analytical design is unparalleled.

There's been dissension in the ranks of late, and one gets the feeling this dissension would have been contained under Steve Jobs. Instead we find Scott Forstall set for early retirement. The story is Scott was more like Steve Jobs than the others could tolerate, a believer in UI paradigms Steve held dear but Jony doesn't, that he and Ive couldn't much sit in the same room without Steve around to demand they fall in line, and so forth.

Scott Forstall pulled the company into the smartphone market and thereafter into the tablet market. The software engineers began with the Cocoa base used for OS X and streamlined it. The interface was completely new, and they wrote drivers for new hardware technologies and changed the man-machine paradigm completely. Then Scott tried to bring some of that good stuff back to a stagnant OS X for the desktop and the laptop. With mixed results.

There are thousands upon thousands of software engineers at Apple, and it's only the fool who thinks a Steve Jobs or a Scott Forstall or a Tim Cook would be peeking over the shoulder at the work of them all. Responsibility has to be delegated even in the Apple world of micromanagement. Small details get overlooked. Bugs and logical bombs and annoying design decisions creep in. And they have a remarkable propensity for continuing to be overlooked and continuing to prevail.

From: Marco
Date: 22 Dec 2012

Open the archive, see the pictures inside.
Seems they screwed up one more thing. :-/

You see?

Fully updated 10.8.2. On 10.7 I see something similar but not that noticeable.
From: Marco
Date: 24 Dec 2012

> On 10.7 we see *nothing*.

See the attachment. I took Xstamp as an example.
Check 'diff.png' in particular. Zoom it. See?

> Are there other apps not from us that have that?

No, haven't seen nothing like that so far.

- SRSLY! WTF are they thinking?
To: Marco
Date: 25 Dec 2012

The texture on that one isn't gradient. It's a flat colour. Where's the setting for that in Xcode?
To: Marco
Date: 26 Dec 2012

We have a full dozen that need a quick fix. But XaBatch does not - and yet is identical in
settings to all the others. Makes no sense.

The quick fix is inserting a line of code to set the background color. This is not identical to the
solution BD used. We haven't been able to find any information on this issue whatsoever.
From: Marco
Date: 26 Dec 2012

Yes, XaBatch is OK. Now that's really strange.

http://stackoverflow.com/questions/7795505/nswindow-textured-background-with-nstextfiel

See if that one helps. I don't fully get it but it may be something.
To: Marco
Date: 26 Dec 2012

Sending along two NIBs both for document-based apps. The settings should be identical.
To: Marco
Date: 26 Dec 2012

'Update: Thanks to cocoahero, if in the content border setting in IB you choose custom you can just
set the gradient height to whatever you want, never noticed that before.'

That does it. Wow. Now to figure out what the default content border settings are...

That's it. Seems to be. Flip on custom border setting and flick 'Manual' in both cases. Keep those
numbers to ZERO, otherwise you'll see a faint shadow line at the bottom.

Now - why wasn't XaBatch affected? ;)
From: Marco
Date: 26 Dec 2012

> Now - why wasn't XaBatch affected? ;)

Now that's a mystery only you may unveil.
From: Marco
Date: 26 Dec 2012

> Now - why wasn't XaBatch affected? ;)

Got it! :)

Just opened the NIBs you've sent. XaBatch has the 'resize' control, CatInfo no.

Watch the screen recording.

Focus on the bottom of the window when I repeatedly activate and deactivate the Resize control.

See?
To: Marco
Date: 27 Dec 2012

Wow. Yes, Hawkeye!

Wow that is SOME BAD BUG! No?

Is this something worth writing about? We're assembling a significant list of Apple quirks.
Fanboys never listen because Apple can do no bad, but it might be good for posterity?
To: Marco
Date: 27 Dec 2012

> - This one
> - The inode mash overwriting mess
> - The not accepting minus floats in IB mess
> - The Xcode projects external frameworks mess

- Telling users when files have been updated externally
- Telling users they can't open documents in singleton apps
From: Marco
Date: 27 Dec 2012

> Wow that is SOME BAD BUG! No?

No doubt. Basically you have a reverse bug switch: turn it off, the bug manifests;
turn it on, it vanishes magically. Unbelievable.

> Is this something worth writing about? We're assembling a significant list of Apple quirks.
Fanboys never listen because Apple can do no bad, but it might be good for posterity?

Who cares about the fanboys? 'Stupidity should be painful' no? :)

You have to criticise, you have to turn the spotlight on faults - that's a mission. And that's
really important for posterity. Someone has to check over.

To me it's definitely worth it.

> Clicking the resize switch and that stuff goes crazy! :(

'Click. Boom. Amazing!' quoting SJ - isn't it? Haha. ;)

Apple's iCake

Time might not heal all wounds, but it can certainly fuzz unpleasant memories. What with people at this site being preoccupied with an unfortunate disturbance elsewhere whilst OS X was intentionally and strategically left on a back burner. But most of those annoyances and glaringly stupid design decisions remain. Marco's discoveries and research served to bring them back into a crisp and fresh present tense. A Madeleine cake for the end of 2012. Apple's iCake.

  • The shading bug. As Marco discovered, this beast rears its head only when a textured window lacks a resize button. The bug is in the rendering, not in IB. It was not present on 10.6 but began appearing albeit discreetly in 10.7, only to go full-blown bat shit crazy in 10.8.



    Marco first got the clue by looking at software sites for signs of updates for 10.8 that concentrated on 'cosmetic issues'.

  • The inode mash overwriting mess. This one is old but is also 'compounded insult'. In fact it's downright stupid. And it only can persist because Apple's 'user experience engineers' [sic] refuse to look or listen and continue to lord it over real engineers who know better.

    Basically it stems from a perplexing situation for them in OS X from years gone by: the predicament when you want to save a file but get told by the UI that you can't because you don't have permission.

    That's actually a Good Thing™ but the oafish UE engineers aren't capable of grasping such niceties. That's actually a Good Thing™ because it stops you from shooting yourself in the foot.

    There are basically only two scenarios where such a situation can arise.

    1. You're tramping on grounds where you have no rights (and for a very good reason).
    2. You've already protected that file on your own grounds (and for a very good reason).

    In either case, the inability to recognise the situation and the unwillingness to take a few seconds to ponder the ramifications speaks of an imbecility rarely seen outside the UE corridors.

    But it gets worse still because of the 'hack' perpetrated by the Apple engineers to placate their UE superiors.

    Apple's 'Cocoa' has a built-in 'document controller' that does all the dirty work in saving files. The document controller tells the client apps when it's time to save and what to save. The client apps are given a file path to save to. But that file path isn't to the file you think you're saving. That file path leads somewhere else entirely.

    The file path given by the Cocoa document controller is to a theretofore unused temporary file. If the client app reports back that the file was saved successfully, the document controller will proceed and access that temporary file.

    This was actually a Good Thing™ back in the 'old days'.

    The method allows for both blackouts and brownouts. It keeps things more secure. That the client app reports back that the file was successively saved is one thing. But if the client app should fail and munge the temporary file, then nothing is harmed. The real target file is untouched.

    And the document controller now has a secure copy of the file update and can take its sweet time in updating the real target (and try as often as it wants).

    That older system was smart enough to keep a backup copy 'just in case'. And that was a Good Thing™.

    Now enter Apple's impatient user experience engineers who get flustered when told they can't overwrite a file they either have no business trying to overwrite or have themselves protected from overwrites. The lift doesn't go to the top floor for those people.

    So the silent but frustrated software engineers devised a 'hack' to please them. This is how the hack works.

    • Hack the Cocoa document controller. Change the file overwrite (copy) operation to a file move operation. This removes the system security the document controller previously had. This means that files are never overwritten - they're first destroyed. Gone! Zip! Bye-bye!

      [Unix files that are 'moved' are never actually 'moved', not when they reside on the same 'volume' (which is the only place this hack works). Their directory information is simply moved to another directory. But this 'move' implies that the original file is first 'unlinked' - which in Unix is tantamount in most cases to the file being destroyed. Ed.]

    • But this leads to another disastrous situation. Unix is so constructed that merely attempting to remove a file requires write permission for the file's directory. That permission is not a given in any scenario.

    It's quite common that directories are protected from stupid or malicious tampering but individual files can be accessed and edited by a wide range of users and groups. Say goodbye to that.

    So this sophomoronic hack leads to the incredible situation where a file is fully writable but Apple's hacked document controller won't allow file saves anyway because the directory isn't writable.


    And that's about as crazy as crazy gets, and that's been the situation for years now, and no one but no one at Apple seems to dare address this ridiculous situation, confront the UE nannies, and get anything done about it.

  • The not accepting minus floats in IB mess. Floats and doubles by definition can accommodate both positive and negative values. This is a Good Thing™. And Cocoa APIs have used floats and doubles wisely.

    A particularly good example is when dealing with table view columns. These columns can be hidden only if they're allowed to assume a width of -3 (something users can do at runtime by simply dragging one column over another). And the hidden columns can thereafter be revealed again by simply dragging them out.

    This method beats alternatives by a mile. The foremost alternative is keeping a running tab on what columns exist, providing a new special user interface for adding or removing columns, and so forth, and then on refreshes checking first the columns that both exist and really need updating. Gobs of code no one really needs.

    Microsoft did something functionally equivalent in the days when people were still chugging along on 16-bit machines. But those days are long gone and that was a matter of conserving resources. Updating everything, whether it's visible or not, is infinitely faster on today's hardware. And the user benefits as well.

    Along comes a programmer tasked with updating Interface Builder. (Keep in mind that Scott Forstall's already stolen all the real 'aces' for his iPhone project, so who knows who's left on projects for the desktop.)

    And this noob programmer decides to arbitrarily disallow negative values for table view column widths because they don't seem to make any sense.



    [There was another bug appearing about the same time time. Another 'noob' came in and tried to grok the old NeXT code for the 'open file' API, couldn't quite get the old head wrapped around it, and ended up ruining the code. Rixstep reported this and the bug was in fact fixed, although it took nearly a year and was only applied to successive releases, not the release where it originally appeared, making it necessary for 3rd party houses to keep their code fixes in anyway. Ed.]

    There's a way around this amateurish blooper of course - hard code the minimal width in the program source instead. But that defeats the whole purpose of the NIB.

  • The Xcode projects external frameworks mess. This is a particularly unfortunate (and for some almost impossible) Xcode bug starting with version 4.3.3.

    Granted that most 'Maccie' developers won't run into the situation (and therefore it doesn't exist, right?) because they use Xcode settings 'out of the box' to build MyApp.app, but there are a lot of enterprise situations where this bug is an almost total pain in the arse.

    Xcode is turning into an unwieldy monster, as evidenced by what happened to IB (above). This particular bug - present throughout version 4.3.3 - rears its head when updating projects to a target OS of 10.7 or greater. For earlier targets such as 10.6, it doesn't appear at all. And that makes it only more mystifying. And scary.

    Suddenly project settings don't work anymore. References to 3rd party frameworks result at link time in the diagnostic 'framework not found' even though the paths can be read in the project settings and in the raw project file source.

    The workaround (for there is one, albeit 'over the top') is to reimport those frameworks into the project and ask Xcode to copy the frameworks into subdirectories of the project directory.

    This is of course patently stupid, and for the following reason: OS X frameworks come with their path baked into their code and may only be run and referenced from that location.

    So even though the tireless programmer actually has Xcode copy entire frameworks into the project file hive, they're still accessed at runtime at their original location and are not copied into the final project build.

    And that of course makes the entire exercise of copying the frameworks unnecessary.

    No one seems to have found a better workaround for the bug, but there is one somewhat less painful method: create symlinks to the actual frameworks and include those in the project instead.

    Unfortunately one must still do this for each and every project dependent on the frameworks.

  • Table view chaos. Up until and including OS X version 10.4, things were great with the table view. It's found in almost all Cocoa applications. It's a real workhorse.

    A crucial capability of the table view is allowing multiple section ranges. The NeXT code - still in place with OS X version 10.4 - was better than any other code on the planet. Then something happened.

    One once again suspects it was Scott's project that left rather clueless noobs behind on projects for the desktop. Bug reporting for 10.4 Tiger got chaotic. Tens of thousands of bugs were not acted on, and the moment 10.5 came out, the bug reporter team were told to inform developers that they should upgrade to the new version to see if the bugs persisted.

    This wasn't the fault of the bug reporter team, and it wasn't the fault of the programmers who fled to the iPhone with Scott, and it wasn't the fault of the programmers who got left behind because Scott didn't think they were good enough for the iPhone. It was the fault of management.

    Whatever: someone got tasked with helping legacy NeXT code make the hurdle to 64-bit and in the process, the old code got reviewed (and damaged) by people who obviously weren't experts at Cocoa. To make matters worse, they didn't seem to be particularly experienced as end users either.

    There have been several attempts to repair the damaged table view code since then - there have been small incremental improvements through several point updates - yet no one seems to have taken the obvious step of simply going back and studying the logic of the legacy NeXT code to grok how table views are supposed to work.

    It's practically impossible to select multiple ranges in a table view today. The bug persists year after year.

  • The incompatible types overwrite bug. This is perhaps the worst and most shameful of them all, it was involved in the first ever Safari bug that appeared on the very first day of that browser's initial release, trashing entire user systems, and the really unacceptable and unforgivable part of the mess is that to this day Apple continue to insist (most likely with the UE engineers cheering on from a safe distance) that this is not a bug but 'expected behaviour'.

    Here's Apple's TextEdit asking permission to overwrite the directory 'foo' (and all its contents) with a single ordinary file. That directory could just as easily be your entire user area, wiped out in a fraction of a second, perhaps by 'mechanical' or 'user' error. (Note the embarrassing admission: 'a file or folder'.)



    There is no one who agrees with Apple in this regard. 3rd party everywhere have to implement safeguards in their own code to prevent disaster. And there's an historic explanation that of course makes matters even worse - a stellar example of how one blooper is actually held in place by older bloopers before it.

    Apple file APIs and UIs don't allow for recursive directory 'merges'. And they're alone in the whole world in this regard.

    What are recursive directory merges? You do them all the time from the command line where Unix still reigns supreme. They might appear to be more difficult to implement, but Apple already had the FreeBSD code and so shouldn't have been at all intimidated.

    Part of the reason may be that 'classic MacOS' didn't understand them either. But that's hardly a good excuse.

    The important thing is that all file copy operations from the 'GUI' level have to first destroy the destination targets before copying. And if that doesn't make any sense to you, you're hardly alone. That particular scenario has led to any number of notorious and widely reported scandals for Apple over the years.

    But will anyone at Apple relent? Will those UE engineers give up the spirit? Not yet.

    Recursive directory merges - the industry standard way of copying files - are easier to deal with once you master the recursion code. The code's responsible for creating directories as it drills down into a hierarchy. But the code never needs to check the success of its directory creation calls - it'll find out how good they were when it starts copying over the files themselves. The overhead in code and in runtime performance is negligible.

    Files are actually opened and written directly. Nothing is trashed that doesn't need to be. Files (and directories) at the destination that aren't supplied by the source aren't touched. It's the only safe way to go.

    Contrast this with the widely publicised catastrophes on Apple platforms. One gets the distinct impression Apple don't understand file systems at all.

    Not using the 'merge' approach means client (application) code must go to extreme lengths to prevent Apple APIs from trashing entire user systems. The file management code for GNUstep (essentially a branch of NeXTSTEP, at least in spirit) goes to inordinate lengths to prevent catastrophes. No such code remains in Apple's port of the original OS from NeXT.

    The documentation for Apple's legacy APIs from old 'MacOS' contained myriad warnings about how injudicious use could trash entire systems.

    Apple file systems never seem to learn how to protect themselves. And if their understanding of file systems is reflected in their file manager Finder, then they really don't.

Apple Shortcake

The list could be made longer - much longer. There are gobs of bad bugs that have been around since the release of 10.5. For the most part, users are blissfully unaware of them. Once in a great while one of them will rear its head, and then everyone will panic, totally convinced the sky is falling.

But all it takes is a bit of Madeleine cake to bring them back into a crisp and fresh present tense. Apple's iCake.

About | Buy Stuff | Industry Watch | Learning Curve | Products | Search | Twitter
Copyright © Rixstep. All rights reserved.