Today’s corporate office is much quieter than it was 10 years ago, since many employees no longer work from their desks all day. Increasingly, people are getting work done remotely on their tablets and mobile devices, with about 30 million Americans working from home at least once a week.

As this trend becomes more widespread, many technology companies want to give their users access to their products everywhere they go by creating a mobile web interface. But speaking from experience, creating an appealing and effective mobile app is easier said than done. I recently managed the development of Smartsheet’s native applications for iPhone, iPad and Android and I learned some important lessons around how to develop a professional mobile application along the way. I’d like to share a few things I learned with others embarking on the road to mobile application success.

No Substitute for Native Code in Mobile

I understand why mobile web clients are necessary—a native mobile client simply can’t serve the overwhelmingly wide array of devices available. But the user experience on a mobile web client almost always falls short of that on a native mobile client. Facebook’s update in August 2012 demonstrated how much better an app’s experience is with native code. Mark Zuckerberg admitted that the company’s mobile strategy relied too much on HTML5 and not enough on native apps.

For many developers, a native mobile client is the obvious choice. If a page contains a lot of data and code it will run out of memory and become difficult to navigate in a mobile browser. Native code prevents that from happening. There are several reasons why: It can reclaim the memory required to run the browser, it can directly manage how memory is used, and native code is simply smaller because it can be more effectively compiled for a given device and take advantage of more items built into the operating system.

If you are creating a professional application for both Android and iOS, one of the best solutions is to write two separate native versions. There are tools that allow cross-compilation of an application into native code on iOS and Android, but the results are not as good as writing two separate versions because iOS and Android are very different platforms, making the app feel out of place on both devices. The most effective method is to build parallel versions of the application. There are also some items that can be used in both apps so you don’t have to reinvent the wheel and rewrite everything.

It’s also important to make a tool’s advanced features just as easy to navigate on mobile. Touchscreens make using powerful features like interactive Gantt charts a pleasure if they work smoothly, but they’re torturous if they don’t. Making scrolling fast and render smoothly can set you apart from the pack as even the heavy hitters like Apple, Google, and Microsoft don’t always manage this.

One way to achieve this is by coming up with a clean and fast UI architecture, tuning it for speed and breaking the cleanliness as required to make it scroll fast enough. When building the grid focus on obtaining “free” functionality by inheriting higher-level objects and balancing that with the subsequent memory and performance costs.

After that, spend some time with Instruments and analyzing the frame rate to pinpoint what takes the most time and speed it up. This is a common approach, and if you scroll quickly in Excel, Numbers, or Google Spreadsheets you’ll see blank white rectangles appear in the view and then get filled in by text. This indicates that the chunking step has been completed but it isn’t fast enough to render the contents of far off chunks when you’re scrolling fast. The slowness can occur when obtaining the data to display in the new region, operating on it, formatting it, or drawing the screen region. Since there are a lot of objects being drawn repeatedly, an insignificant delay in any of those steps can be multiplied many thousands or millions of times and can slow everything to a crawl. So, architect carefully, hack up the lovely architecture as required to make it fast. Tune, then be very careful not to accidentally screw it up later in the ship cycle.

Cramming It on a Tiny Screen Is Tough

Mobile UX design often requires making difficult decisions about what functionality to leave out in order to fit everything on a considerably smaller screen.

As long as you have a healthy user base, somebody will want to do on their phone everything they can do on their desktop. In a perfect world, we would let them. In the real world, it’s not possible. Prioritize which features are presented based on expected usage, keeping in mind that usage patterns differ on desktop, tablet and mobile. This can be determined by analyzing user data.

It’s important to prioritize the most popular features, but include as many features as possible while still presenting them correctly. Aiming low and creating a “companion app” only hurts users and makes you look bad

Mobile First Doesn’t Mean Mobile Only

While mobile usage provides significant customer value, most users will continue to use a desktop or notebook computer for adding information simply because it’s easier to type with a keyboard, a mouse, and a large screen. Since they switch between desktop and mobile so frequently it’s crucial that the two are consistent. For example, settings should roam between the user’s devices so they can easily pick up where they left off when they switch devices.

Visual metaphors and the details of the UX behavior need to walk a fine line between being consistent across all platforms and appropriate for each device. Your app has to remain true to itself while also behaving like an iOS app on Android or an iPhone app. Nailing this requires having a clear understanding of what makes your app’s interaction unique and where you can bend to fit the platform.

One implication of users employing both desktop and mobile devices to edit documents is that mobile users must present everything created on the desktop and cannot discard desktop data when they save a document or their work will be deleted. Apple ran into this problem when they initially released Keynote for iOS. The application removed unsupported features from the saved file so editing a file on the iPad could erase significant content. Microsoft’s newly released iPad Office apps do a better job by showing everything, even if it isn’t interactive, and not losing saved data.

You Can’t Test Apps on Your Own

Even if you have a dedicated QA team and test a number of devices, you won’t be able to cover every device on your own.

The Google Play Developer Console is a great way to get feedback from users. It lets you test your app with groups of users through alpha- and beta-testing so you can receive feedback privately and incorporate it before your app is launched publicly. You can also make sure new versions get a positive response by updating through staged rollouts. In addition, Google Play provides revenue metrics like the number of buyers and average revenue per paying customer, which are incredibly helpful insights. Google Play also has a platform to help promote your app and drive re-engagement with features like Installed App Category Targeting and ads that remind users about the apps they already have. Overall, the program is a little finicky to manage, but it is critical to creating a quality release for your customers. My advice? Use it.

You Already Have a Storefront in Most Countries

Localizing native apps is a lot of work, and it’s easy to de-prioritize localization work by assuming you don’t have any sales presence in a country. But between the Apple App Store, Google Play Store, and the Amazon Android and Kindle stores there is a mobile storefront almost everywhere. The key is getting found within those stores.

The best way to get noticed is by getting your app featured, ideally in the “Best New Apps” section or somewhere similarly easy to find. Hitting the “Best New Apps” list in a category like Education or Productivity can result in an increase in downloads by two times or more. But hitting the overall “Best New Apps” list can drive a massive increase in downloads.

Although the vast majority of smartphone users worldwide have an Android device, about two thirds of Smartsheet’s mobile usage is on iOS. This ratio aligns with the overall mobile commerce business: Research shows that iOS users tend to spend more money on mobile purchases than Android users.

Going Big at Home

The U.S. is still the largest single market in the world for many apps, so it’s worth expending significant effort to hit those same featured lists in the U.S. There is no secret trick to this, at least not that I’ve found! You simply have to build a great app, receive strong reviews, and follow all of the rules for the various storefronts and marketing materials. Then, sit back, cross your fingers, and be really sure that your company and service are ready to handle an enormous increase in volume if it comes.

Pocket Rock Star

Even a great mobile web app probably won’t show the polish it takes to hook new customers as well as a mediocre native app. And a great native app can take customer acquisition to a completely different level. Users with little interaction that have tried the mobile app are still several times more likely to sign up than those who have used the desktop web app extensively but haven’t tried the mobile native apps.

In a world where users flip between their desk, phone and tablet throughout the day, they demand equal control over their information no matter where they are. Providing that control—for example, the ability to give their manager an up to the minute project update while on the go—will make your customer look like a rock star. And that’s seriously fun. I hope these tips provide some guidance so you can build a mobile app that will empower your users with the information and functionality they need at their fingertips.

About the Author

Erik Rucker is Director of Mobile at Smartsheet.