Droids On Roids https://www.thedroidsonroids.com iOS & Android Mobile App Development Company Mon, 12 Apr 2021 09:41:08 +0000 en-US hourly 1 How to Make an App like Uber in 2021: Process, Cost & Tips https://www.thedroidsonroids.com/blog/how-to-make-an-app-like-uber-in-2021 https://www.thedroidsonroids.com/blog/how-to-make-an-app-like-uber-in-2021#disqus_thread Fri, 09 Apr 2021 09:00:07 +0000 https://www.thedroidsonroids.com/?p=30176 Use our expert tips to develop a successful carpooling app like Uber and see how much it costs.

The post How to Make an App like Uber in 2021: Process, Cost & Tips appeared first on Droids On Roids.


The whole process of designing and developing an app like Uber will cost you ~ $442,000 – $621,000  (for both iOS and Android), and take ~ 5 – 7 months (MVP version).

Everything that matters most is included in the above-mentioned price. UX/UI Design, Passenger app for iOS and Android, Driver app for iOS and Android, Admin Panel, Backend development, Quality Assurance securing all applications & the backend, and the work of the Scrum Master who will make the development process smooth and effective.

To understand where these numbers come from and what assumptions we took, continue reading.


How to make an app like Uber? What is the cost of an Uber-like app development? These are common questions we hear from business owners who approach us. Here’s the reason why: large cosmopolitan cities often suffer from lots of traffic and a lack of available parking space. That’s why so many of their inhabitants choose rideshare services like Uber instead of owning cars.

The high demand for personal or shared car rides inspires entrepreneurs around the world to verify how Uber-like apps could play out on local markets. New apps keep appearing on the market, and many startups around the world are looking to grab a piece of this pie.

Uber is considered the archetypal disruptive startup, having created a massive impact on the taxi industry in many cities across the world. This is only one of the reasons why many founders looking to build ride-sharing apps model their products on Uber. In the first quarter of 2020, users booked 1.65 billion trips on the app, helping the company to register a revenue of $15.8 billion. Uber reached an IPO valuation of $82.4 billion.

In this article, we zoom in on the development of an Uber-like app to give you a detailed breakdown of costs and help you estimate your project per feature.

Uber-like app development basics

How does Uber work?

First of all, it’s good to take a closer look at the exact service range Uber offers today. Users can choose from several types of cars that come with different benefits. These options are largely dependent on the location where you hail a ride.

For example, in New York City, users can choose from the following:

  • UberX – economic rides where user books the entire vehicle
  • UberXL – affordable rides for up to 5 users
  • Black – premium rides in luxury cars
  • Black SUV – premium rides for up to 5 users with professional drivers
  • Car Seat – cars that have a car seat for a child
  • WAV – rides in vehicles that are wheelchair-accessible

Moreover, Uber is connected to another handy app from the same company, Uber Eats. Users can easily move between the apps. This type of integration is something every founder should consider when building a ride-sharing application beyond the MVP (Minimum Viable Product) stage.

How many apps do you really need?

When building a ride-sharing app, you basically connect drivers with passengers. That’s why you’ll need to build:

  1. Driver App
    This app is for drivers who can share their location, find optimal matches and get paid for their services. It usually consists of features such as real-time and scheduled requests, trip details and tools for tracking payments.
  2. Passenger App
    This app allows users to request rides easily. It can include features such as real-time matching of passengers with drivers, real-time updates about rides, verified profiles for extra security, and a user-friendly payments portal.
  3. Admin Panel for the App Owner
    This usually comes in the form of a web-based admin panel, which is accessible from any browser. An admin panel is a key component of a successful carpooling app. You can customize it with features such as driver and passenger management, or reports and analytics.

What’s more, you will need also a backend for the above-named app. What is Backend and How to Choose the Best One for your Project?

How to develop an app like Uber and what apps you do need?

Features of an Uber-like app for passengers

Basic features:

  • Geolocation and routing
  • Calling or texting the driver right from the app
  • Ride states
  • Ride cost estimation
  • Payments
  • Push notifications
  • Registration and personal data management
  • Personal profile

Advanced features:

  • Booking rides for others
  • Scheduling rides in advance
  • Splitting the ride fare with companions

Features of an Uber-like app for drivers

Basic features:

  • Driver reporting
  • Route optimization
  • ‘Active/Inactive’ option
  • Daily or monthly reports of bookings and earnings
  • Geolocation and routing
  • Calling or texting the passenger right from the app
  • Ride states
  • Ride cost estimation
  • Push notifications
  • Registration and personal data management
  • Personal profile

Advanced features:

  • Free cancellations within a set period of time
  • Sophisticated reporting and heatmaps (for example, for showing street traffic)

Main functions performed by the Uber admin dashboard

  • Adding and deleting admins
  • Managing admins’ privileges
  • Browsing the list of drivers
  • Updating drivers’ data
  • Driver verification
  • Changing the price of a ride

Revenue models for an Uber-like app

Uber doesn’t own a fleet of vehicles but instead earns profits by acting as the mediator between drivers and passengers. The company charges its drivers a 25% fee on all fares for the use of the software, collection and transfer of fees, credit card commissions, and sending invoices to customers. However, this doesn’t mean that your ride-sharing or carpooling app should work the same.

If you’re looking to build a clone of Uber, consider developing different monetization models such as:

  • Charging fees from passengers
  • Charging fees from drivers
  • In-app advertising
  • Integration with other apps and services

7 stages of an Uber-like app development process

Here are the main phases of a mobile app development process:

  1. Choose a company to design and develop your app
    Researching, analyzing, and selecting a company to cooperate on your ridesharing app with. Signing an Independent Contractor Agreement. Read more about choosing a partner for your app development.
  2. Product Discovery – define what you want to create, for who and why
    Clarifying your app’s vision, defining your product’s goals & its final users. Deciding which features are the most crucial in creating your MVP, on which platforms your app will work, and defining your monetization models. Read more about the Product Discovery phase.
  3. UX/UI app design – determine how your Uber-like app will work and look
    Creating a User Journey Map, clickable wireframes, visual user interfaces, and motion design (animations & screen transitions). Read more about the UX/UI app design process.
  4. Project kick-off & setup – last preparations before the start of app development
    Ensuring the Product Owner knows the development team and vice versa. Defining every role in the team, agreement on rules, and next steps, as well as configuring tools. Setting up the project environment, using best practices from areas like project management to DevOps, helps to make the ride-sharing app development process faster and smoother. Read more about project kick-off and setup.
  5. App development with Quality Assurance
    App production with Continuous Integration: plan, code, build, test (and repeat). Ensuring Quality Assurance at every stage of carpooling app development with manual and automated tests. Development teams usually follow the Scrum framework and divide the work into short iterations, each followed by a demo.
  6. Preparation and publishing of the app on Google Play Store and Apple Store
    Releasing includes uploading assets required by laws & promotional materials, beta testing, optimizing the product page/store presence, and everything else needed for your app approval to go as smoothly as possible. Preparing for launch is essential if you want your Uber-like app to stand out from the crowd and succeed.
  7. Post-development phase – app maintenance & further development
    Detecting crashes, monitoring app’s statistics, product enhancement, and further development. Your Uber-like app stays attractive, adapts to changing market conditions and users’ feedback.

Read Mobile App Development Process – 7 Stages of App Development to learn more about each of the above-mentioned stages.

If you’re not ready to start development, at Droids On Roids we offer a Product Design Workshop that helps to clarify the vision for the app, prepare end-user personas, and kick off a project successfully.

App for passengers – main features cost estimation & developer’s insight

The estimations you can find below show how many hours developers need to build a specific feature for the Android platform. The time required for the same application features for iOS will be approximately similar.

The following estimates are based on our practical experience with Uber-like app development. We give ranges of hours, showing you both the high and low case scenarios.

Geolocation and routing: 150 – 200 hours

Calculating the fastest route for the first time requires a stable internet connection. Later on, the user of the device can be offline since the route is saved in the phone’s memory. You can only get data about the exact position of the user only when they are connected to the Internet because relying on GPS alone might result in erroneous readings (up to several dozen meters!).

All the journey details (pickup point, destination, route, and driver/passenger) must be saved on the device and available offline. This is because, when the user turns off the phone (or it discharges) and then restarts it, all of this information should be recreated so that they can continue their journey.

Of course, it might happen that the driver or passenger change their device during the trip (for example, because it breaks). In this case, the trip needs to be recreated on the basis of the data stored on the server. However, this is a very extreme case.

You may also like: How to Develop a GPS Navigation App Like Waze in 2021

Calling or texting the driver right from the app: 50 – 100 hours

The driver and passenger need to have a direct line of communication in the event that they can’t find each other or experience other problems before starting a joint journey. It’s good to create an internal chat for such cases. Similarly, the calling feature should be carried out through a phone exchange due to the confidentiality of users’ phone numbers.

Ride states: 100 – 120 hours

Each trip has states that must be synchronized with the backend to notify the driver or passenger app about the new trip state (e.g. cancellation). Starting from the very beginning, the app can have states like: create a new ride, ride accepted, on the way, close to pick up point, at the pick-up point, going to a destination, at the destination, ride finished, ride canceled.

Ride cost estimation: 16 – 32  hours

For business and technical reasons, the passenger and driver should know the minimum (driver) or maximum (passenger) cost of the trip. From the business point of view, the user gets to learn the approximate cost before the trip and can be sure that the driver isn’t going to ask for more. This often happens to tourists from another country who don’t know the local rates, as dishonest taxi drivers can take advantage of this.

From the technical point of view, estimating the cost of the trip at the onset is important because of potential issues (such as a lack of internet access or GPS), as the cost of the trip might be wrongly charged, resulting in a loss for the driver or passenger.

Payments: 105 – 175 hours of developers’ work

When building this feature, be sure to pay attention to two issues: User Experience (UX) and security. It’s best to use native solutions such as Apple Pay or Google Pay that offer fast and secure transactions. Moreover, you should consider cash payments as well – paying via the app might become problematic in areas with poor internet connections (this depends on the region where you plan to release your app).

Push notifications: 90 – 160 hours

It’s important that the server-client communication is carried out via push notifications because they reduce the network traffic (primarily for the server), and the application can quickly notify users about events, even when it’s working in the background.

Registration and personal data management: 90 -150 hours

Make sure that the process of registration and login is fast and straightforward for users. The best method is using the telephone number and allowing the automatic reading of the SMS with a verification code. That way, the user will only have to pass a few steps to start using your app, and you’ll minimize the time it takes them. Remember to verify user data on the basis of a valid document since, in some countries, users might find it important whether their driver is male or female due to cultural reasons.

Personal profile: 40 – 60 hours

Profile details should be editable from within the application. Details such as phone number and card number need to be automatically verified so that no one from the company is forced to verify them manually.

In the case of editing the profile photo, taking it and sending it to the server is relatively straightforward. Verifying it is much more challenging. Photos can be verified on the server-side with the use of special algorithms or by a human agent from the customer service department. Consider these two options. Choose the one which is cheaper, faster to use, and safer for you. We usually recommend the first option.

App for drivers – main features cost estimation & developer’s insight

As mentioned before, the estimations you can find below show the number of hours developers need to develop a specific feature for the Android platform. The time required for building the same application features for iOS is approximately similar.

The following estimates are based on our practical experience with Uber-like app development. We give ranges for high and low cases.

Please note that some of the app features for passengers described above are also relevant to the app for drivers. We have described them above, so we don’t repeat them on this list.

Driver reporting: 16-24 hours

This is an important feature of the app because feedback is crucial for both the driver and passenger. The average ratings could affect the driver and passenger pairing algorithms, too. For example, a driver with a high rating would get rides faster and more often than a driver with a poor rating. Showing driver reviews also helps to build trust among passengers.

Route optimization: 24-60 hours

Both the passenger and driver usually want to achieve the shortest travel time and get to their destination as fast as possible. This doesn’t always mean picking the shortest route. The app should have an active internet connection to download current data about traffic while calculating the route.

Moreover, the cost of the journey is often shaped by more than one factor: distance and time. It’s worth remembering these components when calculating the route so that neither the driver nor the passenger experiences any losses.

“Active/Inactive” option: 30 – 50 hours

In the ‘Active’ option, you need to make sure that the driver gets a quick trip request. That’s why the app needs to send their current location and status so that they’re ready for new orders. On the server-side, keep in mind that this is the only method of identifying the available drivers.

Daily or monthly reports of bookings and earnings: 70- 110 hours

This is an important part of the application where drivers can see historical information about their journeys. Offer a simple and clear interface where users can filter, browse, and sum up the cost of their travels. A map with routes taken may also be helpful in the event of a complaint. Make sure that reporting is also available offline.

Calling or texting the driver right from the app: 50 – 100 hours

Creating a direct line of communication between passengers and drivers is just as important for the latter. They can call a passenger if they can’t see them at the pickup location or experience other problems. Your app can include an internal chat as well. Make sure that calling is enabled through a telephone exchange for optimal data privacy and security.


The other features are similar to those described in the App for passengers section:

  • Geolocation and routing: 150 – 200 hours
  • Ride states: 100 – 120 hours
  • Ride cost estimation: 16 – 32  hours
  • Push notifications: 90 – 160 hours
  • Registration and personal data management: 90 -150 hours
  • Personal profile: 40 – 60 hours

Backend development for a ridesharing app (2,500 – 3,200 hours)

For any Uber-like app, you’ll also need a backend – a centralized remote application. Although there may exist mobile apps that use no backend at all, or have a backend in a simplified form (like Firebase or Serverless), Uber-like apps tend to be complex and require the creation of a fully-fledged, custom-made backend application.

Generally speaking, even if you have more mobile applications in the same domain (like a driver app and passenger app in your Uber clone), you should have one common backend for all of them. The mobile apps use the same data and only present them from different perspectives – tailor-made for the driver or passenger.

It’s not uncommon to see the backend part of the whole application cost more than other platforms. This might be true for your Uber clone as well. The more computation and data synchronization an application requires (Uber-like apps have a lot of those), the more of it should be done on the backend side.

Under the hood, mobile apps, web apps, and admin panels only command (eg. “find me a driver”) and query (ew. “how much will I pay?”) for data, which is designed, partitioned, stored, and logically computed on the remote site. All that takes effort.

The typical responsibilities of the backend in Uber-like applications include:

  • Authentication and authorization of users
  • Data consistency – journey status, drivers availability
  • Algorithms (like choosing drivers for your trip or calculating a price for the ride)
  • Data storage and file storage
  • Managing payments, subscriptions, premium status, etc.

When properly configured, the backend can be auto-scaled in an on-demand fashion. This means that you only pay for the resources that are currently in use, depending on how many users (drivers and passengers) are using the application at the moment.

You don’t have to worry about predicting the number of users in the near or distant future. Auto-scaling backends are very handy in handling different numbers of users (and optimizing the costs) in both short-term cycles (like day-night cycles), and long-term cycles (for example, an application just published in stores vs. an application that has been on the market for 5 years).

For high product quality, try to have your backend team in the same company and/or office as the rest of the development team. There are a number of challenges, like understanding the requirements, designing the correct API, and prototyping features, that your team should resolve in close cooperation with each other.

Daily communication between backend devs and mobile devs, not to mention QA engineers and other members of the team, is very important and should help you to address these challenges. Outsourcing backend development generally leads to lower product quality and longer development time. That’s why it’s best to continue working with the same team that developed the mobile app.

Admin panel development for a ridesharing app (350 – 500 hours)

The Admin panel is the place where you or your back-office people (“admins” of the app) can see many different types of information about the application, and/or change some configuration of it. Generally, there is no limit on what data can be seen there. However, the more data is shown, the higher the cost of the admin panel. Similarly, every value used in the application can end up as a value configured via the admin panel, but it makes the panel more costly as well.

The right balance of how much to show and how much to make configurable is hard. On the one hand, you want to give your admins as much power as possible. Yet on the other hand, everything has a cost. A bloated admin panel can make the whole project more expense and complex, not to mention that it can also postpone the launch of the application. Typically, in the MVP stage, admin panels are basic to enable an early launch. As the project goes on, we have more information from the users (and the admins!) about what data is crucial. Remember that features can be added to the admin panel later.

In our case, the MVP stage of the admin panel contained:

  • Adding and deleting admins
  • Managing admins’ privileges
  • Browsing the list of drivers
  • Updating drivers’ data
  • Driver verification
  • Changing the price of a ride

What other factors influence taxi app development cost?

What are the key factors that influence the cost of developing an Uber-like application? Naturally, it all depends on the number and complexity of features that will become part of your MVP.

Here’s a short breakdown of factors you need to take into account during estimation.

  • Number and complexity of features
    Is your passenger/driver app going to include only the basic features or advanced ones as well? Both the range of features and their technical requirements will have a direct impact on the number of hours it will take developers to build your app – and hence, its final cost.
  • Platform
    If you want your app to get the widest reach possible, develop it for both iOS and Android. But, if your budget is tight, you can start with an MVP created for one of the platforms – choose the one that your target audience uses the most.
  • Team setup
    If you’re building a complex app and want to release it to the market as soon as possible, it’s worth hiring a larger team than standard (4 developers per platform). Moreover, if you care about the product quality and efficiency of the software development process, include a Scrum Master and Quality Assurance specialist in your team.
  • Hourly rates of developers
    Where you hire your development team will have a massive impact on the cost of your project. Here is a breakdown of the average hourly rates of development team members in different regions of the world (Source: 2020 Report by Accelerance):
    App development cost - rate ranges per world region

The final cost to develop an app like Uber

So, how much does developing an Uber-like ride-sharing app cost?

Let’s make the following assumptions:

  • We’re going to create an Uber-like app for 2 platforms (iOS and Android),
  • Team setup: 3 mobile developers per platform, 4 Backend Developers, 1 Frontend Developer, 1 UX/UI Designer, 1 Scrum Master, and an Extended QA Plan + Backend Tests Add-on (read more about our QA Plans and Add-ons),
  • The iOS and Android apps + Admin Panel are created at the same time, while the backend development starts about 2 weeks later,
  • The UX/UI Designer begins their work 2 weeks before the development phase begins.
  • The iOS app development has the same hourly estimates as the Android app (in practice, these values ​​may differ slightly from each other).

How much does the team work?

  • One month consists of 4 week-long sprints.
  • Each developer works for 35h per 1 week.
  • The designer works for 35h per 1 week.
  • The monthly amount of payable hours of the Scrum Master is 15% of the hours logged by developers and designers during the month.
  • The QA Engineer works 20 hours per week (Extended QA Plan). The Backend Tests Add-on gives you additional 25 hours of testing per month (API testing, Backend regression testing).

What are the hourly rates of each team member?

  • iOS and Android developer hourly rate = $60 per hour*,
  • UX/UI Designer hourly rate = $60 per hour,
  • Scrum Master hourly rate = $55 per hour,
  • QA Engineer hourly rate = $55 per hour.

*Note that the hourly rates may vary based on platform and country. $60 is a typical hourly rate in Eastern Europe. To learn more, read the article about mobile app development costs.

The total cost of Uber-like app development (including everything from UX/UI Design to Quality Assurance)

The costs presented below are based on:

  • the above assumptions
  • the estimated number of hours needed for developing all app’s features components, listed above.
Hours (low case)
Hours (high case)
Passenger app (iOS + Android) 1,314 2,074
Driver app (iOS + Android) 1,352 2,132
Admin panel 350 500
Backend 2,500 3,200
UX/UI Design (all apps) 540 600
Quality Assurance (all apps + backend) 525 735
Scrum Master 908 1,276
Cost (low case) Cost (high case)
Passenger app (iOS + Android) $78,840 $124,440
Driver app (iOS + Android) $81,120 $127,920
Admin panel $21,000 $30,000
Backend $150,000 $192,000
UX/UI Design (all apps) $32,400 $36,000
Quality Assurance (all apps + backend) $28,875 $40,425
Scrum Master $49,962 $70,175
SUM $442,197  $620,960

Summarizing: The entire process of developing an application like Uber will cost you ~ $442,000 – $621,000 (MVP version).

Everything that matters most is included in this price. UX / UI Design, Passenger app for iOS and Android, Driver app for iOS and Android, Admin Panel, Backend development, Quality Assurance securing all applications and the backend, and the work of the Scrum Master who will make the development process smooth and effective.

The time needed to develop an Uber-like app

The entire ride-sharing app design & development process will take ~ 5 – 7 months (MVP version).

Please note, that the above data is indicative. We can estimate your project for free.

How much Uber-like app cost in 2021

Best tech stack for a taxi app like Uber

The key choice in building an Uber-like app is the Map and Navigation SDK. At first glance, Google Maps is the obvious choice. However, Google Maps may sometimes present legal problems or lack accurate maps for certain countries. In our recent project, we used Mapbox because it is an open-source tool with great documentation and an SDK that uses Open Street Maps.

The second most important thing is choosing the right architecture. We must remember that the main functionality of the application – the map – needs to be visible on most screens. In our opinion, such an application should be based on a Single-Activity Architecture. You can use ViewModels with a Navigation component, for example, or make your own custom solution where everything is based on views (in our Uber-like project, we chose the second option). This means that a few views are closed in a larger view (screen). A screen can be understood as a fragment.

We also have to consider Dependency Injection. For our project, we chose Dagger 2 by Google because it’s the most scalable solution and the best one in terms of speed. Due to the fact that our architecture was a proprietary solution, we also used Assisted Injection by Square.

Also, it’s important to pick tools that are native to iOS and Android due to the optimization of the app size and its speed. Choosing common technologies is important, too. For example, you can pick Firebase Push Notification for push notifications, so that the backend has to integrate with only the one common service, which significantly reduces implementation times.

Sample tech stack for GPS navigation app and Uber-like app:

iOS app Android app
Language Swift 5.1 Kotlin
Analytics Firebase Firebase
Push notifications Firebase Firebase
Crash reporting Firebase Crashlytics Firebase Crashlytics
Networking Moya OkHttp + Retrofit
Maps MapBox MapBox
Database Toolkit GRDB Room
Local map server GCDWebServer Mock Web Server
Continuous Integration Bitrise Bitrise
Architecture MVP+Coordinators Flow MVI + Inflation-inject
Unit Tests Quick, Nimble, Snapshot Testing, Sourcery KoTest, JUnit, AndroidXTest
Security Keychain, CocoapodsKeys Encrypted Shared Preferences
LayoutSDK SnapKit Native, ConstraintLayout
UI Toolkit Native Material


Runtime Node.js
Language Typescript
Web application framework Express
Tests Mocha, Chai, Supertest
Application deployment AWS Elastic Beanstalk
Database (addressing data) MySQL
Database (user’s data) DynamoDB
IaC (Infrastructure as a code) Terraform
Continuous Integration Semaphore CI
Documentation, Acceptance tests Postman

Droids On Roids’ experience in the ride-sharing app development

We have experience in developing an Uber-like application whose name we cannot disclose due to NDA restrictions. It enables 24-hour-per-day, an on-demand connection between passengers and drivers, working on both Android and iOS. What’s more, we have already realized another relevant app – a GPS navigation app called Makani – check out the Makani app case study.

I appreciate the communicative collaboration among their team – and with us – on a personal level. What’s more, I highly value their astounding organizational skills and scheduling abilities.

Droids On Roids generously provided advice, suggestions, and expertise in their field of work for the benefit of our project, assuring us that it would not only be executed but also further developed and improved.

Ahmed Alkaloush
CTO, Lamah Technologies

We have developed over 130 app ideas for clients from around the world, including the UK, US, Saudi Arabia, Norway, and Germany. Get in touch with us if you want real experts in the field to build you a great ride-sharing app.

The post How to Make an App like Uber in 2021: Process, Cost & Tips appeared first on Droids On Roids.

https://www.thedroidsonroids.com/blog/how-to-make-an-app-like-uber-in-2021/feed 0
5 Key Legal Issues to Consider in your Mobile App Development in 2021 https://www.thedroidsonroids.com/blog/legal-issues-in-mobile-app-development https://www.thedroidsonroids.com/blog/legal-issues-in-mobile-app-development#disqus_thread Sun, 14 Mar 2021 11:14:18 +0000 https://www.thedroidsonroids.com/?p=32853 5 top legal issues to be concerned by a future App Owner.

The post 5 Key Legal Issues to Consider in your Mobile App Development in 2021 appeared first on Droids On Roids.

As someone with an idea you’re looking for to realize as a mobile product, you’re probably wondering how to make your application technologically superior and attractive to users, or how to ensure its success. However, why is it worth considering the legal aspects of applications, even at this stage?

Most of all, each stage of app development, involves legal issues which – for your own safety – should be looked into at this very moment. In this article, we will provide a comprehensive presentation of the 5 most crucial legal issues which are involved in the app development process.

1. NDA (Non-Disclosure Agreement) – protect the idea of your mobile product

NDA, i.e. Non-Disclosure Agreement, is a contractual document under which the parties legally pledge to keep certain information confidential. We always encourage our clients to sign such agreements BEFORE starting business negotiations. Why?

It is one of the few ways to protect your product concept. NDAs can be signed with multiple parties. A well-structured confidentiality agreement is an effective tool for protecting your rights in case the party you have signed a contract with breaches its conditions.

What should you pay attention to when signing such an agreement?

  • A firm definition of confidential information.
    It is a good idea that the parties, before signing a contract, very precisely specify what they consider as confidential information. Most of all, it should include all information concerning your company:

    • financial data,
    • know-how,
    • show-how,
    • operating,
    • marketing,
    • or trade data.

    Additionally, the definition should include information concerning the product:

    • ideas,
    • solutions,
    • operating methods,
    • functionalities,
    • and elements of the app’s architecture.

    It is also worth adding a clause according to which confidential information is all information which we have handed over to the other party in connection with business talks.

  • Obligations of the other party
    The other party’s obligations need to be precisely defined. They should include, among others, maintaining the confidentiality of all obtained confidential information, as well as an obligation according to which the other party will disclose information to its staff only if it is necessary and that it will obligate the staff to also maintain the secrecy of this information.
  • Choice of laws
    When signing an NDA with a software house, make sure to determine the jurisdiction governing the contract so that it is favorable to you.
  • Contractual penalties
    Without contractual penalties for breaking the confidentiality obligation, the NDA loses a lot of its value. What penalties can be included? For instance, a specific amount of money for each violation of the confidentiality obligation and, furthermore, a specific sum as compensation for damage to your professional image or lost revenue.
  • Term
    As a rule, the duration of NDAs is 2, 3, or 5 years. This choice depends on the value of the information you want to protect. Some information can lose its value after two years, and others after five years.
  • Obligation to return information
    As a safeguard, it’s worth considering a situation where, after business negotiations, we do not wish to continue cooperation with a given party. For these circumstances, in the agreement, we include an obligation to return or destroy confidential information once the business talks are over.

Let’s sum up:

NDA for App Development - what you should consider

2. Independent Contractor Agreement

What should you pay attention to when starting cooperation with a software house? We have partly discussed this in this article about choosing a partner for your app development.

Furthermore, it is worth thinking about the agreement as a compass guiding us through the process of cooperation in its entire duration, and particularly when there are doubts or conflicts. That is why it is a good idea to specify in the agreement how this collaboration will work. It is a trade standard to e.g. work in the Agile methodology, which should not be omitted in the agreement. To wrap up:

  • Describe the methodology of cooperation
    If you talk about how the cooperation will work at the negotiation stage, you will avoid mismatching mutual expectations. In the agreement, include the tools you will use, rules of communication, and procedure for arranging meetings.
  • Force majeure
    In consideration of the unfolding pandemic situation – but also for unexpected economic or political events, too – remember to include the force majeure clause in the agreement. In case you are affected by any adverse effects of any events outside your control, this clause will allow you to mitigate the adverse effects under the agreement. Force majeure clause usually is mutually binding – as many of typical provisions of such agreements.
  • Exit plan
    It is beneficial for both parties to draw up an exit plan in case the cooperation ends before the planned duration. It is also worth including information about the hand-over of the existing code, payment due dates, and contractual penalties – if any – for unauthorized termination of cooperation, if the parties so decide.
  • Consider other crucial clauses
    Read about them here.

Pro tip: Consider legal aspects of your mobile app from the very beginning

Our experience dictates that legal aspects are often omitted in the app development process. Meanwhile, the right path is to take them into account from the very beginning – at Product Discovery stage, while designing the User Journey Map. Why? Because it may turn out that:

  • it is necessary to design additional functionalities, e.g. check-boxes or space for making the license agreement available;
  • it is necessary to redesign some screens, e.g. when determining which user data we collect.

Thanks to legal monitoring over an application from the very start of its creation, the lawyer, when discovering new directions of app development, is able to determine which solutions are legal and how to design them in line with the provisions of both national or European law.

It will increase the safety of the entrepreneur responsible for the contents of the application. Also, it will help to avoid the additional costs of redesigning the application after it is finished.

3. Privacy Policy & Data Protection

What legal requirements should you meet in connection with personal data protection?

Ensuring the security of processing users’ personal data is one of your fundamental legal obligations. The specific requirements depend on the country of distribution of your app. For instance, if you would like your application to be available to European users, you need to fulfill the legal requirements for applications imposed by GDPR, and if you would additionally like your app to be downloaded by users below the age of 13 in the USA, you need to meet the legal requirements of the Children’s Online Privacy Protection Act.

The requirements also depend on what your application does. Some sectors have higher requirements for data protection, e.g. medical sectors (HIPAA). Since there are so many legal acts regulating the issues of personal data processing in applications, the safest way is to leave it to the lawyer involved in the app development process.

Data must also be appropriately protected from a technical perspective. You, as the Product Owner, are responsible for issues such as data leaks. This is why it is worth choosing a company which makes sure to protect data from the technical side.

It is a good idea to properly fulfill the obligations of personal data processing to make it an advantage of your application for conscious users who care for their data.

How to properly fulfill the obligations of personal data processing?

  • Collect a limited amount of data. Ask users only for data which is absolutely necessary for the application to run properly.
  • Do not use users’ data for purposes other than for which you collected it. For instance, if you collect the data of a user in order to register his or her account, do not use this data for marketing purposes if you do not have separate consent for that.
  • Make sure to keep access to data limited. Make sure that data can only be accessed by those persons who are authorized to do so, and that such access is necessary for the proper functioning of the application.
  • Respect the rights of data subjects. Give the users a feeling that their data is safe and their rights are respected.
  • Care for communication. Many of the legal aspects regulating the protection of personal data require the owner of the application to maintain documentation connected with personal data protection. It is worth starting such documentation already at the stage of designing the application. This also applies to providing users with concise and clear information about how the application uses their data, in the form of a Privacy Policy.

 Privacy and data protection in mobile applications - 5 steps

Extra-territorial application of GDPR

It is worth mentioning that, pursuant to GDPR, even if the seat of your company is not in Europe itself e.g. in the USA or in Asia, but you are addressing your products or services to users in Europe by making the app available for download, then your application also must be compliant with GDPR. This entails a number of additional legal issues that you need to consider, e.g. you are obligated to include the protection of users’ personal data even at the stage of designing the application.

Read also:

4. Terms & Conditions

When it comes to the Terms & Conditions of your application, a lot depends on which country you are going to make your application available to users. For example, there are many legal acts in European countries that impose requirements on the contents of Terms & Conditions to include specific text and legal issues. This includes the recently adopted regulation on online intermediation services (which applies throughout the European Union). Most of all, you should remember to specify:

  • Definition of the controller
    It is a good idea to include basic information about your company in the Terms & Conditions.
  • Conditions of service provision
    In the Terms & Conditions, describe what your application does, the conditions of registration (e.g. age limitations) and deleting the account, as well as when the agreement is concluded and when terminated between you and the user. Also, it is worth mentioning the rules of safe use of the application or technical requirements, alongside the suspension and blocking of user accounts.
  • End-User Licence Agreement
    The application is a computer program which you make available to users under a license. In Terms & Conditions, specify the conditions of this license agreement.
  • Processing of complaints and contact with the controller
    In Terms & Conditions, include the rules of complaints processing and information on how to contact you. It is good practice to establish a clear procedure for complaints, including multiple ways of contact with you.
  • Limitation of liability
    The Terms & Conditions is also a good place to define the scope of your liability towards users. This document should be written using simple language that is easy to understand for a regular user. There is no point in adding clauses in small print s. It will not increase user trust, and can be in conflict with some legal acts regulating the legal issues on informing app users about the terms and conditions of service provision.

Let’s sum up:

Terms & Conditions for mobile apps - what should you specify?

5. App Stores Requirements

Your mobile app must also comply with all requirements about app publishing arising from the guidelines from Google and the guidelines from Apple. These put the emphasis on personal data protection, including health data and information obtained from minors, as well as on the intellectual property issues concerning your mobile product.

To find out more about this topic, follow our blog, as we are preparing a separate article about this. In the meantime, read our:


The development of a mobile application is a complex and multi-faceted process. It is important to consider all its aspects, including legal factors, at the very start. This will allow you to avoid a situation in which your finished and ready application does not meet legal requirements applicable in a given area or sector, and it is then necessary to redesign the app before launching.

Luckily, you can easily protect yourself against this by engaging a specialist to take care of the legal security of your application and to solve all legal doubts. Let’s sum up the 5 key legal issues in mobile app development:

5 key legal issues in mobile app development that you should consider as an App Owner

The post 5 Key Legal Issues to Consider in your Mobile App Development in 2021 appeared first on Droids On Roids.

https://www.thedroidsonroids.com/blog/legal-issues-in-mobile-app-development/feed 0
App Development Cost: How Much Does it Cost to Develop a Mobile App in 2021? https://www.thedroidsonroids.com/blog/mobile-app-development-cost-in-2021 https://www.thedroidsonroids.com/blog/mobile-app-development-cost-in-2021#disqus_thread Wed, 03 Mar 2021 14:50:57 +0000 https://www.thedroidsonroids.com/?p=23468 Discover how much it costs to build a mobile app in 2021 and how to reduce development costs with four proven practices.

