4 ms·

This justification is one of the most astonishingly vapid ones around. I'm not quite sure how it keeps getting repeated as if it has credence, when technically

by ergo98 17y ago

This justification is one of the most astonishingly vapid ones around. I'm not quite sure how it keeps getting repeated as if it has credence, when technically it has no legs to stand on. The distinction Apple is making is that they have a temporary mindspace monopoly of the smartphone markets and they want to cement it in by forcing developers to help the Apple cause.

roc 17y ago
> I'm not quite sure how it keeps getting repeated as if it has credence, when technically it has no legs to stand on. So you've never encountered a standard/API/platform that perpetuates bugs, support for bad practices or misuse of old interfaces to avoid breaking legacy apps?
- bad_user 17y ago
  Good platforms get updated instantly and aren't using too many unofficial APIs. If something so awful happens on an upgrade that it breaks such a middle layer, it will also break many native apps which will also need upgrades. Also, applications written for cross-platform development tools are higher-level and for complying with any new interfaces you may have it's just a matter of rewriting some bindings. In case the change is so radical that it needs architectural changes (like from Carbon to Cocoa), you can always force tool vendors to update their platforms by pulling out Carbon completely (how could they do that if some of their own apps are still on Carbon?) In fact I would bet that applications on stuff like MonoTouch would've gotten upgraded from Carbon to Cocoa a lot faster than native apps were. Really, you're setting up a strawman argument.
  - roc 17y ago
    It's hardly a strawman. The history of personal computing is littered with examples of this, many of which have been covered ad nauseum during this 3.3.1 debate. Your argument, in contrast, is alternately "that doesn't/won't happen" or "that's no big deal". Which is an assertion that stands against the piles of evidence that it does and is, and an assertion you don't back up at all. Why should middle-ware be different this time? For the record, I don't think middle-ware decay is a reasonable argument for Apple disallowing it. (I do think it's the argument against developers relying on it.) I'm just getting rather tired of people either misrepresenting or ignoring the other side of an argument. There's plenty there to disagree with. It makes no sense to pretend that middle-ware decay doesn't or --for unspecified reasons-- simply won't happen this time.
wtallis 17y ago
All the technical justification you need can be had from Adobe's other half, which only 3 days ago shipped their first Photoshop for Mac which doesn't use Mac OS Classic GUI APIs. Adobe's delay in switching to the more modern APIs is the reason why they couldn't ship a 64-bit Photoshop for Mac until now. As Jobs has explained, they've been burned before.
- ergo98 17y ago
  >All the technical justification you need can be had from Adobe's other half, which only 3 days ago shipped their first Photoshop for Mac which doesn't use Mac OS Classic GUI APIs. Humorous given that Apple has several very prominent apps (iTunes, Final Cut Pro) that still have made the migration. And they control both sides! However that is irrelevant. Tell me again how, if Apple revises the API, that suddenly every app available will instantly morph to accommodate it? Of course that is completely and utterly asinine. It's a ridiculous argument that I can't believe knowledgeable people have, desperately trying to reach some sort of rationalization of Apple's actions.
  - cheald 17y ago
    To put it even more starkly, if Apple were to revise the API, then the middleware pushes an update, and all those hundreds or thousand of app developers simply recompile with the new OS target. All of their apps are now feature-compatible with Shiny New Feature X, rather than those hundreds or thousands of developers all having to replicate the same work. This is Frameworks 101. The entire point of an abstraction layer is to isolate a developer away from the underlying systems, to let him write more business logic and less systems support code. All modern software development is built on the concept of frameworks, layers of abstraction, and the like. Even Objective C itself is an abstraction away from the ARM11 instruction set on the iPhone's CPU. Do developers writing Objective C produce inherently inferior apps to those writing ARM11 assembly? Frameworks reduce the total number of man-hours required to produce and maintain software. I will argue that a good framework produces more high quality software than a bunch of developers all rolling apps on the metal, which then have a longer lifetime, due to the fact that fewer developer hours are required per app to maintain it moving forward. (Please note that I am not making any kind of judgment here about whether or not CS5 constitutes a "good framework".) It takes some pretty serious denial to see Jobs' case against middleware, cross-compilers, and abstraction layers as anything but an attempt to lock developers solely into the Apple ecosystem. Frameworks reduce developer hours in more than one way - they reduce the number of hours required to put your app on multiple platforms. (To put it another way, this is why we have 3D engines like Unreal and Crytek; it's why we have 3D API layers like OpenGL and DirectX. You can write a game without them, but you'll spend thousands of hours solving problems that have already been solved for no appreciable benefit.) It's abundantly clear that there is no real technical justification for the clause; Apple is attempting to increase the amount of work that developers have to do to target multiple platforms, so that they'll simply give up and pick one: Apple's.

