4 ms·

Microsoft actively maintains backward compatibility for Windows programs that are decades old. Apple reliably breaks waves of apps on a yearly schedule. You ca

Microsoft actively maintains backward compatibility for Windows programs that are decades old. Apple reliably breaks waves of apps on a yearly schedule. You can't take one company's culture and apply it to a radically different one.

coldtea 10y ago
>Apple reliably breaks waves of apps on a yearly schedule. Not by suddenly stopping support for their previously sole language, so it's a moot point. At worse, they deprecate some APIs.
- bangonkeyboard 10y ago
  The point is not moot as concerns the comparison I was responding to, and illustrates the attitude at Apple toward software and software developers, which is relevant to the topic at hand. If you are not using or targeting the latest version of Apple's releases, they do not care about you. If you do not correctly interpret the often implicit clues to their future directions, and sometimes even when you do, they will pull the rug out from under you with no compunctions. Except -- and this is really fun, thanks, Apple! -- I believe the current OSX build will no longer work as a screen saver on MacOS 10.6. It will work on 10.5, and 10.7+, though. That's because 10.6 was the one and only version of OSX in which ScreenSaverEngine required .saver bundles to use garbage collection, and the latest release of Xcode has dropped support for emitting GC-optional code entirely. So I can no longer compile a version that will run on 10.6. Also apparently the new app-store submission process requires that you set the minimum iOS version to 5.1.1 or newer if you want to include a 64-bit executable at all, despite the fact that the 32-bit executable runs just fine on iOS 3. Thanks again, Apple! Enforced obsolescence. Ain't it grand? [0] > At worse, they deprecate some APIs. That would be very surprising news to iOS developers at large, I'm sure. [0]: https://www.jwz.org/blog/2014/03/dali-clock-2-41/ https://www.jwz.org/blog/2014/03/dali-clock-2-41/
  - comex 10y ago
    Be careful - your post mixes two different types of compatibility. Compatibility between new software and old OSes is something Apple cares very little about, broadly speaking. In Apple's view, you should be on the latest OS, and if your hardware doesn't support that then you should get new hardware. This goes especially for iOS. For example, Xcode out of the box won't even let you target an iOS version older than 8.0 (late 2014), although you can target macOS down to 10.6 (2009). And Apple usually doesn't backport security updates to previous major versions of iOS, and only goes two versions back (two years) on macOS. So neither of the examples in your quote are too surprising. At the time the article was written, Apple didn't care about iOS 3 or macOS 10.6. If you want to support 'ancient' OS versions, that's your problem. On the other hand, Apple cares more about compatibility between old software and new OSes, though not nearly as much as, say, Microsoft. For example, the post mentions garbage collection. Objective-C garbage collection was never supported on iOS (2008) and was officially deprecated in 2012 with the release of ARC; Xcode stopped supporting it in 2014, but macOS continued to support existing binaries until Sierra (2016). Now, this is arguably a pretty aggressive deprecation schedule, but ObjC garbage collection had relatively little adoption throughout its life, and had a significant maintenance burden. (Among other things, in the past it was impossible to use ARC libraries in an GC app, meaning all of Apple's system frameworks had to use manual retain-release; AFAIK though this was later fixed, some time before support was removed.) In any case, Apple added a tool to Xcode that could automatically migrated most GC code to ARC. On the other hand, 32-bit binaries are still supported in macOS even though macOS has supported 64-bit CPUs since 10.4 (2005!) and required them since 10.7 (2011). I guess there was more adoption than GC, and Apple didn't want to break stuff. As usual, iOS is more aggressive: there are rumors support for 32-bit binaries on 64-bit devices will be removed in the next minor 10.x; iOS has supported 64-bit since 2013, though it currently still runs on 32-bit devices. Even so, that's >3 years for what in most cases is just a recompile. Deprecating Swift would be massively more disruptive than either of those, as migrating off it would require complete rewrites. The only analogy I can think of is Carbon, which Apple famously refused to port to 64-bit, requiring Adobe applications to have their UI layer rewritten for Cocoa. But Carbon was meant to be a transitional API since it was released with the very first version of OS X in 2001. It would be 6 years before the transition to 64-bit started, and as I said, 32-bit binaries are still supported today. The only possible reason Apple might be more aggressive with a hypothetical Swift deprecation is its relative newness and the resulting relative scarcity of existing code (but there's still a fair amount). But then, Swift has already been out for several years, and it's clearly not going to be deprecated anytime soon, given the current level of enthusiasm by Apple and others. If for some odd reason Apple decided to deprecate it, it wouldn't be for several more years, at which point there would be even more existing code.