The post App Development Cost: How Much Does it Cost to Develop a Mobile App in 2021? appeared first on Droids On Roids.

What’s app development cost? How much does it cost to develop an app in 2021? What’s the average app price in 2021? 

– questions about the cost of developing an app are the most common ones we hear from our clients. As businesses face overcrowded markets and high competition, they feel the pressure to digitize. But they still want to do it in the most cost-effective way possible.

In short, according to our 10 years of experience and market knowledge:

  • A basic mobile app for 1 platform costs $25,000 – $50,000
  • A medium-complexity app for 1 platform costs around $50,000 – $100,000
  • A complex app for 1 platform costs more than $100,000

If you want to know your app development cost more precisely, we can estimate it within 72 hours – fill a short form here.

Continue reading this article to understand where these numbers come from, what they mean in practice, what factors influence them, and how to reduce your mobile app development cost with our battle-tested practices.

The average cost to develop a mobile app

If you’re going to develop a mobile app for 2 platforms (Android and iOS), you need to be prepared to spend around closer to $100,000 as opposed to $10,000. In our experience, the best way to talk about the cost of mobile app development is by thinking about it in terms of complexity. And so, our classification is:

Mobile app development cost infographic

Basic mobile app for 1 platform costs $25,000 – $50,000

  • The development team (developers, Scrum Master) will log around 325 – 650 h work hours.
  • QA basic plan recommended for this kind of apps contains 50 hours of QA specialist work per month.
  • The development will take around 4-9 weeks assuming that you have 2 devs per platform.

By “basic app”, we mean an MVP app:

  • having a clear vision on the set of simple features with elementary business logic,
  • consisting of up to 5 screens,
  • with basic UI without custom elements.

This kind of apps are usually built by start-ups looking for their market fit.

Medium-complexity app for 1 platform costs $50,000 – $100,000

  • The development team (developers, Scrum Master) will log around 650-1100 working hours.
  • QA Extended plan recommended for this kind of apps contains 80 hours of QA specialist work per month.
  • The development will take around 10-15 weeks (~ 2-3 months) assuming that you have 2 devs per platform.

By “medium-complexity app”, we mean an app:

  • including a few complex features with intermediate business logic,
  • consisting of about 6-15 screens,
  • with some custom UI elements & animations,
  • with localization in up to two languages.

Complex app for 1 platform costs more than $100,000

  • The development team (developers, Scrum Master) will log more than 1100 working hours.
  • QA Enterprise plan recommended for this kind of apps contains 150 hours of QA specialist work per month.
  • The development will take at least 16 weeks (so more than ~ 3 months) assuming that you have 2 devs per platform.

By “complex app”, we mean an app:

  • including many complex features with advanced business logic,
  • consisting of more than 15 screens,
  • with fully custom UI & advanced animations,
  • with a large-scale user base (multilingual),
  • that require building a complicated architecture, multiple integrations, or need,
    to meet high-security demands.

This rough estimate can serve as your starting point in understanding how much it really costs to develop a mobile app.

That said, if you want to develop a native, medium-complexity mobile app for 2 platforms (iOS and Android), your development team will come from Eastern Europe, you can expect that it will cost around $100,000 – $200,000.

Please note: When planning your budget, it’s important to consider the backend development and app design costs that are not included in the above estimation. You can deliver them by yourself, or outsource it to your app development partner. At Droids On Roids, we can take care of the both aspects.

Read also: What is Backend in Mobile App Development and How to Choose the Best One for your Project?

How do we estimate app development cost?

Above you saw the estimations, now we want to explain, where the numbers come from. Hourly rates at Droids On Roids (mobile app development company in Poland, Eastern Europe):

Software outsourcing cost per hour
How much the team works?

  • A developer works about 7 hours per day, so about 140 hours per month
  • Developers log their working time and, on this basis, we issue an invoice to you every month
  • The monthly amount of payable hours of a Scrum Master is usually 15% of hours logged by developers & designers in the month
  • Business Analyst (optional) logs his / her working time, and on this basis, we issue an invoice to you every month.
  • The monthly amount of payable hours of a QA Specialist depends on which QA Plan you choose:
    • Basic Plan: 50 hours per month = $2,750 per month (recommended for basic apps)
    • Extended Plan: 80 hours per month = $4,400 per month (recommended for medium-complexity apps)
    • Enterprise Plan: 150 hours per month = $8,250 per month (recommended for complex apps)
    • For medium-complexity and complex apps, we also recommend Automated Tests Add-on – read more here.

How much does 1 month of app development cost?

The following calculation is estimated for 1 platform, basic team set-up (2 developers per platform, 1 SM), and Extended QA Plan (medium-complexity app). We assume that the month consists of 4 one-week sprints.

DEVELOPERS = 2 developers x 1 platform x 35h x 4 weeks = 280h per month

SCRUM MASTER = 1 SM x 1 platform x (15% x 280h) = 42h per month

QUALITY ASSURANCE Extended Plan = 80 hours per month

Mobile app development cost – calculations for 1 platform

So, as you can see above, 1 month of app development for 1 platform costs around $23,510 / 21 500€ (assuming that your team consists of 2 devs per platform and 1 SM, and that you chose Extended QA Plan – perfect for medium-complexity apps).

Read also: Mobile App Development Process in 2021 – 7 Stages of App Development.

Examples of app development cost

To give you an idea, here are a few popular apps together with their funding levels to help you understand how much money is required to come up with similar applications:

  • Uber received $200 million in seed funding for implementing their idea that eventually disrupted the prop the transportation sector.
  • Tinder, the most popular dating application, raised $485,000 in seed funding back in 2012.
  • The social media tool Snapchat raised $485,000 in 2012. Note: the application received total funding of over $3 billion.
  • The photo-sharing application Instagram received $500,000 in seed funding to allow its further development.
  • Ryanair-like mobile app – around $436,800. Check out the more detailed estimation in the article: how to create an airline app like Ryanair.

Below, we present you a few examples of app development cost based on projects we’ve developed. As you can see, QA and SM hours logged are not always exactly of developers’ work – it is because every project is different, unique, and has its own specification.

Example: Mobile commerce app development | iOS and Android

Mobile commerce app development for an international retail company. MVP estimation.

UX/UI Design 175 $10,500
Android app 1 560 $93,600
iOS app 1 310 $78,600
QA 1 014 $55,770
SM 483 $26,565
Technical tasks 466 $25,026
SUM 5 008 $290,061
TEAM SETUP 3 Android developers, 3 iOS developers, 1 QA, 1SM, 1 UX/UI designer
TIME ~ 4 months

Main features: browsing products, products filtering and sorting, cart, wishlist, finding the nearest store, checking product availability, product reservation, delivery to a chosen shop, barcode scanning, personalized product recommendations; adding loyalty cards to the app;

Technical tasks – this tab contains the cost of all technical aspects (without direct business value) like networking layer setup, Github setup, deep links configuration, or static code analysis.

Please note: we assume that the backend is provided and developed outside.

Example: Fintech app development cost | Android

A personal finance app offering loans

UX/UI Design 120 $7,200
Android app 1 570 $94,200
QA 265 $14,575
SM 250 $13,750
SUM 2 205 $129,725
TEAM SETUP 2 iOS developers, 1 UX/UI designer, 1 QA, 1 SM
TIME ~ 6 months

Main features: integration with a third-party platform that enables users to link with their bank account; providing pay advances, and emergency loans; sign in with email/phone number/passcode; providing loans; notifications on status change; integration with Firebase – Performance Monitoring SDK;

Example: Game & education app development cost | iOS

App measuring people’s behavior through attractive games

iOS app 2 095 $125,700
QA 305 $16,775
SM 295 $16,225
SUM 2 695 $158,700
TEAM SETUP 2 iOS developers, 1 UX/UI designer, 1 QA, 1 SM
TIME ~ 7-8 months

Main features: integration with financial institutions, implementation of dozen games with visually attractive animations

Example: MedTech app development cost | Android and iOS

App helping patients to come back to health through adjusting and monitoring health parameters

UX/UI Design 345 $20,700
Android app 2 015 $120,900
iOS app 1 545 $92,700
QA 565 $31,075
SM 585 $32,175
SUM 5 055 $297,550
TEAM SETUP 2 iOS developers, 2 Android developers, 1 UX/UI designer, 1 QA, 1 SM
TIME ~ 8 months

Main features: adjusting & saving health parameters, prescription list view, pediatric mode, contact a doctor via email, adding events to the calendar, notifications, QR code scanning, photo library, notes

Example: Uber-like app development cost | iOS and Android

You need to develop an app for drivers, an app for customers, an admin panel, and a backend.

The whole process of designing and developing an app like Uber will cost you ~ $445 000 – $622 000  (for iOS and Android), and take ~ 5 – 7 months (MVP version).

To understand where these numbers come from and what assumptions we took, read our guide: How to Develop an App like Uber and How Much Does It Cost? 

What factors affect the cost of mobile app development?

It’s clear that app complexity and the number of features are significant factors that affect the final price of app development. But they’re far from the only ones. Let’s take a closer look at the key factors that affect the cost of building a mobile app.

What factors affect the cost of mobile app development?

App features and their complexity

As we mentioned before, another factor that affects the mobile application cost is the sort of app you’re looking to develop. Before launching a collaboration, your development team will estimate how many man-hours will be required to implement your specifications. This step is a key point in preparing your project.

The critical factors that influence our development costs are the app’s features and functionalities, platforms you want to build for, customization of visual design, the complexity of backend infrastructure and administration, and maintenance costs (we’ll cover this topic later on).

In reality, the number and complexity of features you’re planning to implement in your app will be the most significant cost driver in app development. We’re talking about the amount of business logic required to be translated into the software, the number of screens, buttons, and other elements like in-app purchases that require third-party integrations.

While implementing some features is relatively straightforward, others might be more challenging. Depending on their complexity, the development team might use ready-made solutions or write code from scratch.

Here are a few examples of app features you may need to include in your application and how they affect the final price of building your app.

User engagement features

Such features are authorization, networking, notifications, and others. Even a user authorization feature can come in many varieties that can be simple or more complex.

  • Adding functionalities such as storing passwords, password recovery, attractive visual design, or logging through social networks will increase the cost of your app.
  • Features such as push notifications, social sharing, or commenting and liking content via social media profiles will require some extra costs too.
  • Note that they often demand integration with third-party libraries and frameworks.

In-app purchases

This range of features has to do with the ways users can purchase things in your app. Credit cards, Google Wallet, Apple Pay, and PayPal are all popular forms of payment within apps. Every payment processing method will demand extra time for implementation and increase the cost of development.

Location-based services

If you want to implement innovative technologies such as geo-fencing or beacons, building such features is often time-consuming and expensive. Also, you will have to find a development team that has the right expertise on board to provide you with such services, and that might cost you time as well. Ultimately, integrating any of the more advanced location-based services will also drive up the cost of your app.

Device features

Just a few years ago, software that took advantage of device features could only use things like dialing, camera, or location information. Today, developers can integrate many other things such as near communication field (NFC) chips, payment systems, and newly emergent device features.

Note: To create an app that can access mobile device features, developers need to use platform-specific APIs. New features will require introducing new APIs in which development teams might have less experience. That’s why the development time may increase and, as a result, affect the total cost of building your app.

The geographic location of a development team (rate ranges per region)

So how much does it cost to develop an app depending on where you’re planning to hire? Here is a breakdown of the average hourly rates of development team members in different regions of the world (source: 2020 Report by Accelerance):

App development cost - rate range per region of the world

The price of mobile development will vary a lot depending on where you hire your development team. Naturally, in countries such as the UK, the United States, and Australia, the hourly rates of software developers is much higher than in locations such as India, China, or Eastern European countries like Poland or Ukraine that are becoming a popular outsourcing destination.

Is hiring a local team a good idea?

The team you hire for the job will have a huge impact on the final cost of development. The only serious advantage of developing an app locally is the fact that the team is located close to you physically, which might simplify communication and boost your chances of success.

It’s easier to explain the particular requirements of your product face-to-face, hold regular meetings, and meet the team in-person before paying a lot of money to build your solution. Local development teams may come with greater involvement in the project.

So, what is the key drawback of hiring a local development team? Most of the time, it’s going to be more expensive, and the talent pool you’ll be choosing from will be limited.

Business Analyst at Droids On Roids

Here’s why outsourcing is a smart move

The popularity of outsourcing software development means that outsourcing providers are well prepared to handle such collaborations.

Videoconferencing and instant-messaging tools make it so much easier to communicate with an overseas team. Moreover, experienced providers make sure that the remote team has all the tools it needs and follows the best industry practices for a smooth development process. Foreign developers may come with a higher level of expertise at a reasonable cost. They can perform a lot better in comparison to the local ones.

Just think about it this way:

If you want to hire a development team locally, your choice is very limited. But if you consider outsourcing, you can choose from any country in the world. For example, you can even hire a team that works while you’re asleep so that every day you wake up and see the results of their work.

The undeniable advantages of outsourcing development are:

  • access to a huge talent pool,
  • high level of expertise available,
  • greater balance of talent and cost,
  • full flexibility.

The most serious drawbacks of outsourcing are:

  • time zone challenges,
  • communication, and project management issues,
  • less personal control over the project.

Still not sure? Here are three guides to help you prepare for an outsourcing collaboration:

The growing popularity of nearshoring and offshoring indicates that more and more companies are willing to make their app development cost-effective and take advantage of foreign talent.

Team setup

Your app development cost will depend also on team structure. The team’s size should be adjusted according to your needs. A typical development team consists of 1 Product Owner (from you side), 1 Scrum Master, 1 Quality Assurance Engineer, 2 Android developers, 2 iOS developers, 1 Business Analyst (optional), UX/ UI Designer (optional). You are the one to make a decision, who will work on your project. Get our Free Guide for Product Owners – Drive your Product to Success.

When it comes to Business Analyst, this is an optional team member. You decide if your project needs a Business Analyst’s support. BA helps you in defining the high-quality business requirements to ensure the development team is aligned with the Product Owner’s vision.

In particular, Business Analyst:

  • explains your business needs and problem context to the development team
  • translates technical constraints to the business
  • takes care of backlog management from the business value perspective, along with identifying dependencies, priorities, and blockers
  • documents complex areas of the project scope using an integrated set of analysis and modeling techniques, such as user stories, use cases, and other business analysis deliverables.
  • is responsible for change request management
  • manages and prioritizes the requirements of various stakeholders

Number of platforms

Another choice that will affect the price of building your app is whether you want it to work on one or multiple platforms. When making your decision, take into account factors like the market share of iOS and Android devices, device fragmentation, and prevalence, as well as the specificity of developing for each of these platforms. Android application development and iOS application development need different programming languages with different SDKs and tools.

If you’re developing an app for a single platform, you won’t see a significant price discrepancy between Android and iOS. However, if you want your application to support two or more platforms, the cost of development will increase.

Native or cross-platform app development

If you want to develop a mobile app for both platforms – iOS and Android, it is worth considering if you want your app to be developed with Flutter or with other cross-platform solutions. It can reduce your app development cost and shorten its time-to-market. Check out Flutter’s pros and cons.

App maintenance cost

This point is something many prospective app owners forget about. We tend to think that app development costs run only until the solution is ready. This is not true.

Consumer and market trends are constantly changing, and your product needs to address these changes in order to stay competitive (not adapting to market changes is one of the most common mistakes in mobile app development). That’s why maintenance and updating are such important aspects of app development process – and they’re also a factor in its costs.

In many cases, the cost of app maintenance may account for a significant chunk of the original price of development (around 15% – 20%). Its price depends on the projected duration and the number of hours required for proper support.

Maintenance is a critical service even if you’re not planning to scale up your app or add new features anytime soon.

What exactly do you get in maintenance service? Services such as code optimization, improving stability and performance of your app, adding support for the latest operating system versions, developing new features, bug fixing, and supporting the latest version. 

App development is just a start. The fun begins when you gather feedback from first users, adapt your product to the market needs, and prepare the solution for a larger scale. That’s why it’s best to continue working with a development team even after your product has been completed. Software development is a continuous process, and companies like Droids On Roids offer post-release support.

CEO at Droids On Roids

How to reduce the costs of app development?

Fortunately, business owners can reduce the costs of developing mobile applications by following a few industry practices and applying some smart tricks. In this section, we take a closer look at the different methods companies use to lower the cost of developing mobile apps.

How to reduce the costs of app development

Prioritize features early on

You need to prioritize your app features correctly before beginning their development. Just because you’re not able to build a complete software solution right now, it doesn’t mean that you have to give up on your dream.

It’s smarter to prioritize the functionalities of your app to start driving business value as quickly as possible. This also helps to create an accurate software project estimation.

Save the nice-to-have elements for the later stages of development and add them to your backlog. By starting your project with a Minimum Viable Product (MVP), you get to build a successful product without investing a lot of money into a high-risk project.

The world of IT is constantly changing and investing in a large system with a full range of functionalities doesn’t make sense. Smart business owners build digital products incrementally and keep a close eye on the market trends.

Business Analyst

Business Analyst at Droids On Roids

Want to learn more about MVP development? We prepared these handy guides:

Involve Quality Assurance (QA) early on

Since bugs and errors may accumulate already during the mobile app design phase, you need to address them as soon as possible or risk that they spread out through your entire project. By involving QA professionals right from the start, you will identify serious problems before the development phase begins. As a result, you will save up on redesign costs that might become very high in the middle of your project.

Plan for the future

Remember that the costs of building mobile apps extend beyond the development and release phases. A complete application will still generate expenses.

The app you develop today might look completely different in the future. For example, if you release an MVP, you might get customer feedback that inspires you to change some features. Your target market might evolve in a completely new direction, forcing you to change your product as well.

That’s why it’s smart to be mindful of short-term and long-term goals in developing software. It will save you plenty of money down the road.”

Wojciech Szwajkiewicz - CEO and President of Droids On Roids

CEO at Droids On Roids

Hire an outsourced development team

Outsourcing software development will bring you plenty of cost savings throughout the project. You won’t have to invest in the high salaries and overhead costs that come with hiring developers in-house. There’s no need to pay salaries, taxes, perks, software, hardware, workspace, and many other costs. By outsourcing app development, you can employ teams from all over the world and take advantage of their cost-effective services that often come with high quality.

Check out how to choose the best mobile app development company for your project.


We hope this article helps you to understand how much it costs to develop a mobile app and what factors affect the total price of your app development. By following the tips above, you’ll be able to lower these costs, and ensure that your digital product is developed in line with the global tech standards.

If you’re looking for a skilled mobile development team, get in touch with us. We have delivered a number of projects for clients from all over the world operating across different industries.

We can provide you with expert advice on how to reduce software development costs at each stage of your project. Our experts know how to make the most of the existing technologies to speed up native mobile development and ensure fast time-to-market so that your product starts generating value as quickly as possible.

The post App Development Cost: How Much Does it Cost to Develop a Mobile App in 2021? appeared first on Droids On Roids.

https://www.thedroidsonroids.com/blog/mobile-app-development-cost-in-2021/feed 2
Mobile App Development Process in 2021 – 7 Stages of App Development https://www.thedroidsonroids.com/blog/mobile-app-development-process-stages-of-app-development https://www.thedroidsonroids.com/blog/mobile-app-development-process-stages-of-app-development#disqus_thread Fri, 26 Feb 2021 09:00:42 +0000 https://www.thedroidsonroids.com/?p=10847 This article series describes the 7 crucial Stages of the Mobile App Development Process from a Business point of view. It is an essential guide for current and future App Owners.

The post Mobile App Development Process in 2021 – 7 Stages of App Development appeared first on Droids On Roids.

What are the stages of the app development process? How does a mobile app development process look like? How to start the development process of my application? If you are thinking about developing an app, these are the questions you’re probably asking yourself right now. This article is a guide for current and future app owners who want to know – step-by-step – how their product will be created.

What are the stages of the app development process?

In short, a mobile app development process consists of the following stages:

  1. Choosing a partner – select a company to design and develop your app
    Research, analysis, and selecting a company to cooperate on your product with. Signing an Independent Contractor Agreement. Skip to a section >
  2. Product Discovery – define what you want to create, for who and why
    Clarifying your app’s vision, defining your product’s goals & its final users. Deciding which features are the most crucial in creating your MVP. Useful tools: Product Canvas, Personas, Event Storming, Prioritization Chart. Skip to a section >
  3. UX / UI app design – determine how your app will work and look
    Creating a User Journey Map, clickable wireframes, visual user interfaces, and motion design (animations & screen transitions). Skip to a section >
  4. Project kick-off & setup – last preparations before the start of app development
    PO gets to know the development team and vice versa. Defining every role in the team, agreement on rules, and next steps, as well as configuring tools. Skip to a section >
  5. App development with Quality Assurance
    App production with Continuous Integration: plan, code, build, test (and repeat). Ensuring Quality Assurance at every stage of app development with manual and automated tests. Skip to a section >
  6. Preparation and publishing of the app on Google Play Store and Apple Store
    Releasing includes uploading assets required by laws & promotional materials, beta testing, optimizing the product page/store presence, and everything your app approval needs to go as smoothly as possible. Skip to a section >
  7. Post-development phase – app maintenance & further development
    Detecting crashes, monitoring app’s statistics, product enhancement, and further development. Your app stays attractive, adapts to changing market conditions and users’ feedback. Skip to a section >

Mobile App Development Process – 7 Stages of App Development

Let’s dive into each of the above-mentioned steps of the mobile app development process.

STAGE 1. Choosing a partner – select a company to design and develop your app

Decide if you want to build your app in-house, or outsource its development. This article may help you: Inhouse vs. outsourcing software development. If you decide to outsource your product creation, you need to know how to choose a proper app development company for your project. How to verify if a company you want to choose, is trustworthy? We recommend you to:

  • Use Clutch.co or other platforms  for B2B buying
    Clutch.co, AppFutura, GoodFirms, ContractIQ – use platforms that will help you to make an initial selection of companies that meet your requirements.
  • Analyze pre-selected companies
    Check opinions about them, as well as their portfolio. Ask questions like:

    • Do they have experience in creating products similar to yours?
    • Did they work with partners from many countries and different industries?
    • Do they work with start-ups, big companies… or both?
    • Do they use new solutions and technology?
  • Analyze the estimations you receive
    It is worth to get estimations from more than one company and compare them. If you get two totally different estimations, it is worth checking how each team made their respective figure.

    • Did you deliver the same information and documentation to both companies?
    • Ask the companies on which assumptions they based their forecasts. Does the lower estimation contain all the crucial elements included in the higher one?
    • Did they ask questions to learn more about your app idea?
    • Does the estimation contain the time for team meetings?
    • Does the estimation contain the time for Quality Assurance (e.g. writing tests)?
    • Did the companies take into account the risk of unforeseen events?
    • If your app’s design demands some non-native solutions, is this considered in the estimation?
    • If your product is a typical kind of app, like e-commerce or m-commerce, but you want it to have some untypical features, check if they have been considered in the Estimations.
      Read also: How much does it cost to develop an app?
  • Make sure the code will be written in English
  • Make sure the code will be hosted on Code Repositories Hosts
    E.g. BitbucketGitHub, so you can have access to the code and be sure that it is safely stored.
  • Verify the Independent Contract Agreement
    Verify the contract you get carefully and make sure to consult with a lawyer about it. Below, we’ve listed for you a few important elements that should be included in a contract. We are not writing about some obvious elements, like personal data of parties, but rather factors more specific to software houses.

    • Confidentiality: Make sure that the contract contains a clause about confidential information. Your partner should commit himself or herself to not disclosing any information about your project that is not public yet.
    • Intellectual property: You should have the rights to everything the software house produces. The contractor shall execute and deliver such further instrument(s) and take such action(s) as may reasonably be required to complete the assignment of intellectual property rights in the Deliverables to Company’s sole and exclusive ownership.
    • Choice of Law: The contract should indicate a dispute resolution place. That is especially important if the software house is from another country. Probably, your partner will want to choose the judiciary of his country. We would recommend compromising and choose the laws of another country, with the jurisdiction you know, e.g. the United Kingdom.
    • Advance payment: We recommend that the advance payment should not exceed the cost of the team’s work for one month. In case a contractor must incur significant expenditure (e.g. for hardware or licenses) at the beginning of the project, a higher advance payment can be reasonable.
    • Payment deadline: The contract should regulate the consequences of delays in payments. What is the acceptable delay? After how many days will interest be charged? After how many days can the development team stop work? Contrary to appearances, such a clause secures you.
    • Conditions for terminating the contract: It is safe to set a notice period of about 15-20 days.
    • Deadlines:
      • Time & Material – in this type of contract, there is no need to specify an exact deadline. You decide when the app is ready. Your Feedback after each iteration is implemented up to date.
      • Fixed Price – the contract contains a schedule of partial deliverables. What is more, it is worth setting the time for you to give feedback for every iteration, as well as for the team for implementing that feedback.

In this article – Mobile App Development Process – Stage 1. Choosing a Partner – you will find examples of contractor agreement fragments that should be included in your contract. Read also: Time & Material vs Fixed Price – Comparison for App Owners.

Let’s sum up Stage 1 of the mobile app development process:

Mobile App Development Process - Stage 1Mobile App Development Process - Stage 1

STAGE 2. Product Discovery – define what you want to create, for who and why

Before you start your mobile app development process, it’s necessary to clarify your app’s vision – we call this phase Product Discovery. This is the key to your app’s success. The foundation of Product Discovery is a constant testing of solutions and ideas, as well as learning how to adapt them to the user’s needs. It also ensures that not only you are aware of the end-users’ needs, but your development team knows your goals and is able to deliver your ideas.

Here are the following areas you should focus on during Product Discovery:

  • Establishing a strategy. What is your goal? What outcome do you want to achieve?
  • Targeting potential users and their problem. Who is the user? What kind of problems do they have? How can we help them?
  • Ideating solutions. How can you solve the problem? What will be the outcome of such a solution? What is the best solution?
  • Prototyping. What is my user’s experience? Do I like the solution?
  • Reviewing ideas. Are your ideas good enough? What do my users think about them? Can I really solve their problems?
  • Narrowing down the solutions. Which ideas are we going to implement?
  • Prioritization. Which features are the most crucial in the app? What are the features to be implemented first?
  • Planning. What is the scope of our MVP (Minimum Viable Product)? How can I measure the end result to determine if the goal has been met?
    In this article, you can read more detailed description of each of the above-mentioned Product Discovery elements.

You can find the answers by yourself, with your team, or during a Product Design Workshop organized by an outside app development company – it’s your choice.

The recommended tools that can help you to clarify the idea of your app are Product Canvas (PDF print), Personas (PDF print), Event Storming, User Journey Map, and Prioritization Chart (PDF print). You can find a description of all of these tools in this article: Mobile App Development Process – Stage 2. Product Discovery.

If you already know the answers, and your vision is clear, this is great! Yet it’s simply not enough to have them in your mind. Write them down and confront them with others – talk to people from your team, employees, or just your friends. They should understand what it is about.

How about starting development without clarifying your vision? Product Discovery is an optional process but would it make sense to start costly development without thorough research? In the Theory of Quality Management, we have the “1:10:100 rule”, which states that prevention is cheaper than correction, and correction is cheaper than failure. Product Discovery costs you nothing compared to releasing a useless application.

In short, Product Discovery is the app development phase where we are focused on building the right thing, as opposed to building the thing right.

Please note: it’s worth to consider leal and security issues at this stage. Read more:

Let’s sum up Stage 2 of mobile app development process::

Mobile App Development Process – Product Discovery Phase

STAGE 3. UX / UI app design – determine how your app will work and look

Let’s start with an explanation, what do UX and UI mean. To put it simply: UX (User Experience) is how an app works UI (User Interface) is how it looks. Well designed UX and UI are very important from a business point of view. At the end of the day, they influence the retention rate. If your apps’ user experience will be enjoyable and flawless, and the design of the app will create a positive impression on its users, they will love it, and use it.

This stage of mobile app development process includes creating:

Mobile App Development Process – Stage 3. UX/ UI App Design

User Journey Map

You (alone or with your development team) create a User Journey Map. It is a visualization of the user flow through your app. It tells the story of the user’s experience. At Droids On Roids, User Journey Map takes the form of the drawn schema on the wall (we wrote about it here), or we draw it using Figma. It is usually a part of Project Discovery, but we present it here to show you that is crucial to create wireframes and user interfaces.

Wireframes (UX)

Designers create Wireframes – digital, simplified visual concepts of the future app. They lay out the structure, hierarchy, and relationship between the elements that make up the product. It is a kind of app’s backbone.

Clickable Prototype Mobile App Development Company Poland
Wireframes Mobile App Development Company Poland
Wireframes Mobile App Development Company Poland

Then, designers use Wireframes to create a Clickable Prototype – a dynamic, interactive model of your app. It simulates a real-world product. An example of a Clickable Prototype:

Design (UI)

Designers work on the visual language of your app, its style guide, User Interface, and motion design. You get mockups showing the final look of your app, and videos presenting motion design (animations & screen transitions) in your app.

App Design – Mobile App Development Company Poland

To sum up, even if your app idea is great, but its interface and UX design will be of low quality, you won’t succeed. Make sure that the UX and UI Design processes run in a thoughtful way. Be engaged in each stage of designing your product, so the team can shape the final designs according to your expectations. And last, but not least – remember to put your app’s users in the center of your thinking.

STAGE 4. Project kick-off & setup – last preparations before the start of app development

App Development Kick-off has a significant influence on the successful cooperation with your software partner. In short, it’s time to define your role as a Product Owner and to clarify every role in the team. What is more, Project Kick-off means also setting the rules you want to follow, and planning the next steps. Kick-off may have different forms, at Droids On Roids we organize a Kick-off meeting with every client (remote, or face-to-face), it takes around 2 hours. An example of how kick-off may look:

Mobile App Development Process – Kick-off Phase

When App Development Kick-off is completed, the first Sprint starts. It is also the moment when developers set up your project.

How do the developers set up your project?

These 6 elements are specific for mobile app development, but in the case of web apps, they look similar (with the exception of the third point).

  • Creating a repository for a project at GitHub or another web-based hosting service. It means creating a space dedicated to your project on the cloud-hosted platform, where all versions of your code will be safely kept and archived. 
  • Continuous Integration setup. Every new piece of code has to be checked before it is merged into the project. It’s checked manually, but also with automated tests run by special platforms like Bitrise, CircleCI, or Jenkins. The process of automating the build and testing the code every time a team member commits changes is called Continous Integration. The second role of CI platforms is pushing the app versions to Google Play / Apple Store and allowing running tests by users. At Droids On Roids, we use Bitrise.
  •  Setup of the beta distribution tool on the CI platform. App Center, Fabric – these are a few examples of tools that help you to collect live crash reports, get feedback from your app’s users, or distribute your betas. To say simply – they take care of the quality of your product.
  • Choosing a code architecture, libraries & SDKs. Developers choose the code architecture for your project (e.g. MVP, MVVP, VIPER, MVC, Clean Swift). Code architecture can be compared to the construction of a building. It is not visible outside when the building is finished, but it decides about the shape of the object and its’ solidity.
  • What is more, developers choose also libraries & SDKs (Software Development Kits) which they will use in your project. In other words, SDK is a set of software development tools useful in app development. Read also: Pros and Cons of Using Third-Party Software in Your App Development.
  • Setup project in IDE (Integrated Development Environment). Developers set up your project in a program that they will use to write the code – e.g. Android Studio for Android Apps, or XCode for iOS Apps. To the program, they add also outside SDKs or libraries that will help them to optimize their work.
  • Register the app in Google Play Console, Firebase API Console, and other services if needed. If your app will use some third-party party components (e.g. Google Maps, push notifications), it must be registered on the suppliers’ services.

Get our Free Guide for Product Owners – Drive your Product to Success.

Let’s sum up Stage 4 of the mobile app development process::

Mobile App Development Process – Stage 4

STAGE 5. App development with Quality Assurance

That’s the phase, where developers start to write the code and produce your product. How do they do that? Mobile app development is an iterative process. You have probably heard the term Sprints or Scrum. This basically means that you break up all development work into smaller milestones and develop your mobile app in a series of cycles. Each cycle will include refinement, planning, development, testing, review, and retrospective.


Sprint Refinement (Product Backlog Refinement) is the act of keeping the backlog updated, clean, and ordered. A backlog is an ordered list of everything that is known to be needed in the product. Refinement should be an ongoing process. However, it is useful to have a planned meeting for Refinement.

For example at Droids On Roids, we discuss the tasks from the top of the Product Backlog, making sure that their acceptance criteria are clear, and estimating them. Then, during the Planning Meeting, there is less to review, and planning is easier.

Only the first Sprint starts with Refinement – we need to prepare backlog before the first Planning. Later, every Sprint will start with the Planning meeting.


Sprint Planning is max. 2 hours meeting (for 1-week Sprint). Its’ goal is to decide which tasks should be included in the upcoming Sprint. The team talks about the things to do, making sure that the acceptance criteria for each task are clear and accepted by everyone. The Product Owner (you) joins this meeting (for example on Skype) so he or she takes part actively in planning the next iteration.


Developers are writing the code and implementing the features planned for the Sprint, QA Engineers are writing automated tests. It’s good when developers practice Code Review. Code Review is not necessary for developing a crash-free app but it is a good practice if you want your app to have code written in a clear and transparent way, so in the future other developers can easily improve the app and continue working on the code.

