If you have an idea for a digital product,
you may be wondering if you should build a
responsive web app, a native mobile app,
or a progressive web app.
Is one option inherently better?
What are the pros and cons?
This is part 2 of a three-part series
unpacking the reasons to choose
one platform over another.
Let’s dive into native mobile apps.
If your top priority is to provide a high level of specialized
capability, especially for a specific mobile device like Android
or iPhone, a native mobile app is likely the best option for
building your digital product.
A native mobile app is an app created specifically for one particular mobile
platform such as iOS, Android, or Windows. Native mobile apps are built using
programming languages and tools unique to each platform: Swift or Objective-C
for iOS, or Kotlin, Java, and C++ languages for Android.
Choose a native mobile app when your project requires a high level of hardware
or software integration.
Native apps can access all of a device’s hardware and software features. For
example, unlike responsive web apps (RWAs), native mobile apps can integrate
directly with a specific mobile device’s GPS for geofencing, access light and
proximity sensors, or access advanced camera APIs (e.g. for scanning QR codes).
Choose a native mobile app when you need advanced performance.
Native mobile apps are optimized for a specific platform. Because of this
specialization, they can provide a higher level of processing power for things
like large videos or games with lots of animation. This difference is especially
pronounced when there is limited or no access to an internet connection. Native
mobile apps are downloaded onto a specific device and can usually function even
when there is no internet access.
Choose a native mobile app when you require custom security measures.
A native mobile app offers security beyond the typical HTTPS encryption
available with an RWA. If you are developing a banking product that requires
secure authentication and verification of your users, or need to meet strict
HIPAA requirements, a native mobile app is likely a better option than a
responsive web app.
Discoverable Via App Store
Choose a native mobile app when the people you want to reach will look for your
app in an app store.
Native mobile apps live in app stores like the Google Play Store and Apple’s App
Store. If your research shows that the people you want to reach typically look
for the type of content you will provide in app stores, or if you want to build
your marketing plan around app stores, then a native mobile app is a better
choice than a responsive web app which is not listed in app stores.
On the other hand, a responsive web app with PWA enhancements can be listed in
the app store. Additionally, building a marketing campaign around an app store
can be expensive, and the tools to search for apps in the stores are limited.
Don’t choose a native mobile app when you want to keep short and long-term
Native mobile apps require a unique codebase for each platform. For example, if
you want to make the same native mobile app available on both Android and iOS
devices, you need to build one codebase for Android and a separate codebase for
iOS. Each codebase requires different proprietary technologies, and likely
requires separate teams of developers to build and maintain each platform.
Frameworks like React Native and Flutter allow you to share a significant amount
of your codebase, but come with constraints, and result in an experience that
may not feel as native for users. To take advantage of the more advanced
features or platform-specific expectations, you may still need to write separate
code for each platform.
Due to separate codebases and proprietary technologies, it is frequently more
expensive to reach the same range of people with a native mobile app compared to
a responsive web app.
Don’t choose a native mobile app when it’s a priority to make your app
available to users quickly.
Because native mobile apps require a separate codebase for each platform you
want to support, development generally takes longer than it does to develop a
single codebase for a responsive web app. Additionally, each app store has its
own set of requirements in order to publish an app, and these can be complex.
Wait times for app store approval to publish or update the app can be lengthy as
Not Discoverable Via Search Engines
Don’t choose a native mobile app when the people you want to reach will look
for your content with a search engine.
Unlike responsive web apps, search engines don’t index native mobile apps. If
your research indicates that people frequently use search engines to search for
the type of content you offer, an RWA may be a better choice. Alternatively, you
could build a marketing website for search engines to find, which simply
introduces your app and links people to the appropriate app store for download.
(A separate marketing website will further increase the design and development
Don’t choose a native mobile app when you want to reach a broad audience across
Because it takes longer and costs more to reach the same range of people with a
native mobile app than with a responsive web app, and because native mobile apps
offer less backward compatibility, the number of people who can access a native
mobile app will likely always be more limited than the number of people who can
access a responsive web app. Additionally, a native mobile app is
limited to mobile devices. To provide access to your content on a
laptop or desktop, you would need to develop separate native desktop software or
a responsive web app.
A native mobile app excels in performance and security, and provides the most
advanced level of integration with specific devices. On the other hand, it tends
to be the most expensive to build and maintain compared to the other types of
apps – especially responsive web apps – and the range of people it can reach
is more limited. If you need a balance of expense, reach, and special
capabilities, a progressive web app might be the right answer for your project.
We’ll look at the pros and cons of progressive web apps in the next part of this