- dkonofalski 10y ago
  And when they do deprecate APIs, you've gotten a warning for at least the last 3 versions of Xcode that the API is going to be deprecated.

coldtea 10y ago

>Apple reliably breaks waves of apps on a yearly schedule. Not by suddenly stopping support for their previously sole language, so it's a moot point. At worse, they deprecate some APIs.

bangonkeyboard 10y ago
The point is not moot as concerns the comparison I was responding to, and illustrates the attitude at Apple toward software and software developers, which is relevant to the topic at hand. If you are not using or targeting the latest version of Apple's releases, they do not care about you. If you do not correctly interpret the often implicit clues to their future directions, and sometimes even when you do, they will pull the rug out from under you with no compunctions. Except -- and this is really fun, thanks, Apple! -- I believe the current OSX build will no longer work as a screen saver on MacOS 10.6. It will work on 10.5, and 10.7+, though. That's because 10.6 was the one and only version of OSX in which ScreenSaverEngine required .saver bundles to use garbage collection, and the latest release of Xcode has dropped support for emitting GC-optional code entirely. So I can no longer compile a version that will run on 10.6. Also apparently the new app-store submission process requires that you set the minimum iOS version to 5.1.1 or newer if you want to include a 64-bit executable at all, despite the fact that the 32-bit executable runs just fine on iOS 3. Thanks again, Apple! Enforced obsolescence. Ain't it grand? [0] > At worse, they deprecate some APIs. That would be very surprising news to iOS developers at large, I'm sure. [0]: https://www.jwz.org/blog/2014/03/dali-clock-2-41/ https://www.jwz.org/blog/2014/03/dali-clock-2-41/
- comex 10y ago
  Be careful - your post mixes two different types of compatibility. Compatibility between new software and old OSes is something Apple cares very little about, broadly speaking. In Apple's view, you should be on the latest OS, and if your hardware doesn't support that then you should get new hardware. This goes especially for iOS. For example, Xcode out of the box won't even let you target an iOS version older than 8.0 (late 2014), although you can target macOS down to 10.6 (2009). And Apple usually doesn't backport security updates to previous major versions of iOS, and only goes two versions back (two years) on macOS. So neither of the examples in your quote are too surprising. At the time the article was written, Apple didn't care about iOS 3 or macOS 10.6. If you want to support 'ancient' OS versions, that's your problem. On the other hand, Apple cares more about compatibility between old software and new OSes, though not nearly as much as, say, Microsoft. For example, the post mentions garbage collection. Objective-C garbage collection was never supported on iOS (2008) and was officially deprecated in 2012 with the release of ARC; Xcode stopped supporting it in 2014, but macOS continued to support existing binaries until Sierra (2016). Now, this is arguably a pretty aggressive deprecation schedule, but ObjC garbage collection had relatively little adoption throughout its life, and had a significant maintenance burden. (Among other things, in the past it was impossible to use ARC libraries in an GC app, meaning all of Apple's system frameworks had to use manual retain-release; AFAIK though this was later fixed, some time before support was removed.) In any case, Apple added a tool to Xcode that could automatically migrated most GC code to ARC. On the other hand, 32-bit binaries are still supported in macOS even though macOS has supported 64-bit CPUs since 10.4 (2005!) and required them since 10.7 (2011). I guess there was more adoption than GC, and Apple didn't want to break stuff. As usual, iOS is more aggressive: there are rumors support for 32-bit binaries on 64-bit devices will be removed in the next minor 10.x; iOS has supported 64-bit since 2013, though it currently still runs on 32-bit devices. Even so, that's >3 years for what in most cases is just a recompile. Deprecating Swift would be massively more disruptive than either of those, as migrating off it would require complete rewrites. The only analogy I can think of is Carbon, which Apple famously refused to port to 64-bit, requiring Adobe applications to have their UI layer rewritten for Cocoa. But Carbon was meant to be a transitional API since it was released with the very first version of OS X in 2001. It would be 6 years before the transition to 64-bit started, and as I said, 32-bit binaries are still supported today. The only possible reason Apple might be more aggressive with a hypothetical Swift deprecation is its relative newness and the resulting relative scarcity of existing code (but there's still a fair amount). But then, Swift has already been out for several years, and it's clearly not going to be deprecated anytime soon, given the current level of enthusiasm by Apple and others. If for some odd reason Apple decided to deprecate it, it wouldn't be for several more years, at which point there would be even more existing code.
dkonofalski 10y ago
And when they do deprecate APIs, you've gotten a warning for at least the last 3 versions of Xcode that the API is going to be deprecated.