When you mobilize an enterprise app, you’re not taking away features, you’re adding features.

With all of our talk about mobilizing apps (especially all the attention that app refactoring has been getting this year), generally when we've talked about making desktop apps into mobile apps, we've talked about how we have to remove features. Mostly this is an issue of real estate.

With all of our talk about mobilizing apps (especially all the attention that app refactoring has been getting this year), generally when we’ve talked about making desktop apps into mobile apps, we’ve talked about how we have to remove features.

Mostly this is an issue of real estate. On a big monitor, you can have a lot of menus and buttons, plus you have an accurate mouse and keyboard for lots of fast and precise data entry.

But on a 4 or 5-inch phone you can only fit a few buttons, and they have to be bigger since your fingers aren’t as precise; you also can’t have as many menus, because you don’t want users to get lost or confused.

Much of the time this is okay. When we talk about making desktop apps into mobile apps, we also talk about how a big single desktop app originally meant for dozens of different tasks can get broken up into many different single-task apps, designed for short periods of usage.

Still, often we think that these apps are less powerful because they have so few of the functions of the old desktop apps.

But think about it another way. Think of all the features that a mobile device can add:

  • Location awareness
  • Address book integration
  • Camera uploads
  • Use the camera to scan QR codes
  • Sound and video recording
  • Push notifications
  • Phone call and text message integration
  • Motion sensors
  • Audio

All of these features—enabled by various mobile device hardware and software frameworks—can be used to add to the experience and features of an app.

Sure, many of these features are possible on desktops, but mobile apps and mobile devices offer them in a much more elegant way.

I’m certainly not the first person to think about this. People have been talking for a long time about the “richness” of a mobile experience. More recently it was Benedict Evans, a mobile thinker at Andreessen Horowitz, that really cemented the concept for me in his article on Mobile First. The context he used was a little bit different, but regardless, a similar concept can be applied to our conversations about converting legacy enterprise desktop applications into new mobile apps.

So when you’re thinking about your mobile strategy (or your app-refactoring strategy), don’t just think “What existing features from this desktop application do we need to have in our mobile app?” Instead, think “Can any of these mobile capabilities improve our app?”

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

For that list of mobile features.. is it possible to add them to existing Windows desktop apps that are just refactored for mobile?

If not then the focus of mobile is taking away features, though doing so adds the ultimate feature—the app is actually usable by mobile now!


I use a Surface Pro as a Desktop AND a mobile device so I feel you should add those features to the existing Desktop App.


Benedict was talking primarily about new apps. Uber is simpler than a taxi because it uses location and automatic payments. It's difficult to take an existing taxi service and add those two seamlessly. In New York, hailing a cab is simpler, but payments are more painful. A black car service payments are simpler, but you have to set it up in advance.

I think you would have to build new enterprise apps that use device features as part of the business logic. Are there examples of where you can add these features to an existing app?


Amitabh, I definitely agree, existing business logic is definitely a limiting factor, and so for a lot of desktop to mobile use cases, we're talking basic convenience—autofill an address field from contact, automatically use location API to add location to a record; making adding a photo easier, etc.

But when you consider how much friction these mobile integrations could add to an application, along with the fact that it's even accessible in the first place, it's more than just convenience—entirely new use cases could open up. I'm thinking turning forms into field service apps and other stuff like that.

@Brian, I don't have the specifics on hand, but I know I've seen some refactoring demos where they can pull data from local device frameworks, but I'll have to look into that. Though really my point is that this can apply no matter the development technique—whether refactoring, MADP, Native, HTML5, we should be thinking "what can all the device frameworks (or the fact that the app is in the users pocket and easily accessible while they're on the go) add to this app?"


I've been dying for years for Citrix to add the ability into Receiver on a mobile device whereas the mobile camera can be mapped into device manager on windows and used within a windows app as a webcam or something of that nature.  


Great insights! We have seen more and more customers thinking along these lines. A number of customers thought it couldn't be done based on past research so gave up hope of being able to leverage any sensors on their mobile devices with Windows applications. One of our customers has an application that previously required them to have a not so mobile device with an external barcode reader, and external camera. They now just use hopTo Work with their iPad or iPhone and to push barcodes and photos directly from the device to their Windows application.


Great post and discussion – these considerations are top of mind for organizations looking to extend their existing enterprise applications to mobile.  As Brian pointed out, the most important “feature” being added is the ability to comfortably interact with an application designed for desktop use on a mobile device.  

But, we have seen (at Reddo) that it is very common for customers working on mobilizing an app to come up with a lot of  â€œWouldn’t it be cool if we could…”s that extend their existing business process with features like those posed by Jack.

Different technologies will deliver different levels of flexibility to incorporate mobile functionality into an existing enterprise mobile app.  On one end of the spectrum, you have the ultimate flexibility if you redesign an app from scratch with a mobile app development platform – letting developers create net new functionality while accessing existing enterprise data stores through APIs.  On the other end, you have traditional desktop or app virt technologies that simply pixel push an existing desktop UI to a mobile device (typically resulting in a bad mobile UX).  

Most of the “App Refactoring” solutions you guys cover (including my company, Reddo Mobility) offer some level of ability to tap into the features of the phone to augment the mobile use experience.  Placing us somewhere on the spectrum between new development and virtualization solutions.  

This is one of the reasons Reddo prefers “App Transformation” over “App Refactoring.”  You are literally transforming the application with new features.  Not just rearranging UI elements.

Without getting into specifics, some of the features Jack mentioned are easier to get at with App transformation solutions than others.  Reddo leverages HTML5 to deliver the transformed, mobile-optimized UI.  This gives our apps (which are created by non-developers) access to a good portion of these mobile features through the browser it displays on.  We can access an even greater set if our customer wants to extend an app further with our development kit.  And access the full set if leveraging the SDK and the PhoneGap mobile app wrapper (leveraging the set of PhoneGap APIs that let developers access native device features).

Sorry for long comment, but good discussion.