Testing (QA)

During development, we use a platform called AppCenter. It allows us to privately and securely distribute the in-development version of the app to testers, clients, and other developers. The platform automatically notifies users of new builds (so everyone is testing the latest version), provides crash reporting and ensures only approved testers have access to your app.

Quality Assurance (or simply QA) is a way of preventing mistakes in developed applications and avoiding problems when delivering them to users. It is integrated into every stage of development. This is an example of how Quality Assurance can be integrated into the app development process:

Mobile App Development Process - Continuous Integration

  1. Coding – developer writes the code, QA specialist writes automated tests.
  2. Pull Request – developer tells others about a new part of the code.
  3. Execution of automated tests – automatic tests that check whether new changes didn’t break any already implemented functionalities. It consists of:
    • Static Code Analysis – a code is checked by a special program (Lint, Sonar), which verifies if the code meets the good standards set by our development team.
    • Executing Unit Tests – automated tests that validate if each unit of the software performs as designed.
    • Executing UI Integration Tests – automated tests that check if the app components are correctly integrated.
    • Virtual Device Testing – we use it to find crashes in Android apps. It simulates a real app user.
  4. Code Review – every piece of code written by one developer is approved at least by 1 another dev.
  5. Deployment – the latest alpha/beta release is delivered to the client and testers.
  6. Manual Tests – manual testing of the app based on specified use cases. Made by QA specialists.
  7. The feature is done 

The process is repeated many times during development. Read also: Mobile Security Testing. Make the First Step!

Below you can find a list of good practices in Quality Assurance that we recommend you to consider while working with an outsourced development team:

  • First, make sure that your partner has Quality Assurance engineers who will take care of the highest product quality at every development stage.
  • The development team should have a dedicated specialist who will ensure QA for your project holistically. Why? He will have a map of the whole project in his mind. For work hygiene, pair-testing is fine, but frequent changes of testers carry the risk of mess and chaos in the project.
  • You are not the one who should pick up basic errors and differences between what is in the requirements and what you got.
  • Developers are not testers. Your partner says that they don’t have a Quality Assurance specialist, but it is OK because a developer will test the app? Well, not exactly. A developer who wrote the code shouldn’t check his own work. It is harder for an author to see their own mistakes. What is more, developers can consider something not as a mistake because they understand what they have written. An extra pair of eyes is always helpful.
  • QA should be ensured from the very beginning. Don’t put QA off until later. Even small errors in the early stages of development can cause more complex complications in the future. The sooner you start with QA, the fewer troubles you will have in the future.
  • You should have insight into the output of the tests. Which features have been tested so far? What bugs have been found? As an app owner, you should have insight into testing progress. There are many tools that can be used to easily track and follow the status of tests, e.g. TestlinkQA touchTestRail, or Jira.
  • The tests should be run on different types of devices because your product should work perfectly not only on one type of smartphone. A great solution is Smartphone Test Farm (STF) – it is an app that allows developers to:
    • control and manage real-time testing on many devices remotely from their workplaces
    • run automated tests using dedicated software like Bitrise that enables testing apps on many devices at once.
QA in mobile app development process - STF in action

STF in action


During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. A Sprint Review is held at the end of the Sprint to inspect the Increment (all tasks completed during the Sprint). It takes up to 1 hour in case of a 1-week Sprint. A great practice is if, after Review, your development team send you:

  • An app demo build (so you can check if the created app fits your expectations)
  • A detailed review of what’s been done
  • Information about eventual difficulties or additional work that has been done
  • Information about how many hours the team worked on the project during the Sprint

According to the PO’s preferences, he or she can take part in the Review meeting, or just get the above-mentioned information with an E-mail.


Retrospective meeting (about 45 m for 1-week Sprint) occurs usually after the Sprint Review. During this meeting, you and the team plan together ways to increase product quality by improving its’ work processes. The purpose of the Sprint Retrospective is to:

  • Inspect how the last Sprint went with regards to people, relations, process, and tools
  • See what went well and define potential improvements
  • Create a plan for implementing improvements

Please read the whole article describing app development with Scrum – and learn Scrum Sprint Workflow with all Scrum events.

To sum up this stage – all features are firstly planed, then implemented and tested while the Continous Integrations process, where Quality Assurance is integrated at every step, in the end, they are accepted by the Product Owner. The entire application is built in this way – in repeated cycles – of planning, coding, and testing, reviewing, and improving the process and the product. This approach gives you great flexibility – it makes it easier for you to monitor the process, the product, and introduce changes easily.

STAGE 6. Preparation and publishing of the app on Google Play Store and Apple Store

When the first version of your mobile app is ready, it is time to publish it. Your partner should assist you to upload your Android app on the Google Play Store, and your iOS app on the Apple Store. It is also a part of the app development process. The company should guide you through the app setup on the stores regarding the marketing materials, description, and legacy issues.

Google Play

Releasing includes gathering & uploading promotional materials (like graphics, videos), configuring options, and uploading assets required by law (like privacy policy, geographic and/or age restrictions, pricing), and continuous deployment configuration (this part is optional but recommended). The last step is publishing the release version of your app.

Read more: How to publish an App on Google Play – Guide for App Owners written by our Android Developer with 10 years of experience.

Apple Store

The first step is to fill in the basic information about the app on the Product Page, such as the app’s name, icon, description, keywords, and privacy policy. If your app supports Dark Mode, consider including at least one screenshot that showcases what the experience looks like for users. 

Then, developers upload the build of your app using XcodeThe app might then get tested using the TestFlight tool. The same build of the app that was tested can be then assigned to a specific version of your app. The next step is to upload screenshots of your app taken on different devices, fill in all the missing legal information, and submit the app for review. Apple employees will test your app and see whether it complies with the rules of the App Store. This might take around 2 days. 

Read our step-by-step Guide on How to Publish your iOS App on the App Store.

STAGE 7. Post-development phase – app maintenance & further development

During app maintenance, the development team implements app monitoring tools (e.g. Crashlytics, Google Analytics, Firebase) to your product. Thanks to these tools team can detect any crashes, follow app’s statistics, and plan product enhancements. The post-development phase includes also further development of your product – it allows your app to stay attractive, adapt to changing market conditions, and users’ feedback. 

Mobile app development process – summary

We hope this article helped you to understand the mobile app development process and it’s all stages – from choosing a partner, and Product Discovery, to app release, and its maintenance. Take the steps outlined in this guide, and you’ll make sure that you’re developing a product that has a perfect market fit.

We have never before shared such a in-depth and cross-sectional guide for current and future App Owners. I believe it will make your journey fascinating, safe and goal-oriented.

Wojtek Szwajkiewicz
CEO, Droids On Roids

Why outsource your app development to Droids On Roids?

At Droids On Roids, we have been delivering mobile app development services for 9+ years to companies operating across different industries. In total, we developed more than 130 mobile and web applications for clients from all over the world, including countries such as the USA, UK, Norway, Switzerland, and Australia. If you’re looking for an experienced mobile development team, get in touch with us. We have the talent and experience you’re looking for.

The post Mobile App Development Process in 2021 – 7 Stages of App Development appeared first on Droids On Roids.

https://www.thedroidsonroids.com/blog/mobile-app-development-process-stages-of-app-development/feed 12
How to Submit an App to the App Store – Guide for App Owners https://www.thedroidsonroids.com/blog/how-to-submit-app-to-the-app-store-guide-and-checklist https://www.thedroidsonroids.com/blog/how-to-submit-app-to-the-app-store-guide-and-checklist#disqus_thread Thu, 25 Feb 2021 12:15:10 +0000 https://www.thedroidsonroids.com/?p=5783 Follow this guide to submit your iOS app to the App Store successfully. 

The post How to Submit an App to the App Store – Guide for App Owners appeared first on Droids On Roids.


Before submitting your iOS app to the App Store, you need to take care of technical and legal prerequisites. You should also learn the official App Store guidelines, and prepare resources such as Privacy Policy URL, app screenshots, promotional graphics, texts, test accounts, and more. Then, you will go through the publishing process. It consists of steps like creating a New App in App Store Connect, creating a Product Page, and submitting it for review.

Read on to understand the above steps in detail. Below the article, in the FAQ section, you will find answers to questions like



The App Store is a platform to distribute iOS apps. It was developed by Apple and is the second-largest app store (after Google Play) with almost 1.96 million available apps. Whereas the exact number of apps may fluctuate as Apple and Google regularly remove low-quality content from their stores, the number of applications has been steadily increasing over the years.

With a focus on bringing the best experience for the end-user, the store ensures every app has the highest standards and brings something new. Apple wants their user to feel confident that the app they download is safe and will not break their phones. That is why:

  • Users can choose whether or not to share data.
  • Every week, over 500 experts review around 100k apps.
  • There were over 150k app rejections last year for violating privacy guidelines and over 1M rejections for inadequate content.
  • Every app has a page with detailed information, which an app owner must fill during the publishing process.

As you see, it’s important to prepare an attractive and informative Product Page, complete with all important information. It’s a crucial part of the entire app development process.

In our previous article, Publishing on App Stores, we described the process of app publishing in general – both on the App Store and Google Play. In this post, I will focus only on iOS and how to submit an app to the App Store. I will describe the most important aspects of iOS app publishing to make your review pass smoothly, without rejection.

You can also find out, how to publish an app on Google Play.

Before submitting your iOS app to the App Store

Check what important requirements you should know before you start publishing your application on the Apple App Store.

Take care of technical prerequisites

First, when talking about submitting your app to the App Store, we have to remember technical prerequisites.

1. Developer Account

In order to be able to submit apps to the App Store, you need to enroll in the Apple Developer Program. The annual cost of the account is $99. Besides the availability to publish the app, you get access to various benefits, such as access to the beta version of Apple software or testing tools like TestFlight.

2. App build uploaded to the App Store Connect

Before you send your app for review, you will need an app build. It has to be assigned to your developer account. The assignment can be made by your development team, which will create the proper certificate required by Apple on your Developer Account and sign the app build with it.

Keep in mind that, starting from April 2021, all iOS and iPadOS apps submitted to the App Store must be built with Xcode 12 and iOS 14 SDK.

Meet legal prerequisites

The iOS app you submit to the App Store has to comply with all legal requirements in any location where you make it available. A good example for EU/EEA countries is the well-known GDPR directives, which have been in effect since 25 May 2018.

Apple pays special attention to how user data is handled and if apps meet the Apple Developer Program License Agreement. The license describes the agreements for data collection and storage, data usage and sharing, health research data protection, and collecting data from kids.

Also, your app should only include the content that you created or that you have a license to use. In cases regarding using someone else’s content without proper rights, the app can be removed from the store.

Read also: 5 Key Legal Issues to Consider in your Mobile App Development in 2021

Learn the official guidelines

Apple pays special attention to the quality of the apps and detailed app information visible on the Product Page in the App Store. They created their own guidelines about all aspects related to the app publishing process. This article focuses on the publishing steps that are required. Optional ones are described briefly.

Publishing process on the App Store

1. Create a New App in App Store Connect

The whole process starts in App Store Connect where you can open My Apps and tap the plus button in order to create a new app.

How to submit an app to the App Store – Screen New App

When creating a new app, you will be asked to fill in the following basic information:

  • Platforms – here, you specify which Apple platforms your app supports.
  • Name – up to 30 characters. This is the main app name that the user will see in the App Store (pic.1).
  • Primary Language – the main language for the app’s information. In case of missing translations for a specific language, the primary language will be used.
  • Bundle ID – here you can select from the app identifiers that are registered in the Developer Account (this value is unique for every app on the App Store). If the app build is ready, make sure you choose the same ID that was used in the Xcode during app archiving.
  • SKU – stands for [Stock Keeping Unit]. This is an optional value. It could be helpful if you want to tie the app sales with whatever internal SKU number that your accounting is using.
  • User access – specify if your app should be accessible to all members in your App Store Connect organization or to specific groups or people.

Filling all the required fields and tapping the ‘Create’ button will redirect you to the Product Page.

2. Create a Product Page

In the Product Page, you provide detailed information about the app. This information will be visible to the App Store’s users. Here, you have the opportunity to encourage them to download your app by putting in well-crafted metadata.

The Product Page contains a few tabs – iOS App, General, and In-App Purchases. DOPISAC

iOS App / Version Information

In this part, you can enter information about the current version of the app, regardless of whether it is the first version or an update.

The section contains:

  • App previews – an optional short video that demonstrates the core app features. It can be up to 30 seconds long and you can put up to 3 app previews.
    The app preview can be localized.
  • App screenshots – up to 10 screenshots of your app. Select the features that will visualize your app UX the best way. The first two screenshots (if there is no app preview) are shown in search results, which is why they are very important because they are one of the first things the user sees. The App Store requires some screen sizes to be uploaded (it changes with the new iPhone releases). Find the current requirements here. Screenshots similar to app previews can be different for each supported language.
    Publishing on the App Store – preparing for submission
  • Promotional Text – an optional field. It could be changed without a need to upload a new app version. It helps if you need to inform users about a feature you forgot to mention in the description.
  • Description – a place to put detailed information about app features.
  • Keywords – put some keywords here to make your app more searchable in the App Store.
  • Support URL – the URL where users can get help. This is a required field.
    It is good if you have a website, then you can put a proper link here. The same is with other URLs required by Apple.
    If you do not have a website, you can create a Facebook page for your app and put all information there or use one of many free website creators. One of the most popular is WIX, for example.
  • Marketing URL – the URL where users can find marketing information about the app.
    App Store Product Page Version Information

iOS App /App Clip, iMessage App, Apple Watch

Next, you will be asked to fill in sections on App Clip, iMessage App, and Apple Watch. You only have to do this if your app supports these features.

The Apple Watch section requires uploading up to 10 screenshots of the watch version of the app. The screenshots could be localized. App Store Icon is automatically fetched from the uploaded app build.

App Store Product Page Apple Watch section

The iMessage App section also requires uploading up to ten screenshots of the app that uses the Messages framework (an extension that allows users to send text, stickers, media files, and interactive messages).

App Store Product Page iMessage App

The App Clip section is for the apps that allow users to access a small part of the app to be available through a safari browser without a need to install the app. It is a quite new and promising feature introduced by Apple. In this section, you have to fill in the subtitle that best describes your clip, an action label that appears on the app clip card, and a header image that appears on the app clip card when the experience is invoked from Safari or Messages. If you are interested in App Clips you can read more here.

App Store Product Page App Clip

iOS App / Build

This section can have three states.

The first is for when you do not upload the app build. It will just show a message to upload it. In case you have already uploaded a build, you will see a button to choose the specific build.

Submitting an app to the App Store – Build

Tapping on it will show a dialog with a list of available app builds.

Publishing on the App Store – Add Build

When you select the build, there may appear a second dialog box asking if your app uses encryption. Choose the answer that fits your app’s functionality.

Publishing process on the App Store – Export Compliance Information Screen

When the app build is selected, the section goes to the third state, where you will see selected build information.

App Store Build Screen

App Store General ap information screen

iOS App / General App Information

  • The App Store Icon is pulled from the selected app build. This icon will be visible in the App Store.
  • Version – the version of the app. This should be higher than the previously given value (only during app update). Versioning should follow software versioning conventions.
  • Age Rating – the form where Apple asks about the frequency in which specific content occurs in the app. Mostly, the questions will be about adult content such as violence, nudity etc. Depending on the answers, Apple will assign an age group that is able to use the app.
  • Copyright – here you can put the name of the entity or person that owns the rights to your app. You can see an example of this on the attached screenshot.
  • Routing App Coverage File – here, you can specify a specific geographic region your app supports. It should be a file with .geojson extension. For an example of such a file, you can check here. It is fully optional and you do not need to put the file if there is no need to.

iOS App / App Review Information

Additional information for Apple’s reviewer for testing purposes.

App Store App Review Information

Every new app, or a new version of an existing app, is tested by a real person from Apple. In this section, you can specify test credentials to allow the tester to log in to the app (if such functionality is implemented) and fill in Contact Information in case Apple would want to ask something.

Additionally, you can add notes for the reviewer and an attachment (this could be a video file showing how the app works – helpful if your app connects with a Bluetooth device and you do not have the possibility to send the device to Apple).

iOS App / Version Release

Choose how the app should be released. There are three options:

  • Manually – by clicking the ‘Release’ button,
  • Automatically – just after the positive review,
  • Automatically with date restriction – choose the date when the app should be released.

Publishing an app on the App Store – Version Release

General / App Information

The second tab contains the app information filled during the app creation, as well as a subtitle for the app and a place to choose the app category.

One additional required information here is about Content Rights. If your app contains, shows, or accesses content from some third-party source, you have to have the necessary right to use it.

App store – Content Rights Screen

General / Specify Pricing and Availability

Price Schedule

In this section, you can specify the price for your app. The price determines how much the user has to pay in order to download your app. Your proceeds will be the price paid by the user minus Apple’s commission and taxes.
Apple announced that, starting in January 2021, they lowered their commission to 15% for developers who earn less than $1 million a year. Before, it was 30%.
Additionally, you can specify the app price for a specific time period. It is useful if you want to make your app cheaper at the beginning to  encourage users to download it


This section allows you to specify the countries and regions in which the app will be available. By default, all countries are selected. Careful selection can be useful here if your app contains content that is not permitted by the law in some countries, such as gambling games, or you just built an MVP of your app and want to start in just one country to check how the application will be adopted.
If you are not familiar with the MVP definition, you can read more about it here.

iPhone and iPad Apps on Apple Silicon Macs

This is a quite new feature. Apple allows users to run iPhone and iPad apps on their newest silicon Macs with M1 chip and MacOS Big Sur. You can read more about it on Apple’s site. In this section, you can specify if you want your app to be installable on Macs.

General / App Privacy

App Privacy is the fourth tab.

App StoreProduct Page – App Privacy

Here, you are obligated to put the URL of your app’s Privacy Policy. As an additional option, you can put the URL to the privacy choices where users can modify which data the app collects.

Lately, Apple has added App Privacy Details on the App Store.

It helps users to learn what kind of their data the app collects and if this data is linked or used to track them before they download the app.
What does this mean to you as an App Owner? Well, you need to fill a form that specifies the kind of data that the app collects and how the data is used.

The form is a simple list of data that could be stored and a check box next to each.

When you select the proper options and tap “Save” you will see your selection under the ‘Data Types’ section and, for each type, a rectangle with a button to set up data.

iOS app publishing – App Store data types

Tapping on a ‘Set Up’ button will take you to the next form, where you need to specify how the selected data collected from your app is used by you or your third-party partners. Also, in the next steps of the form, you will be asked if the data collected from this app is linked to the user’s identity and if the data is used for tracking purposes.
When you finish, you will see your answer in the rectangle next to the proper data type, as well as the Product Page Preview section, dividing the data to three section:

  • Data Used to Track You
  • Data Linked to You
  • Data Not Linked to You

All of the data about privacy can be edited any time something changes in your app.

In-App Purchases

If your app will allow users to buy virtual products like points, access to features, or other content, it is a place where you can define all of them.
There are four types of In-App Purchases:

  • Consumable
  • Non-Consumable
  • Auto-Renewable Subscription
  • Non-Renewing Subscription

If you are interested in adding In-App Purchases to your app, visit this Apple website to get more information about it and a detailed explanation of how to implement it.

3. Submit for Review

When all the metadata is ready, you can click the “Submit for Review” button. You can find it in the “iOS App/Prepare for Submission” section. You can be also asked to answer the Export Compliance, Content Rights, and Advertising Identifier questions.

App store – submitting an app for review

After that, your app status is “Waiting for Review”.

4. Go live!

Right now, it is time to wait for Apple’s specialist to test the app and grant approval. You can check the actual status of the review in the General / Version history tab.

Your App Store Versions screen

The review process duration could take anywhere from a few days up to two weeks. It is different for each app. Apple states that around 50% of apps are reviewed in 24 hours and over 90% are reviewed in 48 hours.

It could happen that your app is rejected for some reason. You will be notified about it by email. In the App Store Connect, you will see information about the rejection with the option to go to the Resolution Center and check the details.

You have to fix the problem, build a new app, and send it for review.

In the Resolution Center, you can ask a question if something is unclear to you. Also, if you think that the app was wrongly rejected, you can submit for appeal.

If your app is approved its status will be Ready for Sale unless you have selected manual release, in which case you have to click Release. The app will be visible in the App Store in a few hours since being released.

Now, when your app is on the App Store, you can monitor it by opening the Analytics tab.

You will have insights into the number of users, session times, sales, crashes, etc.

It is also important to fix bugs and make app updates regularly.

App Store Connect Overview

Metadata filled in the Product Page – where is it displayed?

The Product Page is very important, as it contains data that is visible for the end-user and could be the decision point in whether to download the app or not. In this video from Apple, you can find some tips on how to build a Product Page to encourage users to download your app.

Below, you can find where specific metadata from a Product Page is displayed on the App Store. As an example, I used our LetSwift app:


The app publishing process may seem complicated at the beginning but, with this article, we hope that we’ve shown you that it is not as hard as it seems. The key to making the publishing process quick is to prepare the needed resources, such as the Privacy Policy URL, app screenshots, promotional graphics, texts, and test accounts, in advance.

I hope this article will help you with publishing your iOS app on the App Store. Happy publishing!

The post How to Submit an App to the App Store – Guide for App Owners appeared first on Droids On Roids.

https://www.thedroidsonroids.com/blog/how-to-submit-app-to-the-app-store-guide-and-checklist/feed 1
Flutter vs. React Native – What to Choose in 2021? https://www.thedroidsonroids.com/blog/flutter-vs-react-native-what-to-choose-in-2021 https://www.thedroidsonroids.com/blog/flutter-vs-react-native-what-to-choose-in-2021#disqus_thread Thu, 25 Feb 2021 08:00:48 +0000 https://www.thedroidsonroids.com/?p=17221 Flutter vs React Native – comparison for business & app owners. Find out which framework is ideal for your cross-platform app development.

The post Flutter vs. React Native – What to Choose in 2021? appeared first on Droids On Roids.

What you’ll find in this article

Why we created this article

Cross-platform solutions are gaining popularity. Flutter and React Native are the two leading market players, but at Droids On Roids, we’ll build commercial apps for partners using the approach that best fits the solution – be it native, Flutter, or React Native.

Still, business owners always want to know the answer to several critical questions:

  • Which framework best fits my project?
  • Which solution can provide the fastest time-to-market for my app?
  • Will my app be stable and user-friendly?
  • Which solution is best if perfect design is my #1 priority?

We wrote this article to summarize the answers we share with our partners so that you can benefit from them, too.

We hope it helps you make a smart, conscious decision when it comes to choosing the best cross-platform solution for your app idea.

Who wrote the article?

It takes a certain level of experience to write about Flutter and React Native in sufficient depth – and to compare and contrast the two technologies.

As such, we asked two Droids On Roids developers to take on the task:

These two build commercial apps for clients in Flutter and React Native every day. So, you can be sure the knowledge they’re about to share includes not only the theory but years of development experience as well.

We have also tested our understanding against popular articles in the developer community, referencing these sources to answer any questions. You can find a full list of their references at the end of this post.

Flutter vs. React Native: In a nutshell

Flutter React Native
What is it? A portable UI toolkit for building natively-compiled apps across mobile, web, and desktop* from a single codebase A framework for building native applications using React
Official release December 2018, Google I/O March 2015, F8 Conference
Created by Google Facebook
Free and open source Yes Yes
Programming language Dart JavaScript
Popularity 81,200 Stars on Github (December 2019) 83,200 stars on Github (December 2019)
Hot Reload Yes Yes
Native performance Great Great
UI Flutter apps look as good on the up-to-date operating systems as they do on older versions.

Since they only have one codebase, the apps look and behave similarly across iOS and Android – but thanks to Material Design and Cupertino widgets, they can also imitate the platform design itself. How’s that possible?

Flutter contains two sets of widgets which conform to specific design languages: Material Design widgets implement Google’s design language of the same name; Cupertino widgets imitate Apple’s iOS design.

This means that your Flutter app will look and behave naturally on each platform, imitating their native components. 

Application components look just like native ones (e.g. a button on an iOS device looks just like a native iOS button, and the same on Android).

The fact React Native uses native components under the hood should give you confidence that, after any OS UI update, your app’s components will be instantly upgraded as well.

That said, this can break the app’s UI but it happens very rarely.

If you want your app to look near-identical across platforms – as well as on older versions of an operating system (as Flutter achieves) – then consider using third-party libraries (like this one). They will enable you to use Material Design components, in place of native ones.

Sharing code Currently on iOS and Androidbut the long-term vision for Flutter is to offer an integrated solution that allows developers to write one code for both desktop & mobile, and for the web.

Flutter for Web support is available as a tech preview but still, this isn’t an alpha channel yet.

When it comes to developing desktop apps with Flutter, APIs are in their early stages of development and so will be probably released, just further down the line.

iOS and Android – but there are select libraries that allow you to use the same code to build iOS, Android, web, and Windows10 apps.

You can also extract shared code in mobile, desktop, and web apps, to a separate repository; treat it as a separate project; then inject it in the same way as another dependency.

This allows a developer to focus on writing code for a specific platform without having to consider compatibility with another one.

Top apps made with this technology Xianyu app by Alibaba, Hamilton app for Hamilton Musical, Google Ads app Instagram, Facebook, Facebook Ads, Skype, Tesla
Time-to-market Typically much faster than native development. Possibly as fast as development with Flutter.


React Native uses bridge and native elements, so it may require separate optimization for each platform – a problem that widget-based Flutter doesn’t run into. It may make the app development with React Native longer.

Competitive advantage
  • Great look and feel thanks to rich widgets;
  • Rapidly growing community, and popularity;
  • Excellent documentation with strong support from the Flutter team (which makes it easy to start developing with Flutter);
  • Improving Flutter for Web, offering the potential for one codebase across mobile and web platforms
  • Difficult to beat time-to-market length
  • Stability (5+ years on the market);
  • Many successful, prominent market players using React Native;
  • Mature, vast community;
  • Easy-to-learn technology;
  • Plenty of tutorials and libraries, which allow quick and easy development;
  • Code can be easily reused for both web app and desktop app development.
When it is not the best fit If…

• Your app needs to support 3D Touch (for now, Flutter doesn’t support 3D – but it features on the Flutter team’s long-term roadmap)

The design of your app is platform-specific

• Your app requires multiple interactions with an OS; or requires rare, little-known native libraries

• You need a minimalistic UI, but rely on significant use of the phone hardware (e.g. an application that plays music, or only takes pictures)

• You want to create an instant app (small-sized app)

If your app sounds like any of the above, it’s probably better you choose native app development.

Read more about these cases here >>


• Your app needs to handle less common, or ultra-specific tasks (like calculations) in the background

• You require custom communication via Bluetooth (which can be tricky to implement using React Native)

• You want to create an app for Android only

In truth, if you want to build an iOS app and you know JavaScript, consider React Native – but if you want an Android-only app, it’s likely better to build natively with another team. Why? Right now, iOS has better support than Android.

If your app sounds like any of the above, it’s probably better you consider choosing native app development.

Introduction to Flutter and React Native

First, let’s cover the basic (yet essential) details about Flutter and React Native.

What is Flutter?

Flutter is a portable UI toolkit. In other words, it’s a comprehensive app Software Development Kit (SDK), complete with widgets and tools.

What’s Flutter for?

Flutter enables cross-platform app development.

It gives developers an easy way to build and deploy visually attractive, natively-compiled applications for mobile (iOS, Android), web, and desktop – all using a single codebase (source: official Flutter website).

* Please note:

  • When it comes to developing desktop apps with Flutter, the API is still in the development stage. Google is working on extending Flutter to support desktop as a target environment, allowing developers to create macOS, Windows, and Linux applications with the technology.

In the long run, this effort will lead to a fully integrated solution where developers can create apps for desktop platforms as they do for mobile platforms – at the time of writing, however, the solution is in development (source).

  • Flutter for Web is currently available as a technical preview only. Flutter for Web is a code-compatible implementation of Flutter that allows you to compile existing Flutter code written in Dart into a client experience that can be embedded in the browser and deployed to any web server. You can use all the features of Flutter, and you don’t need a browser plug-in (source).

A little more about Flutter…

  • It’s free and open source
  • It’s based on Dart – a fast, object-oriented programming language (Google released Dart 2.3 with new support for UI-as-code features – note that Dart is now in its 2.6 version). Dart is relatively new, and is easy to learn – especially for experienced developers more familiar with Java and C#
  • The architecture is based on the very popular reactive programming (it follows the same style as React)
  • It provides its own widgets, drawn from its own high-performance rendering engine – these are fast, attractive and customizable
  • Thanks to the widget experience, Flutter apps have a great look and feel (while you can still create your own custom app design using readily-available UI elements that follow specific platform guidelines)

Who created Flutter?

A team at Google built Flutter.

But as an open-source project, both Google and the Flutter community contribute to its development.

How mature is Flutter?

A brief history of Flutter:

  • February 2018, Mobile World Congress – First beta release of Flutter
  • April 2018, Google I/O – Flutter beta 2 release
  • May 2018, Google I/O – Flutter beta 3 release
    • Flutter joins GitHub’s top 100 repos
  • June 2018 – Flutter Preview 1 release
  • September 2018 – Flutter Preview 2 release
  • November 2018 — Dart 2.1 release
  • December 2018, Google I/O – Flutter 1.0 release
    • A crucial milestone for the technology – since Dec. 2018, Flutter has been considered as stable and ready for production
  • February 2019, Mobile World Congress – Flutter 1.2 release
  • May 2019, Mobile World Congress:
  • July 2019, Flutter 1.7 release
  • September 2019, Flutter 1.9 release

As you can see, Google shifted from the Flutter beta version to the final stages of stabilization for Flutter 1.0 at a rapid pace.

Better still, since the release of Flutter 1.0, the team hasn’t rested on its laurels. It has actively worked on making the toolkit stronger and more resilient – prioritizing enhanced stability, performance, and quality.

Moreover, Flutter 1.5 includes hundreds of changes in response to developer feedback (source).

Flutter is now one of the top 20 active software repositories on GitHub (16th place as of December 11, 2019), which proves the developer community uses it and continues to contribute to its improvement.

In summary, Flutter remains a fledgling technology.

Yet, given the pace of Flutter’s improvements – and its explosive popularity – we can say with confidence that it’s impressively stable and mature for its age.

And judging by the rate of development, we expect to see Flutter for Web become stable within 12-months, as well.

What popular apps are made with Flutter?

For more examples of top Flutter apps, read this article > Top Apps Made with Flutter – 17 Stories by Developers and Business Owners

What is React Native?

React Native is an open-source mobile application framework that uses JavaScript.

What is React Native for?

React Native is an effective framework for:

  • Cross-platform development
  • Building mobile apps using JavaScript language
  • Developing applications for both Android and iOS using a single codebase
  • Using the same design as React

* Please note:

  • Apps created using React Native are not mobile web apps. React Native uses the same fundamental UI building blocks as regular iOS and Android apps: this means that instead of building in Java, Kotlin, or Swift – you’re putting the same building blocks together, using JavaScript and React (source).
  • React Native uses components that are analogous to widgets in Flutter.

To develop web and desktop applications with React Native, it’s best to use external libraries (as detailed in this paragraph).

Read also: What is React Native and How is it Used? Introduction for App Owners.

Who created React Native?

Facebook created React Native.

How mature is React Native?

A brief history of React Native:

  • Summer 2013, Facebook hackathon – React Native started as an internal Facebook project
  • January 2015, React.js Conference – React Native 1 Preview release
  • March 2015, F8 Conference – Official Launch of React Native
    • Facebook declares React Native, ‘open for use and available on Github’

Looking at the above, two things are for certain: React Native is older than Flutter, and it boasts a bigger community. Not to mention the fact that the Facebook team has had plenty of time to stabilize the API as well as focus on fixing any underlying issues.

And let’s not forget – Facebook is working on several other notable enhancements as well:

  • Lean Core – reducing an app’s size by moving optional components/features to separate repositories (to add to an app as/when needed)
  • TurboModules – for improved handling of native modules
  • React Native Fabric – re-architected UI layer

What popular apps are made with React Native?

Flutter vs React Native 2019

(iOS, Android)

Flutter vs React Native 2019

(iOS, Android)

Top apps made with React Native

Fb Ads Manager (iOS, Android)

Top apps made with React Native

(iOS, Android)

Flutter vs React Native 2019

(iOS, Android)

Flutter vs React Native 2019

(iOS, Android)

Top apps made with React native

(iOS, Android)

Flutter vs React Native 2019

(iOS · Android)

… as well as plenty more.

If you’d like to see other examples of apps made with React Native, check out the official React Native showcase.

Flutter – pros and cons

In this section, we briefly discuss the key pros and cons of Flutter.

If you want to read more, check out this article dedicated to the Pros and Cons of Flutter for App Owners.

✅ PROS of Flutter:

1. Hot Reload = fast coding

From a developer standpoint, Flutter offers more dynamic – and faster – app development. It is one of the greatest things about Flutter, appreciated by every top mobile app development company.

Developers can make changes to the codebase on-the-fly, and see them immediately reflected in the application. This is the so-called Hot reload feature, and it typically takes (milli-)seconds for changes to show.

The feature helps teams add features, fix bugs, and experiment with new ideas in an instant. Plus, Hot Reload is very handy when it comes to developer-designer collaboration.

That said – for a list of updates that require a full restart, see Hot Reload limitations.

2. One codebase, 2 mobile platforms (and more!)

With Flutter, developers can write just one codebase for two applications – covering both iOS and Android platforms.

Flutter is platform-agnostic as it has its own widgets and designs, which means you can have the exact same app on two platforms (while if you want to differentiate your apps that’s just as easily achieved).

