The windows 10 built in apps are terrible and not progressing at all compared to their counterparts on ios and Android. At this point why not just port the ipad apps to Windows and use them as the built in apps? It would save on development, bring higher quality apps to Windows and improve the ios bridge technology. It may even encourage other developers to port to Windows 10. I’m terms of look and feel I’d actually convert the ipad apps to a windows 10 fluent design like the one found on edge for ios.
Speaking of which has a single app ever been converter from ios to Windows 10?
skane2600
<blockquote><a href="#208831"><em>In reply to MutualCore:</em></a></blockquote><p>Given that the WP is essentially dead, I don't think comparisons between iOS and UWP on full Windows are very informative. Native apps don't really enjoy much advantage over browser apps that do the same thing in an environment where a large display makes browsing comfortable. </p>
skane2600
<p>I don't see much benefit in porting iOS or Android apps to Windows. Perhaps a specific example of a superior iOS or Android app would make your point clearer. Keep in mind that it's iOS or Android vs ALL Windows programs, not just UWP apps. Had WP been successful, UWP would have been important on it's own, but it didn't turn out that way.</p><p><br></p><p><br></p>
skane2600
<blockquote><a href="#208547"><em>In reply to hrlngrv:</em></a></blockquote><p>I agree. As I've claimed on numerous occasions the whole "write once run anywhere" goal is a fool's errand. </p>
skane2600
<blockquote><a href="#208594"><em>In reply to hrlngrv:</em></a></blockquote><p>It depends on the sophistication of the application and how much platform-specific code exists in the code base. Console applications are of course the low-hanging fruit. Also one has been able to use #ifdefs and similar approaches for a long time but that's just coupling multiple platform code segments into a single code base. </p><p><br></p><p>The final dilemma is usually the question of whether an application's UI should look and perform identically on each platform or conform to the look and behavior of the specific platform it is running on. Often it doesn't fully achieve either of those goals.</p>
skane2600
<blockquote><a href="#208762"><em>In reply to hrlngrv:</em></a></blockquote><p>I didn't argue that companies never make products that are available for different platforms. That doesn't necessarily qualify them as WORA. </p>
skane2600
<blockquote><a href="#208832"><em>In reply to hrlngrv:</em></a></blockquote><p>The reason I'm so picky about this issue is both because of the hype surrounding WORA or "Universal" that I believe is misleading, but also the implicit technical argument that a single code base for multiple platforms (however convoluted) is always better. </p><p><br></p><p>As with everything else it's a matter of judgement, context, and trade-offs. If OS-specific code is included (whether through run-time checks or conditional compilation) the complexity of the code is increased. One has to weigh that complexity against the advantages a single code base can provide. </p><p><br></p><p>In many cases (IMO) creating a library of "business logic" functions that don't depend on the OS or the UI and then creating OS-specific builds each with it's own UI code can be no more work than trying to integrate everything into a single build.</p><p><br></p><p>As I said, it's a matter of judgement.</p>
skane2600
<blockquote><a href="#208464"><em>In reply to alissa914g:</em></a></blockquote><p>Using XAML you can create very sophisticated styling and behavior. In fact, I would argue that the MS's focus on sophisticated scenarios to the determent of simple ones is a weakness of UWP relative to what came before. </p><p><br></p><p>I just don't think most developers put the effort in to make their UWP apps attractive and given the limited profit their apps can generate I don't blame them. </p>
skane2600
<blockquote><a href="#209273"><em>In reply to jimchamplin:</em></a></blockquote><p>Your use of caps, your assumption that you are the only one interested in new technology and your silly "APE EE EYE" shtick is really getting old.</p>
skane2600
<blockquote><a href="#209187"><em>In reply to hrlngrv:</em></a></blockquote><p>I agree. I think RT was designed as a mobile-first platform and UWP inherits that initial bias. </p>
skane2600
<blockquote><a href="#209277"><em>In reply to MutualCore:</em></a></blockquote><p>If you need the capability it's a negative for both platforms.</p>
skane2600
<blockquote><a href="#209437"><em>In reply to jimchamplin:</em></a></blockquote><p>Win32 programs by default allow multiple instances which means both that no extra work to spawn new windows is required and that users can use multiple instances in a creative way that the author of the application didn't anticipate. This is recurring theme in the comparison between Win32 and UWP, the former puts more power and control into the hands of the user.</p>
skane2600
<blockquote><a href="#209260"><em>In reply to jimchamplin:</em></a></blockquote><p>" If you design for a large window first, and then design it to scale down then it's fucking fantastic."</p><p><br></p><p>You have to do just the opposite. You have to consider the smaller screen from the beginning or it won't work in the general case. Scaling can't solve all of these problems because small items designed for a large screen become unusable on a small screen even if the scaling is perfect. In addition sometimes the optimum choice for an on-screen object is different for a large and small screen.</p><p><br></p><p>That's not to say that with careful planning you can't create an application that works well on large and small screens, but it won't always work and you don't usually get that flexibility for free.</p>
skane2600
<blockquote><a href="#209436"><em>In reply to jimchamplin:</em></a></blockquote><p>Pro Tip: Blaming bad posts on being drunk doesn't increase your credibility. </p><p><br></p><p>Yes, if you create multiple layouts for large and small screens you can, to a degree, optimize for both just as you can do in Win32 programs or through any screen API. UWP might save you the trouble of detecting the screen size and changing the layout programmatically and thus make the process a bit easier, but the real work is in creating the multiple layouts. The layout system can't do all the work for you because it has no idea what you have in mind.</p>
skane2600
<blockquote><a href="#209507"><em>In reply to jimchamplin:</em></a></blockquote><p>:)</p>