September 11, 2009

Daring Fireball on Cocoa/64-bit

John Gruber has posted a thorough, thoughtful piece on iTunes, Cocoa, and 64-bit software. He makes a number of useful, sensible points about how Cocoa is “not magic pixie dust” but does open the door to UI & performance improvements. (Lest anyone forget, the Photoshop team has been working for quite a while to move Photoshop to Cocoa and 64-bit.) It’s well worth a read.

A few thoughts:

  • Getting functionality for free (e.g. when a standard Cocoa control is improved) sounds great, but it’s something a developer like Adobe has to consider carefully:
    • Whether or not it’s important to you, cross-platform consistency matters a great deal to many customers (e.g. those in a large company that runs Macs & Windows machines). It’s hard to expose one’s apps to those sorts of changes. (As I’ve written, consistency within an OS & consistency across OSes both matter.)
    • I know Adobe apps sometimes catch flak for using custom UI widgets, but you don’t want the apps limited (or made inconsistent) by what the different OSes provide. If customers benefit from something like scrubby sliders, and if you want the experience to be consistent, you need to provide them yourself.
  • Gruber writes, “Maybe the Carbon APIs will never go away, but I wouldn’t bet on that.” I don’t know what Apple plans; I just ask (as I’ve asked them previously) that they communicate plans in advance. If they want to say, “Listen, four years from now, Carbon-based & 32-bit apps aren’t going to work anymore, period; you can transition everything now, you can wait ’til the last second, or you can spread it out,” that’s fine. (It’s enormously helpful in planning, actually.) Just provide plenty of lead time so that no one–Mac users, developers, or Apple–gets squeezed.
Posted by John Nack at 3:05 PM on September 11, 2009