Google is currently working on Flutter for Web, which you can see as a preview version. Once this goes live, a single codebase will cover Android, iOS, and web platforms.

3. Up to 50% less testing

Given you have the same application on both platforms, your Quality Assurance process will be much faster as you can test less.

We write roughly 50% fewer automated tests because we can create the same tests to run on both platforms, reducing the demands on our QA team.

That said, you’ll still have to run manual testing at a similar level as with native programming – as your QA specialists will have to check both apps on each platform, by hand.

4. Faster apps

Flutter apps perform smoothly and fast – without ever hanging or cutting while scrolling. Why?

Flutter uses the Skia Graphics Library. Thanks to this, the UI is redrawn each time when a view changes.

Most of the work is done on GPU (graphics processing unit); that’s why Flutter UI is smooth and delivers 60fps (frames per second).

However, you must be careful during the development so as not to cause redrawing of those elements of the view whose data has not changed.

Redrawing the whole view instead of just those elements that change, can affect the performance and speed of the application, especially if you need to reload the view often, e.g. in a stopwatch application.

5.  Designs your users will love

Flutter doesn’t rely on native system components. Rather, Flutter has its own set of custom widgets, rendered and managed by the framework’s graphics engine (source). Users will see different UI components from typical native apps, but that isn’t necessarily a disadvantage.

Flutter apps have a particularly user-friendly UI: a crucial advantage for Flutter over React Native, stemming from super-attentiveness to the visual details. Flutter was created so that you could easily create your own widgets, or simply customize an existing widget.

Feel free to browse a catalog of Flutter widgets; or, click the links to see examples of Material Design widgets and Cupertino widgets.

6. Same app UI, even on older devices

Even new apps look the same on older iOS or Android systems, so you never have to worry about supporting older devices.

Why Flutter

Android 5.1.1

Why Flutter

Android 8.1.0

7. Perfect for MVPs

If you need to build an MVP (Minimum Viable Product) for your app – say, as a showcase for potential investors – Flutter is the perfect option, especially if time is short. Read also:

Check out the Flutter Gallery app, which includes a demo of Flutter’s core features, widgets, and vignettes.

Flutter Gallery

Flutter Gallery

Flutter Gallery

Flutter Gallery

Flutter Gallery Screen

Flutter Gallery

🔻 CONS of Flutter:

1. Size of the developer community(??)

Most people will tell you: a key advantage for React Native over Flutter is its more established, more experienced developer community. Further, in terms of programming languages, Dart isn’t as widely used as JavaScript, at least for now.

In truth, Flutter has a lot of catching up to do if it’s to match its ‘older brother’ – which is understandable. The community needs time to educate its audience and to gain more experience, which is typical for any new, young tool.

However, we don’t see it as a significant disadvantage, and that’s why we added the (??) in the header. It’s also worth noting that the Flutter community is growing exponentially. Plus, there’s phenomenal excitement around the toolkit.

Please note:

There are also 35 Dart courses (with about 187,500-course participants (25 June 2019))

React Native numbers are roughly the same – about 287,000 students across 59 courses

  • Flutter has 80,600+ stars on Github while React Native has 83,000+

To sum up, Flutter does have a smaller, less experienced community at the moment, and Dart is more niche than JavaScript.

Still, current trends indicate that Flutter will catch up with its competitor in this respect, soon enough.

2. Libraries & support – impressive, but still not as rich as native development

Google’s support for Flutter is impressive, but Flutter is still quite new. This means you can’t always find the functionality you need in existing libraries, so your developers might need to build custom functionality themselves, which takes time.

Read more about this disadvantage here >>

3. Continuous Integration support

At the time of writing, Flutter lacks support for CI platforms like Travis or Jenkins. So, to achieve automatic building, testing, and deployment, your developers need to use and maintain custom scripts like this one.

That said, it is worth to note that:

4. Platform risk

Even though Flutter is open source, if Google decided to pull support for the project, it would spell disaster.

That said since the Google team released the Beta version of Flutter, it has only ramped up its efforts, as illustrated by Flutter’s prominent role during Google IO ’19, alongside the recent Flutter Live event.

At the current point in time, we cannot imagine a world where Google walks away from Flutter.

5. App’s size

Applications written in Flutter are bigger than native ones. Check out the article Comparing APK sizes. However, the Flutter team is working on reducing the size of apps made with Flutter.

React Native – pros and cons

✅ PROS of React Native:

1. Hot Reload = fast coding Fast refresh = fast coding

Essentially the same feature as Flutter.

Hot Reload speeds up the development process by allowing a developer to inject new code directly into a running app. So, a developer can see changes instantly, without rebuilding the app.

Hot Reload also retains the application’s state, avoiding the risk of losing it during a full reload (a critical benefit in the context of state-based frameworks) – speeding up the mobile app development process even further.

To improve the developer experience with hot reloading, the React Native team includes in 0.61 version a new feature called fast refresh that unifies live and hot reloading. It’s more resilient to typos and mistakes compared to the previous version. You can read more about fast refresh here.

2. One codebase, 2 mobile platforms (and more!)

Exactly the same as Flutter: write a single codebase to power 2 apps – covering both Android and iOS platforms.

Better still, JavaScript gives you a leg up when writing cross-platform applications by sharing code with web apps. This is accomplished by creating abstraction components that you can compile to target platforms.

See below for example libraries that allow you to simultaneously create code on platforms other than iOS and Android (including web and desktop apps):

  • React Native for Web – supports Android, iOS, and web (Twitter used this to create Twitter Lite)
  • ReactXp – developed by the Skype Team to support Android, iOS, and web; plus, works on Windows 10 (UWP)
  • react-native-windows – developed by the Microsoft team, supports all the devices supported by Windows 10 ( PCs, tablets, 2-in-1s, Xbox, Mixed reality devices, etc.)

Side Note:

Bartosz (our React Native developer) sees things a little differently to most, and so prefers an alternative approach.

If you compare a web desktop app, a mobile web app, and a native app, you can assume they share the same business logic – but they likely need a specific UI that fits distinct user requirements.

So, why not:

  1. Extract shared code to a separate repository;
  2. Treat it as a separate project;
  3. Inject the code in the same way as any other dependency?

Working this way allows developers to focus on writing apps to an actual platform – without having to consider cross-platform compatibility.

Watch Ben Ellerby’s presentation about the approach and if you like idea of creating abstraction over platform, check out Radek Pietruszewski’s presentation as well. 

3. It uses a wildly popular language – JavaScript

React Native uses JavaScript: a programming language that many developers know well (whereas Dart is still not so widely known or used). And if you’re a developer who prefers statically-typed programming languages, you can even use TypeScript – a JavaScript subset.

4. Developer freedom of choice

React Native lets developers build cross-platform apps; no more, no less.

The advantage is that React Native allows the developer to decide precisely what solutions they want to use; both according to the project’s requirements as much as the developer’s preferences.

Say, if a developer needs to decide how to handle the global state (how to store and manage the data that’s used in many components in the app), choose a router library, or choose between JavaScript and TypeScript – they can decide if they’d prefer to use a custom UI library, or write their own.

4. Relative maturity

The official React Native release was more than 5 years ago, so the Facebook team have had plenty of time to stabilize the API, as well as focus on fixing issues and solving problems.

Now, they’re working on a few exciting improvements – like reducing app size.

5. An active – and vast – community

React Native has a massive developer community. Not just that, but there are countless tutorials, libraries, and UI frameworks that make it easy to learn the technology – as well as quick and easy to develop with it.

And if you compare repositories focused on gathering articles, tools, and materials about specific technologies, React Native is much better placed than Xamarin, Flutter or Ionic (source: Awesome-Flutter, Awesome-ReactNative, Awesome-Ionic, Awesome-Xamarin).

What is more, React Native is part of the “React family”. While many of its libraries are platform agnostic (like Formik, React Router, styled components), which means they work across both web and mobile.

  • It’s also worth calling Expo to your attention – the React constitutional framework that simplifies access to native APIs – which has ready-made solutions for typical mobile features (e.g., push notifications).
  • A second library worth mentioning is AWS Amplify: a solution that simplifies integration with AWS features by covering authentication, storage, push notifications, and analytics.

6. Easy to learn for React developers

This advantage in our list is highly targeted at React developers. If you have a background in web development and already use popular React solutions, you can easily get to work with React Native, without having to learn new libraries. You can use the same libraries, tools, and patterns.

7. Up to 50% less testing

We write roughly 50% fewer automated tests because we can create the same tests to run on both platforms, reducing the demands on our QA team. It looks the same as in Flutter app development – we described it here.

🔻 CONS of React Native

1. It isn’t really Native

Like any cross-platform solution, neither the UI experience nor performance will be the same as in native apps – just close to them.

But still, it is easier to achieve a “native feeling” with React Native than with Flutter. If you want your Flutter app to have native components, it will require additional work.

2. Fewer components out of box

React Native supports only basic components out of box (many of them are adaptive to a platform out of box, like button, loading indicator, or slider).

As we said in this paragraph, there are outside repos with many additional components for React Native. A developer can use them in a project but that requires additional effort and time.

On the other hand, Flutter is designed to support Material Design out of box, so the framework supports much more widgets. It saves time. A developer using Flutter can create most of the views with pre-made widgets which are easily customizable and cross-platform consistent.

3. Developer freedom of choice

…both a curse and a blessing.

Once a developer has created a new project, they then need to decide which navigation package – as well as which global state management – to use.

It can take a lot of time to understand the nuances of every solution, and ultimately, to decide upon the best ones to use for the project.

4. Lots of abandoned packages

React Native boasts an enormous number of libraries. Unfortunately, too many of them are either low quality; or have been abandoned altogether.

Dan Abramov advises checking the number of issues and frequency of commits in a repository to prevent using abanded packages.

Read more about the problems and limitations of the current shape of React Native in this summary of his discussion of “What do you dislike about React Native?”

5. Fragile UI

The fact that React Native uses native components under the hood should give you confidence that, after every OS UI update, your app components will be instantly upgraded, as well.

That said – this can break the app’s UI but it happens very rarely.

What’s worse, updates can become even more dangerous if they cause certain changes in the Native Components API. The good news? This kind of event happens very rarely.

Whereas when it comes to Flutter (thanks to the way the framework recreates native components on their own), the app UI is a lot more stable.

6. Apps are bigger than native ones

Applications written in React Native must be able to run Javascript code (JavaScript Virtual Machine). Android doesn’t have this functionality by default – meaning applications need to include a library that supports JavaScript code, resulting in apps that are bigger than their native Android counterparts.

iOS apps made with React Native don’t this problem, but they are still usually bigger than native ones. The good news? As we mentioned before, React Native team is working on reducing their apps’ size.

Read more about the Pros and Cons of React Native Development for App Owners in 2021.

Predicting the future: Flutter & React Native

More and more companies are attracted by Flutter. After all, we’re witnessing monthly improvements in the Flutter SDK as Google continues to refine its tool. Plus, the community is always helpful and enthusiastic. What’s more, we can expect that soon Flutter will enable us to create not only mobile applications but also apps for web and desktop.

Putting it all together – and given leading companies like Alibaba are already using Flutter – the future looks promising for the toolkit.

As for React Native – well, Facebook is currently focusing on a large-scale re-architecture of the technology.

The team is doing its level best to improve support for both React Native users and the wider community. And thanks to this, the community can now easily suggest changes to the framework’s core functionalities through an RFC process that uses a dedicated GitHub repo.

The actual results of such architecture improvements are:

  •  Hermes  – an open-source JavaScript engine optimized for mobile apps that improves time to interaction, and lowers app size and memory utilization
  • Big changes in the 0.60 version (find the full summary here):
    • it’s easier to manage iOS dependency by using the most popular dependency manager CocoaPods by default,
    • you can migrate React Native to AndroidX,
    • you can extract optional features as part of lean core process.

Creating an open environment to discuss React Native is a significant step. It’s both a sign of ongoing improvement as well as a signal for the technology’s bright future.

Given React Native has such a stable position in the marketplace – and is on a trajectory of continuous development – it’s unlikely we’ll see the toolkit left in the dust any time soon. Read about the long-term vision for React Native in this article.

Still, Flutter is an imposing competitor to React Native.

Read also: Outsourcing Software Development – Benefits & Risks for App Owners

React Native or Flutter? 3 insights from developers & app owners.

We recently wrote an ebook covering the best Flutter app examples – including key insights from 17 different app owners and developers who are actively working with the Flutter framework.

Below, you’ll find a selection of quotes that cover the Flutter vs. React Native debate.

Abin Baby
Co-founder and Developer at KlasterMe
  • For me, Flutter was harder to learn than React Native. Mainly because React Native uses JavaScript (which is a familiar language for me) whereas I was new to Dart – the language used by Flutter. So, if you are new to Dart and trying to learn Flutter, it will take more time than learning React Native. But the opposite is also true – if you have experience in Dart, then learning Flutter will be a walk in a park.
  • The components in React Native are pretty basic, so if you need anything extra, considerable effort is required when styling. Only a handful of components are adaptive to the platform, while most of the time you have to use a different component for both iOS and Android; or, style it differently.
    On the other hand, with Flutter, everything is a widget. And the widgets are based on Material Design, making them easily customizable. Most of the widgets are adaptive, and you can use the same widget across both Android and iOS.
  • When it comes to performance, Flutter has the upper hand as it’s compiled to ARM or x86 native libraries, which makes it really fast. React Native isn’t compiled to native code, and it still has the JavaScript layer, making it less performant than Flutter.

Ishaan Bahal
Co-founder at Meeve

React Native is the closest competitor to Flutter. I like it as it sets the standard for cross-platform native development.

That said, our experience with it has surfaced a few issues.

  1. React Native is just a wrapper over native methods, so it requires a bridge to translate those calls into a native API; this becomes a bottleneck when you have a lot of native calls happening. There are ways around this, but with Flutter, you don’t ever have to worry about the issue as the view layer is rendered like a game would be – and as all components are designed by Flutter engineers, there are fewer native calls to the bridge.
  2. React Native components aren’t always customisable enough as they are just wrappers over native views. So, say someone decided not to wrap a certain method, then you won’t have access to it (for instance, dashed borders around a view don’t work) – while new components released by Google and Apple can take a long time to become available on React Native.
  3. Bugs on React Native have also started to take a lot longer to get fixed. The dashed border issue, for one; as well as a separate issue supporting various build flavours etc. Most companies running React Native in production, run a custom fork to fix bugs that aren’t fixed upstream. The Flutter devs are more proactive, and you can expect fixes fast. We ended up spending most of our time looking for issues in React Native documentation, then figuring out why things weren’t working the way they should.

The issues we found sent us searching for something better – fortunately, Flutter was just around the corner.

Swav Kulinski
Lead Engineer at The App Business

The main benefit of Flutter over React Native (and native, in general) is the lack of platform constraints. Flutter isn’t muzzled by the platform UI because it doesn’t use it; it renders everything by itself. This frees you to build the best UX without compromise – and it’s the primary difference between Flutter and React Native. Read more here >>


When to choose React Native, and when to choose Flutter

Delivering projects on time is one of the most critical aspects of mobile and web app development.

The cross-platform nature of both React Native and Flutter reduce time-to-market. Plus, their third-party libraries and ready-to-use components make it more efficient to use them to build your app.

Better still, Flutter and React Native offer more than just speedy development, they can reduce project costs as well.

…and these are the key reasons you should consider either framework for your project. But which solution offers the fastest development time? Or fits your app idea best?

Well, that depends on the specifics of your project and the balance of your team’s skills.

  • Do your developers know Dart? If yes, then programming with Flutter will be a walk in the park.
  • Are your developers fluent in JavaScript? If yes, then React Native seems the logical choice.
  • Do you want to build your app’s GUI using native UI components? If yes, choose React Native.
  • Is brand-first design your priority? If yes, we suggest Flutter fits the bill.

Remember that each application is different, so you must consider each one on its own merits. It’s always worth discussing your project with an experienced team of developers: people capable of considering the different approaches, with a varied enough skillset when it comes to cross-platform development – as if you seek the advice of programmers who know just one framework, they’ll likely steer you to use that tool.

If nothing else, take confidence from this: both Flutter and React Native are very good technologies. They benefit from huge popularity and enduring trust.

Read also: 5 Legal Issues to consider in Mobile App Development.

Each of the frameworks can help your application spread its wings and fly. We’ll keep our fingers crossed for you – best of luck with your next steps!

Useful links & resources

The post Flutter vs. React Native – What to Choose in 2021? appeared first on Droids On Roids.

https://www.thedroidsonroids.com/blog/flutter-vs-react-native-what-to-choose-in-2021/feed 8
What Is a Mobile App? | App Development Basics for Businesses https://www.thedroidsonroids.com/blog/what-is-a-mobile-app-app-development-basics-for-businesses https://www.thedroidsonroids.com/blog/what-is-a-mobile-app-app-development-basics-for-businesses#disqus_thread Mon, 01 Feb 2021 17:03:52 +0000 https://www.thedroidsonroids.com/?p=23642 What is a mobile application? What kind of benefits does it bring to businesses? Read this guide to learn about the process of building a mobile app.

The post What Is a Mobile App? | App Development Basics for Businesses appeared first on Droids On Roids.

Mobile is a growing industry that attracts businesses from every marketplace. No wonder – mobile app revenues are projected to reach almost $600 billion in 2020. The exploding popularity of smartphones and tablets has made mobile application development an increasingly popular trend among business owners all over the world.

But what exactly is a mobile app? What kind of benefits does it bring to businesses? And what does the process of building a mobile application look like?

We prepared a guide that answers all of these questions and more! Read on to learn everything you need to know about mobile apps and their development.

All this knowledge comes from our 9 years of experience which we have gained as an Android app development company and iOS app development company.

1. What is a mobile application?

A mobile application (also called a mobile app) is a type of application designed to run on a mobile device, which can be a smartphone or tablet computer. Even if apps are usually small software units with limited function, they still manage to provide users with quality services and experiences.

Contrary to applications designed for desktop computers, mobile applications move away from integrated software systems. Instead, each mobile app provides an isolated and limited functionality. For example, it can be a game, a calculator, or a mobile web browser.

Because of the limited hardware resources of the early mobile devices, mobile apps avoided multi-functionality. However, even if the devices used today are far more sophisticated, mobile apps remain narrowly functional. This is how mobile app owners allow consumers to handpick exactly the functions their devices should have.

2. Key mobile app development technologies

To help you understand the process of building a mobile application here’s a closer look at all the different technology considerations business owners must make before building an app.

Native apps

What are native apps? Such apps are built for a single mobile operating system. That’s why they’re called native – they’re native to a particular platform or device. The majority of mobile apps today are built for systems like Android or iOS. To put it simply, you can’t install and use an Android app on iPhone, and vice versa.

The main benefit of native apps is their high performance and excellent user experience. After all, developers who build them use native device UI. Access to a broad range of APIs also helps to accelerate the development work and extend the boundaries of app usage. Native applications can only be downloaded from app stores and installed directly into devices. That’s why they first need to pass a strict publishing process. 32157

Read also:

The most important drawback of native apps is their cost. To build, support, and maintain an app for Android and iOS you basically need two development teams. As you can imagine, this may result in a higher price tag on the project.

Web apps

Web apps are software applications that behave similarly to native mobile apps and work on mobile devices. However, there are significant differences between native apps and web apps. For starters, web apps use browsers to run, and they’re usually written in CSS, HTML5, or JavaScript. Such apps redirect the user to the URL and then offer them the option to install the app. They simply create a bookmark on their page. That’s why they require minimum device memory.

Since all of the personal databases will be saved on the server, users can only use the application if they have an internet connection. This is the main drawback of web apps – they always require a good internet connection. Otherwise, you risk delivering a subpar user experience.

Moreover, developers don’t have that many APIs works with, except for the most popular features like geolocation. The performance will be linked to browser work and network connection as well.

Hybrid apps

These apps are built using web technologies such as JavaScript, CSS, and HTML 5. Why are they called hybrid? Hybrid apps basically work like web apps disguised in a native wrapper.

Hybrid apps are easy and fast to develop, which is a clear benefit. You also get a single codebase for all the platforms. This lowers the cost of maintenance and streamlines the updating process. Developers can also take advantage of many APIs for features such as gyroscope or geolocation.

On the other hand, hybrid applications may lack speed and performance. Also, you might experience some design issues as the app might not look the same on two or more platforms.

3. Types of mobile applications

Mobile applications come in many shapes and sizes. Here are the most popular types of mobile apps to help you understand the current trends in the mobile landscape.

  • Gaming apps – this is the most popular category of mobile apps. You’d be surprised to learn how many users install games on their phones. Businesses invest an increasing amount of time and resources into creating games and mobile versions of well-known stationary games because it’s such a profitable market. According to a recent study, mobile games account for 33% of all app downloads, 74% of consumer spendings, and 10% of all the time spent using apps. The most successful mobile games like Candy Crush Saga or Angry Birds become known all over the world.
  • Business or productivity apps – these apps hold a large chunk of the market today because people are increasingly prone to using their smartphones and tablets to perform many complex tasks on the go. For example, apps can help them to book tickets, send emails, or track their work progress. Business apps are geared at boosting productivity and minimizing expenses as they allow users to complete a wide range of tasks, from buying new cartridges for office printers to recruiting a new office manager.
  • Educational apps – this category includes mobile apps that help users gain new skills and knowledge. For example, language learning apps like Duolingo have become incredibly popular because they give users the flexibility they look for in learning. Educational game apps are an excellent tool for kids. Many educational apps turn out to be popular among teachers too, who use them to organize their teaching process better or educate themselves further.
  • Lifestyle apps – this broad category of apps spans shopping, fashion, virtual fitting rooms, workout, dating, and diet apps. These apps basically focus on various aspects of personal lifestyle.
  • M-commerce apps – the most popular shopping apps like Amazon or eBay offer the experience of their desktop versions to mobile users. Mobile commerce applications provide customers with convenient access to products and seamless payment methods for an optimal shopping experience. Learn more about mobile commerce definition and types of mobile commerce.
  • Entertainment apps – these apps allow users to stream video content, search for events, chat, or watch content online. Social media apps like Facebook or Instagram are great examples. Moreover, video streaming apps such as Netflix or Amazon Prime Video have become incredibly popular with users all over the world. These apps usually boost user engagement by notifying members about updates and newly added products.
  • Utility apps – these are so obvious that we barely even realize that we’re using them. In fact, utility apps usually have the shortest user session times – people use them to get things done and then move on. The most popular types of utility applications are barcode scanners, trackers, or healthcare apps.
  • Travel apps – the main idea behind this category is helping users to travel easily. Travel apps transform a smartphone or tablet into a travel diary and guide that helps users to discover everything they need to know about the site they’re visiting. Most of the tourists are digitally savvy travelers who know how to use apps to their advantage. Can you imagine what traveling would look like without Google Maps, Airbnb, or Uber? You may also like: How to Make an App like Uber: Process and Cost in 2021

4. Mobile app statistics

To give you a broader view of the mobile app scene today, here are the most important statistics that show you the current mobile landscape and its future.

  • An average mobile app user in the United States has over 100 apps installed on their device. (Source)
  • A typical mobile user will check their smartphone 63 times a day. (Source)
  • 87% of users check their phone at least one hour before sleep. Out of those, 69% will check their phone at least five minutes before sleep. (Source)
  • 79% of users will abandon a digital product after only one day of use. (Source)
  • Mobile apps today account for more than 57% of all digital media usage. (Source)
  • By 2021, almost 7 billion people worldwide will be using mobile devices. (Source)
  • By 2022, the mobile app downloads number or year will reach 258 million. This is a great increase from 2017 when that number reached 168 million. (Source)
  • By the same year, the app store consumer spending will increase by 92% to reach a smashing $157 billion all over the world. (Source)

5. What is mobile app development?

Mobile app development is a process that draws a lot from traditional software development. However, it’s focused on creating software that takes advantage of the unique features of mobile device hardware.

The most straightforward scenario for building a mobile app is taking a desktop-based application and importing it to a mobile device. However, as the app becomes more robust, this technique can become problematic.

A better approach involves developing specifically for the mobile environment. It’s a technique that takes advantage of all the benefits mobile devices offer. The process takes into account their limitations and helps business owners balance cost with functionality.

For example, applications that use location-based features such as maps are always built from the ground up with mobile in mind. Location-based services delivered on a desktop app make less sense because desktop users aren’t moving around.

Modern smartphones and tablets are equipped with features such as Bluetooth, Near Field Communication (NFC), GPS, gyroscopic sensors, cameras, and many more. Developers can use these features to create apps with technologies such as Virtual or Augmented Reality, barcode scanning, location-based services, and many more. The most successful and popular mobile applications use smartphone features in the best possible way.

Optimal performance is a key goal of mobile development teams. Mobile devices such as smartphones or tablets differ from desktop devices in many ways. Experienced software agencies are aware that mobile apps need to be designed and built with performance in mind.

Wojciech Szwajkiewicz - CEO and President of Droids On Roids

CEO at Droids On Roids

The issue of hardware in mobile devices introduces another complication:

While developers building apps for iOS can only expect the apps to be run on two types of devices (iPhones and iPads), Android developers can’t say the same. In fact, for them, every smartphone and tablet may be running on different hardware and various versions of the operating system.

6. How to build a mobile app?

If you’re planning to build a mobile application, you can basically choose from three different options:

  • Build an in-house development team,
  • Hire specialized software development agency,
  • Rely on the expertise of freelancers.

Here’s a short overview of each of the options with its respective pros and cons to help you make the best decision for your mobile development project.

Building an in-house team

If you decide to create an in-house development team for your project, you will have full control over the direction developers take in building your mobile app. However, this will come at a high cost.

After all, you will not only have to pay for developers’ salaries but also a range of overhead costs such as workspace, benefits and perks, hardware, software licenses, and many others. This can be especially difficult if you’re located in a region where hiring mobile developers is expensive.

If you choose this option, expect a very high price tag on your app. The risk of your project will increase as well because you will be responsible for the work of your team.

Hiring a freelancer

This option is definitely the cheapest one of all three. By hiring a single freelancer to build your mobile app, you will enjoy a simplified development process. Communication might be easier, and you’ll face no collaboration issues because only one person will be responsible for building your app.

However, finding a reliable and trustworthy freelancer is a challenge. You will be better the entire success of your project on a single person’s skills and expertise. Even if you hire a talented mobile developer, they might be really talented in backend development and have limited knowledge of frontend development. If you create an app that works well but has an unattractive user interface, your product will suffer.

Hiring a freelancer is a cost-effective option, but it comes with many different risks that may compromise the process of building your app at every single stage.

Hiring a software development company

There are many software development agencies that specialize in mobile development today. By teaming up with such companies, you will be delegating the task of building your app to a group of professionals who can provide you with a broad range of services such as:

  • UX/UI design,
  • product development,
  • backend and frontend development,
  • testing,
  • quality assurance (QA),
  • and project management.

The main benefit of this option is that you can take advantage of the collective expertise and knowledge the team has acquired through realizing projects that are similar to yours. You can confirm their experience and skills through the portfolio and ask for client recommendations as well.

We recommend you to check out more tips on how to choose the best app development company for your project.

This option offers an excellent cost and quality balance, especially if you decide to outsource your project to a team located in a region where the development rates are lower than locally. You can estimate your project with different software houses to compare their offers and learn mobile app development cost in 2021.

So, that is all when it comes to comparison of the 3 above models. For a more in-depth comparison of an in-house and outsourced team, read our guides:


We hope this guide helps you understand what the mobile app development landscape looks like today. In the future, we’re going to see even more innovative mobile applications take advantage of cutting-edge technologies like the Internet of Things, Augmented Reality, Virtual Reality, and many more.

And here’s something you can be sure of:

Businesses are going to be investing in more resources in mobile apps as mobile devices overrule desktop devices when it comes to the number and engagement of users.

Are you looking for an experienced mobile development team for your project? Get in touch with us.

We specialize in mobile development, and our experts know all the latest technologies to help you create a mobile app that offers an outstanding user experience and generates a tangible value for your business.

The post What Is a Mobile App? | App Development Basics for Businesses appeared first on Droids On Roids.

https://www.thedroidsonroids.com/blog/what-is-a-mobile-app-app-development-basics-for-businesses/feed 2
How to Publish an App on Google Play | Guide for App Owners https://www.thedroidsonroids.com/blog/how-publish-app-google-play-guide-and-checklist https://www.thedroidsonroids.com/blog/how-publish-app-google-play-guide-and-checklist#disqus_thread Fri, 22 Jan 2021 15:00:47 +0000 https://www.thedroidsonroids.com/?p=5884 An Android developer with 10 years of experience explains how to publish your app on Google Play.

The post How to Publish an App on Google Play | Guide for App Owners appeared first on Droids On Roids.


The number of available apps in the Google Play Store is placed at more than 3.4 million apps (January 2021). Google Play is certainly one of the largest platforms for distributing, promoting, and selling Android applications.

Publishing your Android app on Google Play is not only exciting but also a crucial element of your application development process that influences its final success. Will your app be submitted, will it be popular, and will people download and install it? All this and more depends on how fruitful your release will be.

In our previous article, Publishing on app stores, we described the process of app publishing in general – both on App Store and Google Play. In this post, we focus only on Android apps and go deeper into Google Play’s requirements. Read on to learn how to publish an app on Google Play.

Read also our Guide on How to Submit an App to the Apple’s App Store.

1. Before you begin

Before you publish your Android app on Google Play, you need to check whether it is ready from both a technical and legal point of view.

Technical prerequisites

Target API Level

New applications have to meet the target API level requirements. It cannot be too low. The target API level (also known as the target SDK version) is a number indicating the newest Android version an app is designed to.

If the Android version on the user’s device is newer than the target level of the app, then some backward compatibility behavior may be applied. In changes in subsequent Android versions, you may often expect increased security by adding new permissions and restrictions. For example, if some action wasn’t permission-protected so far, but starts to be protected from a particular API level onwards, the developers writing the code a few years before had no way of knowing that.

App versions that are already published should not break after such changes. However, new apps, as well as new versions of published ones, should meet the current standards. Nowadays (January 2021), the minimum target API level for new apps is 29 (Android P). This will be increased to 30 (Android R) at the beginning of August 2021. As history suggests, the analogous version increment (to 31) is likely to happen in August 2022. Read on to learn how to publish an app on Google Play.

Keep in mind that increasing the target API level is not just bumping a number in the configuration file. It may be a very time-consuming process when you have an existing codebase. Moreover, not only the application source code itself but also 3rd party libraries may be affected. That’s why it is important to maintain the app on a regular basis and reduce the technical debt.

App bundles

Starting from August 2021, all new apps have to use the App Bundle (AAB). This format is useful only for uploading to the Google Play Store. Its backend generates an installable app variant dedicated to the actual user’s device and system. For example, assets for non-matching screen density will not be shipped, which will result in a smaller app size and faster installation.

APK file uploads won’t be accepted. What’s more, the APK expansion files (OBB) won’t be supported. They are superseded by Play Asset Delivery or Play Feature Delivery.

In most apps (not necessarily games) the AAB format can just be used instead of the APK. The only noticeable exception occurs when the app size exceeds 150 MB and the aforementioned APK expansion files are used.

Legal prerequisites

Your app has to comply with Google Play Store’s terms of service and the United States’ laws in order to be distributed legally via the former. We’ve prepared a dedicated article about all those rules and we will publish it soon, so here we’ll only list some general advice.

Information about key topics like restricted content, intellectual property, and what is considered a forbidden malware or spam are placed in the Developer Policy Center. You can find videos and even interactive tutorials there. The formal distribution agreement is also available.

Another important fact is that the app has to meet US export laws. Google Play Store servers are located in the USA so, in order to deliver the app to users located in other countries, the app needs to be exported. This is required even if your app is not available to customers in the USA itself. You should take special care of this if your app uses cryptography.

For example, the PGP project could not be used for some time outside the USA. You can read more about export compliance in Play Store docs and the official website of the US Bureau of Industry and Security.

Keep in mind that your app also needs to be compliant with local laws in the customers’ countries. The most widely known are the GDPR laws found in EU/EEA countries. These are known to be enforced as, for example, Italian authorities fined Facebook £8.9m for misleading users of its app.

Read also: 5 legal issues you should consider before your app development.

2. The metadata

If you have reached this point, we can assume that your app is technically and legally eligible to be published on the Play Store. Let’s start with the proper publication!

App details

The main store listing for any app consists of 3 text fields:

  • App name – up to 50 characters
  • Short description – up to 80 characters
  • Full description – up to 4,000 characters

All of them are mandatory and can be localized to one of the supported locales (the combination of a language and optional region). You can also use customized listings to provide the same set of texts (and also graphics described later in this article) to more than one locale.

Look at the screenshots below to see where the app descriptions are displayed. Note the differences between mobile and web versions.

App description on Google Play – mobile and web view

Apart from marketing-related factors, you also have to follow the metadata requirements.

Particularly, you should avoid creating a visual distraction and using copyrighted words (eg. other brands’ names). Keep in mind that if you have permission to use some restricted content (eg. 3rd party intellectual property or something reserved for governments) you can submit a notice in advance to ease the review process.

Don’t forget about SEO (Search Engine Optimisation). If the app name is very similar to some unrelated word, the users may have trouble finding it using search engines. For example, if you have an app with soup recipes and you name it Souper then, most likely, the search results will begin with dozens of apps with names starting with Super. Of course, this may change if you use some paid promotion and/or other SEO-related actions.


You have to choose if your app is free or paid at the very beginning. That setting can be changed anytime from paid to free, but not the other way around!

