3 ms·

We've had this argument more than once and I still disagree with that take. I took a .NET application through those transitions and there was never a "from scra

We've had this argument more than once and I still disagree with that take. I took a .NET application through those transitions and there was never a "from scratch rewrite" step at any point. A lot of cheese moved and there was sometimes quite a bit of XAML shifts to meet new UI expectations, but most of the business logic code stayed the same or barely changed. On the other side, I've seen Apple enforce equal or worse "enforced" rewrites between major iOS versions with not even a fraction of the complaints Microsoft got across those product versions. (I had more inconvenience moving apps back and forth between WPF and Silverlight in some of the years prior, and even those moves were never from-scratch rewrites. Admittedly that may have left me with more skills to handle XAML changes and write to lowest common denominator XAML, so I am aware of my biases.) I realize you aren't ever going to agree with me on this, and I don't expect you to. I do think it is still useful for other people to see that there are counter-opinions here.

int_19h 4y ago
Apple can get away with a lot more given its dominant market position (esp. when it comes to delivering paying customers to app authors). But when you're the new scrappy contender with minimal market share, so you need the devs to make apps for your store rather than the other way around, it better be smooth sailing all around.
pjmlp 4y ago
A rewrite is a rewrite, even if only one line changes. Not going to bother to list everything that changed, it is public available for anyone to judge.
karmakaze 4y ago
The difference of course is that iOS already has enough adoption to get away with this. Windows Phone and Windows UI development forked for no good reason while keeping very similar names and structures while trying to get initial adoption. It was clearly a mistake at that stage. I personally looked into the tech and as soon as I saw how fragmented it was realized MS didn't have a good plan and didn't venture developing for it.
- WorldMaker 4y ago
  Windows Phone 7 was pretty clear [1] it was a temporary platform (bootstrapped on Silverlight) while they waited for the engineering projects that were to become Windows Phone 8 finished. Microsoft helped pay to migrate some projects across that hump and there was a migration story. That's the only "hard fork" between the versions. I know a lot of people (including respondents in neighboring comments) saw the changes between WP8 and WP10 as a big deal "soft fork", but very little actually changed other than a UI library upgrade from 1.x to 2.x. (In .NET; JS was dropped in 2.x and C/C++ developers saw some other shenanigans. But JS and C/C++ didn't exist in WP7 either so none of those developers saw all three "migrations" either.) I hear a lot from developers that it seemed very fragmented, but working in it at the time, it seemed very "incremental" at best, mostly just upgrading library major versions and dealing with semver major breaking breaks. Sure, that's frustrating when that's not your primary development environment and also you aren't getting paid enough for it because adoption is low, but that is a very far cry from "Microsoft didn't have a good plan". They were iterating hard on it. They made some semver breaks that other library authors in other ecosystems could get away with no problem, even with equally low adoption (looking at random JS libraries here). It's easy to blame low adoption for making those semver major breaks seem more painful and "fragmented" than they actually were in practice, but sometimes it just also looks like that was an excuse to ignore the platform more than a problem for development experience reality. (As you seem to state that you skipped the platform entirely, possibly because you were looking for an excuse to skip it and latched onto the first one you saw.) [1] Obviously not clear enough for some.
  - karmakaze 4y ago
    IIRC, there was also dev kits for Windows RT around the same time with the same or similar names which added to incompatibilities and confusion. The only sharable source was non-UI core code, or perhaps hand-altered variations of UI file type contents. It's one thing to develop versions for Android, iOS, and Windows Phone. It's another if the UX source elements can't be shared within the MS ecosystem Phone, RT, x86 metro apps.
  - pjmlp 4y ago
    This is clearly not just upgrading libraries. https://learn.microsoft.com/en-us/previous-versions/windows/apps/br230302(v=vs.140) https://learn.microsoft.com/en-us/previous-versions/windows/... https://learn.microsoft.com/en-us/cpp/porting/porting-to-the-universal-windows-platform-cpp?view=msvc-170#BK_81Component https://learn.microsoft.com/en-us/cpp/porting/porting-to-the... https://learn.microsoft.com/en-us/archive/msdn-magazine/2014/october/universal-windows-apps-reuse-code-assets-with-universal-windows-apps https://learn.microsoft.com/en-us/archive/msdn-magazine/2014... https://learn.microsoft.com/en-us/windows/uwp/porting/wpsl-to-uwp-root https://learn.microsoft.com/en-us/windows/uwp/porting/wpsl-t... https://learn.microsoft.com/en-us/windows/uwp/porting/w8x-to-uwp-root https://learn.microsoft.com/en-us/windows/uwp/porting/w8x-to...