Comments

  • Luke — 4:58 PM on September 11, 2009

    Correct me if I am wrong, but doesn’t Apple have a pretty bad track record on that last point of communicating plans in advance?

  • Lindsey Thomas Martin — 5:13 PM on September 11, 2009

    ‘cross-platform consistency matters a great deal to many customers (e.g. those in a large company that runs Macs & Windows machines)’
    A good point. Cross-platform consistency also matters to those of us working for smaller companies, one day in the office on Windows and another at home on Mac.

  • David — 7:35 PM on September 11, 2009

    I’m fine with custom widgets inside the app. What I don’t like is the custom window edges and titlebar in CS4 apps. I expect apps to gain new functionality if the OS window manager is updated.
    Several things are effected:
    Windows:
    1. No drop shadow behind the app window
    2. “X” button can’t be activated by clicking the upper right pixel of the screen in maximized mode.
    3. Windows 7 has a feature that lets you jam a window to the side of the screen to make the app fill one side of a screen… it doesn’t work with CS4 apps. (it works with the keyboard shortcut, but not with the mouse)
    OS X:
    1. Expose and Spaces don’t work as well as with CS3
    2. I had an issue with one app (Configurator?) that didn’t let be drag it to another monitor. I have my 2 monitors arranged vertically (bottom monitor is a Cintiq). The menubar is on the bottom screen. The app would snap to the menubar, but couldn’t pass through it.
    None of these are huge issues, but I’d rather have the window chrome managed by the window manager.

  • John.B — 7:37 PM on September 11, 2009

    I asked this same thing in the comments for your “Why do you want a 64-bit iTunes?” blog entry, but I think it’s even more germane here.
    GCD will give you a lot of multi-core/multi-threading functionality on OSX that doesn’t readily exist today for Windows.
    I’m curious if that means you’ll pass on using GCD for the OSX versions of Ps (and Lr), in order to be able to control all lines of code associated with thread management for both the OSX and Windows versions — so thread management can be dealt with in a similar manner?
    [I can only say that we're actively investigating our options. As you'd imagine, PS & other Adobe apps already include a great deal of thread management, VM, etc. code. Generally speaking, and for obvious reasons, we like to build atop open, cross-platform standards (e.g. OpenCL), but we've also sought to tune Photoshop for the specific strengths of platforms (e.g. AltiVec, SSE). Apple's open-sourcing of GCD code is an interesting turn of events. --J.]

  • John.B — 7:42 PM on September 11, 2009

    (Apologies for replying to my own thread; comments can’t be edited…)
    To be more concise, what doesn’t readily exist on Windows is the “for free” GCD out-of-the-box threading support. Not that Windows doesn’t support threading (we all know it does) but that it’s a ton of work to manually implement.

  • John Hoffman — 11:34 PM on September 11, 2009

    I recall the same sort of debates about moving apps from 16 bit to 32 bit coding.
    I wonder how many years will pass before the same debates rage about switching apps from 64 bit to 128 bit coding. It probably will not take very long. After all, it is less than 30 years since the IBM PC was introduced, and people asked “Why would you ever need 640K of memory?”
    Some things never change.

  • Chris — 12:02 AM on September 12, 2009

    I wonder how many apps have no benefit being 32bit over 16bit.
    On the 128bit, not sure it would happen, as there isn’t much point. 64bit can address 16 exabytes of ram. What other reasons exist to jump up?

  • Thomas Maier — 2:56 AM on September 12, 2009

    why don’t we go back to 16bit apps when 64bit is no improvement to 32bit?

  • Axel Polt — 3:37 AM on September 12, 2009

    Adobe sits on tons of optimized multi-plattform legacy code …
    The ideal solution:
    one GUI for the MS Win standards, one GUI following Apples Interface guidelines and three the Adobe propietary interface (for those bi-world users).
    Those bi-world users really accept the legacy MS interface @work and the imho slicker Apple GUI for the rest of their work @home, so i really would challenge this fact once again…
    One central core for the easy normal functions, as baseline OpenCL / Grand Central for the heavy computing things for Apple Systems and workarounds for the other Seattle systems…
    Any compromise on that issue is a strategic one, trying to avoid the hard decision, that will come sooner or later.
    I really do not like the recent Adobe Interface. My workflow now focuses on Lr and i try to use as much as possibles alternatives to other Adobe programs on Mac OS 10.6 SL…
    I do not believe at this time that i will upgrade my rather expensive Adobe Collection due the mentioned interface / performance issues… I am truly disappointed by Adobes progress as well as the non-performance of your support-hot-line.
    For a four-figure amount of money on a more or less two year cycle (in Europe!) the expectation is a no-compromise system that sticks to the interface guidelines of the host OS using the underlying performance to the max, and that includes 64bit, OpenCL, GrandCentral…
    Or: Adobe establishes it’s OWN holistic ecological system, including OS, GUI, applications consistency (running under VMware on MS or as a system like PathFinder + Apps under Mac OS 10.6)…

  • Marc — 9:13 AM on September 12, 2009

    All i can say is:
    http://i31.tinypic.com/35hfmnq.jpg
    [I wouldn't worry. --J.]

  • Lorin — 9:26 AM on September 12, 2009

    Consistency within an OS matters far more, because it affects every user every day. Conststency across OSes affects many fewer people, much less often.

  • Stephen — 3:48 PM on September 13, 2009

    No to mention, people already deal with differences between platforms.
    When I am forced to use Windows, I know I don’t have Spotlight and Expose.
    I’m all for consistency where it makes sense, but this constant push for a single unified shitty UI on both platforms is not the way forward.

  • RCotton — 2:27 AM on September 14, 2009

    Gunning for a common UI look and feel across Windows and OS X is a virtuous goal in the abstract.
    Unfortunately, in practical application, what you (adobe) produce is a UI that is palpably worse than the native look + feel of either OS.
    (see preceding comments detailing how your “unified UI” fails to behave properly in either window manager)
    p.s. your comment form also forgets name and email when you hit “preview” (firefox 3.5.3, XP)

  • Josh Bryant — 8:40 AM on September 14, 2009

    I throw my ring into the hat that consistency across platforms at the cost of consistency within the OS is really sad.
    It seems odd to me that people would expect such a thing, as one commenter already pointed out, people who go back and forth between Windows and Mac OS *already* adjust to a different UI every time they sit down. The start menu doesn’t exist on Mac.
    I dunno, that’s just *really* disheartening to hear someone from Adobe say.
    [I really get it from both sides, you know? I have Mac purists (are there any "Windows purists"?) beating me up for trying to ensure reasonable consistency between Mac & Win. And I have certain geniuses in Adobe's design group beating me up for insisting on reasonable OS consistency (as opposed to driving some platform-independent Adobe "brand"). Maybe the net result is that I'm doing okay.
    Incidentally, remember that Apple was once trying to get everyone to "write once" to its cross-platform abstraction? Of course, many Mac partisans would say, *that* would have been different. If Apple had attempted to make everything the same across OSes, well, that would be good, simply by virtue of Apple being the company responsible. Think different, as long as you're Steve. --J.]

  • Manuel Herman — 1:14 PM on September 15, 2009

    My thougths are, that Adobe should stop with the custom UI branding and refocus on native platform UIs for both platforms. I switch platforms on a daily basis (work: mac, home: winpc) and if I get how a programs workflow is, it’s no problem to adjust to the respective UI of each system. Scrubby sliders are fine, but they can be implemented on top of the existing platform UI. Much more important to me is the custom windowing… but I think you’ve got enough heat about this issue, I don’t need to reiterate that . Last and least, regardless of custom branding UI or native UI, most important for me is, that it’s bugfree and responsive (performance!)

  • Locke — 11:01 AM on September 16, 2009

    Here, here. Us switchers switch. It’s what we do. We may have different reasons, it may be choice or more forced upon us, but we fully grasp that the platforms are different because we go back & forth every day. Heck I’d be willing to bet we use keyboard shortcuts for much of or work so the adjustment is made on the fly just about every keypress.
    So long as you don’t do something really stupid like put menu items under different headings or name the same thing differently, it it’s just the platform UI widgets, we’ll roll with it just fine.

  • David — 7:21 AM on September 17, 2009

    Let’s look at the facts.
    Pro-users are willing to invest more time in learning (initial training), to gain in productivity. Both Mac OS X and Windows have behaviors that are easy to learn, but often not the fastest/most efficient way to do things, or way limited in versatility or certain workflows. By Adobe doing their own UI they can extend things like tear-off palettes, combining windows into a users workflow, and things that you can’t do on Mac or Windows native UI.
    Yes, a noob will look at that, and say “inferior, harder to learn, non-standard”. But a pro will say, “that saves me a little time, and lets me customize — worth it”. So figure out who you’re sampling first.
    Same with consistnency across platforms. Some users say, “bleck, that doesn’t work like Mac or Windows”. But a pro that has many machines or works in a mixed environment gets to ignore the platform, and focus on his work and workflow. Who are you sampling — casual users or pro’s?
    Even if we assume that a standard UI is inferior for users (which I’ve already demonstrated as false for many useres) — what about the testing benefits? If you’re using common code-paths and behavior paths across platforms, you can create one set of test code, and one set of tests that test BOTH platforms (more or less). That means commonizing your interface decreases development and decreases bugs. (You get more testing and development in for the same effort). That means you can afford to add more features or stability. How much stability (increased bugs) or features would you give up to have native UI on each platform. Of course that assumes that Adobe doesn’t waste that opportunity by overspending the savings on UI features or other things, but there is an opportunity there.
    I’m sure if Apple or Microsoft was willing to take suggestions on what Adobe feels their customers need as far as advanced window/palette behavior or other things, then Adobe could adopt more standard behaviors. But they don’t. And remember, when Apple goes to Windwos, or MS goes to Mac, do they only stick to the native UI? Heck, they can’t even do that on their own platforms and break their own rules all the time. So Goose, meet Gander. Copmanies and App teams feel they know more about their customer base than the OS UI designers do (and usually they are right). Most often it is the casual user (not the core market and repeat buyers of pro-apps) that complain — because they don’t like the idea of increasing the barrier to entry just for the sake of later time-savings once they become and expert. But if they were the majority of the buyers of the product, then Adobe, MS, Apple, would tune their UI’s for them, instead of who they do.

  • Breton — 6:34 PM on September 20, 2009

    “Incidentally, remember that Apple was once trying to get everyone to “write once” to its cross-platform abstraction? Of course, many Mac partisans would say, *that* would have been different. If Apple had attempted to make everything the same across OSes, well, that would be good, simply by virtue of Apple being the company responsible.”
    I don’t think the lesson to be learned from that is “it’s bad if adobe does it, but good if apple does it”. The lesson to be learned from that article you linked is that “It was a complete failure when Apple tried it, and apple will probably never try that strategy ever again”
    from the article:
    “The Eternal Death of Yellow Box
    After failing for NeXT as OpenStep, and again for Apple as Yellow Box, it is very unlikely that Apple will ever attempt to reintroduce the Yellow Box strategy for developing cross platform applications.”
    So, I’m not sure how to derive anything from that which is in support of your point. It seems to me more that diluting the special character of a particular OS’s UI, by trying to be cross platform consistent will probably fail. Where you see products with this strategy succeeding, they are succeeding in spite of that strategy, not because of it.

  • Mark Alan Thomas — 11:09 PM on September 20, 2009

    On the 128bit, not sure it would happen, as there isn’t much point. 64bit can address 16 exabytes of ram.
    That sounds an awful lot like Bill Gates famously declaring that nobody would ever need more than 640k of memory.*
    My first computer had 1 MB of RAM. Back then, the notion of having 4 GB would have seemed as ludicrous as having 16 exabytes seems today.
    (*Gates now denies ever having said it, though.)

  • Jay — 7:08 PM on September 21, 2009

    I just installed Photoshop CS4 for Windows and I literally feel nauseated at what Adobe has done to the window’s interface. I cannot STAND apps that do not adhere to the native look of the OS. I can forgive some things, but completely removing the native titlebar and window controls makes me want to throw up. I don’t know how to say it any stronger. I am seriously contemplating just continuing to use CS3, I hate it that much.
    If anyone at Adobe ever listens to their customers, CUT IT OUT with your God awful “self-branded” user interfaces!

Copyright © 2014 Adobe Systems Incorporated. All rights reserved.
Terms of Use | Privacy Policy and Cookies (Updated)