I want to be, but I'm not convinced - Universal Apps

[Jas00555]

It's limited and Xamarin is a tiny company. That would change if a big dog like MSFT started doing it. Remember the platform wars back in the 1990s (Netscape was going to turn Windows into "just a bunch of buggy device drivers)? That led to the big antitrust trial.

Ah, that makes sense then. I don't really mess with Xamarin too much, so I wasn't sure how much you could do with that.

However IIRC, can't you use VS Community to make Android apps? I can't imagine Google would have a rule like "Google Play only accepts apps that were written in approved SDKs" but that's something I should probably look into

 

[manicottiK]

There might be clauses in iOS and Android SDKs about using "non-approved" tools to create programs...

If you look at what Xamarin does, XCode comes out for the iPhone. That code must be compiled on a Mac. I'm not sure that Apple could do much (directly) if MS took this route.

The bigger issue is that Xamarin uses the local controls and I doubt that MS could without forcing developers to give up a lot of flexibility/control over the UI. (For example, I do "sneaky" things with my panorama header to facilitate landscape support. I also "know" how far things are so that I can do some negative margin tricks. If native controls are used, those techniques would fail or require me to have a lot of conditional code in place. If MS ignores built-in controls, opting instead of a set provided by them, this could still work.)

I must reiterate: we have no idea if MS is even trying to do something like this. Xamarin is a partner, one that they'd be driving over if they took this strategy. This idea would really annoy Apple and Google; maybe they couldn't stop it directly, but there are all kinds of indirect actions large firms can take to make their displeasure known. Still, I have my fingers crossed.

 

[Mike Gibson]

If you look at what Xamarin does, XCode comes out for the iPhone. That code must be compiled on a Mac. I'm not sure that Apple could do much (directly) if MS took this route.

I thought that AAPL had a restriction, at least in earlier SDKs, that you couldn't write a program in a scripting language that was run on iOS. Would XAML for the UI be considered a "scripting language"? I don't know.

The bigger issue is that Xamarin uses the local controls and I doubt that MS could without forcing developers to give up a lot of flexibility/control over the UI. (For example, I do "sneaky" things with my panorama header to facilitate landscape support. I also "know" how far things are so that I can do some negative margin tricks. If native controls are used, those techniques would fail or require me to have a lot of conditional code in place. If MS ignores built-in controls, opting instead of a set provided by them, this could still work.)

If we assume MSFT defines a stripped down XAML UI layer and embedded the TrueType rasterizer, I could see them putting a complete rendering engine in an iOS or Android app generated by VS. Both use OGLES so rendering performance wouldn't be a problem. Add in more glue layers and you could have an almost completely platform-independent single source tree (which compiles to different binaries). VS is the superior development platform so I could easily see ISVs running to it.

I must reiterate: we have no idea if MS is even trying to do something like this. Xamarin is a partner, one that they'd be driving over if they took this strategy. This idea would really annoy Apple and Google; maybe they couldn't stop it directly, but there are all kinds of indirect actions large firms can take to make their displeasure known. Still, I have my fingers crossed.

You bet they would fight tooth-and-nail to screw up this plan. Lawyers must be licking their lips just thinking about it. However, if you think about it, how much different is this than apps that are effectively a shell to a website? Websites don't follow iOS or Android rules.

 

[manicottiK]

What Xamarin is doing and what I suggest Microsoft could try, is NOT running XAML on iOS. Instead, since iOS doesn't support declarative UIs or data binding the way that Windows does, the Visual Studio output of an iOS app would be a collection of Objective C code that is then moved to a Mac and compiled as any native iOS would be.

 

[spaulagain]

What Xamarin is doing and what I suggest Microsoft could try, is NOT running XAML on iOS. Instead, since iOS doesn't support declarative UIs or data binding the way that Windows does, the Visual Studio output of an iOS app would be a collection of Objective C code that is then moved to a Mac and compiled as any native iOS would be.