int_19h 4y ago

Apple can get away with a lot more given its dominant market position (esp. when it comes to delivering paying customers to app authors). But when you're the new scrappy contender with minimal market share, so you need the devs to make apps for your store rather than the other way around, it better be smooth sailing all around.

pjmlp 4y ago

A rewrite is a rewrite, even if only one line changes. Not going to bother to list everything that changed, it is public available for anyone to judge.

karmakaze 4y ago

The difference of course is that iOS already has enough adoption to get away with this. Windows Phone and Windows UI development forked for no good reason while keeping very similar names and structures while trying to get initial adoption. It was clearly a mistake at that stage. I personally looked into the tech and as soon as I saw how fragmented it was realized MS didn't have a good plan and didn't venture developing for it.

WorldMaker 4y ago
Windows Phone 7 was pretty clear [1] it was a temporary platform (bootstrapped on Silverlight) while they waited for the engineering projects that were to become Windows Phone 8 finished. Microsoft helped pay to migrate some projects across that hump and there was a migration story. That's the only "hard fork" between the versions. I know a lot of people (including respondents in neighboring comments) saw the changes between WP8 and WP10 as a big deal "soft fork", but very little actually changed other than a UI library upgrade from 1.x to 2.x. (In .NET; JS was dropped in 2.x and C/C++ developers saw some other shenanigans. But JS and C/C++ didn't exist in WP7 either so none of those developers saw all three "migrations" either.) I hear a lot from developers that it seemed very fragmented, but working in it at the time, it seemed very "incremental" at best, mostly just upgrading library major versions and dealing with semver major breaking breaks. Sure, that's frustrating when that's not your primary development environment and also you aren't getting paid enough for it because adoption is low, but that is a very far cry from "Microsoft didn't have a good plan". They were iterating hard on it. They made some semver breaks that other library authors in other ecosystems could get away with no problem, even with equally low adoption (looking at random JS libraries here). It's easy to blame low adoption for making those semver major breaks seem more painful and "fragmented" than they actually were in practice, but sometimes it just also looks like that was an excuse to ignore the platform more than a problem for development experience reality. (As you seem to state that you skipped the platform entirely, possibly because you were looking for an excuse to skip it and latched onto the first one you saw.) [1] Obviously not clear enough for some.
- karmakaze 4y ago
  IIRC, there was also dev kits for Windows RT around the same time with the same or similar names which added to incompatibilities and confusion. The only sharable source was non-UI core code, or perhaps hand-altered variations of UI file type contents. It's one thing to develop versions for Android, iOS, and Windows Phone. It's another if the UX source elements can't be shared within the MS ecosystem Phone, RT, x86 metro apps.
- pjmlp 4y ago
  This is clearly not just upgrading libraries. https://learn.microsoft.com/en-us/previous-versions/windows/apps/br230302(v=vs.140) https://learn.microsoft.com/en-us/previous-versions/windows/... https://learn.microsoft.com/en-us/cpp/porting/porting-to-the-universal-windows-platform-cpp?view=msvc-170#BK_81Component https://learn.microsoft.com/en-us/cpp/porting/porting-to-the... https://learn.microsoft.com/en-us/archive/msdn-magazine/2014/october/universal-windows-apps-reuse-code-assets-with-universal-windows-apps https://learn.microsoft.com/en-us/archive/msdn-magazine/2014... https://learn.microsoft.com/en-us/windows/uwp/porting/wpsl-to-uwp-root https://learn.microsoft.com/en-us/windows/uwp/porting/wpsl-t... https://learn.microsoft.com/en-us/windows/uwp/porting/w8x-to-uwp-root https://learn.microsoft.com/en-us/windows/uwp/porting/w8x-to...