A few days ago I met and had a great conversation with Mark Lee, one of the co-founders and the CEO of Splashtop. Splashtop is pretty well known for their consumer remote desktop access solution, which has 14 million users. Essentially it comprises a desktop agent (Splashtop Streamer, available for Windows and Mac), Splashtop’s cloud service to broker the connection, and clients for iOS, Android, Windows, Windows RT, and Windows Phone 8.
Besides their consumer product, Splashtop also pushing into the enterprise space. They have an on-premises version of their product that can broker connections, manage and configure clients, and integrate with Active Directory. In addition to connecting users to distributed physical PCs, Splashtop Enterprise can connect to and VDI or RDS desktops and apps.
Now we’ve been saying for a long time that when it comes to enabling employees to work from mobile devices, having native mobile apps is key—if your default “answer” to mobile devices is just desktop virtualization, then you’ll have a user revolt on your hands. But we can deal with this—the EMM industry is giving us plenty of different options for providing secure, native access to email, files, and other basic apps like document editing. In the grand scheme of things, these basics aren’t that hard to figure out and implement.
However, what is difficult to figure out is what to do with the thousands of Windows desktop apps that we’ll be using for decades. Writing new apps for mobile platforms, writing new clients, and even re-factoring apps takes time, money and effort. But just plain-old remoting a desktop? No matter how inconvenient it is to use a desktop app on a tablet, you can’t argue with the fact that doing so can instantly enable new productivity scenarios.
But what about the barrier to entry for desktop virtualization? If a company isn’t already doing VDI or RDS, what are the chances that they’re going to go to all that expense and trouble just for a few iPads? Maybe they might several years down the road, but iPads are here now. (Or really they’ve been here for three years.)
Splashtop has been getting a lot of traction with companies in this exact situation. Since mobile devices on their own probably aren’t a big enough reason for a company to invest in VDI or RDS, many of Splashtop’s customers are just connecting their users’ device back to their own desktops.
Splashtop has also been partnering with a lot of enterprise mobility management (EMM) vendors recently. For the customers of EMM vendors that don’t have desktop virtualization solutions (that’s most EMM vendors except for Citrix), Splashtop is a quick answer for what to do about Windows apps once the customer has figured out the EMM basics. Splashtop is working on making versions of its client that work with several different mobile app management SDKs, too. (Mark had some interesting insights about this process, but I’ll save that for another time.)
One of the important aspects of what Splashtop is doing is that the experience of using a remote Windows desktop is getting better. They have their own remoting protocol, built to be used on mobile devices. It takes advantage of hardware encoding and decoding when possible; for example they’ve worked with Nvidia so that the Splashtop Streamer can work with their graphics cards, and on the client end they’ve optimized it for Tegra and Qualcomm chips. To make the touch experience better, they use what they call “profiles” to overlay hotkeys to act as keyboard shortcuts.
Bringing this all together
To bring all these points together, we can consider a few things: First, that remote desktop experience is getting better—both the client app and the protocols. Second, the EMM industry has figured out how to provide secure access for a lot of basic tasks (email, browsing, file syncing, doc editing) in native apps. Taken together, these mean that remote desktops can be used at the right times, with a better experience.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.