> I'm a full-time iOS developer and want to share my perspective on this news.
As someone who spent the better part of the last 3 years porting things, I'll share my rebuttal :)
> I will not accept my brand being introduced on Windows or any other platform using a glorified code generator.
That's a rather negative slant on a compatibility layer - one that must exist if you're doing multiplatform dev in a reasonable fashion (i.e. not rewriting the entire application for every platform.) Granted, one you write yourself will likely suit your app's needs better.
> If I want to bring an app to Windows, I would learn the platform, go "all in" and make my app as perfect on Windows as it is on iOS. This would require me to dig into all the SDK docs, understand the platform capabilities, learn the native APIs, deal with the challenges of supporting different form factors, and a lot more.
I have never seen a perfect app in my life. Regardless, even if you want to take this route, having a compatibility layer you can lean on to get things up and running, before you begin to replace the things that aren't up to snuff, can be incredibly useful. I've repeatedly used this kind of technique to good effect - relying on banned APIs for Windows 8 ModernUI apps before replacing said calls with their WinRT equivalents, using slower POSIX I/O APIs on PS4 before replacing them with their faster platform specific equivalents, etc.
The nastiest bit of porting was always the big elephant in the room which I could not (efficiently) handle in this manner - the graphics APIs. Maybe 10-20 kloc of platform specific code, written blindly in the hopes that it would be roughly along the right lines, and that my program would one day link on the new platform.
If I was lucky, I'd be able to recognize bits and pieces of what I'd rendered on my first run. I was frequently not lucky - but a program that can run can be debugged, and so I did.
> A great app is one in which the developer has written and/or analyzed every line of code to maximize the aesthetics and performance on the platform it is running on.
That might work for small mobile apps. The projects I've worked on are simply too big to afford this kind of effort. We would much rather analyze every line of code that matters, and ship within a lifetime. Chances are, a compatibility layer will handle some things which I won't need to replace. One of the things that annoyed me greatly for my windows 8 port, was that so much had to be replaced simply because the older APIs were banned. Plenty of that code would have worked just fine to ship with, otherwise - it felt like busywork. E.g. instead of CopyFile or CopyFileEx, you'd be forced to use CopyFile2 - except the latter was unavailable on Windows 7 and earlier, so we had to keep around both versions for our platform abstraction layer. This got nastier with the OVERLAPPED I/O bits of code...
> Windows' code conversion isn't going to encourage the really good apps to migrate
Simply put, I disagree. Although we agree that it's no panacea - it's quite unlikely to be as simple as Copy, Paste, Build, Profit.
> If all it involved was learning a new language or porting some code, developers would do it
I personally know and regularly have lunch with counterexamples. Developers who insist that the only reason they're not targeting e.g. Android is that they don't want to bother porting some code. Ditto for Windows. They don't think porting some code would have an acceptable return on investment, so they don't bother with it. They already know the languages and APIs involved, too.
> just like they learned to go from Objective C to Swift
They didn't learn to do this. Neither have I - why write platform specific Objective C for my logic, unless I'm actually dealing with platform specific details? The vast majority of my code does not benefit from being platform specific, being instead written in C++, which means the vast majority of my code does not benefit from replacing Objective C with Swift.
Again: There simply isn't an acceptable return on investment. A few horror stories of Swift compiler bugs encountered by early adopters overheard in my local IRC channel helped remind me of the costs of following the latest shiny thing.
> Developers avoid Windows for far more complex, intangible reasons that go way beyond a code converter. There are all kinds of perceptions about Windows and Windows users that simply will not change because of this tool. The iOS developers I know will shrug off this announcement, and continue shipping their apps on iOS. I admire Microsoft for overcoming the technical challenges of creating this tool, but sadly they have not overcome the perception and mindset challenges of a dieing platform.
At least this I can agree with :). The cross-platform developers I know won't shrug, however - and will note that one more barrier making Windows dev not worth it has been, if not eliminated, lowered.
As someone who spent the better part of the last 3 years porting things, I'll share my rebuttal :)
> I will not accept my brand being introduced on Windows or any other platform using a glorified code generator.
That's a rather negative slant on a compatibility layer - one that must exist if you're doing multiplatform dev in a reasonable fashion (i.e. not rewriting the entire application for every platform.) Granted, one you write yourself will likely suit your app's needs better.
> If I want to bring an app to Windows, I would learn the platform, go "all in" and make my app as perfect on Windows as it is on iOS. This would require me to dig into all the SDK docs, understand the platform capabilities, learn the native APIs, deal with the challenges of supporting different form factors, and a lot more.
I have never seen a perfect app in my life. Regardless, even if you want to take this route, having a compatibility layer you can lean on to get things up and running, before you begin to replace the things that aren't up to snuff, can be incredibly useful. I've repeatedly used this kind of technique to good effect - relying on banned APIs for Windows 8 ModernUI apps before replacing said calls with their WinRT equivalents, using slower POSIX I/O APIs on PS4 before replacing them with their faster platform specific equivalents, etc.
The nastiest bit of porting was always the big elephant in the room which I could not (efficiently) handle in this manner - the graphics APIs. Maybe 10-20 kloc of platform specific code, written blindly in the hopes that it would be roughly along the right lines, and that my program would one day link on the new platform.
If I was lucky, I'd be able to recognize bits and pieces of what I'd rendered on my first run. I was frequently not lucky - but a program that can run can be debugged, and so I did.
> A great app is one in which the developer has written and/or analyzed every line of code to maximize the aesthetics and performance on the platform it is running on.
That might work for small mobile apps. The projects I've worked on are simply too big to afford this kind of effort. We would much rather analyze every line of code that matters, and ship within a lifetime. Chances are, a compatibility layer will handle some things which I won't need to replace. One of the things that annoyed me greatly for my windows 8 port, was that so much had to be replaced simply because the older APIs were banned. Plenty of that code would have worked just fine to ship with, otherwise - it felt like busywork. E.g. instead of CopyFile or CopyFileEx, you'd be forced to use CopyFile2 - except the latter was unavailable on Windows 7 and earlier, so we had to keep around both versions for our platform abstraction layer. This got nastier with the OVERLAPPED I/O bits of code...
> Windows' code conversion isn't going to encourage the really good apps to migrate
Simply put, I disagree. Although we agree that it's no panacea - it's quite unlikely to be as simple as Copy, Paste, Build, Profit.
> If all it involved was learning a new language or porting some code, developers would do it
I personally know and regularly have lunch with counterexamples. Developers who insist that the only reason they're not targeting e.g. Android is that they don't want to bother porting some code. Ditto for Windows. They don't think porting some code would have an acceptable return on investment, so they don't bother with it. They already know the languages and APIs involved, too.
> just like they learned to go from Objective C to Swift
They didn't learn to do this. Neither have I - why write platform specific Objective C for my logic, unless I'm actually dealing with platform specific details? The vast majority of my code does not benefit from being platform specific, being instead written in C++, which means the vast majority of my code does not benefit from replacing Objective C with Swift.
Again: There simply isn't an acceptable return on investment. A few horror stories of Swift compiler bugs encountered by early adopters overheard in my local IRC channel helped remind me of the costs of following the latest shiny thing.
> Developers avoid Windows for far more complex, intangible reasons that go way beyond a code converter. There are all kinds of perceptions about Windows and Windows users that simply will not change because of this tool. The iOS developers I know will shrug off this announcement, and continue shipping their apps on iOS. I admire Microsoft for overcoming the technical challenges of creating this tool, but sadly they have not overcome the perception and mindset challenges of a dieing platform.
At least this I can agree with :). The cross-platform developers I know won't shrug, however - and will note that one more barrier making Windows dev not worth it has been, if not eliminated, lowered.