In 15 years of mobile app development, we’ve interviewed hundreds of customers. We found out that 90% of them need to implement the same functionality. They follow the same UX & design best practices and experience the same development and publishing pitfalls.
It’s rare to find an app that is not fully or partially a chat, social, audio, video or e-commerce. This made us realize that the common parts of mobile apps can be boilerplated.
So what is it that apps have in common? Practically every app contains:
Onboarding- Authentication
- Permission Requests
- Paywall / Payments
- Homescreen
- User Profile
- Terms & Policies
- Help & Support
- Light & Dark Mode
- Deep Linking
- Push Notifications
- Error Monitoring & Crash Reporting
Many of these are in the list due to years of market research and A/B testing, as well as regulations and app stores guidelines. So let’s dive into the strongest resemblances:
Onboarding
Proper user onboarding is the first step on the way to success. It’s not just a bunch of screenshots that look nice, but rather a flow giving the user the understanding of all the nooks and crannies of your app.
You can’t even imagine how many users your app loses when it lacks Onboarding or has it poorly done.
Onboarding is not just a few first screens briefly advertising what’s inside the app. It’s a carefully crafted process helping the user reach the final destination while acquiring all the data necessary for the app. The app parts listed further in the article can also be attributed to the Onboarding process.
Authentication
Even if your app is mobile-first, you have to ensure the way to sync your data with different platforms. Without it, the user won’t be able to access the needed data across all devices.
There are many ways to implement it, but the most habitual one is authentication using a phone, an email or another popular authentication provider.
The easier and clearer this process is, the more likely the users are to not get stuck and fall off. This is the prime reason to provide different single-click sign-in options (e.g. sign in with Google, Apple, etc.). Even the order of buttons is at play.
It may seem like Authentication is just a single screen, but in reality it takes more than 10. You can’t not develop them and you can’t not include them in the app. But what you can do is boilerplate the process.
Authentication is key to users’ data, and it has to be safe. During our experience in Bug Bounty programs, we’ve learned that numerous developers’ knowledge of this process is shallow. Some of them try to build authentication from scratch instead of using well-established ready solutions. Others copy a line of code from a tutorial without understanding what is going on under the hood. All of this leads to apps having security issues and blunders.
The next common thing in Authentication is that it’s most often than not based on JWT tokens. Here is a graph that briefly explains how it works.
With some app types, you also have to Know Your Customer. Authentication can be daunting for users, with sign-up forms that demand tons of information at the very start. We recommend requesting as little information about the user profile as possible during the sign-in phase. This lets the user into the app faster, while you can enquire about additional information later.
Permission requests
Most often, a permission request is triggered when the app requires access to a function connected to users’ privacy, tracking or intrusive notifications. In all cases it’s a system alert with a short text explaining the need or the use of this permission. They look the same in all apps, and most users click ‘deny’ as an afterthought.
If the user denies an instrumental part of your app, you have to process this case and provide them with the instructions on how to re-activate it. This is common courtesy.
To minimize the rate of rejections, it’s a good idea to use soft permissions requests. They are practically an instruction that gives a more clear explanation behind the request and teaches users how to deal with system alerts.
Paywall with payments and subscriptions
Even free apps have their costs. The funding sources may differ from grants to transaction fees to ads to subscriptions, but either way, an app cannot exist without funds.
Subscription plans and in-app purchases are some of the most straightforward sources. Though they may seem fairly simple, there are some similarities to consider:
First, the paywall screens are designed in accordance with app stores guidelines.
Next, they are placed in the right spots and displayed as early as possible. The paywall is seamlessly integrated into onboarding. Provided that the screens are simple and not irritating, it helps increase the conversion rate.
Following this, there is integrated subscription processing and revenue tracking. This helps share subscriptions across different platforms and collect the revenue data in real time.
And finally, A/B testing is enabled to collect data from different paywall templates and pricing.
Homescreen
Every app has the main screen and all navigation starts there. If you take a look at popular apps, 90% of them have a Tab Bar. It makes the most sense, as this is the result of an evolutionary process. In the older phone models, you used to be able to reach any part of your screen with your finger while you held it, which made Burger Menu convenient. But the screen sizes have grown and it soon became impossible, hence replaced by a more handy Tab Bar, which is now a standard practice.
The older versions of Android didn’t use to have the bottom Tab Bar navigation pattern at all. Still, even Android has finally switched to this type of UX.
Tab Bar and Burger Menu combination still exists in more complex apps, but is slowly getting removed. Where it’s still used, Burger Menu is more characteristic of secondary functions, the access to which is not frequently needed (e.g. profile switch on Slack).
User Profile & Settings
User Profile goes hand in hand with the Authentication process. At the very least, an app should show who is signed in and provide the option to sign out. A minimum user profile carries an avatar and a user name, but making a separate screen just for that isn’t rational. In most apps, the user profile screen contains additional information (e.g. settings, terms and policies, subscription management) and any other information that is technically linked to the user and not frequently used.
Additionally, it's common courtesy for any app to include such pages as terms and policies, feedback forms, etc. It’s reasonable to place these sections in the user profile to simplify navigation.
Terms & Policies
Terms and Policies are included not only for App Store and Google Play release policy, but also due to users and businesses avoiding risks. In most cases, you will find the link to this information in user profiles or on the subscription/payment screens. Some apps also have a non-skippable ‘Accept terms’ screen, which is built into onboarding or authentication.
Help & Feedback
The support form is the most common way to collect feedback from users. It’s placed not far from the User Profile or Settings in most apps and is easy to find.
Light & Dark mode support
It’s a rare occasion for an app to not support light and dark mode. As a rule, this mode is absent in either outdated or very niche applications and games.
Deep Linking
Navigation is designed to support Deep Linking in most apps, which enables the apps to open the exact screen using a predefined URL when the user clicks on the link. This comes in handy when you share a link to a specific screen or resource, which is opened directly in the app in case it's installed (e.g. news, products, etc.).
Push Notifications
Most apps support Push Notifications that are used for marketing or user-specific updates/notifications. The apps request the permission to send Push Notifications, which is preceded by a soft permission request and seamlessly integrated in Onboarding.
However, the alert is only the tip of the iceberg. What actually happens at this moment is the app is collecting the Push Notification token, binding it with the user’s device and saving it inside the User Profile.
A Push Notification token is a sort of a mailbox address inside the specific app used to send the notification from the backend.
Error monitoring and crash reporting
Bugs happen. Even in most high-quality apps. They incorporate tools like Sentry and Crashlytics to monitor errors and collect crash reports. It lets the developers know about extraordinary situations inside the app in almost real time both before and after the release to issue newer versions with bug-fixes as fast as possible. However, for them to work the build process has to be adjusted to collect build metadata (e.g. Dsyms, Sourcemaps, Deobfuscation etc.) to match the code line where the error occurred.
The key takeaway
As you can see, quite a bunch of modules migrate from app to app during the development process. They’re also very much alike. We’ve calculated that on average around 480 hours are spent on design and development, and this time can be saved in any project if you boilerplate.
So, you may want to reconsider your building process…
… or try out CodePlatform! We’ve got it all boilerplated in our App Starters 🙂