Once set as free on the market, an app can not subsequently be given a price.

Note that a free app can still use in-app purchases. Keep in mind that receiving payments from users is not available in some countries. These are mainly ones which have some economic sanctions applied by the USA, such as Iran or Cuba. The up-to-date list can be found in the Play Store docs.

Take care when choosing the exact price amount. There are value limits separate for each supported currency. If an amount is close to the upper or lower limit, it may not be possible to achieve equal absolute values in all currencies. In January 2021, the minimum price is 0.50 EUR and 0.99 CHF (Swiss Francs) respectively. The latter is approximately 0.91 EUR (using the exchange rate current at the time of writing) so the lower limit is almost 2 times higher in CHF. You can find up-to-date limits in the official table.

Read also: How much does it cost to make a mobile app?

Graphic assets

You have to provide the app icon and screenshots for store listing purposes (for TV and daydream-enabled apps, the additional content is needed). Optionally, you can also add a link to a video on YouTube. These assets are used to highlight and promote your app.

By default, the app may be promoted even outside Google. However, you can opt-out of such external marketing by changing the setting in the Play Store console. Keep in mind that it may take up to 60 days for this change to take effect.

All the assets have to be compliant with the Developer Program Policies. They must also not violate any intellectual property or use forbidden elements like badges imitating those provided by Google Play Store, like Editors’ Choice.

App icon

The app icon on the Play Store usually looks like the launcher icon, which you should already have. The difference is that, for store listings, a higher resolution is needed – 512×512 px.

Hint: the Android Asset Studio (built-in to Android Studio IDE) can be used to generate all the icons – including the standard needed for the launcher and a hi-res one for the store.

Feature graphic

It is a 1024×500 opaque picture shown in various places on the Play Store mobile app and website. It should present the key point of your app or game. More guidelines can be found in the documentation.


You have to provide at least 2 screenshots of your app. However, you can add up to 8 of them for each device type supported by the app: phone, 7-inch tablet, 10-inch tablet, TV, and wearable. See the official docs for more guidelines. Hint: enable demo mode before making screenshots.

Promotional video

The video is optional but recommended, especially for games. If present, a video is displayed on the listing before the screenshots. Don’t forget to avoid using copyrighted content and turn off monetization to prevent displaying someone else’s advertisement. Of course, the video must not be private. Read more in the docs. Here is an example of the video from the Glovo app:


For Android TV-enabled apps, you also need a TV banner. Similarly, for Daydream-enabled apps, a 360-degree stereoscopic image is required.

Store settings

To help users encounter your app when browsing the store, you need to pick an appropriate category (like Shopping or Finance) and up to 5 optional tags (like Comics or Loan). Read more about tags and categories in the docs.

You have also to add your contact details in order to provide support for users. E-mail is required here and it may be different from the owner’s Google account address. Optionally, you can also add a phone number and a website link.

3. Content policy

Google needs to know several pieces of information about the content in your app. This is needed, for example, to correctly resolve the age restrictions. Let’s check those settings!

Privacy policy

This covers information about how you treat sensitive data. It is required when your target audience includes children below 13 years old. Usually, the privacy policy text is prepared by lawyers. However, guidelines are also available. Despite the fact that the form validation rules on Google Play allow you to proceed without specifying privacy policy, it may be still required by local laws (GDPR especially) even if you target only adults.

Stay tuned to read a detailed article about that, we’re working on it.


You have to declare whether your app contains advertisements. Note that not only banners or interstitials are considered ads. For example, sponsored articles also qualify as ads.

App access

If any part of your app is restricted eg. by geolocation or signing-in requirement, you have to provide the instructions for reviewers.

Content rating

Your app or game needs to have IARC ratings assigned. After filling a questionnaire, you will receive the ratings according to authorities like PEGI, ESRB, or USK. They are mainly used by parents to check whether an app is appropriate for their children.

Target audience

You have to indicate the target age group(s). In general, the lower the age groups you choose, the more requirements there are and the more questions you need to answer. Targeting children younger than 13 years old requires a privacy policy. If the app is designed for both children and adults, you may be interested in the families’ policy.

News policy

The last section is about news. This is only needed to indicate if your app is a news app. If so, you have to comply with additional rules. If an app claims to have a relationship with the publisher, that fact will be reviewed.

4. Targeting

Country restrictions

You may need to limit your app availability depending on geolocations because of licensing, copyright or other legal agreements. Within a particular country, you can adjust restrictions even finer by selecting particular mobile operators. Such restrictions can be configured separately for each track: production, open (beta), closed (alpha), or internal testing. Read more about this in the official docs.

Note that the term “country” here means one associated with the Google Play user account. It may not necessarily be the same as the actual user’s location. However, it may be only set to the value of the current country at the time of setting, not more frequently than once a year.

Device restrictions

Sometimes, it turns out that an app doesn’t work well on some particular device models despite the fact that they theoretically meet the requirements (like the minimum Android version or the presence of hardware features like NFC). You can exclude such problematic devices using the device catalog.

Advanced settings

You can also configure Actions on Google and add websites for App Indexing purposes.

Payment settings

If you want to sell your apps or use in-app payments, you have to set up a payment profile. In this case, you also need to specify a physical postal address.

Developer page

Optionally, you can set up the developer page. This is common for all apps published from the same developer account. If you want to publish the page, you have to specify your name, promotional text, developer icon, and header image. None of those fields can be blank.

Moreover, if you monetize your apps, then the aforementioned postal address will be displayed on the developer page. Optionally, you may also add a website address and choose a featured app.

See how this looks in the case of Glovo.

5. Technical settings

Apart from mostly business-related settings, there are also several technical ones that are important if you want to know how to publish an app on Google Play.

Application ID

All the apps must have a unique identifier. For example, for the CCC app, it is eu.ccc.mobile. The App ID may be visible to users, such as in the links. Once an app is uploaded to the store, the ID is reserved and no one else can use it. Moreover, the ID cannot be changed (you can, however, publish the new app with a different ID). So choose the ID wisely.

Including a brand name in the app or your ID may not be a good idea. For example, if you decide to acquire some other company or you will be acquired, then rebranding can happen. Since the App ID cannot be changed, it will contain the old brand forever. The technical requirements for the app ID can be found in the docs.


Every app has to be signed in order to be installable. In general, signing is a broad topic and a separate article would be needed to describe it fully. Here, we will focus only on the key points. The simplest way, nowadays, is to use app signing by Google Play.

There are a few options available: you may let the store generate the signing key for you, use the same key as another app on the same developer account, or provide your own key, which you have to generate beforehand.

Usually, just using a key generated by the store is sufficient. The same key for multiple apps may be needed in some advanced scenarios like custom permissions using signature protection. Such things are not widely used nowadays. Using your own self-generated key may be required for existing legacy apps.

The finishing touches

You have almost everything you should regarding how to publish an app on Google Play.

Before you release the app to the public you may want to test it within some restricted user group(s). You can set up open, closed, or internal test tracks for that purpose. You may also be interested in enabling API access to upload app builds automatically from the CI/CD pipelines.

Google automatically checks all the app versions you upload. The robot crawls your app by simulating basic actions like taps and gestures for a few minutes. Then, it prepares a pre-launch report. It is extremely helpful in discovering potential issues. Among others, it checks accessibility, performance, security, and Android compatibility.

How to publish an app on Google Play – wrap-up

App release is not rocket science but it does require precision. Remember to prepare the app from both the legal and technical points of view. Don’t forget about agreements and privacy policy if targeting children. If you are ready with these, most of the work consists of preparing graphic assets and promotional texts. Keep SEO in mind when choosing the wording. Note that most of the updates made through the developer console are not published automatically. They may need to be reviewed, which could take anything from a few hours to a few days.

I hope this article will help you to publish your application successfully on Google Play.

At Droids On Roids, we have extensive experience in publishing applications on both Google Play and the App Store. It is an integral part of our app development process. If you have any questions, please leave a comment or drop us a line.

The post How to Publish an App on Google Play | Guide for App Owners appeared first on Droids On Roids.

https://www.thedroidsonroids.com/blog/how-publish-app-google-play-guide-and-checklist/feed 2
Flutter Pros & Cons for Mobile App Owners https://www.thedroidsonroids.com/blog/flutter-in-mobile-app-development-pros-and-cons-for-app-owners https://www.thedroidsonroids.com/blog/flutter-in-mobile-app-development-pros-and-cons-for-app-owners#disqus_thread Wed, 20 Jan 2021 08:00:56 +0000 https://www.thedroidsonroids.com/?p=9675 What is Flutter? How can it make your app outstanding and beautiful? What are the pros and cons of Flutter? Is it a good idea for every mobile app development project?

The post Flutter Pros & Cons for Mobile App Owners appeared first on Droids On Roids.

Google I/O 2019 dedicated a lot of attention to Flutter and announced an almost overwhelming amount of news about this technology. Just to name a few:

Tim Sneath, Product Manager of Flutter made an aggregation of all the big news announced for Flutter in I/O 19: A roundup of Flutter news at Google I/O.

At the same time, the rate at which Flutter apps are published on Google Play continues to increase. Flutter is becoming a hot topic and, whether you decide to use it or not, if you want to develop or improve your mobile app, you should be aware of what Flutter is, as well as what pros & risks it carries. Let’s start with the basics.

What is Flutter?

Flutter is Google’s mobile app SDK, complete with a framework, widgets, and tools, that gives developers an easy way to build and deploy visually attractive, fast mobile apps on both Android and iOS platforms (official Flutter website).

Flutter enables a smooth and easy cross-platform mobile app development. You don’t need to develop an iOS and Android app separately. All you need is one codebase for both platforms.

What’s more, Flutter:

  • Is free and open source,
  • Is based on Dart – a fast, object-oriented programming language which is in itself easy to learn,
  • Provide its own widgets, drawn with its own high-performance rendering engine. They are fast, pretty, and customizable,
  • Thanks to the rich widgets, Flutter apps look and feel great (you can create your own custom app design, but also use readily available UI elements following specific platforms’ guidelines). Check out the article about Top Apps Made with Flutter
  • The architecture of Flutter is based on the very popular reactive programming of today (the same that React has been made from)
  • It’s becoming a serious competitor to React Native, but also to native app development. Read the articles: Flutter vs React Native – what to choose in 2021? and React Native Pros and Cons.

Let’s go to the pros & cons of Flutter!

Why Flutter in Mobile App Development

Why Flutter? 7 top advantages for mobile app owners

From the perspective of an app owner, the crucial advantages are as follows: Flutter speeds up the mobile app development process, reduces the app development cost, and helps your team to build a beautiful app UI with smooth animations. Let’s take a look at it more deeply. We have prepared the below lists for you with Paulina Szklarska and Karol Wrótniak – our Android Developers who work with Flutter.

1. Faster code writing

For developers, Flutter means faster & more dynamic mobile app development. We can make changes in the code and see them straight away in the app! This is the so-called Hot reload, which usually only takes (milli)seconds and helps teams add features, fix bugs, and experiment faster. It is one of the things about Flutter loved by every top Flutter app development team

Hot reload is also very comfortable in developer-designer cooperation when we want to improve or experiment with an app’s look and check the effects on the spot. In other words, with Flutter, your designer or tester can work together with a developer on the UI, making changes – for example, “Put it 2 pixels right” or “Make the animation faster” – and see them immediately. 

Why Flutter

Most types of code changes can be hot reloaded. But there is a list of changes that require a full restart: Hot reload Limitations.

Whereas, in the case of native app development the project needs to be rebuilt and that takes much more time. You have to wait for every single change – sometimes, even up to several minutes.  

2. One code for 2 platforms

Developers write just one codebase for your 2 apps – covering both Android and iOS platforms. Flutter doesn’t depend on the platform, because it has its own widgets and designs. This means that you have the same app on two platforms. Yet what’s important is that, if you want to differentiate your apps – it’s possible.

3. Less testing

If you have the same app for 2 platforms, it means less testing! The Quality Assurance process can be faster. Because of one codebase, the developers write automatic tests only once. What’s more, Quality Assurance specialists have less work to do, because they have only one app to check. Of course, if your apps have some differences, they need to be tested on both platforms.

4. Faster apps

Flutter apps work in a smooth and fast way, without hanging and cutting while scrolling. If you want to understand why and how it works from a technical point of view, read this article. Also, check out this amazing page in the Flutter documentation that talks about best practices for app performance.

5.  Designs which your users will love

Flutter is designed to make it easy to create your own widgets or customize the existing widgets. Here you can browse a catalog of Flutter’s widgets and view, for example, Material Design widgets and Cupertino widgets.

6. The same app UI on older devices

Your new app will look the same, even on old versions of Android and iOS systems. There are no additional costs for supporting older devices. Flutter runs on Android Jelly Bean or newer, as well as iOS 8 or newer.

Why Flutter

Android 5.1.1

Why Flutter

Android 8.1.0

7. Perfect for MVP

Do you need an MVP (Minimum Viable Product) for your app to show it to your investors? Flutter will be perfect, especially if you have little time.

If you want to see some apps built with Flutter, check out the Flutter Gallery app, which is a demo of some of Flutter’s features, widgets, and vignettes.

Flutter Gallery

Flutter Gallery

Flutter Gallery

Flutter Gallery

Flutter Gallery Screen

Flutter Gallery

Does Flutter have any cons? 3 risks for mobile App Owners

1. Flutter is still in beta

In April 2018, Flutter beta 2 has been announced. The Flutter team hasn’t released the stable version yet. “Our APIs are stabilizing, and we continue to improve parts of the system based on user feedback. Some key features are not yet ready for broad deployment” – we read on the official Flutter website.

So this means that we can expect changes and improvements that can demand future changes in our code if we ship an app before the stable version of Flutter is ready.

Edited: Flutter is no longer in beta

On May 2019, Google announced the availability of the new stable build, Flutter 1.7.

2. Libraries & support – impressive, but still not so rich as for the native development

Google support for Flutter is impressive, and there are many helpful libraries with functionalities ready to be implemented. But Flutter is still new and not every functionality which you need can be found in these libraries. This means that your developers would need to build them by themselves, which can be very time-consuming.

Here you can find Flutter Packages – a list of features ready to be added to your app. What’s important is that these packages are checked, analyzed and rated for factors like health, popularity, and maintenance.

However, we can expect see that the support for Flutter is improving at a rapid pace. What’s more, the Flutter team is actively involved in supporting Flutter users by frequent solving and answering requested issues.

3. Continuous Integration support

Since Flutter is still in beta, For now, Flutter is not widely supported by CI platforms like Travis or Jenkins. So, to achieve automatic building, testing, and deployment, your development team needs to use and maintain custom scripts like this one. However, Bitrise.io is the exception where you can find a ready to use build step.


  • There is a new CI/CD system for Flutter applications called Codemagic that was announced at Flutter Live 2018.
  • In January 2019, Bitrise announced the full-featured Flutter CI.
  • Worth to mention: one of our team members, Karol, is continuously working on Flutters build step for Bitrise. The last release added the possibility to build appbundle for Android releases (read more about it here).

Is Flutter a good idea for every kind of mobile app?

There are a few cases when it’ s worth to consider if Flutter will be a proper solution:

  • Progressive Web Apps & Instant Apps
    They need to be small and Flutter apps – even optimized – are bigger than native ones. The overhead varies from just a few to 20 megabytes, depending on whether it is a release or development build. Note that Google allows apps of max. 10MB.
  • Apps which communicate with any hardware via Bluetooth
    If you want to develop an app with this kind of features and use Flutter, you can:

      • Develop these features separately for iOS and for Android and then add them to the main Flutter app using platform channels. In this case, it’s hard to say if it will save you time more than if you would develop two 100% native applications.
      • Develop these features for both platforms at the same time, using an existing Bluetooth plugin for Flutter – e.g.– FlutterBlue.

    Which option is better? Hard to say.

    As we can see on FlutterBlue repository on Github (06.12.2019), there are more than 200 opened issues and 36 pending Pull Requests. These numbers suggest that this library might require more maintenance and development.

    In the case of technologies such as Flutter, which are improving rapidly, frequent plugin’s updates are essential – and it has been updated very recently.

    How essential is it? We do not know, because the technology is still too young, but in the case of iOS apps, if a library is not maintained for six months (it’s a lot of time), we keep away from it, and the plugin for Flutter is basically a library for Android and iOS implementing the same features.

    Last, but not least – if your app needs an advanced Bluetooth feature, FlutterBlue might be not enough.

    In our opinion, FlutterBlue might not be mature enough to be used in a commercial product, but we see promising potential in it.

    For now, a less risky option would be choosing native development for apps that communicate with any hardware via BLE – especially if you will need some advanced BLE functionalities.

  • Apps demanding rare, little-known native libraries
    If in your app development, you expect to use any specific and rare native libraries and they are not already in Flutter’s repository, it can still be possible but it will be complicated. Developers would have to implement the custom platform channels by themselves – separately for both Android and iOS. This is what can take time.

Wrap up & our recommendation

In our opinion, Flutter has many more advantages for business and development teams than risks. It’s a great chance to build beautiful, high-performance, and outstanding mobile apps that fit your custom needs and requirements. It’s worth considering Flutter, especially if you want an app both for iOS and Android.

What’s more, it can save you time & money. The major risk comes from the fact that Flutter is still improving and is not 100% completed. So, if you want to use Flutter, consider if you want to wait for the stable version release. It’s hard to say when this will be ready. Hopefully, it’s only a matter of months. Flutter 1.17 is already available, so it is worth at least to give it a try! 

Why Flutter

We also asked our friend – Tomek Polański – for his opinion about Flutter. Tomek is a Senior Android Developer at Groupon and, at the TOAST – Android Developer Meetup #17,  he gave a presentation: “I convinced Groupon to Flutter. Do the same with your company”. Here’s what he said:

Flutter is perfect for creating a customized application experience. Time and time again it has been shown that award-winning applications (MWC’s Glomo AwardsTIME’s Best Apps of the Year and the Webby Awards Mobile Apps) focus on delivering beautiful custom experiences rather than the pixel perfect native iOS/Android look – and Flutter delivers on this.

On one hand, you have the ability to create a simple UI rapidly and, on the other, Flutter is a powerful tool to create beautiful custom applications thanks to its extensibility. The thing that I’ve found positively surprising is that we have communicated that developing applications in Flutter is much faster than native, product people were still astonished that’s true in practice.

Tomasz Polański
Senior Android Developer at Groupon

We wish you good luck with Flutter! If you already have tried it out, share your impressions and leave a comment 🙂

Useful links about Flutter

The post Flutter Pros & Cons for Mobile App Owners appeared first on Droids On Roids.

https://www.thedroidsonroids.com/blog/flutter-in-mobile-app-development-pros-and-cons-for-app-owners/feed 4
How to Develop a GPS Navigation App like Waze in 2021 | Process and Tips https://www.thedroidsonroids.com/blog/how-to-develop-a-gps-navigation-app-like-waze https://www.thedroidsonroids.com/blog/how-to-develop-a-gps-navigation-app-like-waze#disqus_thread Sun, 10 Jan 2021 14:19:00 +0000 https://www.thedroidsonroids.com/?p=29910 Use our expert tips to develop a successful GPS navigation app like Waze.

The post How to Develop a GPS Navigation App like Waze in 2021 | Process and Tips appeared first on Droids On Roids.

Navigation apps market

When a smartphone user needs to go somewhere, chances are high that they use a mobile app to find the best route with the fewest obstructions and lightest traffic. The rapid growth of GPS navigation and map apps shows that consumers are increasingly using smartphones while traveling or running errands.

Did you know that 77% of smartphone owners have navigation apps on their phones? This way, they avoid getting lost, get to discover new places, read reviews of restaurants and other service shops, and easily share this information with friends. A recent report on the navigation app market showed that GPS apps are going to bring $34.56 billion of revenue by 2021. A navigation app can be a very profitable business.

The two most popular apps for both iOS and Android in this segment are Google Maps and Waze. They offer lots of real-time information, turn-by-turn directions and many more features that make them so attractive. Google Maps counts a smashing 154.4 million active users every month, bringing its market share to 67%! But we decided to choose Waze as our example because of its innovative nature and rapidly growing user base.

What is Waze mobile app and why is it notable?

In 2019, Waze counted 110 million monthly active users. The company’s annual revenue is estimated at $37.7 million. You can now probably tell why we chose Waze as our example for this blog post.

Google bought Waze in 2013 and then continued to develop it as a separate, community-based GPS navigation app. Waze stands out on the market thanks to its real-time and crowd-sourced social networking features. For example, drivers who use Waze can alert other users about accidents, hazards, obstacles, speed traps, police activity and other issues. Users can then change their route with the app, which also gives them an ETA based on real-time traffic conditions.

But this is just the tip of the iceberg. Aside from geolocation and navigation features, Waze users can listen to their favorite music from apps like Spotify, as well as podcasts, from within the app. Waze also helps to find the cheapest gas stations along the route. Drivers can use the app on your car’s display thanks to Android Auto or Apple CarPlay.

Users can also choose from a variety of app audio voices to guide you while driving or even arrange carpools where you can offer rides or find companions to carpool. Waze is free to use and even features a motorcycle mode – it has everything a user could want!

That’s all great, but how does Waze make money?

If you want to build a GPS navigation app, you’re probably wondering about the potential monetization strategies. How does Waze monetize its navigation app?

Basically, Waze makes money on location-based advertisements through the following features:

  • Branded pins – these pins appear on Waze maps when the user is driving nearby. They work like a store sign, raising brand awareness and attracting on-route customers to the store.
  • Zero-speed takeovers – such digital billboards appear on the device screen when the user comes to a complete stop for at least 3 seconds. It’s like a traffic stoplight.
  • Promoted search advertisements – Waze also displays promoted search ads when drivers use the app’s search engine to look for shopping malls, restaurants, movie theatres and other places.

Navigation app development – 7 stages

If you’re looking to build a navigation app like Waze, you’re going to follow the standard mobile development process. Here are its main phases:

  1. Choosing your technology partner
    You need to pick a software development company to build your app. This is the stage where you research, analyze and select a company to cooperate on your navigation app. Signing an Independent Contractor Agreement is a key part of this process. Read more about choosing a partner for your app development.
  1. Product Discovery
    Define the app you want to build: what problem does it solve, who is your target audience and why do you want to build it? Clarify your app’s vision, define your product’s goals and determine who your end-users are. At this point, you also need to decide which features are the most crucial for creating your Minimum Viable Product (MVP), which platforms your app will work on, and what will be your monetization models. Read more about the Product Discovery phase.
  1. UX / UI app design
    This is where you determine how your navigation app will work and look. You need to create a User Journey Map, and then use the UX insights to create clickable wireframes, visual user interfaces, and motion design (animations and screen transitions). Read more about UX/UI app design process.
  1. Project kick-off & setup
    These are the last preparations before the development team begins to work on your app. This is where you get to meet team members, define roles in the team, agree on key rules, the next steps and tools that will be used. The idea here is to set up the project environment using best practices, ranging from project management to DevOps. This is how you make sure that the development process runs quickly and smoothly. Read more about project kick-off and setup.
  1. Mobile development process with Quality Assurance (QA)
    This is where developers finally get to build your product, using best practices such as Continuous Integration: plan, code, build, test (and repeat). Make sure that your team involves Quality Assurance at every stage of navigation app development, using manual and automated tests. Most teams follow the Scrum framework and divide the work into short iterations followed by demos.
  1. Publication of the app on Google Play Store and Apple Store
    Releasing an app means that you need to upload assets required by laws, create promotional materials, get some beta testing done, optimize the product page/store presence, and everything else that ensures your app approval will go as smoothly as possible. Preparing for launch is key if you want your navigation app to stand out from the crowd and succeed.
  1. Post-development phase – app maintenance and further development
    The team keeps a close eye on your navigation app, detects any crashes, monitors the app’s statistics, and works on further development by adding new features or improving the existing ones. This way, your GPS app keeps on attracting users and responds to the changing market conditions, as well as feedback from end-users.

If you partner with a software development agency that specializes in building apps, you get access to many other helpful services. For example, at Droids On Roids we offer a Product Design Workshop, a service designed to help app owners clarify the vision for their app, prepare end-user personas, and kick-off a project successfully.

Need more insights about the development process? Read this article: Mobile App Development Process – 7 Stages of App Development

What is the best technology stack for a navigation app?

As you may guess, the answer to the question “What technology stack should I choose for my app” is always the same in IT: “It depends” 🙂

Developers will find a lot of SDKs on the market that provide turn-by-turn navigation, such as Google Directions API or Mapbox. Which one should you choose? This choice is strongly connected to the problem the app needs to solve and its additional features. The core feature of the navigation app is the map itself. 

Questions that will help you to choose the optimal technology stack for your navigation app

  • Does my app have a step-by-step navigation feature within it?
    If yes, Google Map SDK is not an option here. Google Maps API privacy states that you can’t use their SDK to “build a product or service with features that are substantially similar to or that re-create the features of another Google product or service.” Fortunately, we have a wide variety of navigation SDKs available on the market that do the job perfectly – for example, Mapbox or Sygic.
  • Can my app be used without an internet connection?
    In this case, developers need to find an SDK that supports fetching a map and saving it in a local database so that it can be used without a network connection.
  • Does my app give voice instructions during navigation?
    Again, not all of the available SDKs support voice instructions so it is important to choose one that has this feature if it’s part of your app vision.
  • Does the SDK allow my backend to interact with it for providing the best map and navigation experience to the end-user?
    Some apps require adding custom roads to the map. It’s also really important that the SDK you use in your project is flexible and allows you to modify map tiles as needed.

Answering the above questions will help you to choose the most suitable SKD. In our experience, Mapbox is one of the best APIs for developing navigation apps. It offers a great directions API, allows us to use the map without an internet connection, and provides step-by-step navigation with text and voice instructions.

To build a great navigation app, all you need is a solid SDK that delivers maps and routing options. Other functionalities and UI can be added using native code.

Read also: Pros and Cons of Using Third-Party Software in Your App Development

Future technologies for navigation app development

Many companies are now testing cutting edge technologies such as Augmented Reality in navigation apps. For example, Google Maps already offers AR-powered navigation to users in the areas that are covered by Google Street view. Google is planning to improve the app’s Visual Positioning System to make orientation more accurate.

We are also seeing other AR apps pop up on the market, such as the Japanese PinnAR, or paid AR packages in navigation apps like Sygic. Navigation app owners can take their services to the next level by implementing technologies like AR or Optical Character Recognition (OCR) which help to make the map more interactive and detailed. For example, Google Maps offers AR-based navigation when users travel the distance on foot. Other examples of apps that use Augmented Reality are Sygic, ARCity, and Yahoo Maps.

What are the key features of a navigation app like Waze?

Basic features of a navigation app

  • Authorization and user profiles
    By creating personal accounts, users get a space where they can leave notes, write reviews and communicate with other drivers. This is particularly important in navigation apps like Waze, where users rely on the advice of others. It’s easier to build a sense of trust between users if they can see who shared the tips and warnings they are following.
    how to develop an app with geolocation – Waze screens exmaple
  • Geolocation and navigation
    The map forms the core of a navigation app. It uses the GPS system to locate objects, determines user location and displays the route. To minimize errors, it’s a good idea to include the Cell ID functionality in your app, as it’s based on data coming from mobile operators. If your team combines GPS and Cell ID, the app’s geolocation services will be precise and accurate.
    how to develop an app with geolocation – Waze screens exmaple
  • Voice directions
    Apart from geolocation services, your navigation app needs to offer users the option of voice directions for the route. For example, developers can use Google Maps Directions API, which allows users to choose any voice from the list and instantly implement it. This feature is attractive to users because drivers are used to receiving directions by voice. You can add a little twist to this and hire someone famous to be the voice of your app.
    how to develop an app with geolocation – Waze screens exmaple
  • Rerouting
    Your GPS app needs to reroute drivers quickly if they make a wrong turn or stumble upon a road accident that prevents them from following the initial directions. Drivers don’t want to wait for several minutes for your app to recalculate the route – they need accurate directions straightaway.
  • Social networks integration
    It’s worth integrating your app with social media networks for the purpose of authentication, as well as to provide social features. For example, Google Local and Google Contacts offer access to information about businesses located nearby, as well as where friends have checked-in. They also show drivers places of interest on the basis of their previous visits.
    Integration with social networks boosts the user experience but also mitigates security risks around authentication because most potential issues and vulnerabilities are already taken care of. Moreover, you won’t be forcing users to create yet another account, but use their existing accounts for smooth login.
    how to develop an app with geolocation – Waze screens exmaple

Advanced features of a navigation app

  • In-app messages
    If you’d like to spice up your navigation app, you can think about how user messages will be displayed. Will you send them to a chat or deliver them as push notifications? It makes sense for navigation apps to do this when users enter a specific area or region.
  • Payment services
    Your navigation app might include in-app purchases as its monetization strategy. If your app becomes a hit among drivers and those who provide complementary services (car repairs or gas distribution), you might enter into a partnership. For example, your users could get discounts or a cashback offer if they buy something via your app. In return, you forge reliable partnerships and get an additional source of income.

The functionalities of the navigation app we described above are just a selection – in our opinion, the most important ones. You can see other examples of the Waze app features below on screenshots.
how to develop an app with geolocation – Waze example screens how to develop an app with geolocation – Waze screens exmaple
how to develop an app with geolocation – Waze screens exmaple

What are the most common problems with GPS navigation apps?

In the 21st century, we have much more advanced technologies than our ancestors could ever dream of. One of them is the GPS system that most of us use almost every day.

However, during navigation app development, we might face some problems here.

The most common issue is the correct user position tracking. It’s key for a navigation app to provide the most accurate user position. Which factors affect location accuracy? Here are a few examples:

  • Old hardware – older devices could have problems with signal strength and struggle to receive information from cellphone towers or satellites.
  • Topography – in cities with big buildings or areas with large population density, the signal can bounce from different structures and GPS receivers might become confused by the additional time that the signal took to reach them.
  • Not enough satellites – to calculate the user location with the accuracy of 10 m, the device needs a signal from at least 7 satellites: the fewer satellites, the worse the location accuracy.
  • GPS bouncing – the GPS signal can jump from one place to another, which can cause it to record more distance traveled than it was in reality.
  • Outdated maps – this is another problem that you should take into account. The world’s infrastructure changes very quickly and it is important to have up-to-date maps to provide the best user experience.

You may also like: How to Make an App like Uber and How Much It Costs

Our recommendations for developing a successful GPS navigation app like Waze

  • Start with a Product Discovery Workshop and describe the main features of your navigation app. This will help in technology stack selection and you will avoid surprises during development.
  • Add handy features such as rerouting, which instantly provides an alternative route when the user makes a wrong turn or if there was some accident and a faster route is available.
  • Add social integration to the app so users can share their trips and communicate with each other to inform about traffic or other situations on the road.
  • Add voice directions to make navigation safer as users will not be distracted by looking at the screen.
  • Make sure that the voice instructions play at the right moment. When you achieve this, the user can follow them without any distractions – for example, looking at the phone screen. The same is true for sending too many notifications during navigation – users simply shouldn’t get too many of them.
  • Add gamification features to motivate users to come back to the app. An example of this feature could be a points system. Users get points for different actions in the app, like sharing road information or for kilometers driven with the app. Users can compare their points with other drivers.
  • Provide a selection of the transport mode so the user can see the optimal road for the mode they chose (of course it won’t be a part of the MVP).
  • Make the UX/UI design of your app as simple as possible. The app buttons should be large and visible so drivers can find and tap them without any problems. Focus on the core functionality of your app – the UI should contain only the elements required during navigation.
  • Add a video while publishing the app. When uploading the application for review, it’s worth attaching a video that shows how the application works. Without this, Apple or Google might reject the application, arguing that they don’t know why the application needs to be allowed to run in the background and play audio.

Tips on Navigation App Development

Droids On Roids’ experience in the navigation app development

Libya’s lack of official addresses paralyzed the economy and stalled innovation in the country. Our client – Lamah company – addressed this problem by working with us to create Makani – a revolutionary GPS navigation app to improve the lives of millions in the country.

The Makani app moves Libyans from the use of difficult descriptive addressing to smooth digital addressing and enables the navigation of geographical locations within the country. It helps users to locate places within their region through a digital map that allocates specific postal codes to almost all locations.

The app is available for free on any iOS or Android smartphone and is positively rated by its users – in the Apple store at 4.5, and on Google at 4.2. In 3 months after launching, the map contains more than 430,000 addresses from nearly 180 cities in Libya, and we are constantly developing new features.

If you’d like to learn more about the technical and business details of the project, have a look at the Makani case study.

I really appreciate the communicative collaboration among Droids On Roids team and with us on a personal level. Astounding organizational skills and scheduling abilities and resources. Highly specialized with project management tools. They are very efficient and punctual with deadlines. Care for customers and impressive capacity of handling situations that might jeopardize their clients’ projects. The team generously provided advice, suggestions, expertise in their field of work for the benefit of our project assuring that it would not only be executed, but also further developed and improved. Our experience with Droids On Roids is outstanding, and we look forward to future collaborations.

Ahmed Alkaloush
CTO, Lamach Technologies

We have realized over 130 app ideas for clients from around the world, including the US, UK, Saudi Arabia, Norway and many more countries. Get in touch with us to get help from expert teams that know how to build a navigation app like Waze successfully.

The post How to Develop a GPS Navigation App like Waze in 2021 | Process and Tips appeared first on Droids On Roids.

https://www.thedroidsonroids.com/blog/how-to-develop-a-gps-navigation-app-like-waze/feed 0
Pros and Cons of Using Third-Party Software in Your App Development https://www.thedroidsonroids.com/blog/third-party-software-pros-and-cons https://www.thedroidsonroids.com/blog/third-party-software-pros-and-cons#disqus_thread Wed, 23 Dec 2020 15:39:30 +0000 https://www.thedroidsonroids.com/?p=34108 Learn when you should to use 3-rd party software in your app development and understand its key advantages & disadvantages.

