4 ms·

Apple has broken compatibility plenty of times When Apple breaks compatibility, I have to tweak the Objective-C code I've been toting around for ten years. Whe

Apple has broken compatibility plenty of times When Apple breaks compatibility, I have to tweak the Objective-C code I've been toting around for ten years. When Microsoft broke WinMo compatibility, you burned it to the ground and started over.

scarface74 8y ago
Were you around for either the 68K to PPC transition, the PPC to x86 transition or have you had to move from Carbon to Cocoa?
- craftyguy 8y ago
  Apple was using x86 10 years ago, so I would assume the former..
- mikestew 8y ago
  I was not writing Objective-C code for any of those on mobile platforms, which is the topic at hand. EDIT: though in rereading your original comment, it's a fair question. Yes, I was around. No, I still don't think it applies. Even considering desktop, IMO Apple made great efforts to make such transitions at least somewhat seamless. In more than one instance, Microsoft's mobile message was: "that app won't run on the new OS without a lot of work."
WorldMaker 8y ago
If you burned it to the ground and started over, that may have also been on you. The amount of code that was capable to run unchanged between 6.5 (CF), 7 (Silverlight-like-CF), 8.1+ (.NET Core) was very high. Sure, there was a ton of churn between 6.5's horrid WinForms fork, 7's Silverlight XAML, 8's .NET Core-ish version of Silverlight-ish XAML, and 10's WinRT XAML, but if the majority of your app wasn't just UI code-behind (at which point, why not rearchitect to a good MVVM pattern or relative?), transitioning that XAML should have been simple.
- ThrowawayR2 8y ago
  Perhaps he's referring to the Win32-style apps that were the norm on Windows Mobile 6.0 and earlier? There was an huge number of apps (for that era anyway) that were obsoleted by the transition away from that paradigm.
  - WorldMaker 8y ago
    Yeah, it is possible that it could have been written in C/C++ Win32-ish COM. Though Microsoft was never subtle in Windows Mobile <= 6.5 in telling developers they should only use .NET Compact Framework's System.Windows.Forms fork on that platform, as opposed to Desktop Windows where it has seemed far too subtle in their framework recommendations (partly because they were far too divided internally in the Desktop space). As I said, from that perspective, most Compact Framework code should have worked in Silverlight other than UI rewrite because the Silverlight runtime wasn't far from CF. It needed a recompile, but not necessarily a rewrite, in theory. (Though obviously theory and practice are very different things.)

scarface74 8y ago

Were you around for either the 68K to PPC transition, the PPC to x86 transition or have you had to move from Carbon to Cocoa?

craftyguy 8y ago
Apple was using x86 10 years ago, so I would assume the former..
mikestew 8y ago
I was not writing Objective-C code for any of those on mobile platforms, which is the topic at hand. EDIT: though in rereading your original comment, it's a fair question. Yes, I was around. No, I still don't think it applies. Even considering desktop, IMO Apple made great efforts to make such transitions at least somewhat seamless. In more than one instance, Microsoft's mobile message was: "that app won't run on the new OS without a lot of work."

WorldMaker 8y ago

If you burned it to the ground and started over, that may have also been on you. The amount of code that was capable to run unchanged between 6.5 (CF), 7 (Silverlight-like-CF), 8.1+ (.NET Core) was very high. Sure, there was a ton of churn between 6.5's horrid WinForms fork, 7's Silverlight XAML, 8's .NET Core-ish version of Silverlight-ish XAML, and 10's WinRT XAML, but if the majority of your app wasn't just UI code-behind (at which point, why not rearchitect to a good MVVM pattern or relative?), transitioning that XAML should have been simple.

ThrowawayR2 8y ago
Perhaps he's referring to the Win32-style apps that were the norm on Windows Mobile 6.0 and earlier? There was an huge number of apps (for that era anyway) that were obsoleted by the transition away from that paradigm.
- WorldMaker 8y ago
  Yeah, it is possible that it could have been written in C/C++ Win32-ish COM. Though Microsoft was never subtle in Windows Mobile <= 6.5 in telling developers they should only use .NET Compact Framework's System.Windows.Forms fork on that platform, as opposed to Desktop Windows where it has seemed far too subtle in their framework recommendations (partly because they were far too divided internally in the Desktop space). As I said, from that perspective, most Compact Framework code should have worked in Silverlight other than UI rewrite because the Silverlight runtime wasn't far from CF. It needed a recompile, but not necessarily a rewrite, in theory. (Though obviously theory and practice are very different things.)