by ergo98 17y ago

roc 17y ago

> I'm not quite sure how it keeps getting repeated as if it has credence, when technically it has no legs to stand on. So you've never encountered a standard/API/platform that perpetuates bugs, support for bad practices or misuse of old interfaces to avoid breaking legacy apps?

bad_user 17y ago
Good platforms get updated instantly and aren't using too many unofficial APIs. If something so awful happens on an upgrade that it breaks such a middle layer, it will also break many native apps which will also need upgrades. Also, applications written for cross-platform development tools are higher-level and for complying with any new interfaces you may have it's just a matter of rewriting some bindings. In case the change is so radical that it needs architectural changes (like from Carbon to Cocoa), you can always force tool vendors to update their platforms by pulling out Carbon completely (how could they do that if some of their own apps are still on Carbon?) In fact I would bet that applications on stuff like MonoTouch would've gotten upgraded from Carbon to Cocoa a lot faster than native apps were. Really, you're setting up a strawman argument.
- roc 17y ago
  It's hardly a strawman. The history of personal computing is littered with examples of this, many of which have been covered ad nauseum during this 3.3.1 debate. Your argument, in contrast, is alternately "that doesn't/won't happen" or "that's no big deal". Which is an assertion that stands against the piles of evidence that it does and is, and an assertion you don't back up at all. Why should middle-ware be different this time? For the record, I don't think middle-ware decay is a reasonable argument for Apple disallowing it. (I do think it's the argument against developers relying on it.) I'm just getting rather tired of people either misrepresenting or ignoring the other side of an argument. There's plenty there to disagree with. It makes no sense to pretend that middle-ware decay doesn't or --for unspecified reasons-- simply won't happen this time.

wtallis 17y ago

All the technical justification you need can be had from Adobe's other half, which only 3 days ago shipped their first Photoshop for Mac which doesn't use Mac OS Classic GUI APIs. Adobe's delay in switching to the more modern APIs is the reason why they couldn't ship a 64-bit Photoshop for Mac until now. As Jobs has explained, they've been burned before.

ergo98 17y ago
>All the technical justification you need can be had from Adobe's other half, which only 3 days ago shipped their first Photoshop for Mac which doesn't use Mac OS Classic GUI APIs. Humorous given that Apple has several very prominent apps (iTunes, Final Cut Pro) that still have made the migration. And they control both sides! However that is irrelevant. Tell me again how, if Apple revises the API, that suddenly every app available will instantly morph to accommodate it? Of course that is completely and utterly asinine. It's a ridiculous argument that I can't believe knowledgeable people have, desperately trying to reach some sort of rationalization of Apple's actions.
- cheald 17y ago
  To put it even more starkly, if Apple were to revise the API, then the middleware pushes an update, and all those hundreds or thousand of app developers simply recompile with the new OS target. All of their apps are now feature-compatible with Shiny New Feature X, rather than those hundreds or thousands of developers all having to replicate the same work. This is Frameworks 101. The entire point of an abstraction layer is to isolate a developer away from the underlying systems, to let him write more business logic and less systems support code. All modern software development is built on the concept of frameworks, layers of abstraction, and the like. Even Objective C itself is an abstraction away from the ARM11 instruction set on the iPhone's CPU. Do developers writing Objective C produce inherently inferior apps to those writing ARM11 assembly? Frameworks reduce the total number of man-hours required to produce and maintain software. I will argue that a good framework produces more high quality software than a bunch of developers all rolling apps on the metal, which then have a longer lifetime, due to the fact that fewer developer hours are required per app to maintain it moving forward. (Please note that I am not making any kind of judgment here about whether or not CS5 constitutes a "good framework".) It takes some pretty serious denial to see Jobs' case against middleware, cross-compilers, and abstraction layers as anything but an attempt to lock developers solely into the Apple ecosystem. Frameworks reduce developer hours in more than one way - they reduce the number of hours required to put your app on multiple platforms. (To put it another way, this is why we have 3D engines like Unreal and Crytek; it's why we have 3D API layers like OpenGL and DirectX. You can write a game without them, but you'll spend thousands of hours solving problems that have already been solved for no appreciable benefit.) It's abundantly clear that there is no real technical justification for the clause; Apple is attempting to increase the amount of work that developers have to do to target multiple platforms, so that they'll simply give up and pick one: Apple's.