When you plan to build a new enterprise line-of-business application, you have many choices as a .NET developer for the client-side technology:

• WPF
• Windows Forms
• UWP
• Xamarin
• Angular with TypeScript
• …

By enterprise line-of-business application I mean an application that your customer is using to enable his business, to support different processes etc. I think about individual software that you build for your customer to support his business processes.

So what should you chose? Before I think about a technology I usually split up the environment of my customer for client-side applications into these three segments:

• Desktop
• Web
• Mobile

The mobile segment can even be splitted into iOS, Android and Windows Phone (which is indeed Windows 10). So we get this picture:

When you look at the technologies I mentioned above, you can put these technologies exactly into these three vertical categories.

As you can see, if you have a customer that needs mobile applications for different platforms, you can use C# and go the native way with Xamarin. You can also use Angular 2 or plain HTML/JavaScript in combination with Apache Cordova or even other things like NativeScript or React Native to build a mobile app for these platforms.

When you look at UWP on the Mobile-vertical, you can see that it’s just there for Windows Phones. It’s the native technology for Windows 10, which is similar to building native apps by using Objective C / Swift for iOS or by using Java for Andriod. So you can decide what technology you’re using on which mobile platforms.

When you look at Angular 2, it looks quite promising. Building one single app, and you have desktop, web and mobile. But the reality is not as simple. On the desktop you usually have a different screensize and a different flow in your line-of-business app. On the desktop many people want to see many input fields on a single screen. When I tell them that’s bad UX, they say “it might be bad UX, but that’s an application for experts. We want it this way”. So it seems to be hard to build an enterprise desktop app and a mobile app with one single thing, even as the technologies like Xamarin, Angular and UWP would allow us to do so. Beside these points, you would also build your service-Layer in that form like it is needed by the client. On a desktop-application that runs in your fast intranet the Web API can be designed different than for a mobile-application that runs everywhere and might have sometimes a slow connection. There are more points, but I don’t want to go deeper into this discussion how to build a single app for desktop and mobile. Why?

Because for my enterprise customers – remember, I’m talking here about MY customers and line-of-business apps – there’s always just a very minor or even no mobile use case: Looking at some charts on an iPad, looking at some KPIs on a mobile phone and so on. But the big administration of the data and the main job is always done in either a big desktop application or in a big web application. So mobile from my personal point of view is regarding enterprises in most cases a smaller use case on top or beside of the bigger application that runs on the desktop. That’s why most enterprise applications are still Web- and Desktop-applications, and that’s why I still see many new projects made with WPF for the desktop. And I don’t see that this will change in the close future. Why?

My customers are sitting at their desk the whole day. Ok, now many of them have standing-desks. :) But that means they’re working with their PC, and not with their mobile device. When you’re sitting at your desk: Are you using your PC to write emails, to update a spreadsheet etc.? Or are you using your mobile device like a phone or a tablet? Of course you’re using your PC. Having a solid keyboard, a big screen – or even multiple of them – makes the PC the most productive device. That’s why the PC/desktop still matters during the next years for enterprises.

The desktop is the most productive device if you’re doing your job while sitting at your desk

The next thing is Windows: All my customers have a homogeneous environment of Windows PCs. So using a native technology to build a Windows application is a good idea for them. Don’t get me wrong, I love Angular 2, TypeScript, and other client-side web-technologies. And I think there are many use-cases where you want to have a web application. But for big internal line-of-business applications, the kind of expert applications with a lot of data and logic inside, a desktop app can be the right way to go: Use the power of C# & XAML & .NET.

When you build a classical desktop-application with a client/server-architecture – many enterprises still do this for internal apps, as it’s fast, simple and straight forward –  you can still build up an additional Web API that provides the central data of your data base for a mobile application. So you’re never locked out of the mobile use case, no matter what you do.

For my customers, I don’t see that these things are changing in the close future:

• most/all work is done on the desktop, as it is productive
• mobile use cases are rare and sometimes even don’t exist
• email and calendar exist on every device, these are the most used apps.
• homogeneous environment with Windows PCs

That means, focusing on native desktop-technologies for enterprise line-of-business-apps is not a bad idea. You just need to ensure that you have the reach the customer wants. And if web & mobile is not important, you can focus on the desktop. And if all desktops are running on Windows, why should you chose something else than a native windows technology to build your app? So as a C#/.NET-developer, I’m ending up with this picture for Windows 10 when I think about the internal enterprise applications for my customers that are running on the desktop:

Ok, you can argue that you could build your desktop app for example with Angular and Electron. Fair point. And if you have synergies for a mobile use case or you need a web app accessible from everywhere, that’s fine. But a C#/.NET-Developer will go the native route with the native technologies, when all the people of an enterprise are sitting at their desk in the same network using a Windows PC.

That’s why today many new projects are started with WPF: Building for the desktop. There are even new projects started with Windows Forms. Windows Forms is still a big player in the enterprise space. But what about UWP?

UWP has today the problem that it runs only on Windows 10, while WPF runs on Windows 7. So it’s a no-brainer what to chose when your enterprise customer is not on Windows 10 yet. But when your enterprise customer shifts to Windows 10, you have three choices for native desktop applications from a C#/.NET point of view:

• Windows Forms
• WPF
• UWP

WPF is still the most powerful XAML-framework out there for enterprise apps. But when you look where the innovation happens, that’s in UWP. With the Anniversary Update of Windows 10, Microsoft has extended the x:Bind markup extension that is used to create compiled data bindings. Compiled data bindings are faster than classical data bindings, as they’re resolved at compile-time and not at runtime. Data binding is important, as most enterprise apps are built by using the MVVM-pattern. And by using that pattern, x:Bind has a lot of advantages: You can forget about ICommand to execute actions, as you can directly bind to methods of your ViewModel. You can also cast values directly in XAML and much more. x:Bind does not exist in WPF.

I think WPF will be important in the upcoming years, and there’s nothing wrong to set on this technology today. But I also think that UWP has a big chance to become the number one technlogogy for native applications on the Windows desktop for enterprises. UWP is part of Windows and a lot of innovation is happening in UWP. Let’s wait for the Redstone 2 and Restone 3 updates.

To use UWP for enterprise line-of-business applications for my customers, Microsoft has still to implement some features (Please vote for these features, just follow the links):

• Support for client/server architecture
• Validation
• there’s validation-support in the PRISM-library and you can even do it on your own. But WPF is more comfortable with IDataErrorInfo and INotifyDataErrorInfo. We need this
• Deployment
• Should be simple like today with ClickOnce

Also there are some nice to have features:

• XmlnsDefinitionAttribute
• Build in Enterprise controls like TreeView and DataGrid
• There are 3rd party vendors having these kind of controls

What do you think? What features do you require to build your next line of business application with UWP? Or are you going another way? Xamarin or Electron? Share your thoughts in the comments.