The post Pros and Cons of Using Third-Party Software in Your App Development appeared first on Droids On Roids.

Building a new application from scratch takes a lot of time and effort. That’s why developers today use so many tools, libraries, and platforms to avoid reinventing the wheel and writing common features from scratch.

Are you wondering whether to use third-party software when building your application? You’re in the right place. Read this article to learn what third-party software is, the pros and cons of using it, and get expert recommendations from our development team with 10 years of experience on the market.

What is third-party software?

In its broadest definition, third-party software refers to reusable software components supplied or developed for a particular purpose by a different company/person from the one that built the existing product on a particular system (source).

Third-party solutions come in various forms. Here’s our breakdown of the most common types of third-party software:

1. Libraries

Libraries come in handy for writing web or mobile applications by delivering source code for a component. They can be open-source (available to everyone at no cost) or closed-source/proprietary (where a purchase may be necessary).


  • SnapKit (iOS) – library for building application layout from code, helping developers to be more productive and achieve more with fewer lines of code,
  • Lottie (Android) – library for designing animations that developers can enrich with interactions, you can find example animations here,
  • Moya – (iOS) library for networking and communication with the backend, very popular among iOS developers looking to save a few days of work.

2. Platforms

Platforms are integrated, ready-made solutions that developers can use to realize a specific feature – for example – user logging, chat, or maps. They’re SaaS (Software as a Service) products to which developers can outsource certain functionalities for a fee (usually monthly), or in some cases for free.


  • Firebase – it delivers ready-made components for logging in, a database for storing application data that can replace an application backend, the option to use deep links, remote configuration of application features (perfect for A/B testing!), a space directly to Facebook.
  • Auth0 – this platform allows developers to rapidly integrate authentication and authorization for web, mobile, and legacy applications so you can focus on your core business.
  • Google Maps Platform – the Google Maps Platform is a set of APIs and SDKs that allows developers to embed Google Maps into mobile apps and web pages, or to retrieve data from Google Maps.

3. Tools

A variety of tools that in many ways make the app development more effective and increase the quality of the final product.


  • SwiftLint – an open-source tool for enforcing Swift style and conventions. Developers can set their coding style rules and enforce them during development. SwiftLint has a command-line tool, Xcode plugin, AppCode, and Atom integration. So, it always fits any development environment. It’ll show us warnings and/or errors if we violate the linting rules (learn more here).
  • Danger – a tool used by many developers to automate common code review chores.  You can use it to codify your team’s norms, leaving humans to think about harder problems. Danger leaves messages inside your Pull Requests based on rules that you create.
  • Zeplin – a tool for UI designers and developers, enabling them to collaborate efficiently and save time. Among others, it allows designers to share the design system with the team, and generate development resources automatically. Everyone in the team can access the latest design resources and gets notified of changes without you having to ping them.

In this article, we focus on the above-mentioned 3-rd party “platforms” mentioned in point 2. Our clients often ask us about the pros and cons of using this type of solution in software development, which is why we decided to share our insights with a broader audience.

Pros of using 3rd-party software in your app development

We believe that using 3rd party software in a reasonable way:

  • improves the efficiency of the app development process,
  • increases the quality of the product,
  • reduces app development costs significantly.

Below you can find the key pros of 3rd-party software.

Pay just for what you need

When using a third-party solution, you pay a monthly fee for the used limit instead of having to pay a high up-front cost for building the feature from scratch. Sometimes you pay the fee after passing a set limit – at the beginning, you might get away with not paying anything for using the solution.

Faster development process

The greatest perk of using third-party software is that developers don’t have to write everything from the ground up. For example, if you’d like to add a login feature to your app, your team can simply use Auth0 and focus more on the features that form the core of your app and its competitive advantage. It makes the app development process much much faster.

Significant cost savings

Using third-party services comes at a much lower cost – both upfront and during the app’s operation over time. Some third-party platforms might be available free of charge until a certain level. Then it’s likely that you’ll be paying a monthly fee for the used resources. As a result, the cost of using a feature is spread over time, and you end up paying monthly fees instead of a high upfront fee.

For example, a solution for instant chats, Pusher, offers 200k messages and 100 concurrent connections free of charge. If you need to support 1 million messages and 500 connections monthly, you pay only $49.99/month. And if your chat grows a lot, you can take advantage of larger plans. Building the same chat from scratch would cost at least $50k – you could get 1000 months on Pusher’s smaller plan for that.

Read also: What’s the average app development cost in 2021?

Faster time-to-market

By accelerating the development speed, you can bring your application to market faster. As a result, you can quickly verify your idea, check whether it solves the problem of your target users, and achieve a product-market fit.

A shorter feedback loop from users

By releasing the product or MVP faster to the market, you can quickly verify the value of your application to users and learn what they think about it. Their feedback will help you to build an even better app.

Potentially greater capabilities

Platforms are examples of mature software that might be too sophisticated for the client’s initial requirements. They help us to build applications that offer greater capabilities than needed, but at the same time, they offer a real value for the application’s future development.

Easy integration for developers

Many platforms available on the market today are equipped with modern SDKs that allow easy and fast integration. For example, it usually takes only 2 days to implement the user authentication feature with Auth0, while building the same from scratch would take several weeks.

Less maintenance effort

Third-party platforms come with another advantage – there’s no need to maintain their code in shape. This is the job of the provider, not the company using the resource. As a result, developers get less code to take care of and maintain, making their job easier.

Using third-party solutions is a smart move in MVP development

All of the benefits we mentioned above – faster time-to-market, accelerated development process, and shorter feedback loop from users – means that third-party solutions are a great match for MVP development.

When a client approaches us with an idea for an app, we usually advise them to start with a simple MVP that brings value to users. Following the agile methodology of software development, our teams focus on the most important elements of the app.

Example scenario:

Imagine an app for car cleaning. The core idea is ordering your car to be cleaned via the application. This is what builds the app’s competitive advantage. Other features don’t make the app stand out, so it makes sense to focus on the core feature when developing an MVP for this app.

This is where third-party solutions come in. For example, we can use Auth0 for logging in and authentication. The platform offers various options for logging in with passwords, phone numbers, two-factor authentication, etc.

The team doesn’t have to write this feature from scratch, helping to bring the MVP faster to get tested in the market. You can use such a solution for free until a certain level and then pay for its usage – but not for its development.

As a result, the cost of building your app is much lower – building such functionality from scratch would drive the project’s costs up by a lot. The more third-party platforms you use, the faster the development team will deliver your MVP.

Now you can see how third-party software slashes the development costs and speeds up the moment of releasing the app to the world. This is a huge product win because you get to verify your idea on the market early on and pivot if necessary.

And once your app gains traction and starts to generate revenue, you can replace the third-part solution with your own code.

Cons of using third-party software in your app development

Less flexibility

Naturally, using third-party solutions comes with some limitations. When we’re not using the default methods supported by the solution provider, we usually need to work hard to adapt the provider’s tool to our needs. Developers can do that, but at some point, it just becomes too expensive.

If you’re looking to build a feature that is really original / custom, finding the right third-party solution might be impossible.

Also, it’s smart to consider the migration costs before jumping on the third-party bandwagon. For example, it’s common to use third-party software for authentication during MVP development. But then it might turn out that the flow of logging in needs to be changed because of the market specificity and user needs. For instance, we might need to add a new field where the user states their height and limit that value to 2 meters.

This is when you move to custom code and solution. The cost of this migration is different in each case. That’s why analyzing this cost at the project’s outset is a smart move.

Vendor lock-in

When using a third-party solution, you’re inevitably dependent on the provider. This poses a risk to the stability of your software. That’s why it’s a common practice to write core application features from scratch and use third-party solutions only for its non-core elements.

Risk of rising costs

Being dependent on the provider also means that the application’s costs might go up when the provider changes the pricing. It sometimes happens that the costs of third-party solutions grow drastically at a certain scale.

How to minimize this risk? Avoid building core application features with third-party solutions. While this risk isn’t that important in MVP development where you’re looking to verify the idea when scaling the app, consider whether this risk is acceptable to you.

What’s more, at some stage of application growth with a rapidly growing scale, the costs of using a given 3rd-party platform may increase drastically. It may turn out that because of scaling up, a particular solution is no longer cost-effective for you.

Example of 3rd-party platforms pricing


Auth0 pricing

Auth0 pricing – to see more, go here


When to replace third-party solutions in your project?

When paying for it doesn’t make sense anymore

As your application grows, its scale might make using third-party solutions just too expensive. When the costs of using the platform get really high, you can save up a lot by building your own solution from scratch.

When you need more customization and flexibility

Another scenario where ditching a third-party solution makes sense is when we need more flexibility, and the solution just doesn’t allow it. It’s important to take a good look at your features from the business perspective and decide how important they are. If your competitors offer a functionality that is similar, it might be a good opportunity to gain a competitive advantage by building a unique feature from scratch and differentiate your app from your competitors.

Our recommendations for using third-party software

Have a plan b

It’s worth asking yourself: what happens when we’re forced to stop using a third-party solution for some reason? It’s good to have a plan b – a migration strategy where you list all alternatives to your solution. The strategy should also point out how your own solution would be implemented and estimate the cost of migration both between different providers and between a provider and your custom solution.

Consider the feature at hand

When deciding whether to use a third-party solution or write up functionality on your own, ask yourself these questions:

  • Is it a core or non-core feature?
  • How important is this feature for my application?
  • If it’s a non-core feature, how often will it be used?

Your answers will indicate whether third-party software is a safe bet.

Decide whether you’re building something specific or generic

If you’re looking to build a generic functionality, it’s worth it to use third-party software. But if what you need is something specific – something that a third-party solution might not deliver – just don’t use it.

Note that some platforms allow adding custom components. So, if a third-party platform doesn’t include everything, check whether adding a feature could be an option.

Carry out a pricing analysis and licensing terms

Developers tend to consider the SDK and integrations, but you also need to assess third-party software from the cost perspective. Carry out a pricing analysis to understand which platforms match your budget best.

Also, analyze the licensing terms – especially regarding the scale. Consider what would happen in case of the dynamic growth of your user base. For example, if you have an e-commerce store, the number of shoppers in your mobile application might get just as high as in your e-store.

Analyze project threats

When deciding on a third-party solution, check what level of security it offers, what its data management policy is, and whether it complies with regulations such as GDPR. The platforms we use in our development projects are well-known and recognized on the market as reliable providers, so we can be certain of their security.

Read also: What is Mobile (and Web) Application Security? | Introduction for App Owners

If you’re looking for product-market fit, third-party software is a good pick

The primary benefit of using third-party software is that it speeds up the development process and makes it cheaper. If you’re still looking for a product-market fit and want to check how your idea performs on the market, you probably don’t want to spend a lot of money on experimenting with your app. Third-party software helps to keep costs at bay and deliver something you can test fast.

Consider changes and don’t get attached too much

Even if you used a third-party solution for your MVP or product, it doesn’t mean that you need to stick to it at all costs. Changes are normal in software development. Your application is bound to change due to the changes in the market, among your customers, or in your business. And so will its technical requirements. Migrating a feature to code written by your development team is a common scenario, so there’s no need to be afraid of third-party software.

Examples of third-party platforms we use in our projects


This platform allows developers to rapidly integrate authentication and authorization for web, mobile, and legacy applications so you can focus on your core business. The integration of Auth0 on the backend takes about 2 days of development. And the implementation of such a feature on your own would take 3-4 weeks, so that’s a lot of time and money savings. What’s more, thanks to Auth0, you avoid the risk that comes with creating your own solution to authenticate and authorize users.


A great payments solution that comes with outstanding API and SDK. Developers love working with it.  It allows your app to accept payments, send payouts, and more.


This real-time, bidirectional, and event-based communication helps us build features like instant chat messaging. It works on every platform, browser, or device, offering great reliability and speed.


A serverless platform for voice, video, and messaging APIs trusted by thousands of developers around the world to innovate and scale real-time communications.


This is a paid Mailchimp add-on designed to help applications or websites that need to send a transactional email like password resets, order confirmations, and welcome messages.


It’s Google’s mobile platform that helps you quickly develop high-quality apps. It delivers ready-made components for logging in, a database for storing application data that can replace an application backend, the option to use deep links, remote configuration of application features (perfect for A/B testing!), a space for hosting files like photos, and access to lots of helpful analytics.

AWS (Amazon Web Services)

A secured cloud service platform providing computing power, database hosting, content delivery services, and many other products. In our opinion, it’s a great choice for hosting the entire server infrastructure in the cloud.


Google’s platform for building Augmented Reality in mobile applications. ARCore uses three key capabilities to integrate virtual content with the real world as seen through your phone’s camera: motion tracking, environmental understanding, and lighting estimation. Read more here.

Firebase ML

Part of Firebase, but this solution deserves a separate point. Firebase ML delivers machine learning based on artificial intelligence and can be used, for example, to recognize text, images, etc. Basically, anything where ML can be used.

Firebase Crashlytics (formerly Crashlytics)

It is a lightweight, real-time crash reporter that helps you track, prioritize, and fix stability issues that erode your app quality (source).


A great source of custom online maps for websites and applications. It allows teams to build better mapping, navigation, and search experiences across platforms.

Wrap up

We hope that this article helps you understand the advantages of using third-party solutions and the role they play in modern software development.

If you have any questions on how our teams use third-party software in building applications – especially in MVP development – feel free to drop us a line.

Our experts have many years of experience in building applications with the help of third-party solutions to achieve an optimal balance between cost, speed, and functionality.

The post Pros and Cons of Using Third-Party Software in Your App Development appeared first on Droids On Roids.

https://www.thedroidsonroids.com/blog/third-party-software-pros-and-cons/feed 0
Pros and Cons of React Native Development in 2021 | Business Perspective https://www.thedroidsonroids.com/blog/react-native-pros-and-cons https://www.thedroidsonroids.com/blog/react-native-pros-and-cons#disqus_thread Wed, 23 Dec 2020 09:45:55 +0000 https://www.thedroidsonroids.com/?p=34077 Learn the key advantages and disadvantages of React Native and consider when to use React Native.

The post Pros and Cons of React Native Development in 2021 | Business Perspective appeared first on Droids On Roids.

This article presents the biggest advantages and disadvantages of React Native. It’s worth to consider them when deciding whether to develop a mobile application with React Native. In what follows, I will present examples of application types for which React Native will work best.

What is React Native?

Facebook engineers created React Native in 2015. It allows you to accelerate the process of creating mobile applications and reduce the costs of their production. It’s a framework that helps to create cross-platform applications for Android and iOS platforms.

By writing one code in Javascript (according to the StackOverflow survey, currently the most popular programming language), we can create a native application for Android and iOS systems. After building the application, we get the same file as if we have used the native language of the platform. For more details on React Native, please refer to this article: What is React Native? Introduction for App Owners.

Now we can move on to the pros and cons of React Native.

Pros of React Native

What are the benefits of using React Native? The decision to create a mobile application using the React Native cross-platform framework comes with a number of advantages. Below I present the most interesting pros of using React Native (in my opinion).

It speeds up the app development process

The main advantage of React Native is the ability to create applications for two platforms using one code. So while working on a given function/update, we create them immediately for each mobile platform. For a product released on both platforms, this can save you time and money by up to 30%.

It’s worth mentioning that thanks to the community support and React Native’s extensibility, the list of supported platforms is growing. You just need to install additional libraries.

Lower cost of app development

The common source code allows you to build the app with one development team familiar with Javascript. This significantly contributes to the reduction of app development cost. Contrary to native development, you can involve a smaller number of people in the project. It’s because there is no need to “duplicate” teams per platform.

Having one team and one programming language also allows eliminating problems when something disturbs the development between platforms. E.g. due to difficulties in implementation on a given platform or random factors such as a programmer’s sick leave in one team).

This, in turn, leads to a situation where the application for one platform is ready, while the other one requires additional work. Typically, it’s impossible for developers to switch between platforms when native languages ​​are used. In the case of React Native app development, there are no such situations – so there’s no downtime, and you can plan the team’s work optimally.

It ensures stable growth of the app

One of React Native’s pros is that RN shares its set of components that “know” how to display the app on a given platform. Thanks to this abstraction, React Native allows the developer to focus on developing the application without going into the details of the platform. So given that, the process of building app features is more stable and resistant to discrepancies between platforms than in separate native teams. This allows for better planning of application releases with new features/upgrades.

It has a rich ecosystem

Thanks to the fact that React Native is based on Javascript, it has access to a wide range of libraries and tools that facilitate developers’ work and accelerate the software development process.

At the time of writing this article, the library repository for Javascript npm returns 29,352 results after typing the phrase “react-native,” while the corresponding package search engine for Flutter returns only 12,900 results for libraries supporting this framework. This means that the choice of 3rd party libraries for Flutter is 44% smaller than React Native.

It’s worth mentioning that we compare the search for libraries strictly for cross-platform programming, excluding those that are universal enough that they can be used for both mobile and web projects. Of course, the number of available libraries doesn’t always translate into their quality. However, it shows the community’s commitment to developing tools for the React Native framework.

Another aspect of increasing access to libraries and tools is basing React Native on how ReactJS works. ReactJS is one of the most popular web development frameworks. Thanks to a common mechanism, many libraries for ReactJs also work for React Native.

It can integrate with the native application

React Native has mechanisms that allow it to integrate with an already existing native application. For this reason, you can find both views that are written natively, as well as views written with React Native in a mobile application. This offers many possibilities.

Developers can write some views with React Native in order to lower their costs (e.g., account management, purchase summary, etc.). And the rest – which the framework can’t handle – remain native.

If you want to transfer your application to a cross-platform solution, your existing application can be rewritten in small steps. This approach reduces the chance of errors and allows for a faster release of the new application.

It’s supported by external tools

The application development process isn’t only writing code but also repetitive routine tasks. For example building (compiling a new version of the application), testing the application using automated tests, releasing the application to the store, as well as investigating and fixing bugs.

Such repetitive tasks are usually delegated to external tools or services (3rd party software), which, once configured, perform them for developers who can instead focus on adding new functionalities. This approach also eliminates human error in repetitive activities.

The most popular tools supporting the process of developing mobile applications that also support React Native are, for example:

  • Bitrise – a platform supporting the process of automatic testing, building, and releasing a new version of the application.
  • CircleCI – as above.
  • Code Magic – as above.
  • AppCenter – a platform that comprehensively supports the development process – allows you to test, build, and release a new application. It also helps to share application versions with the test group. Additionally, it supports bug reporting (collecting information about the cause of an error in the application) to provide developers with the necessary information for fixing it.
  • Sentry – a platform dedicated to collecting and displaying bug reports that provide the necessary information for its repair.
  • Bugsnag – a platform that collects and displays bug reports in order to provide the necessary information for its repair.
  • Amplify – a framework allowing for easier integration with AWS services, incl. authentication, data retrieval from API, saving/reading files, and notification service.

Cons of React Native

What challenges do developers and app owners face with React Native? The use of React Native, in addition to its undoubted benefits, also comes with several disadvantages and challenges. You should take them into account when choosing this technology for your application. Let’s dive into the disadvantages of React Native.

It’s not a native solution

As I mentioned before, React Native is a cross-platform technology based on JavaScript. To make this possible, the authors of the framework had to create communication mechanisms between the native world and Javascript (you can read more about it here). For this reason, an application written in React Native might be slower compared to native applications and take up more space than its native counterpart.

It’s worth noting that the performance problem can only arise in applications with high dynamism, in which there are continuous/large changes on the screen, such as, for example, action games. Facebook engineers have made every effort to ensure that applications written in React Native render at 60 frames per second (in accordance with the applicable standard), providing the user with a native experience.

Hard to debug

React Native is built using Javascript, Objective-C, Java, and C / C ++. This makes debugging bugs more difficult. It may require basic knowledge of the native language of the platform – React Native constantly communicates between the native environment and the thread in which the Javascript code is executed.

To facilitate the debugging process, the React Native community and developers have enabled integration with Flipper since version 0.62. It provides many useful tools in the debugging process – bug report, log preview, local database, and performance inspector. Since version 0.63, they have introduced a refreshed error and warning display module.

It doesn’t speed up the testing process

While the working time of development teams decreases, the same cannot be said about the work of the Quality Assurance team. The time spent on testing is similar to testing in native development. And in some cases, it might be even more. This is another factor to consider when choosing React Native for your app development.

Testing is more challenging

One of React Native’s cons is that the use of cross-platform technology introduces two new potential error groups.

The first is related to how the application communicates with native components and bad code that causes errors on each platform. React Native translates JavaScript components into their native equivalents and provides the ability to freely communicate between them (e.g., a native button notifies the JavaScript code that the user has pressed it so that it can react correctly – read more here). For this reason, you should test a React Native app much more thoroughly. There may be bugs and edge cases in the components provided by the framework.

At the same time, it’s worth emphasizing that React Native is a mature framework. It is actively used by many Facebook products, as well as many other companies and a large community. Thanks to this we can be sure that React Native is error-free.

The second group of errors that occur only in cross-platform solutions is related to the common source code. If there’s an error there, you can be sure that it will occur on every platform. For this reason, when finding an error, the tester should check whether that error occurs on both platforms.

In the case of native development, such propagation of errors between platforms doesn’t occur. It’s worth noting, however, that in this situation, it’s enough to fix the bug once. Thanks to the shared source code, the bug will be fixed on each supported platform.

Inferior Android support

Initially, React Native only supported the iOS platform. The support for the Android platform was added only in subsequent releases. For this reason, React Native still has weaker support for the Android platform. This was addressed by the Facebook framework development team, and there’s ongoing work that aims to fix this. However, these are not problems that prevent the development of Android applications with React Native. They require more accuracy and testing of this platform.

The second disadvantage of React Native in the context of Android is its performance on this platform. This is one of the reasons why the Discord team decided to develop its Android application with native technology. Nevertheless, in this case, they managed to share 94% of the code – not between mobile applications, but between iOS and web applications (you can read more about the Discord application development use case here).

It’s harder to build a cross-platform team

React Native is a cross-platform technology. The team should also have knowledge of both the world of web technologies (React, JavaScript, and its ecosystem) and native technologies (project configuration, CI, UX guidelines for the platform). It’s much more difficult to build a team able to cope with all the challenges that may arise in the development of a cross-platform application.

Read also: 5 key legal issues to consider before your mobile app development

When to choose React Native?

The framework works well for an application that needs to be developed for both Android and iOS and is based on a custom design. The ability to work on both platforms in parallel shortens the development time. What’s more, the custom design allows for easier and faster styling of views on both platforms. For this reason, this technology is a good candidate for applications where time-to-market is important (Idea review/MVP version). It’s also a great solution if you want to reduce production costs.

The React Native benefits will also come in handy to applications that main goal is to “provide a graphical interface” for communication with API, such as applications for purchases or reporting improvements in the factory. Applications of this type mainly come down to downloading data, displaying it to the user, and sending the user’s changes to the server. In this case, we will get the largest amount of common code, which everyone associates with a faster development process and lower costs.

When developing native applications, it’s worth considering using React Native to create individual views or groups of views, thus lowering the cost of their creation (many companies such as Pinaster or Facebook did that) without losing their quality.

If you have a web application (and in particular one written with ReactJS) that has the same functionalities as the target mobile application, you should consider using React Native. Thanks to the common language and ecosystem, it’s easy to use the code of a web app in an application written with React Native.

React Native is a great choice for those project which do NOT require creating complex animations and strong integration with native technologies such as geolocation or Bluetooth module. Using RN in such cases is not impossible, of course, but would require a lot of additional work.

Alternatives to React Native

React Native is not the only technology out there that allows you to create cross-platform applications.


Google’s Flutter framework is currently the most popular alternative to React Native. Flutter has a different rendering approach that allows developers to render components very quickly. An additional advantage of Flutter is the support for Android (Material UI) and iOS (Cupertino) out-of-the-box design. Google engineers wrote their framework in Dart language which is less popular than JavaScript. It means that it has a smaller number of available libraries and a smaller community than React Native. Howece, it’s dynamically developing.

Read also:


The oldest of the mentioned frameworks, Xamarin is strongly associated with Microsoft’s technology based on the C# language and the .NET framework. As we can read on its website, Xamarin allows you to share up to 75% of the source code. It supports platforms such as Android, iOS, tvOS, watchOS, macOS, and, of course, Windows.

Xamarin has built-in components that allow creating a design compatible with a given platform. The disadvantage of this technology is a smaller community and a smaller number of available libraries. What’s more, one of its cons is the high cost of the Visual Studio – the IDE license that you need to create applications in this framework. A more detailed analysis of the advantages and disadvantages of this solution can be found on this blog.

Hybrid app

Hybrid applications allow you to create a mobile application using any web technologies with any framework and then use the Apache Cordova framework to create a mobile application.

The advantage of this solution is the possibility of using an existing web application and a common code for each platform. The downside is efficiency and the fact that you need to work more on the app to ensure its native feel. For more details, please refer to this article

Native development

The last alternative worth mentioning is, of course, the use of native technologies to write the application. This is the most expensive way to execute an application (two teams required) where teams duplicate their code.

The biggest advantage of this approach is application performance. Other benefit is the easiest use of native components such as GPS or Bluetooth, and the native feeling of the application.

Wrap up

The biggest advantage of cross-platform solutions is the simultaneous production of code for both mobile platforms. It saves time and money.

React Native stands out from the alternatives. Why? Because it’s based on the JavaScript programming language, which has a large and engaged community. Currently, the availability of JavaScript developers on the market is much greater than in the case of, for example, Dart (Flutter is based on it). An additional advantage is the fact that React Native is based on ReactJS. Thanks to this, having a web team of ReactJS developers, it is easy to implement it in the development of mobile applications.

React Native limitations

React Native isn’t a technology without flaws and limitations. The downside of React Native is the poor performance when displaying views in which there is a constant change of elements caused by, for example, a large number of animations.

Due to the fact that it’s mainly developed by the Facebook team to meet their needs, some features aren’t available out of the box or have poor support – e.g., tracking the user’s location while the application is running in the background. For this reason, it’s worth researching first whether the application you want to build will use tools poorly supported by React Native or one of the 3rd party solutions from the community.

Even if our application uses a module that doesn’t have React Native support, there’s still no reason to cross this technology out. Thanks to the possibility of integration with native solutions, we can write a native module for a missing or poorly supported function per each platform, and then integrate it with the JavaScript code.

Mature solution

React Native is a mature, 5-year-old solution. Facebook team and a passionate community actively support and develop this technology. Over the years, both small and large companies have been using it in many commercial applications. The key to the success of creating a good application written in React Native is hiring a good team experienced in both React Native, ReactJs, and JavaScript, as well as having the support of native developers.

The above-mentioned advantages and disadvantages of React Native are worth considering before kicking off with React Native. We’re an experienced React Native app development company that would love to take the whole app development off your shoulders. If you have any questions, leave a comment below, jump on a call, or drop us a line.

The post Pros and Cons of React Native Development in 2021 | Business Perspective appeared first on Droids On Roids.

https://www.thedroidsonroids.com/blog/react-native-pros-and-cons/feed 0
Internationalizing and Localizing a Flutter App | How to Develop an App with Flutter – Part 7 https://www.thedroidsonroids.com/blog/development/flutter-app-localization-and-internationalization https://www.thedroidsonroids.com/blog/development/flutter-app-localization-and-internationalization#disqus_thread Wed, 16 Dec 2020 16:22:07 +0000 https://www.thedroidsonroids.com/?p=32840 Learn how to develop your first app with Flutter. This time, we will make our app multilingual.

The post Internationalizing and Localizing a Flutter App | How to Develop an App with Flutter – Part 7 appeared first on Droids On Roids.

Are you interested in internationalizing and localizing your Flutter app? If yes, you’re in the right place. In this article, we will make our Smoge app multilingual. More precisely, we will explain how to easily localize and internationalize your Flutter app, making it accessible to users in different locales.

Want to build an app with Flutter? Follow our series “Flutter app development tutorial for beginners”. We’ve published the following posts so far:

  1. Introduction to your first Flutter app development 
  2. Flutter Project Setup
  3. Creating a Home Screen
  4. Styling the Home Screen
  5. Networking and connecting to API
  6. Refining Widgets’ Layer with Provider
  7. Internationalizing and Localizing your Flutter App – you are reading this

What’s more, we’ve also prepared a Roadmap that can be useful in your Flutter development journey:

This article consists of the following sections:

Let’s define a few important words.

What does internationalizing and localizing a Flutter app mean?

  • Internationalization (aka i18n) is a necessary setup and process for app localization. It is mostly done by developers.
  • Localization (aka l10n) means adding support of multiple locales to the application. This work is mostly done by translators (which may not necessarily be developers).
  • Locale (no fancy abbreviation like l4e 😉 ) is a descriptor of a specific region (political, cultural, or geographical). In Flutter (more precisely in Dart) it consists of 3 ingredients:
    • language (mandatory), eg. English, Polish or Serbian.
    • region (optional; in API it is called country code), eg. Australia, USA, or Hong Kong.
    • script (optional), eg. Latin or Cyrillic.

Numbers in fancy abbreviations represent the number of omitted letters. Apart from i18n and l10n, you may also encounter a11y (accessibility) in related contexts.

Localization mechanism – Flutter vs native platforms

Flutter does not have its own localization mechanism similar to native platforms (iOS, Android). In short: in native projects, you can just define the key-value pairs for each supported locale, where key acts as a unique identifier (like settingsScreenName) used later in a source code and value is an actual translation (eg. Settings for English or Rendszer for Hungarian). Read more in the official documentation for Android and iOS respectively.

On the other hand, Flutter does not have such mechanisms available out of the box. Flutter CLI supports Dart’s intl package which can help in app localization. However, it is not so easy to use as built-in support on native platforms.

Flutter app internationalization

The most important requirement is to separate potentially translatable texts from the source code. In other words: translatable texts must not be hardcoded, so instead of code like this:
Text('Measuring points')
You have to use something like this:

The exact form depends on the chosen internationalization technique. This one is from intl_utils (which will be described in the next paragraphs).

Many internationalization frameworks for Flutter including the built-in intl package use the ARB (Application Resource Bundle) file format based on JSON. More information about ARB can be found in the specification.

It is important to follow this approach since the beginning of the project. The later massive transformation of hardcoded text into translatable resources is almost always more error-prone and time-consuming. Sometimes, further changes require even code refactor. This may happen especially if texts contain placeholders and/or plurals.

In the next few paragraphs, I describe the common aspects related to internationalization. Not everything occurs in every app nor it’s a completely exhaustive list. However, it should cover most of the cases which can be encountered during app development.


Let’s assume that the app displays an English text: Always allow Wi-Fi Roam Scans and it looks very well. So let’s translate it into Polish. Now, the text will be Zawsze szukaj Wi-Fi w roamingu, but it may look bad. Keep in mind that translated text may be shorter or longer than English (or another default language of your app).

All the text fields have to be configured to handle that. Depending on the context, you may need to increase the number of displayed lines or enable various overflow like an ellipsis (three dots at the end). Please note that translation may contain dîąćŗĩţĭċš so it may also grow vertically.


Let’s say that we need a text like Gmail application is running. Where Gmail represents a variable value evaluated somehow by the business logic. One may think that such cases may be easily implemented like this:

Text('$appName ${Strings.of(context).runningLabel}')

So we take a variable, a hardcoded space character, and translatable text referred by key. Well, nothing can be further from the truth!

That text translated to other languages may use a different order of the words, for example in Polish it will be Aplikacja Gmail jest uruchomiona.

So it is important to treat the entire text as one translatable unit with placeholders instead of manual crafting in the code. The mentioned sample text can be expressed like this in ARB format:

  • English: "runningLabel" : "{appName} is running"
  • Polish: "runningLabel" : "Aplikacja {appName} jest uruchomiona"

And it may be used like this:


Let’s consider the following text: 3 songs found, where 3 is a dynamic value evaluated in the app logic. It seems to be analogous to the previous example. However, it isn’t… In the case of a single song, we have 1 song(not songs!) found.

Languages other than English may even have more plural forms eg. in Polish we have: Znaleziono 1 piosenkę, Znaleziono 2 piosenki and Znaleziono 5 piosenek respectively. In some cases (eg. in Arabic) there are even 6 plural forms!

Plural definition in ARB format looks like this:
{num, plural, one{A song found} other{{num} songs found}}

Note that although plural quantity names (like one or other in this example) are standardized, the number ranges they cover depends on the language. For example, in Polish one is used only for 1 while in Croatian it applies to every number ending with 1 except 11. You can find exact quantity mappings in the official Unicode CLDR documentation. Also, note that the number does not necessarily need to be additionally a placeholder (we don’t use num in one quantity).


Similarly to numbers, we can parametrize texts by the argument of any type:
"weather": "{weather, select, sunny{The sun is shining} cloudy{There are clouds} rainy{Take an umbrella} other{No clue what the weather is}}"

The other case must be provided and it acts as a fallback for any undefined case passed from the code. Note that at the time of writing the documentation says that other cases may be omitted and an empty string is returned when there is no mapping found. See this issue for more information.

On the Dart source code side, the argument (weather in this case) is passed as an Object. Note that the cases should be unique. If there are duplicates the result depends on the used tool. The intl_utils for example takes the first one and raises a warning (not an error) so the building process does not fail.


Texts can also be parametrized by gender:
"invitation": "{sex, select, male{He invites you} female{She invites you} other{They invite you}}"

