4 ms·

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 re

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.
- bangonkeyboard 10y ago
  Note that I do not agree with the premise of the topic article, but then, even the author positions it as a low-probability thought experiment. I take the standard position that Apple is betting on Swift. What I do not believe, and what I am arguing against, is that Objective-C will continue to be supported as an equally first-class development language. Apple fundamentally does prefer simplicity, and whenever there are two ways to achieve something one is likely to be pared, and probably not the new and shiny one. Apple can lose interest rapidly, and any API or technology that has fallen out of favor will simply and intentionally be allowed to rot. OpenGL on the Mac is stuck at a version from 2010 while Apple instead pushes its in-house Metal. Dashboard is a vestigial growth that hasn't even garnered enough attention to be cut off. My examples were meant to illustrate that Apple will not put resources into supporting much more than the minimum if it can help it, and that extends to development. As you have noted, iOS is on an accelerated schedule when it comes to switching to new tech, and this is possible due to Apple's much greater control of the platform and its developers. Given the sheer amount of app breakage in the Store from release to release, my impression is that Apple cares less about old software compatibility on iOS than it does on the Mac; and of course, they also care much less about the Mac than iOS. The Objective-C runtime will continue to limp along behind Swift on the Mac, but I think that the day that Apple decrees that all new iOS applications must be written in Swift is coming sooner than some expect. > But Carbon was meant to be a transitional API since it was released with the very first version of OS X in 2001. To my recollection, this was not quite so clear-cut at the time, at least to the public. Apple continued to maintain and add to Carbon in the years up to the 64-bit transition, releasing new Carbon sample code even as Cocoa got most of their attention. It was relatively common to mistakenly believe that the two APIs were simply different abstraction levels for the same functionality [0], and there were no serious signs of the imminent deprecation until around the five year mark. There is probably a historical lesson here. [0]: http://archive.oreilly.com/pub/a/mac/2001/05/23/cocoa_vs_carbon.html http://archive.oreilly.com/pub/a/mac/2001/05/23/cocoa_vs_car...
  - pvg 10y ago
    It was quite clear cut, even though you've found one person who was either confused or trying to be colorfully contrarian. But the analogy to Carbon (or some other old tech/new tech switch) is really poor because Swift is just a language. There are no new Swift-based frameworks yet. After a few years of development, Swift itself is not a (let a lone the) true 'first class' language on Apple devices - that's still Objective C. It's going to take quite a while for Swift to assume that role, even if you think Apple is in a big hurry to accomplish that. There isn't much evidence of that to begin with.

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.

bangonkeyboard 10y ago
Note that I do not agree with the premise of the topic article, but then, even the author positions it as a low-probability thought experiment. I take the standard position that Apple is betting on Swift. What I do not believe, and what I am arguing against, is that Objective-C will continue to be supported as an equally first-class development language. Apple fundamentally does prefer simplicity, and whenever there are two ways to achieve something one is likely to be pared, and probably not the new and shiny one. Apple can lose interest rapidly, and any API or technology that has fallen out of favor will simply and intentionally be allowed to rot. OpenGL on the Mac is stuck at a version from 2010 while Apple instead pushes its in-house Metal. Dashboard is a vestigial growth that hasn't even garnered enough attention to be cut off. My examples were meant to illustrate that Apple will not put resources into supporting much more than the minimum if it can help it, and that extends to development. As you have noted, iOS is on an accelerated schedule when it comes to switching to new tech, and this is possible due to Apple's much greater control of the platform and its developers. Given the sheer amount of app breakage in the Store from release to release, my impression is that Apple cares less about old software compatibility on iOS than it does on the Mac; and of course, they also care much less about the Mac than iOS. The Objective-C runtime will continue to limp along behind Swift on the Mac, but I think that the day that Apple decrees that all new iOS applications must be written in Swift is coming sooner than some expect. > But Carbon was meant to be a transitional API since it was released with the very first version of OS X in 2001. To my recollection, this was not quite so clear-cut at the time, at least to the public. Apple continued to maintain and add to Carbon in the years up to the 64-bit transition, releasing new Carbon sample code even as Cocoa got most of their attention. It was relatively common to mistakenly believe that the two APIs were simply different abstraction levels for the same functionality [0], and there were no serious signs of the imminent deprecation until around the five year mark. There is probably a historical lesson here. [0]: http://archive.oreilly.com/pub/a/mac/2001/05/23/cocoa_vs_carbon.html http://archive.oreilly.com/pub/a/mac/2001/05/23/cocoa_vs_car...
- pvg 10y ago
  It was quite clear cut, even though you've found one person who was either confused or trying to be colorfully contrarian. But the analogy to Carbon (or some other old tech/new tech switch) is really poor because Swift is just a language. There are no new Swift-based frameworks yet. After a few years of development, Swift itself is not a (let a lone the) true 'first class' language on Apple devices - that's still Objective C. It's going to take quite a while for Swift to assume that role, even if you think Apple is in a big hurry to accomplish that. There isn't much evidence of that to begin with.