From my understanding the UI layer will not be XAML and will remain native to Apple. However the back-end code (C#) will be all MS and will run independently as an application rather than depending on elements of iOS to run. Xamarin is basically a set of UI controls that are written in native environment for Android and iOS. It just lets you plug in the C# to those controls.

Microsoft has already made the UI layer for Universal apps extremely flexible (XAML vs HTML/CSS/JS). Allowing for unique UI layers for Android and iOS shouldn't be that much of a stretch and is basically what Xamarin is already doing. That's why MS partnered with them.

In the CTP for Visual Studio 2015, iOS and Android are built in project types now. They are still separate from a universal apps, but they are getting pretty close to being all in one project.

 

[typhon62_1]

Why? What about going over to a completely new and separate environment like Linux which has 0% market-share effectively is more attractive then updating and migrating to the WinRT environment?

What about the Universal App thing is so damn bad that you would want a Linux app instead?

These engineering tools already run on Linux and Windows. They've put in millions of dollars to develop them and they aren't going to rewite them from the ground up anytime soon. Hell, I still have to use command line tools with most of my FPGA design tools. This will NEVER work in a Universal App environment, NEVER.
I don't hate Universal Apps, I look forward to using them, but they will be calculators, impedance calculation tools, unit converters, things I use web pages for now. Complicated design tools just won't work in an app. Like I said, if MS ditches Win32 these companies will leave the Windows desktop and just support Linux. This pisses me off because I hate Linux.

 

[typhon62_1]

I'm also curious as to the logic that would go into a decision like that. That seems very nonsensical.

See my reply to spaulagain.
To put it a different way; These design tools run on both Win32 and Linux and I'm pretty sure most of them use TCL/TK for the GUI's so its easier to support both OS's. This alone is why I'll never see Altium Designer, LabView, Xilinx, Altera, design tools in a Universal App environment. I have three monitors running with several command line windows open and 4 or 5 programs open and running. How can a Universal app do this?

​

 

[spaulagain]

These engineering tools already run on Linux and Windows. They've put in millions of dollars to develop them and they aren't going to rewite them from the ground up anytime soon. Hell, I still have to use command line tools with most of my FPGA design tools. This will NEVER work in a Universal App environment, NEVER.
I don't hate Universal Apps, I look forward to using them, but they will be calculators, impedance calculation tools, unit converters, things I use web pages for now. Complicated design tools just won't work in an app. Like I said, if MS ditches Win32 these companies will leave the Windows desktop and just support Linux. This pisses me off because I hate Linux.

First of all, Microsoft is not going to kill the Win32 environment. It will be there for years to come. My point is that to increase their audience and stay with the times, all these Win32 apps will eventually be done in WinRT. You may have niche products like the one you talk about that remain there for a while, but the majority will eventually phase over to the new environment.

Second, just because the app is a WinRT environment, doesn't mean the UI can't be complex or heavily involved. Especially for a desktop. What it means is ideally the developer would write their app such that the UI changed depending on the screen size. In this case, in desktop mode the complexity and tools would be all on the surface like AutoCAD, etc. But as the screen is smaller, these tools begin to get hidden in off canvas menus that slide in and out, etc. It's exactly what MS is doing with Touch Office. And I imagine eventually Touch Office will just be Office.

This is how Responsive websites work and there is no reason this doesn't apply to an application. In fact most advanced applications already do this to some extent, even for desktop. So people really need to get it out of their head that a WinRT app is some basic level app that has no chance of being an advanced tool with a complex UI. That's just not the case.

BTW, did they write this application you are talking about in C#, etc.? They can re-use that code, they just have to write for a different set of APIs and some other stipulations. It's not like all that code is now worthless.

Remember, Microsoft had Full Office apps and IE on the Surface (ARM). And I can tell you those were definitely not ground up re-writes (That's what Office Touch appears to be). So clearly they were able to use existing code even in the new environment.

 

[spaulagain]

See my reply to spaulagain.
To put it a different way; These design tools run on both Win32 and Linux and I'm pretty sure most of them use TCL/TK for the GUI's so its easier to support both OS's. This alone is why I'll never see Altium Designer, LabView, Xilinx, Altera, design tools in a Universal App environment. I have three monitors running with several command line windows open and 4 or 5 programs open and running. How can a Universal app do this?

​

Universal apps may not be able to do all of that right now. But I think Microsoft is making it pretty clear this is the new environment and I'm sure they'll improve flexibility like that as they continue to develop the environment. It's not like the Win32 environment was all set in stone the day it launched.

 

[a5cent]

I was thinking more in terms of games like Crysis 3 or Assassin's Creed Unity. Would it be possible for those games to be store apps that people with high-end hardware would be able to run at maximum resolution?

These types of games have few direct dependencies on the OS. The Graphics HAL (DirectX, OpenGL) or the game/gfx engine (Unity, Frostbyte, Crytek, etc) represents the biggest, OS dependent piece of software these games rely on. As a result, a games portability is usually determined (to an extent of 99%) by the middleware it uses. The thing is, most of the big game engines don't yet support the WinRT environment, but at least technically, there is no reason they couldn't.

More important than the question "can they?", is "why should they?". For example, there is no way a company like EA, who has their own Origin store, would be willing to sacrifice 30% of their revenue to MS. That by itself already means EA will never release a WinRT game (under current conditions). OTOH companies that are willing to make that sacrifice must ask themselves why they would choose the MS' app store over Steam, or pay to do both? Everyone that buys such games already has a Steam account, which includes many gaming specific features (social, sharing, trading), which MS' app store lacks. To get something that is somewhat comparable requires participation in the Xbox program, which is not something the typical PC gamer even cares about, nor is it as simple to certify for as Steam, making the MS route even less attractive.

The real question is: "how much more can devs earn by distributing their game in MS' app store, compared to just supporting steam?"... or by extension: "how much pent up demand is there from consumers to purchase such games through the app store?"...

Here too, MS has their work cut out for them.

 

[Jas00555]

These types of games have few direct dependencies on the OS. The Graphics HAL (DirectX, OpenGL) or the game/gfx engine (Unity, Frostbyte, Crytek, etc) represents the biggest, OS dependent piece of software these games rely on. As a result, a games portability is usually determined (to an extent of 99%) by the middleware it uses. The thing is, most of the big game engines don't yet support the WinRT environment, but at least technically, there is no reason they couldn't.

More important than the question "can they?", is "why should they?". For example, there is no way a company like EA, who has their own Origin store, would be willing to sacrifice 30% of their revenue to MS. That by itself already means EA will never release a WinRT game (under current conditions). OTOH companies that are willing to make that sacrifice must ask themselves why they would choose the MS' app store over Steam, or pay to do both? Everyone that buys such games already has a Steam account, which includes many gaming specific features (social, sharing, trading), which MS' app store lacks. To get something that is somewhat comparable requires participation in the Xbox program, which is not something the typical PC gamer even cares about, nor is it as simple to certify for as Steam, making the MS route even less attractive.

The real question is: "how much more can devs earn by distributing their game in MS' app store, compared to just supporting steam?"... or by extension: "how much pent up demand is there from consumers to purchase such games through the app store?"...

Here too, MS has their work cut out for them.

If I were a developer and I make a game using Unity, which I believe does support WinRT, why would I then NOT submit it to the Windows Store? It's not like I would lose money submitting it to two stores, if what you say is true and 99% of the programming is the same. I don't think we'll see EA or Ubisoft games because of their own services, but I don't see the reason not to just submit it to another store if there would be very little work involved. For example, let me ask you this. If you made an iOS app, and you only had to change 1% of it to submit in the Windows Store, wouldn't you? To me, that seems like an easy payout.

Edit: Just to clarify, this is in response to your "or pay to use both" as if there's a fee for submitting a store app. The costs to put an app in the store seems like it would be a rather trivial barrier (its a one time $20 fee).

To answer your question of "Why the Windows Store over Steam", I think Microsoft takes less of a cut. IIRC, it's 30% for the first $1000, then 20% after that.

 

[a5cent]

If I were a developer and I make a game using Unity, which I believe does support WinRT, why would I then NOT submit it to the Windows Store? It's not like I would lose money submitting it to two stores, if what you say is true and 99% of the programming is the same. I don't think we'll see EA or Ubisoft games because of their own services, but I don't see the reason not to just submit it to another store if there would be very little work involved. For example, let me ask you this. If you made an iOS app, and you only had to change 1% of it to submit in the Windows Store, wouldn't you? To me, that seems like an easy payout.





To answer your question of "Why the Windows Store over Steam", I think Microsoft takes less of a cut. IIRC, it's 30% for the first $1000, then 20% after that.

For large sales volumes Steam is also assumed to take less than 30%. Developers can share their sales numbers, but AFAIK are under NDA when it comes to their deals with Valve, so nobody really knows (no guarantee on any of that info). At this time, being considerably cheaper than Steam is the only thing MS could offer game developers, but I don't think MS is doing that.

You are mistakenly assuming that distributing over an additional store comes at zero cost to you as a developer. You end up integrating and supporting two separate licensing models. More importantly, you end up integrating and supporting the social, matchmaking, sharing and trading features of two separate platforms, which in addition to costing money also fractures your player base, making your game look less popular in both communities.

You don't do that if you don't have to, particularly if you can reach 99.9% of your potential customers without it.

 

[rhapdog]

Confirmation bias. No, you can't use your experience and extrapolate to every other developer.

Which is exactly what you are attempting to do on your own point of view. Just because you back up your experience with your opinion really means nothing, because no one can predict what will actually happen one, two, or 10 years from now. Please stop behaving like you're the only one that can be right about it, and then perhaps a more civilized and enlightened discussion can ensue.

I'd argue that there's not even a probability that developers will create universal apps.

Fallacy. There are some developers that already ARE creating universal apps, so to state there isn't even a probability is total hogwash.

I must reiterate: we have no idea if MS is even trying to do something like this. Xamarin is a partner, one that they'd be driving over if they took this strategy. This idea would really annoy Apple and Google; maybe they couldn't stop it directly, but there are all kinds of indirect actions large firms can take to make their displeasure known. Still, I have my fingers crossed.

MS has already shown what is going to happen with VS 2015, where you can build both iOS and Android apps, as well as Universal Apps. They are working toward being able to compile for all in the future, but it isn't quite there. However, it may well be by 2016.

I hope you are wrong. The electrical engineering tools I use will NEVER be ported to a MS Universal App. They'll leave Windows and go to Linux 1st.

These engineering tools already run on Linux and Windows. They've put in millions of dollars to develop them and they aren't going to rewite them from the ground up anytime soon. Hell, I still have to use command line tools with most of my FPGA design tools. This will NEVER work in a Universal App environment, NEVER.
I don't hate Universal Apps, I look forward to using them, but they will be calculators, impedance calculation tools, unit converters, things I use web pages for now. Complicated design tools just won't work in an app. Like I said, if MS ditches Win32 these companies will leave the Windows desktop and just support Linux. This pisses me off because I hate Linux.

Tsk, tsk, my, oh my. People said the exact same thing of AutoCAD... "It's already on DOS. It can't possibly run as well on Windows, and since it already works so well on DOS, there is no way it will ever get a total rewrite to win32. There's just too much involved for a total rewrite. It will NEVER happen." Yeah, well, we've had AutoCAD on win32 for a long time now.

Let me tell you what I think. As competing engineering and electrical design software providers start creating the universal apps so that they can take advantage of Hololens technology (and I guarantee you Hololens will drive some to enter that arena), then the "big boys" will eventually be forced to follow suit just to stay relevant.

I've stated before that I have multiple degrees in multiple disciplines. I may be a retired Chief Information Officer of a corporation, but I'm also retired from several other disciplines, and doing mechanical engineering is one of them. I designed playground equipment on AutoCAD for one company, and designed pressure vessels for the department of transportation for the transport of hazardous chemicals for another company. I was using AutoCAD on DOS when they said it would NEVER be ported to Windows, and I was one of the ones saying it. I later used AutoCAD on Windows, and while the first iteration of it took some getting used to, and felt slower, it was eventually properly optimized.

Windows was the way the world was going, and DOS was dying out. They HAD to make the switch to stay relevant. The same will happen with Universal Apps, no matter how much we whine and complain. I know this, because I understand how history works to predict what will happen in the future.

When Windows first arrived, and even through a few iterations, all the way up to Windows 98, you could still exit to the DOS prompt to run your DOS applications. The day did arrive where DOS was abandoned entirely, and the day will one day arrive where non-Universal Apps will go the same route.

Normal Windows is being phased out to some extent, and Microsoft's plan looks to be very capable of doing just that. It won't happen right away, but it is going to happen. We will adapt or get left behind.

 

[spaulagain]

^100% agree.

It's clearly the way things are heading. And it baffles me how some people don't recognize the need to go with these changes.

It's like if I as a web developer refused to accept Responsive design and HTML5/CSS3 as the new industry norm/standard. Over time, I'd have zero value as a web developer.

 

[quicoli]

Friends, what about LOB applications? Will be worthy build them as universal apps? What do you think about?

 

[Mike Gibson]

I know this, because I understand how history works to predict what will happen in the future.

I'm a geezer, too, but there's an almost perfect counterexample in OS/2. It was "the future" of PC development and IBM+MSFT poured hundreds of millions of $$$ into its development and marketing. It failed miserably because it couldn't supplant the existing Win16 API. OS/2 had a zero userbase and zero developer base, wasn't accepted in the PC community, and required rewriting significant chunks of code to convert to it. And that was at a time when MSFT was coming on strong. It's even worse today because MSFT has far more powerful, entrenched competitors (if things continue the way they are, AAPL will be able to do a cash buyout of MSFT in five years).

 

[theefman]

(if things continue the way they are, AAPL will be able to do a cash buyout of MSFT in five years).

The windowscentral forums that day.....

 

[tgp]

(if things continue the way they are, AAPL will be able to do a cash buyout of MSFT in five years).

Have you been watching NASDAQ? Microsoft's market cap just dropped under Google's for the first time in a couple months. And Apple took a big jump. Apple's market cap is about $60 billion away from equaling Microsoft & Google put together!

 

[Jas00555]

(if things continue the way they are, AAPL will be able to do a cash buyout of MSFT in five years).

Even if things went perfect for Microsoft and everyone adopted Windows 10 and the app gap was 100% closed.... Apple could still probably buy out Microsoft, Google, and probably Europe in 5 years.

 

[EBUK]

MS has already shown what is going to happen with VS 2015

They have shown what they WANT to happen. Not the same thing. To quote you again:

no one can predict what will actually happen one, two, or 10 years from now.

I don't have a point of view on this matter, so I don't know where you get the idea that I'm using my experience (I have none) to push a point of view. The title of the thread says it all - I want to believe, but need to be convinced.

I want MS to succeed with Windows 10. I just remain unconvinced that a market share of 14% is going to be enough. In fact market share will be LESS than 14% - that figure includes all versions of Windows. Strip out those still using XP (I have two devices that will never be upgraded to Win10) and the market share is considerably less. That's not opinion, that's fact. 14% was stated by Nadella himself.

If I didn't have any faith in MSFT's ability to make Windows relevant, I would have gone out today and bought a Windows Phone specifically for the technical previews that are headed our way.