In fact, it is only a special case of the above-mentioned select feature. If (apart from other) there are only male and female cases then the text is treated as gender on the Flutter side (at least when using intl_utils to parse ARB).

Note that there are only 3 genders supported: male, female and other. In Dart source code, gender is passed by string, not by Object like in the aforementioned select feature, and it is the only difference in practice. Due to the fact gender is a select feature, the other case is also effectively mandatory. Even if your app logic supports only 2 genders, you have to provide 3 variants of gendered texts, also you can’t add more.

Let’s go to another aspect of internationalizing and localizing your Flutter app.


In the source code we usually write numbers like this:
However, on the UI they should appear formatted. The exact format depends on the context eg. we may want a compact format, 2, 3, or no decimal places, etc. Moreover, it depends on the locale as different languages use a variety of decimal and thousand separator combinations. What is more, a locale determines the usage of either long or a short scale.

The aforementioned number may be represented for example like this:

  • 12,345,678,901.2 – US English, decimal.
  • ١٢٬٣٤٥٬٦٧٨٬٩٠١٫٢ – Egypt Arabic decimal.
  • 12 345 678 901,2 – Polish, decimal, note that there are non-breaking spaces.
  • 1.2 trillion – US English, compact long.
  • 1,2 billion – Polish, compact long (note that Polish uses long scale).

There are also other kinds of formats like scientific or percent. You can find the complete list in the NumberFormat class documentation.


Similarly to numbers, we can also use NumberFormat class to format currency values. Note that apart from the locale, it also depends on the currency, eg. Japan yen has no decimal digits while the Omani rial has 3 of them.

For example, the value 12,345,670,000 (in millionths of a currency unit as defined in MicroMoney class) may appear as:

  • 12 345,67 Kč – Czech koruna, simple format.
  • ١٢٬٣٤٥٫٦٧ EGP – Egyptian pound using Eastern Arabic numerals, regular format.

Note that (at the time of writing) there are 2 currencies in the world (Mauritanian ouguiya and Malagasy ariary) which units are divided into 5 subunits, not to 100 or 1000 like any other currency having subunits. However, in terms of programming (including Dart/Flutter), usually, only subunits which are powers of 10 are supported, so they are treated like having 100 subunits.

Warning: The floating-point types (like Dart’s double) should not be used for mathematics on currency types! It may lead to subtle errors eg. adding 0.1 (expressed as double) ten times gives 0.999… not 1.0.

The aforementionedMicroMoney class can only be used for number formatting. Flutter standard library does not contain a dedicated decimal or monetary type which can be used for mathematics. If you need to perform such calculations, you can do that on integral subunits (cents or millionths), or use some 3rd party library from the pub.

Dates and times

Similarly to numbers, the date formatting also depends on the locale. Unlike pure numbers, there are more kinds of differences between various data formats. For example, November 23th 2020 may be represented as among the others:

  • 11/23/2020 – US English, yMd format (year Month day).
  • 23.11.2020 – Polish, yMd.
  • 23 listopada – Polish, dd MMMM.
  • 23 November – English, dd MMMM.
  • 23 listopad – Polish, dd LLLL (L stands for a standalone month).
  • 23 November – English, dd LLLL.

Apart from separators and word translations, we have to take into consideration:

  • order in which day month and year is written,
  • whether 12- or 24-hours clock is used,
  • whether a month is written as a name, number, or a Roman numeral.

Some languages (eg. Polish but not English) also make a distinction whether the month is a standalone word or appears near the day.

Find more information about the available date and time formats in the DateFormat class documentation.

Units of measurement

Most of the world uses the metric system (SI) with units like (kilo)meters for length, grams for mass and Celsius degrees for temperature. However, a few countries (USA, Liberia, and Myanmar) use imperial system with units like miles for length, pounds for mass, and Fahrenheit degrees for temperature. Some countries like the United Kingdom may use both of them. It may depend on the context in which one should be used.

Note that unlike aforementioned dates, numbers, and currencies where raw value is always the same (eg. the source of both 1,50 zł and $1.50 is a 1.5) in case of different measurement systems also the value has to be calculated separately eg. 1.5 km is approximately 0.93 mi.

There is no support for units of measurement conversion nor formatting in the standard library but various 3rd party packages are available on pub.dev.

Right To Left (RTL)

This text is written in English using the Latin alphabet. It uses left to right text direction (LTR). However, some alphabets (or more precisely scripts) are written right to left (RTL).

Take a look at the examples:


Arabic (look on the right side):


Note that not only is the text direction different (the first letter – مـ is on the right of the text) but also the layout direction (the entire block of text is on the right of the screen). In general, you should not think about the left and right sides but rather the start and end.

The aforementioned sides are usually used with margins, paddings, alignments, etc. In Flutter standard library, class names supporting RTL use a Directional suffix. For example, we have EdgeInsetsDirectional or BorderRadiusDirectional. For text direction, there is a TextAlign enum which – as the name suggests – determines the text alignment.

Information whether the start is on the physical left or right side, is primarily taken from the BuildContext with the help of Directionality class. In the case of text, apart from its alignment, we can also explicitly set its direction. Text displaying is a complicated topic. We can have eg. Arabic text (written normally right to left) with embedded English proper names (written left to right). Flutter standard library has a Bidi class with a set of methods that can help handle such cases.

Note that although Flutter supports directional properties, it does not mean that they should be blindly used everywhere in the code, even if your app supports RTL locales. For purely decorative elements (excluding those connected to direction like back arrows), you should use visual properties (those without Directional suffix).

Phone numbers

Phone numbers are also formatted differently depending on the country and other factors eg. whether it is dialed domestically or internationally. For example:

  • (541) 754-3010 – domestic USA
  • +1-202-555-0108 – international USA
  • 123 456 789 – domestic Poland

There are some falsehoods programmers believe about phone numbers.
There is no library having capabilities like libphonenumber for native platforms. However, some unofficial ports exist.


Sometimes you may want to localize assets. For example, if the image contains text or currency. There is no built-in mechanism for such use cases in Flutter. However, you can construct asset paths dynamically like this:

Depending on geographical region (not necessarily a country) the laws may be different. For example in the European Union, we have to follow GDPR, while in Brazil there is LGPD, CCPA applies in California (USA), etc. It may impact necessary consents obtained from users and/or displayed legal notices, disclaimers, terms of services, etc.

Some countries may require additional actions, for example when dealing with sensitive or medical data (eg. HIPAA in the USA), gambling or interacting with children (eg. COPPA in the USA). Sometimes, you may need to display different content in different locations because of licensing, copyright, price discrimination, etc. Eventually, you may be even enforced to geo-block some content in the app.


