Many popular startups from the last 10 years began as native apps. As they proved themselves out, they expanded to the web. Instagram and Uber, for example, had no web app components when they first launched. Since then they've launched web versions of their services that offer functionality more in line with their native counterparts.
A number of our projects at Savvy Apps followed similar paths. In working on them, we encountered considerations and challenges specific to not just creating web apps, but making them work cohesively with existing native apps. In this guide, we use our experiences to examine the special concerns you need to address before releasing your web app into the wild.
Why Expand From a Native App to a Web App?
So you have a native app already established. Why would you need a web counterpart? Generally, we've seen two main reasons to expand to the web. The first is to target an audience you aren't reaching with the existing native app. You would consider moving to the web, for example, if your native product has saturated iOS and Android, and you are missing other potential users. The second reason we often see native apps expand to the web is to capture other use cases better suited for an experience with much more screen real estate. You might go this route if you're getting feedback from users saying they would love to be able to use the existing native app on their laptop or desktop.
Instagram's web growth speaks to both reasons. In 2012, Instagram added a stripped-down version of their native app on the web in response to “overwhelming user demand.” The web component allowed Instagram users to view photos on the web, rather than within the native app. In 2017, Instagram further refined its web app to appeal to users with slow mobile network speeds who might have difficulty downloading and using the native app.
If you decide to make the move from native to web, you'd be in good company. Here's a look at some popular native apps that later added web apps:
- 1Password: Along with a new subscription service, 1Password launched a web app that allows users to access their password information on 1password.com.
- Telegram: Secure-messenging app Telegram launched its web version to allow its users to utilize most of the features in the native app on their browser.
- Uber: Uber's lightweight web app “m.uber” targeted mobile users who couldn't or wouldn't download the native app. The app is optimized for users who don't have the latest phones or the best cell service and plans.
- WhatsApp: WhatsApp Web syncs across all of your logged-in devices. It allows users to send messages via their browsers.
Adding a web app isn't as simple as copying your existing native app on a new platform. There are new use cases and design challenges to account for. You'll need to establish how your new web app will interact with the native app, if at all. You'll also need to decide what changes might need to occur to your backend architecture. Oh, and don't forget about testing your new web app against the seemingly endless browser, device, and operating system combinations your users will bring to the table.
Understanding Use Cases for Web Apps
Your web and native use cases won't always align. Recently, we helped Pocket Prep, a test preparation app, develop their web app in an attempt to reach a new user base. While the Pocket Prep web product looks, feels, and acts like its existing native counterpart, we designed it for web users and their own set of unique goals. Get an idea of what the Pocket Prep web app experience is like by trying one of the exams for free.
Pocket Prep's native app users prefer to complete a quick exam on a ride downtown or answer a few questions while standing in line at the grocery store. They're mobile, more distracted, and value convenience. By comparison, the web app users prefer to study at the library or at home, with fewer distractions, on laptops, desktop computers or tablets. These users generally schedule time for studying and take longer exams that are more ideal for larger screens.
Knowing the goals and context for both user bases, we decided to do things a little differently when building the Pocket Prep web app. You'll likely find yourself in a similar situation as you move from native to web. Using your own user research, you will need to decide which of your existing native app's features should be translated to the web. Your use cases will also inform your design, cross-platform experience, and backend architecture decisions down the road.
Designing for Web Apps vs. Native Apps
Though web and mobile have become more alike in recent years, there are still design-specific items to address when adding a web counterpart. One of the more obvious differences is the increased real estate available on a web app as opposed to a native app. That's more space to do more things with. That extra space could mean a deeper dive into features than on your native app. It could also allow for a different navigation scheme, more visual elements, larger elements, or more content in general. While you have more space in a web app, how you use that real estate is as important as on the smaller, native version of your app. Be aware of what information you include “above the fold,” and make sure your user has a clear call to action.
Another notable difference is that your web users will generally be clicking rather than tapping. Native users utilize tap and gesture controls as well as different types of taps and presses to complete different actions. They can pinch to zoom, swipe to advance pages and even press and hold to pop open more options. In the browser, they're mostly clicking. Keep in mind that native is a very fluid experience. Users expect immediate reactions to their actions (new screen, modal pop up, pickers, etc.). It can be difficult to create a similar experience on the web as you have to account for a wider variety of hardware, browsers, and other elements out of your control.
Native apps cover a wide variety of experiences ranging from entertainment to navigation. Web apps, on the other hand, tend to be more utility-based, focused on completing tasks. They also often have more complicated functionality, with longer user sessions. Improper colors or font sizes can cause issues for users like eye strain, especially if they're staring at the screen for long periods of time.
Use platform-appropriate fonts. Apple offers San Francisco for iOS and Google provides Roboto for Android. You'll want to seek out web-ready fonts for your web app. Ideally, you would use a custom or specific font for your brand across all platforms. It's important to optimize the web app for web browsers, but you can still use a custom font and fall back to a standard web-ready font if needed.
We made some different design choices when moving from the Pocket Prep native app to the new web app. For example, we split the custom-exam builder over several screens, allowing users to navigate using quick swipe pagination. The same feature lives on a single screen in the web app because of the increased real estate available on that platform. We kept both native and web exam views minimal to eliminate distractions and draw focus to the question in front of the user. On the web app, we added keyboard shortcuts and A, B, C, D options for more of a multiple-choice feel. Pocket Prep's web app also offers more graphics that compliment the web app's available real estate.
Transitioning App Users Seamlessly Across Platforms
When will your web users interact with your native app and vice versa? Pocket Prep, for example, is a cross platform experience. Users can complete a short exam on the go and then further their studying by taking a much longer exam on their computer at home. Their progress syncs across the web and the native apps, so both apps always reflect the most recent data. Just like Pocket Prep, you may expect some of your users to utilize both native and web apps. If so, you'll need to consider how your users will transition between them.
To help create a consistent experience across both apps, try to keep the visual language, hierarchy, and order of features the same. This is also true for your brand indicators. It would be jarring to go from one experience to another with a completely different logo, imagery, tone, and message.
Consider how you can educate your existing native users about your web app and entice them to give it a try. Some options include promotion within the native app itself, such as app banners, push notifications, and status messages or through a separate marketing website. You can also leverage social media, email, and paid ads to get your message out. Assess your native user base for more opportunities, and reach out to any partners you've accrued through your native app business.
You also need to consider the type of experience you want to allow your users to have on each platform. What happens if a user tries to pull up the web app on his or her mobile device? Do you force the user to download the native app? Do you provide them with a full, responsive experience for mobile? Or do you provide only part of that experience to encourage them to download the app? My Fitness Pal, for example, allows you to log your exercise and food intake on the web app just as in the native app. While they push users to get use the native app instead, they still allow you to do the same things inside the web app as the native app.
Web App Backend Architecture and Security
If you already have backend architecture for your native app, you'll need to analyze how a new web app might impact those existing resources. You may have to make changes to accommodate for these new needs as your service scales. Adding a web app comes with its own unique challenges for backend support. Think about how you'll create and store any new records, ensure encryption and security, deal with the server load, and scale your resources.
You'll also need to decide what you'll use to host your new web app. Hosting costs might drastically scale as your user base grows. For example, Heroku is a great platform as a service (PaaS) tool. They offer many plugins that can quickly get you up and running. At a certain point, however, it might make more financial sense to migrate off of such services. There are cheaper options, but they require more setup and ongoing maintenance.
Use SSL certificates to make sure web traffic is secure. Be sure to assess, identify, and resolve any security vulnerabilities during development. Keep privileges as minimal as possible, and set redirects for deep links not only for security, but for the best user experience. When dealing with financial transactions, it is extremely important to make sure your services are secure. Ensure that you are following all of your payment service's protocols. Also note that if you prompt users to subscribe or make a purchase via your web app, your payment service will have a transaction fee, like the major app stores do. Stripe, for example, takes 2.9 percent plus $0.30 per successful card charge. That's still drastically better compared to Apple and Google taking 30 percent.
Be sure to assess the potential impact ahead of time by conducting some server load testing. You could, for example, simulate 10,000 concurrent users on the web app before you launch. The last thing you want is to start onboarding users only to have your server go down because you didn't have the correct resources allocated. Some services, like Heroku, have autoscaling. This feature allows you to add more resources only for the times when the load exceeds acceptable limits. This is a good interim option until you need to fully scale with additional resources. It would be a different story if you maintain your own backend. In general, be ready for growth, and be aware of what problems may arise if growth is larger than expected.
Considering Cross-Browser Compatibility
Compared to native apps, a web app must account for an even greater combination of devices, screen sizes, browsers, browser versions, and operating systems. To make this easier, use a tool like Browser Stack to test your web app against virtual devices and all their variables. Sauce Labs, CrossBrowserTesting, and Vanamco offer similar alternatives. Use existing user data to identify and prioritize the browser and OS combinations your users use the most. Your marketing website, for example, might tell you what devices, browsers, and operating systems most of your users prefer.
As for tools that help with testing and identifying errors, our favorite is Instabug for the way it simplifies the bug reporting process. You should also look into Rollbar, Airbrake, and Honeybadger for more error and crash logging options.
It's no small feat to add a web app when you have an existing native app. Not only do you need to consider all new use cases for your web app, but you have to design differently for them. You have to decide how you want your users to interact with both apps, and how to make that transition as seamless as possible. Adding a web app also puts a strain on your backend architecture and brings up new security and compatibility concerns. Despite all these challenges, adding a web app can prove to be the best way to reach new users, do more for your existing users and expand your business. If you're ready to expand to the web, drop us a line.
Thank you to our team member Megan Balaguer for contributing her thoughts on this topic.
Join 20,000+ Other Readers
Sign up to be notified of new blog posts and be the first to receive helpful app goodies from Savvy.