I’ll pile on the blogversation that Brian and Jack are having and offer up my 2¢. Brian says that if you haven’t converted your Windows app to mobile yet, you never will. Jack says that if you haven’t done it, you’re either not thinking about it properly (web vs. mobile) or migrations will pick up as users create pressure and development platforms get more mature. In many ways I think they’re both right, but that there is a huge difference between applications that makes generalizing very hard.
Some companies are clinging to off the shelf apps that are no longer made or supported, and are faced with keeping that app or having a new one developed from scratch. If that company doesn’t already have developer resources on staff, this is no small feat. Even if they do have resources, it’s hard to argue against the status quo, especially with solutions like PowWow out there (and other similar solutions).
There are other applications that are home-grown by a company. Some of those apps fall prey to the above scenario (old, and the developer no longer works there). Others could be considered such massive projects the company couldn’t possibly have managed to get their expected value out of making their own super-app. Yes, it’s a sunk cost, but for anyone emotionally connected to this project (or whose job depends on it), it’s worth bleeding that stone a little more. Is that the correct course? Nah. Call it job security when it all goes south.
Then we also have to consider the application uses. So far the conversation has been lumping apps together into one bucket that is ripe for pillaging (or not, depending on which article you read). There is a major challenge taking a huge medical records system and making it usable in mobile devices. Then you have to make it effective. It has to be better than the previous way. In a healthcare setting, the employees don’t have the privilege of demanding that they be allowed to use iPads. The decision is made for other reasons, like speed of processing patients, lack of downtime, manageability, etc. Nobody is going to move to a mobile solution because the device is lighter and lasts for 8 hours on a single charge if it takes twice as long for the workers to do their jobs.
On top of all that, unless you migrate entirely to mobile apps, you need to have multiple apps for multiple devices that access the same data. Having apps access the same data isn’t impossible, but you can’t just move one group of development resources to a new, mobile solution because you have to have people working on the Windows side, too. If you outsource the app, you have to find a platform that does everything you need it to, too.
There’s so much more that goes into it than just waiting for development platforms to mature and waiting for companies to come around. Is the purpose of the app viable on a mobile device? If I can use it better as a Windows app or a Windows app with transformations, then guess what? It’s going to stay a Windows app. Is it more appropriate to have only on a mobile device? If so, then move it there. But if the stipulation is that we have to support it on Windows and mobile, and we’re talking about multiple applications, we’re beginning down a slippery slope. Solutions to deal with this exist and will get better, but for the moment it almost looks like to make that decision would be to enter a state of perpetual transition.
To his credit, Jack gave a little at the end, saying there will always be a use case for some Windows apps. He’s right, but the eventual reality of the handful of Windows apps surrounded by a world of mobile apps is VERY far in the future. I’m talking 10 years from now. Windows is that entrenched.
So guys, relax. Brian is dead on that Windows apps will be here for the foreseeable future, and that remoting them with transformations is a viable solution. Jack is right on all of his points, too. You’re at either end of the same football field, and all that space in between you is full of wickedly challenging decisions, an incalculable number of use cases, and a lot of waiting.