fbpx

6 Reasons to Develop Your Kiosk Application as a Native Windows Application

.NET WPF kiosk application developmentIn a previous article I briefly covered my thoughts on the pros and cons of developing a kiosk application as a website.  In this article I’ll be exploring the pros and cons of developing your kiosk application as a native Windows application (i.e. a .NET WPF kiosk application).  It boils down to a case of client-side vs. server-side and deciding which approach best fits your needs. My goal for this 2-part series is to define the pros and cons of each approach to better help kiosk application developers make an informed decision.

Let’s move on to exploring the option of developing a kiosk application as a native Windows application. In our scenario you would create a native Windows application (i.e. .NET WPF) specifically designed to run on a touchscreen kiosk environment and install it directly on your kiosk. With the assistance of some kiosk lockdown software it’s simply a matter of configuring the kiosk to only allow the user to be able to run your kiosk application. Sounds easy enough right? Well it is, but there’s some other variables that you should consider before getting started.

.NET kiosk application developmentPros of developing your kiosk application as a native Windows application:

  1. Ability to employ robust retry logic for sensitive transactions and to account for a flakey internet connection.
  2. Responsive UI and animations
  3. Potentially low bandwidth usage and minimal load on the central server because much of the processing can be performed on the kiosk.
  4. Ability to deploy updates to a single kiosk without impacting other kiosks.
  5. Provides direct access to kiosk hardware devices.
  6. “Offline mode” can be supported for internet outages by caching data locally.

Cons of developing your kiosk application as a native Windows application:

  1. The learning curve for native Windows applications is typically more steep especially when compared to a basic HTML website.
  2. Sensitive information or code logic stored on the kiosk could be potentially exposed to hackers if the kiosk was compromised.  This can be overcome with careful design and adhering to PCI-DSS guidelines.
  3. Initial deployment can be time consuming because your kiosk application needs to be installed on every single kiosk.
  4. Challenging to deploy updates to individual kiosks unless a robust updater is put in place like Microsoft ClickOnce or the nVision Updater.
  5. If a central server is part of the kiosk solution it will requires separate coding projects for client and server.

Conclusion

When deciding on a technology for developing your kiosk application the kiosk functionality is also a major factor. The kiosk applications our company typically develops tends to involve complex financial transactions with a need for high reliability and robust retry logic should the internet ever get flakey. This is one of the reasons we prefer to develop our kiosk applications as a native .NET WPF Windows application but by all means go with whatever strategy works best for your needs.  My goal for this series is not to steer you in a particular direction but empower you to make an informed decision.

Articles In This Series

Andrew Savala
Follow me
Latest posts by Andrew Savala (see all)

Author: Andrew Savala

Andrew Savala is the CEO of RedSwimmer, with a background in designing and deploying complex payment kiosk systems. Andrew offers high-value, strategic consulting services to companies looking to develop their payment kiosks.