To achieve working locale-dependent APIs, we need to specify which locales do we support and provide the localization delegates with actual implementation. Usually, we don’t need to implement the latter by hand as they can be provided by libraries. In the case of the Smoge app we need to extend the MaterialApp instantiation like this:

        localizationsDelegates: [
        supportedLocales: Strings.delegate.supportedLocales,
        theme: AppThemeDataFactory.prepareThemeData(),
        home: NavigationContainer(),

Note that GlobalMaterialLocalizations are provided by the official Material library. Not to be confused with DefaultMaterialLocalizations which are English-only. Strings class is generated by intl_utils which will be described in the next paragraphs.

Native resources

Some of the properties cannot be changed at the Flutter level and need to be done natively. This includes at least the app name – label shown near the icon on the home screen and in various places like the recent apps screen on Android.

For iOS, the label can be set by adding CFBundleDisplayName property to ios/Runner/Info.plist file. If the app name itself has to be localized, its translations can be added to InfoPlist.strings files for the appropriate locale.

Note that if your app needs privileged access eg. to camera or device location (not to be confused with localization 😉 ), then you also need to provide the messages for each such permission. It can be done analogously to the app title.

Additionally, on iOS it is mandatory to list locales supported by the app (apart from doing the same at Flutter Level). This can be done by the CFBundleLocalizations array in the mentioned Info.plist file.

On Android, the label is set using the label application manifest attribute. In order to localize it use the string resource instead of a hardcoded value.

Moreover, some functionality of the Flutter app may be provided by plugins and implemented separately for Android and iOS. If there is some content that needs to be localized there you have to use some platform-specific technique.

See official documentation for Android and iOS respectively for more details about localizing native resources.

The tools that simplify Flutter app localization

There are many 3rd party tools available that can simplify Flutter app localization. Here are some popular ones at the time of writing this article. If you are reading this months or years after publication then the list may be out of date, new solutions will appear, some may be abandoned and forgotten.

For our Smoge app, we have chosen the latest one – intl_utils. It is simple to use, supports the device’s locale changes (unlike eg. easy_localization – see an issue),  integrates well with Localizely – a web service with GUI for localization, has Flutter pub CLI bindings and dedicated IDE plugins (for both Android Studio and VS Code).



The first step of integrating intl_utils is to enable it in pubspec.yaml:

  enabled: true
  class_name: Strings
    project_id: 39cf3f3a-a154-4d3f-85b5-f57e71774f3e

Note that apart from enabling we also configure 2 more optional settings. We set the generated delegate class name to Strings (without that it is by default called S). We also set a project id on Localizely so we can manage the translations using an online editor. You can find the complete list of options in the official documentation. Note that project ID can be safely committed to the repo and even published.

Additionally, we need to enable Material library translations by adding the following entries to the dependencies section:

intl: 0.16.1
intl_translation: 0.17.10+1
  sdk: flutter

The last step of setup is to configure the static code analysis to exclude generated sources related to the localization. This can be done by adding the following entry to analyzer -> exclude list in analysis_options.yaml:
- 'lib/generated/**'


Translations are located in the lib/l10n directory, in locale-specific ARB files named using intl_<locale>.arb scheme. Where locale is eg. en (English) or es_MX (Spanish, Mexico).

Files contain JSONs like this:

"@@locale": "en",
"airQualityNorm": "norm",
"@airQualityNorm": {
  "description": "Air quality norm percentage label"
"percentage": "{value}%",
"@percentage": {
  "description": "Pollution percentage norm scheme"
}, more keys...

At the beginning, we have a locale specifier (usually matching file name) and then actual translations. Each one can have an associated description which can help translators to find an actual context.

For example, the English word book may be translated into French as either livre (noun) or réserver (verb). Without a context, the translators may not be able to choose the correct translation, or even worse they can infer an incorrect one.

Note that if you provide region-specific translations (like Spanish, Mexico), you should also consider providing a generic region-agnostic file specifying only a language (es – Spanish in this case). Without that, if a user has set the Spanish language, but a country other than Mexico, the resolution mechanism will fall back to the default locale (by default English). It won’t try other Spanish variants as it can happen on Android.

Generating sources

Actual Dart source files can be generated out of ARB using either Flutter CLI (useful on CI) or by IDE plugins.

Another question is whether generated files should be committed to VCS or not. If they aren’t, new developers need to know how to generate them before they first build the project. Otherwise, they will get compilation errors.


Intl_utils also integrates well with Localizely (it’s a company behind it). It provides a spreadsheet-like graphical online translations editor. Usually more convenient than raw JSONs in ARB files. Keep in mind, that professional translators may not be technical.
You need to generate an API token in the Localizely console in order to communicate with its API. That token is saved in your home directory, so there is no need to gitignore it.

There is also an OTA (Over-The-Air) translations update available. However, in the Smoge app, we don’t use it.

Note that Localizely in general is a commercial, paid service. At the time of writing It can be free of charge for open source projects or small closed source ones (up to 250 string keys). See pricing for more details. Disclaimer: we are not affiliated with Localizely.

Internationalizing and localizing a Flutter app – wrap up

Internationalization is not a trivial process. It involves not only texts themselves but also numbers, dates, sometimes images, or even functionalities of the app. There are tools like intl_utils or Localizely which can help. However, it is very important to think about localization from the very beginning. Internationalizing an already done app is much harder and error-prone.

We hope that, whether you want to be a freelancer or work at a Flutter development company, our series will help you to become a Flutter developer and develop your first Flutter app.

The post is written in cooperation with Wrocław Java User Group.

The post Internationalizing and Localizing a Flutter App | How to Develop an App with Flutter – Part 7 appeared first on Droids On Roids.

https://www.thedroidsonroids.com/blog/development/flutter-app-localization-and-internationalization/feed 0
How to Communicate Asynchronously with your Development Team – 8 Tips https://www.thedroidsonroids.com/blog/how-to-communicate-asynchronously-with-your-development-team-tips https://www.thedroidsonroids.com/blog/how-to-communicate-asynchronously-with-your-development-team-tips#disqus_thread Tue, 17 Nov 2020 10:42:29 +0000 https://www.thedroidsonroids.com/?p=32571 8 battle-tested tips on improving asynchronous communication with your offshore app Development Team. 

The post How to Communicate Asynchronously with your Development Team – 8 Tips appeared first on Droids On Roids.

Are you wondering how to communicate asynchronously in an effective way? Welcome to our discussion about asynchronous communication between the App Owner and the Development Team.

In the previous article – Communication with your Remote Dev Team – Introduction for App Owners – we’ve explained what asynchronous communication means, what benefits it brings, and when it’s worth to be asynchronous.

In this post, we will focus on how to make asynchronous communication with your offshore Development Team effective. Below you’ll find advice on different levels of abstractions: mindset-related advice, dos and don’ts, as well as more technical tips. 

8 tips on how to communicate asynchronously in an effective way

1. Tip: Remember remote ≠ asynchronous

We need to carefully differentiate remote from asynchronous. The former means cross-location contact. Asynchronous, the latter, means decoupling the sending and reading of messages.

Remote doesn’t automatically mean asynchronous. If your team is remote, but you constantly require meetings in order to see the progress, this isn’t asynchronous. If you allow your team to show their progress when they feel it is best (eg. record a video with a presentation), and you watch the videos at your most convenient time, this is asynchronous.

In 2020, lots of teams and companies were forced to be remote. But they will only achieve success if they also switch to asynchronous. Learn more basics about asynchronous communication.

2. Tip: Don’t try to mimic the office

You may be used to working in the office; chances are you haven’t worked differently in your career. If you want efficient asynchronous communication, you may need to change your habits. For example, when working in an office, if you want to announce an important message, it’s pretty straightforward to have a meeting, invite everybody and make a speech. In the async world, a message on email or Slack should be enough.

After switching to remote, you may miss your everyday chit-chat in the kitchen with your coworkers. In the asynchronous world, you can still achieve it, only in an asynchronous fashion. Instead of nagging whoever is currently available, you can create a Slack channel titled “random” and encourage people to drop a message whenever they have a little time. Remember, not everyday at 12, but whenever they feel like and if they feel like it.

If you struggle with reorganizing your work in a no-office fashion, there is plenty of great literature on the subject. Remote and Rework from pioneers in the field might be especially helpful.

Remember that some data shows that working remotely is more efficient, even if you wish otherwise.

3. Tip: Don’t expect immediate answers

This is probably the hardest habit to break. In the office, you are used to getting immediate answers – you can call a meeting, or you can go straight to somebody’s desk.

Remember that, in an asynchronous world, you allow other people to acknowledge your messages at a time convenient to them. Expecting immediate answers is a common mistake to avoid when developing a mobile app with a remote team.

Simply put – you allow the team to close Slack. In exchange, you get two things:

  • you can close Slack as well 🙂
  • the other side must respond to messages regularly. At least once a day, but typically it’s several times a day. Only then will asynchronous communication will work. Remember that you should respond regularly as well!

4. Tip: Avoid meetings

Another tip on how to communicate asynchronously with your Development Team is about avoiding meetings. In my experience, that’s another habit that’s hard to break. Working in the office, it’s extremely obvious for some people to communicate by meetings. A new requirement from a client? Let’s refine it in a meeting. Team rotation? Let’s make a meeting. My work is hard? I’ll tell you about it in a daily meeting.

In reality, meetings are often a waste of time and energy, not bringing enough to the table even if some people wish it. Yet half-remote, half-onsite meetings tend to be particularly painful.

This is not to say that you shouldn’t make meetings at all! There are occasions where a meeting is the best medium. However, in my experience, sticking to asynchronous communication is enough in most cases.

Before making a meeting, you should ask yourself about the goal of it. If you can achieve the same goal without making a meeting, that would be a great win in terms of communication. Believe me. If not, well, it happens – but at least try to make your meetings better. In the next article in this series, you’ll find a whole section about better meetings.

Finally and perhaps most importantly, asynchronous communication is usually much cheaper than having a meeting. A meeting 1 hour long for 8 people costs you: 1 hour x 8 = 1 man-day, in exchange giving you often no more than false consensus. Read also: How Much Does it Cost to Develop a Mobile App in 2021?

5. Tip: Overcommunicate

A message that hasn’t been sent, has no chance to be received. In contrast, if you send one message twice, and some receive it twice, there’s not much hurt. A simple conclusion – everybody should send more messages, or at the very least, not hold them back if they hesitate.

Overcommunication can happen on many levels. You can send:

  • more messages
  • more information in a message
  • to more receivers
  • the same information multiple times

Generally, you should encourage your team to communicate more, rather than less. If you are afraid of being “spammed”, then think twice. Maybe you need more communication channels (eg. Slack channels)? Maybe you need some standards on what to send and where? Maybe you need a document (a single source of truth) rather than a stream of Slack messages on some particular subjects?

Pro tip: if you want to increase your overcommunication, send a quick message with a link, whenever you change a single source of truth. It doesn’t have to contain all the information – that is kept in the other place. But people don’t keep track of that place every second, so such information may be extremely useful, even if is kind of redundant:

“Hey, I’ve just changed the requirements files – added a bunch of acceptance criteria to feature X. Please let me know what you think – <link>”

6. Tip: Provide a link

That’s an example of “overcommunicating” that I often find to be very useful, but lacking in frequent use. If you are talking about something on the Internet, provide a link to it immediately. Other people can quickly see what you are talking about, read more details if needed, etc. It’s very simple yet also very handy.

7. Tip: Make everything public

The IT world is complex and every Dev Team is cross-functional by nature. Therefore, its members need much information for their work. If the information is missing, it can mean the whole app development process for a person or even the whole team can be blocked. Because of one little piece of information that somebody forgot to pass!

Regardless of the missing information being blocking or not, it’s always time-consuming or even annoying, if you need to ask somebody for permission. In general, it’s very unpredictable when somebody needs access.

The solution to this problem would be to have everything public to everybody. In my experience, this is rarely the case. Unless your project is in a very top-secret area (such as with the government), you should give your team every piece of information that can possibly help them understand the product – such as the requirements, prototypes, historical discussions, and user feedback.

At the same time, the Dev Team should not hide anything on a technical level – like the code, documentation, or infrastructure, all of which should be public within the team.

Read also: What is Product Discovery in Mobile Application Development?

8. Tip: Communicate directly

In the previous article, we explained what Scrum Team is, and who is who in this team – read about it here. You, as a Product Owner, may be onsite, but it’s likely that the Dev Team and Scrum Master are remote. It’s tempting to treat the SM as some kind of “mother” to the Dev Team and talk to the latter through the former, rather than directly. Please don’t do that. It’s worth to communicate with the whole team directly.

On the other hand, the PO should expect their team to talk to them directly as well.

In other words, you should eliminate middlemen in communication, because they can add noise.

However, remember that in the previous chapter we learned to communicate publicly. This means that you should avoid private messages. Aim for public channels (eg. non-private Slack channels) and as wide an audience as is needed.

How to communicate asynchronously – takeaways

That was the short guide on how to communicate asynchronously with your offshore Development Team. I hope you enjoyed yourself and have tons of ideas. To sum up:

How to Communicate Asynchronously with your Development Team

In the next article, you’ll learn how to improve your communication skills, regardless of whether it’s synchronous or asynchronous. Read also: Outsourcing Software Development – Benefits & Risks for App Owners.

The post How to Communicate Asynchronously with your Development Team – 8 Tips appeared first on Droids On Roids.

https://www.thedroidsonroids.com/blog/how-to-communicate-asynchronously-with-your-development-team-tips/feed 0
What is Mobile (and Web) Application Security? | Introduction for App Owners https://www.thedroidsonroids.com/blog/what-is-mobile-and-web-application-security-introduction-for-app-owners https://www.thedroidsonroids.com/blog/what-is-mobile-and-web-application-security-introduction-for-app-owners#disqus_thread Tue, 10 Nov 2020 14:20:01 +0000 https://www.thedroidsonroids.com/?p=32298 Discover the most common threats related to application security, and learn how to analyze risks and their consequences for your app.

The post What is Mobile (and Web) Application Security? | Introduction for App Owners appeared first on Droids On Roids.

In this article, you will learn what application security is, what the most common threats related to app security are, and how to analyze risks and their consequences for your application.

What is application security, and why is it so difficult to define?

You may be wondering what application security actually means. Everyone believes that mobile/web applications’ security is essential, and you need to take care of it during development – no one would disagree with this statement.

But what does application security mean?

It turns out that it’s hard to find/come up with a helpful definition without identifying the risks and threats against which we want to protect ourselves.

If we don’t define the risks, we can’t accurately define application security.

Security is basically protection against threats. Let’s take cars as an example. If we talk about a safe car, it means that the car will protect us in a possible accident (to some extent). In the context of car safety, the risk is a traffic accident.

So when we talk about security in the context of software development, we need to define the potential threats against which we want to protect ourselves. This enables us to formulate a common view of what we’re talking about.

Definition of application security

We can define application security as the process of finding and fixing security gaps and ensuring adequate protection against possible threats.

This definition doesn’t clarify the matter, but we can deduce one important thing from it: application security is a process, not a one-time action.

To achieve the desired level of security, we must be prepared to create an application security process and make sure that it’s followed throughout the entire life of the application – design, development, and maintenance.

What is missing from this definition? We said that application security is a process, but we haven’t really identified what exactly it concerns and what it provides.

The key issues here are threats and risks against which we want to protect ourselves. If we are unsure or have no idea what the risks are, we won’t be able to correctly assess the level of security we would like to achieve.

Security is a response to potential threats and risks

What’s crucial in terms of security is realizing that we want to eliminate or mitigate potential threats and the risks arising from them. When we start thinking about security, we shouldn’t immediately focus on the methods and techniques that will keep us safe. First, we should analyze the risks and threats against which we want to defend ourselves. We can’t begin properly adjusting the techniques and security methods if we’re not aware of the risks.

The 6 most common application security threats

The most common threats related to the security of mobile and web applications are:

  1. Unauthorized extraction of information – e.g., obtaining private messages in a chat application,
  2. Unauthorized use of application functions – e.g., gaining access to the admin function by an unauthorized user,
  3. Denial of service – an attack aimed at overloading the system so that users are unable to use the application – def: https://en.wikipedia.org/wiki/Denial-of-service_attack,
  4. Unauthorized remote access control (breaking into servers) – gaining access to application servers by unauthorized persons,
  5. Data leakage – obtaining confidential data by unauthorized persons, often through an unauthorized remote access control attack,
  6. Installing malware (malicious software) on user devices – causing application users to download malicious software.

This list isn’t complete. These are just a few of the most common threat examples we may deal within a web or mobile application.

As you can see, app owners face many threats on different levels. In order to accurately assess and design security solutions, we need to carry out an accurate analysis of our application.

Note that the threats may differ depending on the type of application. To sum up:

Common application security threats

Types of applications and related threats

Let’s take a closer look at security threats that await us in different types of applications by industry.

E-commerce/m-commerce application threats

  • Sensitive data leak
  • Denial of service and financial losses

Social application threats

  • Personal data leak
  • Identity theft

FinTech application threats

  • Extorting user money
  • Carrying out unauthorized transactions
  • Financial data leak
  • Failure to meet financial regulations

MedTech & Healthcare application threats

  • Very sensitive and confidential medical data
  • Non-compliance with regulations (e.g., HIPAA in the USA)
  • Denial of service and interruption of access to medical data

Threats of applications requiring personal data

  • Personal data leak
  • Failure to meet regulations, e.g., GDPR

Threats of application prototypes

  • very few risks, the topic of safety may be marginalized

Frontend application threats (no backend)

  • No information exchange
  • Most security risks do not exist

Note that many factors affect the risks we have mentioned so far:

  • the purpose of the application,
  • the data users store,
  • the data we share with them,
  • and the services we provide via the application.

Read also: 5 Key Legal Issues in Mobile App Development you Should Consider

Examples of security vulnerabilities

We have seen many examples of security vulnerabilities leveraged by cybercriminals in the history of app development.

  • Whatsapp – A security vulnerability allowed an Israeli company to install spyware on the devices of human rights activists (source).
  • Under Armor example – 150 million identification data (email, passwords) were leaked and then appeared on the black market (source).

These examples show that even large companies with significant resources are vulnerable to such threats and experience security holes that may be exploited.

The scale is important. Additional security factors

The above examples also show us the extra factors that affect the scale of threats. Different threats await an application used by a million users and a different one an app used on a smaller scale. The consequences are different as well, and so is the pressure to quickly fix the security gap. Security processes also vary between them a lot. The scale of the application is another factor that should be taken into account when analyzing risks and threats in the context of security.

Another important factor is the target audience. An important aspect in terms of security is how we acquire users – whether the application is public or intended for a limited number of users (e.g., employees of one company). For example, if we create an in-house application, we have more control over who will use it and in what circumstances. We can then introduce other security solutions and processes.

What to do before starting development to take care of app security?

Here are a few things you can do before the development starts to boost the security of your application:

  • precisely define the industry in which your application will function,
  • find out if there are regulations in a given industry that must be met (e.g., HIPAA, GDPR, PSD2),
  • define the main users of the application (who will use the application),
  • identify the data that will be available in the application (personal data, medical data, messages, payments, etc.),
  • carry out a short analysis of the possible threats and consequences of security gaps in line with the answers to the previous questions.

The above is a good start to start the application security process.

How and when to conduct an analysis of threats, risks, and possible consequences?

We should raise the issue of security at the very beginning of the application development process. Everyone on the development team, stakeholders, and founders or owners should be aware of the risks.

The key to safety is an individual analysis of threats, risks, and possible consequences. We should carry it out at the stage of collecting requirements.

The level of security should be adapted to the performed analysis.

The analysis doesn’t always have to be a long process that generates extensive documentation. On the contrary, it’s better to start with something simpler.

1. Investigate the risks

When analyzing the risks, it’s smart to consider the possible consequences of negligence. Of course, the implications will be different from application to application. But answer these questions, and you’ll get an idea:

  • What happens if user data is leaked?
  • What data do we store?
  • What happens when the application stops working? (denial of service attacks)
  • What happens if app data is leaked?
  • Do we store payment data?
  • What happens when an attacker gets unauthorized access to some functions of the application?
  • Does the application industry force it to comply with any regulations (HIPAA, GDPR)?

Knowing the answers to these questions increases the awareness of the entire team about the risks that may occur. Taking your answers into account, the development team and you get to design security processes and solutions more accurately.

2. Define the data stored in the application and the data that is exchanged (between users, and the user and the system).

3. For each main functionality of the application, answer the following questions

  • What happens if a feature stops working for some time?
  • How long can a given functionality not work?

Let’s sum up:

How to conduct analysis of app security threats and risks?

How to take care of security during the app development process?

You should also pay attention to security practices during the app development itself. It’s worth making a conscious decision about who will have access to communication channels, development tools, application servers, and various third parties.

Here are a few questions that will help verify whether we care about the right level of security during development:

  • Is the Principle of least privilege applied?
  • Do we avoid exchanging passwords in e-mails, private messages?
  • Do we require appropriate security rules on the websites (2FA, strong passwords, etc.)?
  • Do we use safe, proven tools?

Application security – summary and takeaways

I hope that after reading the article, the topic of app security is clearer to you. Here are the key takeaways:

  • Ensuring application security is a process, not a one-time action.
  • You should consider security from the very beginning of work on the application.
  • To ensure security effectively, you need to be aware of security risks.
  • It’s very important to analyze the application and threats for your specific application.
  • It’s key that you analyze the risks, threats, and possible consequences of threats (damage control).

In the next article in our series on mobile and web app security, you will learn about best practices and tools that help to ensure the security of your application and see how to test if the application is safe.

The post What is Mobile (and Web) Application Security? | Introduction for App Owners appeared first on Droids On Roids.

https://www.thedroidsonroids.com/blog/what-is-mobile-and-web-application-security-introduction-for-app-owners/feed 0
Publishing on App Stores – 6th Stage of the Mobile App Development Process https://www.thedroidsonroids.com/blog/guide-on-how-to-publish-your-app-on-the-app-stores https://www.thedroidsonroids.com/blog/guide-on-how-to-publish-your-app-on-the-app-stores#disqus_thread Mon, 09 Nov 2020 07:42:40 +0000 https://www.thedroidsonroids.com/?p=32157 Learn how to prepare for publishing your mobile app.

The post Publishing on App Stores – 6th Stage of the Mobile App Development Process appeared first on Droids On Roids.

Once you have your app developed, it’s time to make it available to users. How can you submit a mobile app to the app stores? If you want to learn how to publish your app on both the App Store and Google Play, you’re in the right place. In this article, you will get to know some of the problems of mobile app publishing and the requirements imposed on app owners by app stores.

Where does app publishing fall in the app development process?

Let’s briefly recall the stages of the mobile app development process:

  1. Choosing a partner – select a company to design and develop your app
    Research, analysis, and selecting a company to cooperate on your product with. Signing an Independent Contractor Agreement. Read more about this stage.
  2. Product Discovery – define what you want to create, for who and why
    Clarifying your app’s vision, defining your product’s goals & its final users. Deciding which features are the most crucial in creating your MVP. Useful tools: Product Canvas, Personas, Event Storming, Prioritization Chart. Read more about this stage.
  3. UX / UI app design – determine how your app will work and look
    Creating a User Journey Map, clickable wireframes, visual user interfaces, and motion design (animations & screen transitions). Read more about this stage.
  4. Project kick-off & setup – last preparations before the start of app development
    PO gets to know the development team and vice versa. Defining every role in the team, agreeing on rules, and the next steps, as well as configuring tools. Read more about this stage.
  5. App development with Quality Assurance
    App production with Continuous Integration: plan, code, build, test (and repeat). Ensuring Quality Assurance at every stage of app development with manual and automated tests. Read more about app development with QA and Scrum framework useful in app development.
  6. Preparation and publishing of the app on Google Play and Apple Store (you’re reading this)
    Releasing includes uploading assets required by laws, as well as promotional materials, beta testing, optimizing the product page/store presence, and everything else your app approval needs to go as smoothly as possible. You are reading the article about this stage.
  7. Post-development phase – app maintenance & further development
    Detecting crashes, monitoring the app’s statistics, product enhancement, and further development. Your app stays attractive, and adapts to changing market conditions and user feedback.

So, as you can see, publishing the app obviously comes after the app development stage. But how should you decide if your product is ready for publication?

It’s generally best to gain user feedback as soon as possible. That’s why we suggest aiming for the MVP version of the application and releasing it to the market. As soon as the required minimal product scope is implemented and thoroughly tested, you should consider immediately releasing the first version of the app.

Releasing the MVP allows you to quickly acknowledge user experience before the app is used by a broader audience. This approach allows you to identify potential upcoming issues and immediately act accordingly. Read also:

What does app publishing mean?

Your mobile app should be available in exactly the places where the largest potential audience resides. Currently, these places for Android and iOS are, respectively, Google Play and Apple’s App Store.

Along with the development team, over the past few months, you might have created the best app in the world for a given sector. However, this app’s whole potential, gorgeous user experience, and state-of-the-art functionality can all be wasted if no significant user base is even remotely aware of its existence.

The application publishing process serves to make your app available to millions of potential users.

Nowadays, there are thousands of apps released in the app stores every day. Because of this, you have to stand out from the crowd. A successful app showcase requires a bit of a knack for marketing and presentation. Fortunately, an experienced partner will surely guide you through the whole process. Publishing an app is, after all, a vital part of the app development lifecycle.

Your app development partner should assist you in uploading your Android app to Google Play, and your iOS app to the App Store. There are also a few other app stores, like Huawei’s App Gallery. Nonetheless, there are still a few obligations that you as the App Owner should be aware of.

In this article, we focus on the publishing process, because it’s paramount to have an eye-catching app presentation page in an app store. The official guide from Google and the guide from Apple are great starting points for this. From these documents, you can find out what  a successful application page comprises of, what the dos and don’ts are, and how to avoid common pitfalls.

How long does it take to publish a mobile app?

Provided that you have all the required promotional materials (showcase graphic assets, descriptions, etc. – see the exact list below in theses sections: How to prepare for publishing your app on Google Play, How to prepare for publishing your app on App Store), the app submition process alone only takes a couple of hours. This is by no means the end of the app review process, however.

The app stores have to check your application for various possible misconducts. Nowadays, there are a lot of people who will try to introduce malicious software to the largest app stores. There are a plethora of ways to hide harmful code in the app. That’s why the app store platforms cannot take anything at face value. Later on in this article, we will also touch upon the popular reasons for app review rejections.

Google and Apple have to be constantly searching for potentially malicious software and have therefore both developed complicated review processes. It’s an inherent part of the publishing process. In Google Play, most of the work related to app verification is levied on automatic systems that rely on machine learning.

Platform operators were forced to harness complicated classification models. If it wasn’t for machine learning, the app review process would go on for weeks, literally. According to some sources like Statista, Google Play is now seeing three times as many new applications as the App Store. This means a border between still being able to process all of the apps manually (as AppStore does) and having to rely on algorithms (like Google).

The sheer amount of published apps Google and Apple are bombarded with is astounding. Every day, the app stores see thousands of newly released apps.

Google Play app reviewing machine learning algorithms, as sophisticated as they may be, often stumble upon ambiguous cases. They check every aspect of the submitted application. If there are any doubts, the app will then get flagged and passed on to be checked by an employee. This is why, in extreme cases, the application review process can last up to a few days. This is dependent on the current workload on the store’s side.

In some cases, the review process takes about a few hours on Google Play, but can last up to a couple of days. App Store reviews have similar reviewing times, but the whole process is a bit more mysterious. We don’t know if any machine learning algorithms check our app (probably yes), but we can be sure that an Apple employee always opens our app and checks it against the App Store Guidelines. Because of this, human errors happen sometimes and developers need to have additional talks with reviewers to find solutions.

What are the costs of publishing an app in stores?

Both Google Play and App Store require a paid development account to upload and update apps to the platform. The publishing license entry threshold is negligible compared to app development costs.

The price of the developer account required for uploading iOS apps to App Store is $99 a year. It’s the same whether you’re signed up as a person or organization. This is the fee for standard apps.

However, if your company wishes to develop proprietary software only for internal company use, that’s when you have to get the Developer Enterprise Program account, which costs $299 annually. You can use Apple’s publishing platform to distribute apps in the company: while are some other solutions, like Microsoft AppCenter, the app still has to be signed with an Apple certificate, so the account is required.

Keep in mind that, regardless of whether or not you have an app in the store, and regardless of whether or not you are profiting from your apps, you will still have to pay this annual fee. However, this payment does not change with how many apps you have in the store at any given time.

On the other hand, Google Play only requires a one-time payment of $25. You are then able to get access to your developer account and publish apps.

How to prepare for publishing your app on Google Play

Before devoting your time to app submission, it’s good practice to have a few things handy already. App stores have a structured way of presenting apps. That’s why it’s possible to know what’s needed for an app launch beforehand. Google has created a guide describing every part of the app upload process in detail. Here’s a list of all of the prerequisites:

  • App name. The name that will be shown to users in Google Play.
  • App package name. The app package name has to be unique across the entire Google Play. Moreover, it cannot be changed in the future. Every Android app has a unique application ID that looks like a reverted www address, such as com.example.myapp. This ID uniquely identifies your app on the device and in Google Play. If you want to upload a new version of your app, the application ID (and the certificate you sign it with) must be the same as the original APK*— if you change the application ID, Google Play treats the APK as a completely different app.
    *An Android Package Kit (APK for short) is the package file format used by the Android operating system for the distribution and installation of mobile apps. Just like Windows (PC) systems use an .exe file for installing software, the APK does the same for Android.
  • Short App description. This is a brief description of the app’s functionality. It’s an 80-character field that is shown to the user in the listings and can then be expanded to see the full description.
  • Full app description. This is the place to list all of your most important features and short instructions for the users. It’s one of the most important sections on your app’s showcase page. The ideal description is a concise, informative paragraph. This field in Google Play gives you space for an up to 4,000 characters.
  • Graphic assets. This comprises all of the graphic assets for the presentation of your app. It’s the app icon, videos, screenshots, and feature graphic. These assets’ purpose is to showcase all of the most important pieces of functionality. Here, Google describes the required assets in detail.
  • Application type and Categories. Google Play requires you to state your app’s category. Assigning proper categories helps you make sure the app is more easily discoverable for the users. Here it’s described in detail.
  • Content rating. You have to comply with Google content rating policy and truthfully state the correct age rating and what content you are presenting to users. A full guide on assigning a content rating is available here.
  • Contact details to the App Owner
  • Privacy Policy URL. A Privacy Policy is now mandatory if your Google Play app asks for sensitive permissions from users. You have to comply with GDPR and tell users what you need their data for, as well as how will it be stored and processed.
  • Countries and localization. You can choose the countries your app will be available in and also provide localization for all of the uploaded content. More details can be found here.

How to prepare for publishing your app on App Store

Similarly to Google Play, the App Store has a list of things required for an app upload. These things can and should be done before you commit to the app uploading process. Apple has created an official guide describing these parts of the final app presentation page. For a successful launch, you have to have prepared the following list of showcase materials:

  • App name. Choose a distinctive name that is up to 30 characters long.
  • Icon. The app icon is one of the first things an app store user sees. Work with a graphic designer to create an icon that is simple and recognizable.
  • Subtitle. This is a quick, 30 character long app summary which appears underneath your app’s name
  • App Previews. The app previews section presents the main functions of the app. App previews autoplay with muted audio when users view your product page, so make sure the first few seconds of your video are visually compelling.
  • Screenshots. Screenshots highlight the essence of your app. You can feature up to 10 images on your App Store page. Depending on which types of devices your app supports, you have to add screenshots for different screen sizes, such as separate examples for big iPad Pro and iPhone Pro Max devices. If your app supports Dark Mode, consider including at least one screenshot that showcases what the experience looks like for users.
  • Description. The ideal description is a concise, informative paragraph followed by a short list of main features. The first sentence of your description is the most important — this is what users can read without having to tap for more. You can update your app’s description when you submit a new version of your app.
  • Promotional texts. Your app’s promotional text appears at the top of the description and is up to 170 characters long. This section of the app can be used for communicating the latest news concerning your app.
  • Keywords. A list of words that will be used for competing for top places on the app search results list. Keywords are limited to 100 characters in total, with terms separated by commas and no spaces. In addition, keep in mind that promotional text doesn’t affect your app’s search ranking so it should not be used to display keywords.
  • In-App Purchases section. If your app features in-app purchases, users can view and start an in-app purchase from your product page. Each item has its own display name, promotional image, and description. In-app purchase names are limited to 30 characters and descriptions are limited to 45 characters, so be descriptive, accurate, and concise.
  • What’s New section. When you update your app, you can use What’s New to communicate these changes to users. This text appears on your product page and on the Updates tab.
  • App categories. You can assign a primary and a secondary category to your app. The primary category is particularly important for discoverability, as it helps users find your app when browsing or filtering search results, and it determines in which tab your app appears on the App Store.
  • Localization. If your app is available in multiple languages, make sure to localize your app description, keywords, app previews, and screenshots for each of the markets in which you offer your app.

Check out our Step-by-step Guide On How to Submit an App to the App Store.

Publishing your app on Google Play

Now that you have collected all the required information and graphic materials, it’s time to actually submit your app along with all of the marketing content.

This part of the process is normally conducted by your development team.

  • You can decide whether or not you’d like a full rollout of a new version of your application.
  • You can decide which countries the app will be available in.
  • Moreover, you can also set up some alpha and beta testing tracks that allow only selected people to access the app and give their feedback before the app goes live to a broader audience.

Releasing the app first to a small testing group of users allows you to quickly get valuable feedback. It may happen that, with their feedback, you will want to iterate and introduce some minor changes to the app to make the overall user experience better. If you’d like to know more about uploading your application, check this out: How to Publish an App on Google Play Store – Step-by-step Guide for App Owners.

Publishing your app on App Store

Similarly to publishing your app on Google Play, we have created a separate article about the technicalities of uploading an app to the App Store. You can read it here. It describes how to create provisioning profiles required for submitting your app, as well as the general setup, and will walk you through the many forms and fields to complete.

Common reasons for application rejections

There are a few reasons why most of the app review rejections happen. As an app owner, you are surely concerned about the quality of your application. So are Google and Apple, and for this reason they aren’t keen on letting substandard apps slip in. Here’s a list comprising what aspects of the app you should be especially aware of in order to get successfully listed on Google Play and App Store.

  • Crashes, bugs and performance issues. This factor plays a big role and is responsible for a big chunk of app rejections. Both Google and Apple naturally aim to be identified with quality products. Both companies hardly ever turn a blind eye to apps containing explicit bugs or blatant crashes. If the testing process of your app suggests some problems with performance and/or crashes, you’d better get that resolved before submitting for review. Otherwise, your app is almost guaranteed to be rejected.
  • Substandard user interface and user experience. Similarly to the previous point, the user interface and experience is a quality issue. The stores will want to make sure that your app offers clean, refined, and user-friendly interfaces. Make sure your UI meets these requirements by planning your design carefully and following best practices for UI and UX. Please refer to Apple’s UI Dos and Don’ts and Google’s UX Best Practices.
  • Inaccurate screenshots and advertisements. Your app presentation page should accurately communicate your app’s value and functionality. Even the unintentional misleading of users will result in your app being rejected. Please make sure that your showcased movie clips and screenshots accurately reflect the list of currently implemented key app functions.
  • Inappropriate content. If your app contains any form of violence, sexual or mature content, you must mention it in the app’s rating details. It’s best to not sign it off as something of negligible importance, otherwise, your app will surely get flagged for inappropriate content and rejected during a review process.
  • Incomplete app information. In order to successfully get through the app review, you are required to enter all of the detailed information. If certain features of the app require signing in, on both platforms you are expected to provide some sort of demo credentials so that all of the app functionality can be shown to the store employee. In edge cases where significant parts of your app rely on a custom hardware piece, you may have to provide additional details and even a physical device to the reviewers. Please also make sure all of your contact details are up to date.
  • Repeated submission of similar/clone apps. There was a time when Google was especially plagued with massively uploaded clone apps and games. This was an avid attempt from numerous creators to piggyback on their successful predecessors. Both stores are now particularly alert to this matter. Make sure your app cannot be mistaken for any other, either by name or visual similarity.
  • Extensive and shady permission requesting practices. Why would a very simple file browser app need the permissions to manage user’s incoming calls or SMS messages? This is an over-colored example but you get the point. Your app might not have nefarious intentions but, nonetheless, too many permissions can potentially open a way for exploits to take their toll. Both Google and Apple go the extra mile to make sure that an app doesn’t request more permissions than really needed to fulfill the included app functionality demands. You have to have a clear reason for requesting specific parts of the mobile OS functionality. You are also required to make it unambiguous to the user when explaining why you need a specific set of permissions.
  • Placeholder content and broken links. Mistakenly including in the app unfinished functionality that shows any kind of placeholder content is heavily frowned upon by the app stores. It’s deemed inappropriate and unprofessional toward users and is another common mistake made during the app release process. Please make sure to exhaustively test your release candidate build before uploading it to the app stores. On Android, it’s as simple as installing the release build on your device, while iOS developers can use the TestFlight tool.

More details on common causes for App Store rejections can be found on the Apple Developer page.

The common causes for rejection are pretty much the same across both main platforms, so this might also be a good guide for common reasons for app rejections on Google Play. The industry has pretty much a unified definition of what conditions a good quality application meets.

Next steps

Congratulations, you have made your application available to a broad base of millions of users. Now, you can monitor your app performance live. Using numerous tools available in the app stores, you can quickly get hold of user habits and how they find your app. You will be given access to powerful tools like app ratings and written feedback. These built-in tools will enable you to track key metrics like user acquisition, retention and usage patterns.

Moreover, if your development team integrated some analytics tools, you will be able to get detailed user crash reports from the released version of the app. Such a valuable insight will enable you to act accordingly – you can schedule work on some new features or plan work focused on fixing crucial errors. This maintenance process will be described in detail in the next article in our mobile app development process series.

Publishing a mobile app on the app stores – summary

In order for your app to be available in the Google and Apple app stores, it has to comply with their guidelines. Don’t treat these guidelines as a form of restriction, rather a valuable resource for creating a successful app showcase page.

Both the app owners and app stores work for a common cause – to have great, professional products put out to the public. Don’t hesitate to devote as much time as needed to create eye-catching and concise marketing materials. Keep in mind that it’s always better to do your best to comply with all guidelines and requirements stated by app stores. If there are still some parts of the process unclear to you, don’t worry. A competent partner will guide you through the whole process, keeping your attention to common pitfalls and ensuring a successful app launch.

To sum up, in order to upload your app to Google Play and/or App Store, you have to have several things ready:

To upload your app to Google Play and Apple App Store, you need to have several elements ready:

Google Play Apple Store
  • App name
  • App package name
  • Short App description
  • Full app description
  • Graphic assets
  • Application type and Categories
  • Content rating
  • Contact details
  • Privacy Policy URL
  • Countries and localization
  • App name
  • App Icon
  • Subtitle
  • App Previews
  • Screenshots
  • Description
  • Promotional texts
  • Keywords
  • “In-App Purchases” section
  • “What’s New” section
  • App categories
  • Localization

If, by any chance, your app gets rejected during a review process, don’t let it discourage you. It’s not the end of the world and, with a few quick fixes, you will be eligible for resubmitting your app.

Don’t worry if some aspects are not clear at first glance – an experienced partner will guide you through the process of publishing your product painlessly. With their help and expertise, you will know the ins and outs of the app publishing process in no time.

The post Publishing on App Stores – 6th Stage of the Mobile App Development Process appeared first on Droids On Roids.

https://www.thedroidsonroids.com/blog/guide-on-how-to-publish-your-app-on-the-app-stores/feed 0
Get the Best Free Ebook – Guide for Product Owners: Drive your Product to Success https://www.thedroidsonroids.com/blog/free-ebook-product-owners-guide https://www.thedroidsonroids.com/blog/free-ebook-product-owners-guide#disqus_thread Wed, 04 Nov 2020 15:33:02 +0000 https://www.thedroidsonroids.com/?p=31961 The best free Product Owner Guide now available! Check out what's inside and get your copy today.

The post Get the Best Free Ebook – Guide for Product Owners: Drive your Product to Success appeared first on Droids On Roids.

Even the best teams can’t deliver a successful product without proper guidance. Your responsibility as a Product Owner plays a crucial role in the app development process. That’s why we’ve created Free Ebook: Drive Your Product to Success. A Quick and Easy Guide for Product Owners.

At Droids On Roids, we have been working in Scrum since 2014. During this time we have been engaged in various kinds of projects and have built more than 130 products with different Product Owners from all over the globe.

It has been a fantastic journey which allowed us to gain great levels of experience and to reach a practical mastery in our line of work. We are happy to share our perspective on what drives the development teams to build a great product. Check out the contents of our free Ebook for Mobile Product Owners.

Drive your Product to Success – Guide for Product Owners. Table of contents: 

  • Introduction
  • TIP 1: Be aware that you are a part of a team
  • TIP 2: Know what you need and why you need it
  • TIP 3: Be the voice of the Development Team for the outside world
  • TIP 4: Deliver the requirements and keep them prioritized
  • TIP 5: Be the decision-maker and the budget keeper
  • TIP 6: Allow the Development Team to be the experts
  • TIP 7: Be available when the team needs you
  • TIP 8: Give feedback
  • A quick guide on how to calculate the Estimation of a Scrum project’s budget
  • Wrap up & 5 killer tips on what to avoid
  • About Droids on Roids

Below, we present only a few excerpts from our free Guide for Product Owners. To read the whole Ebook, download it here.

A few excerpts from the free Ebook for Mobile Product Owners: Drive your Product to Success

TIP 1: Be aware that you are a part of a team

In Scrum, collaboration and transparency are the key components to unlocking and creating value.

It’s impossible to collaborate effectively without recognizing that you, as the Product Owner, together with the developers, QA (Quality Assurance) Engineers, UI/UX designers, and a Scrum Master, should create a synchronized team. Make no mistakea Development Team is not an outsourced group of workers “building a bridge” on their own, based on the given documentation, and simply checked upon from time to time.

There is no “you” and “they” in a Scrum Team. Instead, there is a group of people who share a common goal of creating an outstanding product. This requires, under your guidance, dedication, and the proper skills to achieve the desired goal.

Secondly, like in every good team, each “player” contributes to the project’s success, in accordance with their given role. In order to avoid becoming a “football team” in which all the players play as goalkeepers or – even worse – without a goalkeeper at all, it’s particularly important to understand who is responsible for what.

Scrum Team

To put it simply: You, the Product Owner, are responsible for “What?”. The Development Team is responsible for “How?”. The Scrum Master is responsible for the process. If you know your “what” well, then the Development Team will make sure to come up with the best, most optimal “how” and implement it through a smooth, painless development process, which is made possible by the Scrum Master. Read also: How to communicate with your Offshore Development Team – Tips for App Owners.

TIP 5. Be the decision-maker and the budget keeper

As the Product Owner, you plan and review the work the Development Team does every Sprint, keeping in mind what’s still in the backlog.

Scrum Sprint Illustration

The decisions you’re making for every Sprint are inseparably linked to both the project’s overall budget and possible timelines. A good understanding of this process results in a lack of surprises when the time for payment comes.

The most important thing you might want to do, as a budget keeper, is to develop a proper understanding of Estimations. You cannot simply treat the rough estimate numbers as a guaranteed, rock-solid basis to build your entire budget upon. Instead, you should acknowledge that you will need to play an active role in the constant monitoring process.

The initial ballpark (a very rough approximation) – provided to answer the questions of “how much is the project going to cost me” and “how much time is the development going to take” – gets more and more realistic with every iteration. As we move forward with the development, the initial general requirements will get split into smaller chunks and will become much clearer. Moreover, some new requirements will most definitely appear. This is especially evident if the UI/UX design of your product is just a bit ahead of the actual development schedule.

A key to successful budgeting in a Scrum project is understanding that you, as the Product Owner, manage the budget through the Product Backlog. By asking the right questions, such as “are we on track?”, you need to prioritize and de-prioritize specific product features, adjusting the scope of each new Sprint to fit the budget, not the other way around.

If you want to know how to calculate the Estimation of a Scrum project’s budget, read the guide which can be found at the end of our Ebook.

Estimation formulas

Inside the Ebook, you will find:

  • Sprint Cost Estimation Formula,
  • Number of Sprints Estimation Formula,
  • Development Cost Estimation Formula.

Sprint Cost Estimation Formula - Guide for Product Owners

With the above-mentioned calculations, you will be equipped to maximize the development team’s work value delivered with every Sprint. Just remember to play an active role in the iterative inspect and adapt cycle. Read also: What’s the average app development cost?

5 killer tips on what you should absolutely avoid as a Product Owner

At the end of our free Guide for Product Owners, we added also some additional tips on what you should avoid:

  1. Attending meetings late or not showing up at all. Remember that, if you force a team of a couple of people to wait for you, instead of maximizing the value of work, you simply waste your money on the non-productive anticipation of your appearance.
  2. Changing a Sprint’s scope after it has been carefully planned and started. As a Product Owner, only you have the right to stop the current Sprint and decide that the direction of development needs to be dramatically changed. However, with iterations lasting only 5 workdays, such scenarios shouldn’t really happen, since the very short feedback loop is more than enough to effectively adjust to changes and plan the work ahead.
  3. Keeping the Product Backlog empty. If you don’t provide information regarding which features should be developed next, there is simply no way to maximize the value of the Development Team’s work, not to mention responsible budget management.
  4. Saying “ok, good” if, in fact, you are not happy about something. If you are not happy about something or not clear about any of the elements of the development process, don’t pretend that everything is ok. Give honest feedback and share your doubts.
  5. Saying that all product features are “a must”. If you can’t prioritize the features of your product – deciding which ones are a “must-have” and which would be “nice-to-have” – you will most likely end up running out of budget, instead of launching a nicely working product which can be made perfect a little later on.

Wrap up

We hope, the excerpts described above, will make you decide to Download your Free Ebook and read it cover to cover. To sum up, you will learn:

  • how you can deliver on your requirements and keep them prioritized,
  • how you can calculate the Estimation of a Scrum project’s budget,
  • how you can become a professional and engaged Product Owner, with whom the development team will love to work.

We wish you a fantastic journey as a PO!


The post Get the Best Free Ebook – Guide for Product Owners: Drive your Product to Success appeared first on Droids On Roids.

https://www.thedroidsonroids.com/blog/free-ebook-product-owners-guide/feed 0
What is React Native and When to Use it? Introduction for App Owners https://www.thedroidsonroids.com/blog/what-is-react-native-introduction https://www.thedroidsonroids.com/blog/what-is-react-native-introduction#disqus_thread Mon, 19 Oct 2020 11:09:33 +0000 https://www.thedroidsonroids.com/?p=31239 What is React Native? When is it worth to use React Native in your app development? Read the comprehensive introduction for App Owners.

The post What is React Native and When to Use it? Introduction for App Owners appeared first on Droids On Roids.


What is React Native and when it’s worth using React Native in mobile app development? Skip to a section:


More and more people simply can’t imagine their lives without mobile devices like smartphones, tablets, and wearables anymore. This is especially true for smartphones that note increasing penetration rates every year. We use mobile devices to pay for our bills, arrange medical appointments, or order food. Over the last 10 years, the percentage share of mobile devices in Internet browsing has increased from 1.56% (January 2010) to 51.5% (September 2020).

Source: StatCounter Global Stats – Platform Comparison Market Share

It’s no wonder that so many website owners have decided to create two versions of their sites – one for wide-screen personal computers and the other for narrow-screen mobile devices. They are doing this to ensure the best possible experience for their users.

This solution turned out to be problematic, with issues ranging from maintaining two applications and problems with SEO to the challenge of detecting whether the device is a smartphone or a PC. That’s why we came up with a better solution: a responsive web design that adapts to the device on which it’s displayed. As a result, you only need one code to operate both platforms for a website to look good on any screen.

A similar problem occurs in the mobile app development process. Many apps are created based on a non-standard look (compatible with the company’s brandbook and other customer requirements) while maintaining the same design across platforms such as iOS and Android (with minor differences required by the platform).

In many cases, developers of individual platforms duplicate their work by writing the same functionalities (login, registration, adding a product to the basket, etc.) in the language native to a given platform. This has a significant impact on the cost of the developed application.

Many companies and developers have tried to solve this problem over the years.

What is a hybrid application?

One solution to this problem is creating a hybrid application. The basis of such an application is a web app that can be made using any front-end libraries (e.g., ReactJS, Angular or JQuery).

The next step is building a mobile application using the Apache Cordova framework, which places the ready application in WebView ( a native component on iOS/Android for displaying websites). Cordova also provides solutions that allow hybrid applications to use native functionalities such as Bluetooth, geolocation and battery.

This approach allows creating one application (one code used on each platform) without using the native programming language of a given platform and maintaining consistency between the platforms. What’s more, we can also use such an app as a web application.

The hybrid solution is not without its drawbacks:

  • When programming a hybrid application, we need to spend more time creating a user experience compatible with the native application (which is often difficult and boils down to imitating the native impressions).
  • Another downside is the application’s performance, which relies on a web rendering engine that can become an application bottleneck.
  • It is also worth noting that, because a hybrid application operates as a web application, you might see problems typical for such applications (the reason behind this is the inconsistency in the operation of individual rendering engines on each platform).

In recent years, we have witnessed a decline in the popularity of hybrid applications in favor of cross-platform applications. Examples of libraries based on this solution are PhoneGap and Ionic. You can learn more about how hybrid and cross-platform applications compare here.

What is a cross-platform application?

The latest solution is cross-platform technologies that allow code to be written in one language, using components provided by a given technology, then building an application for multiple platforms. Just like in hybrid applications, thanks to this approach, we write one code which we then use to build applications for the platforms we’re interested in. Particular frameworks differ in implementation details, but all of them use code native to a given platform under the hood.

Thanks to this, cross-platform applications can achieve much better performance than hybrid applications (in most cases, even similar to native applications). The UX they deliver is similar or the same as using the native language for a given platform.

The most popular technologies showcasing this approach are React Native and Flutter. You can read more about these here:

In this series of articles you are reading now, we’ll cover React Native in detail.

What is React Native?

React Native is a framework built by Facebook engineers and based on ReactJS (I’m describing the connection between ReactJS and React Native in more detail here). It allows you to write the code just once using the popular JavaScript (TypeScript) language and create a mobile application for both Android and iOS.

Facebook uses React Native in many of its applications, including the Facebook mobile application (for example, the Marketplace functionality is made using React Native) and Instagram. So, you can be sure that the framework is of high quality and has practically guaranteed future support from the Facebook team.

Read also: Advantages and Disadvantages of React Native | Business Perspective 2021

What is React Native?

The most popular applications that use React Native

In addition to Instagram and the Marketplace functionality in the Facebook mobile application, React Native is also used in applications such as:

It’s worth emphasizing that not all of these applications were created 100% in React Native. The framework allows for integration with ready-made native applications, a fact that many of these aforementioned projects have benefited from.

Recently, Microsoft has also shown interest in this technology – its developers have released the React Native XP library. Based on React Native, the tool allows you to create applications for iOS, Android, Web, and Windows 10 – UWP.

What’s more, the teams that create individual Microsoft products are experimenting with this technology. For example, the new Skype application was implemented for some time in React Native (then this technology was replaced by the Electron library), while latest version of the Xbox application for PC was rewritten from Electron to React Native.

The history of React Native in a nutshell

We know what React Native is, but now let’s have a look at its history. React Native was created as a result of an internal Facebook hackathon in the summer of 2013. In January 2015, Facebook released a preview of React Native and, during a conference in May, the company announced the official launch and release of the framework to the community as an open-source project. Initially, React Native only supported the iOS platform, but in September 2015, it also received support for Android.

In recent years, Facebook engineers have been working on increasing the performance of the framework, new architecture, and reducing the size of the application.

What’s the difference between React (ReactJS) and React Native?

Published by Facebook in 2013, React (also known as ReactJS; I’ll continue referring to it under this name for clarity) is a library designed for web applications. It’s the main framework used to create Facebook web applications. The main role of ReactJS is to display individual components/widgets of the page, depending on the current configuration (provided data).

Thanks to its simplicity and declarative nature (meaning that the developer declares what they want to achieve and a given component is responsible for this effect), ReactJS has gained both recognition and popularity – it’s one of the 3 most popular libraries for the fast and effective writing of web applications, next to Angular and Vue.

To better illustrate the benefit of ReactJS’s declarative nature, let’s analyze the following code for creating the (WelcomeDialog) component:

<WelcomeDialog show={true} title=”Hello Reader” />

Even a non-technical person can easily understand that such a piece of code should display a dialog (the show property is true), the title of which will be text Hello Reader ( the title property is set to Hello Reader).

The way of thinking about the application (architecture/assumptions, etc.) proposed by ReactJS is so universal that it was also used in its younger sibling – React Native.

React Native uses the mechanisms of ReactJS in line with the “Learn once, write everywhere” principle, and the main difference between the siblings is the type of application under construction. As I mentioned before, ReactJS focuses on web applications, so we use HTML, CSS, and, of course, JavaScript there. However, thanks to React Native, we can build an application for multiple platforms at the same time.

What makes React Native unique?

Here’s a list of the greatest advantages of React Native (in my opinion):

  • The framework is based on one of the most popular languages ​​at the moment – JavaScript (source). Thanks to this, React Native developers have access to many external libraries that work in React Native applications (day.js, lodash). Moreover, many libraries that are written with ReactJS in mind also work with React Native (e.g., Formik, redux, victory.js i AWS amplify).
  • The possibility of integrating React Native with an already existing mobile application, thanks to which we can continue developing an existing application using React Native. What’s more, even at the stage of designing a mobile application, we can distinguish between views/functionalities that are worth writing in React Native (e.g. user profile, login), and ones for which speed is critical, and should therefore be implemented using native code.
  • “Learn once, write everywhere” makes it easy for anyone who knows ReactJS to get into a React Native project very quickly. The knowledge and experience acquired with the web version can be translated in a ratio of almost 1 to 1 to React Native.
  • React Native also allows you to write a code fragment for just a given platform (e.g., if we want to have a menu that complies with the standards of a given platform, we can program this element separately for each platform).
  • The ability to create your own native code that can communicate with our JavaScript code. This is helpful for communication with the API of a platform that is not supported or when we want to integrate with a ready-made solution.
  • Another advantage of the framework is that its architecture is focused on adding new platforms. Thanks to this, as well as the community’s support, React Native also supports platforms such as Windows, macOS and offers the possibility to write web applications.
  • The Expo framework is worth a mention as well. It significantly improves work with React Native by providing many useful components for creating a typical mobile application – for example, access to text messages, contacts, cameras, or login via social media. You can read more about this framework here.

To sum up the pros of React Native:

React Native advantages

How does React Native work?

React Native’s main task is to provide components, which are then translated (mapped) to their native equivalents on a given platform. This is how it maintains the UX of a given platform.

For this reason, the framework has its own special components (e.g., Button, Modal, Text Input) from which we build the UI. Thanks to this, React Native knows how to build an application for a specific platform. For example, when creating an Android application, React Native translates its Button component into a native button available in Android. This architecture also allows developers to easily add additional platforms.

onPress={() => console.log('Hello Reader')} 
title="Button with native styling" 

Platform Result
macOS (React Native for Windows + macOS) React Native in app development - UI example macOS
Windows (React Native for Windows + macOS) Windows screen example
Web (React Native for Web) Example of web screen
iOS (React Native) Example of iOS screen made with React Native
Android (React Native) Example of Android screen made with React Native

The second important thing to mention here is the need to communicate between the JavaScript world (where our application code exists) and the native environment of the platform in which the application is displayed.

For example, the code in React Native needs to know when the user has pressed a button, typed text into a text field, or switched to another view to react to it accordingly. The task of the built-in mechanism in React Native Bridge is to ensure communication understandable for both environments.

However, the downside of this solution is the additional time associated with communication between platforms during the application’s operation, which must be taken into account – for instance, when creating efficient animations in React Native.

Communication between native and javascript modules

React Native – differences in development for Android and iOS

Will React Native make my app look and run the same way on iOS and Android? Here are the key things you need to know about the differences in development for Android and iOS.


By default, when you run the React Native application on different platforms, you will see a different-looking application. Why? Because it works the way it works, React Native will use native styling for each platform. Let’s look at this example: 

Nothing stands in the way of making the appearance of individual components consistent so that they look the same, regardless of the platform.

The React Native community also provides solutions in the form of UI frameworks. These are ready-made components styled in accordance with a given design (for example, material design). Some of them also have completely new components ready to be used in our application (like a floating action button, chip, and avatar). The use of ready-made UI frameworks significantly accelerates the development process. The most popular of these are:

  • React Native Elements: link
  • NativeBase: link
  • UI Kitten: link
  • Shoutem UI toolkit: link
  • React Native Paper: link

React Native gives us complete freedom in how we want our application to look; it can resemble the native look and also be consistent on individual platforms.

Developer’s experience

Thanks to the introduction of abstractions for the application code, it’s often irrelevant on what platform it’s executed (from the programmer’s perspective). However, React Native provides tools that allow you to judge what platform it’s running on so that you can create a styling/behavior that resembles the native one more closely.

In extreme cases, when a given component looks completely different, a developer can easily create a component for a specific platform (just add the suffix .ios/.android in the file name before the extension).


Since the Android system doesn’t provide the mechanism needed to run JavaScript code (JavaScript Virtual Machine) by default, React Native must add it when building an application for this platform. This makes the application size larger than the same application built for iOS.

Will my React Native app work on mobile?

As I mentioned before, React Native is used in Facebook products. For this reason, we can be sure that the delivered code is refined and has been tested by many users. In one of their articles, Facebook assured that its application would use the same version of React Native we can download from the public repository, giving us even more confidence about this framework’s quality.

It is worth noting that React Native currently has better support for iOS than for Android. This means that developers should spend a little more time on this platform, as some bugs may only occur on Google’s system. This issue has been addressed, and work is underway to improve Android support.

Will my React Native app work on the web?

Yes, it’s possible! One option to achieve this is by using React Native Web (it’s used in the mobile version of Twitter, just to give you an example). React Native Web is a library that adds support for a new platform – web.

Thanks to this, we can get code that you can use to build a web application as well.

When comparing the development of web applications with React Native Web and ReactJS, the downside is that there are fewer external libraries available for RN and developers need to use internal React Native components instead of regular HTML and CSS code.

It’s also worth paying attention to the fact that, thanks to React Native’s foundation on JavaScript language, we can transfer the common part of the code responsible for business logic and other aspects into a separate project (library) and then use this project in web and mobile application.

As an example, let’s consider a view/page that contains a cart summary along with a promotion calculation under certain conditions. The code responsible for calculating the total cost and the discount can be transferred to a new library (cart.js), while individual platforms are only responsible for displaying the cart view.

Does React Native mean we don’t need native developers?

In typical use cases for mobile applications, a native developer isn’t needed in the development process. A React Native developer works with JavaScript code in their everyday work.

It’s worth noting, however, that the stages of creating an application such as configuration for release, configuring CI/CD, and the release process are just like in the case of native applications. After building a cross-platform application, we get the same file as in native development. That’s why React Native developers need to use tools and services that support mobile applications. Some of these tools might be a complete novelty, especially for those who previously worked only with web applications.

However, due to the high popularity of React Native, more and more tools support this framework (such as Bitrise or App Center), so the presence of a native developer for these steps is also not necessary, although it can certainly speed them up.

Experience in native application development will also be useful when integrating with native modules (we create code on the native side, which can communicate with JavaScript code) or when we use React Native only in specific areas of the mobile application.

Read also: 6 Common Mistakes to Avoid when Developing a Mobile App for your Business

Why should you consider React Native for your mobile app?

As I mentioned in the introduction, the main argument for considering the use of React Native technology is the possibility of reducing app development costs and faster application development. RN works well if what you have in mind is creating the same mobile application for two platforms (iOS, Android), where the speed of operation is not critical.

Since React Native enables fast application development, it’s also a good tool for prototyping and quickly delivering the idea to the market for business verification.

Another advantage of this framework is that it allows us to immediately deliver new functionalities to supported platforms.

Note that React Native uses the popular JavaScript language and the ReactJS framework, which means that the number of experienced software developers available on the market is large.

I hope that now you know what React Native is, how it works, and why you should consider using it in your mobile app development process. We’re going to publish more articles about React Native in our series dedicated to app owners soon. Stay tuned!

The post What is React Native and When to Use it? Introduction for App Owners appeared first on Droids On Roids.

https://www.thedroidsonroids.com/blog/what-is-react-native-introduction/feed 0