Droids On Roids https://www.thedroidsonroids.com iOS & Android Mobile App Development Company Tue, 26 Jan 2021 11:57:22 +0000 en-US hourly 1 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.

]]>
Introduction

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.

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.

Pricing

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.

Screenshots

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:

Others

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.

Ads

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.

Signing

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
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).

Examples:

  • 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.

Examples:

  • 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.

Examples:

  • 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:

Auth0 pricing

Auth0 pricing – to see more, go here

Mapbox:

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

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. 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.

Stripe

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.

Socket.io 

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.

VoxImplant 

A serverless platform for voice, video, and messaging APIs trusted by thousands of developers around the world to innovate and scale real-time communications.

Mandril

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.

Firebase

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.

ARCore

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).

Mapbox

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.

Flutter

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:

Xamarin

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:
Text(Strings.of(context).measuringPoints)

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.

Design

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.

Placeholders

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:
Text(Strings.of(context).runningLabel(appName)

Plurals

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).

Select

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.

Genders

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.

Numbers

In the source code we usually write numbers like this:
12345678901.2
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.

Currencies

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:

English:
Hello

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.

Images

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:
Image.asset('assets/images/${Localizations.localeOf(context)}/icon.png')

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.

Implementation

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:

MaterialApp(
        localizationsDelegates: [
          Strings.delegate,
          ...GlobalMaterialLocalizations.delegates
        ],
        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).

intl_utils

Setup

The first step of integrating intl_utils is to enable it in pubspec.yaml:

flutter_intl:
  enabled: true
  class_name: Strings
  localizely:
    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
flutter_localizations:
  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/**'

Localization

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.

Localizely

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
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 Tue, 24 Nov 2020 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:

Summary

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
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 2020?

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.

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:

Introduction

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:

  • Uber Eats,
  • Discord (iOS version),
  • Walmart,
  • Wix,
  • Pinaster,
  • and Bloomberg.

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.

<Button 
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.

Look

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).

Size

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 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
Mobile Security Testing. Make the First Step! https://www.thedroidsonroids.com/blog/mobile-security-testing-introduction Tue, 13 Oct 2020 09:59:22 +0000 https://www.thedroidsonroids.com/?p=30833 An introduction to mobile security testing in your app development process.

The post Mobile Security Testing. Make the First Step! appeared first on Droids On Roids.

]]>
Have you ever wondered how to secure a mobile project? Maybe you have even started conducting research, only to become even more confused about the topic? If you answered “yes” at least once, then let me give you a helping hand! In this article, you will learn how to test the basic aspects of security in the modern mobile app ecosystem and the benefits of taking such a direction.

First things first. Why mobile security matters.

Why should you even bother to raise awareness about the security in your workspace? Security, similarly to Quality, is a distributed responsibility of the entire team. While working on an app, you’re not only bound by a contract with a client but also with end-users by an informal social contract.

Ensuring mobile security – what does it mean to me?

  • One of its arising responsibilities is active data leakage prevention.
    Very often, a team working on an app is the last bastion of enforcing the seven key principles of GDPR (General Data Protection Regulation), published in 2016 and implemented 2 years later. Check out: What does GDPR mean for Mobile App Owners – 12 Use Cases.
  • When it comes to mobile security responsibilities towards a client, securing an app code from leaking is definitely one of them.
    This aspect is extremely important while working on complex algorithms implemented on the client-side. Such solutions should not be public or easily accessible by anyone other than the project owners. The company needs to keep things such as API keys, Web API details, algorithms, custom and innovative solutions private.
  • Avoiding situations when a mobile app is attacked and gets removed from application stores is an obligation towards both the client and end-users.
    Apps can be exposed to undesirable effects of third parties, which can result in turning your phone into a well prospering bitcoin miner. When such a situation happens, the app is taken off the store as soon as the faulty behavior is detected and remotely uninstalled at worst.

Underestimating the aspects I mentioned before may lead to serious consequences for all 3 sides. Find out more about this topic:

Once upon a time… What may happen if you neglect mobile security

Imagine the scenario when a company encounters a huge security gap in an app but they notice it too late. The app is already released and users have suffered from those issues. After a tiring and lengthy legal process, as well as enormous financial penalties, the company wants to start over.

Sadly, their reputation is in shreds already and even rebranding may not help. The company is losing the trust of their users and receiving lots of negative opinions. They need to face the inevitable – all that’s left to do is to shut down. If you have signed a contract with that company – you have just lost the client, and your reputation as a specialist can be harmed too.

Have you felt that shiver in your neck? I know it might sound scary, but if you are reading this article, it means you are in a good place to protect yourself from being a part of this pessimistic scenario.

Let’s see what the most crucial areas of mobile security are and which of them should be addressed first.

5 key areas of mobile app security you should be aware of

1. Network traffic

When building and testing a mobile app, it is important to ensure that the communication with servers is properly secured. This is where the HTTPS protocol comes to the rescue. The enhanced version of its older HTTP brother encrypts the exchanged data with SSL (secure socket layer)/TLS (transport layer security).

To perform basic tests in this area, it is handy to gain some experience with Proxy tools like Burp Suite, Charles Proxy and Proxyman, which can be used to intercept requests and responses from a Web API. If you have never worked with any of them, I recommend you pick Burp Suite and give it a try. It can quickly become your favorite toy during mobile testing as it provides a broader view on the integration and communication with a Web API.

Additionally, you can use the tool to verify if the app<->server communication relies on the HTTPS protocol. Simply check the network traffic going through the device and filter URLs under the domain your API is deployed to. For example, in Burp Suite, you can track all the URLs that are not starting with “https” and are within the API domain. If any URLs are logged while this filter is set, you should carefully verify them, as it may be the first vulnerability in the app you have encountered.
Mobile security testing - key areas - https
HTTPS is not the only protocol you should be aware of. As mentioned before, SSL/TLS  is used for data exchange encryption. Similar to HTTP/S, there were multiple versions of those protocols released and implemented in the last quarter of the Internet’s existence (so far!). The oldest TLS versions (1.0 & 1.1) have been considered as not secure enough, deprecated and, as of 31st of March 2020, no longer supported.

So what is it all about? Why can’t we just adapt our API to use 1.2 onwards?

Well, it turns out that it’s not as simple as you may think. For example, Android 4.4 and all the versions below support 1.0 and 1.1 versions of TLS by default, so developers should remember to enable TLS 1.2 support manually. To make sure your team did this, type the following command in your terminal with the Web API URL and its port.
Mobile security testing - key areas - 2
As an output, you will get the TLS version supported by the Web API.
Mobile security testing - key areas - 3
With the recently published (2 years ago) TLS 1.3 version, why not migrate to it upfront? Well, native support for TLS 1.3 comes only with iOS 12.2 and Android 10 onwards. With over 80% of iOS 13 adoption, you don’t need to worry about the Apple world. With less than 10% Android 10 adoption, however, you can either enable the support with custom implementations for earlier Android APIs or wait 3-5 years for the TLS 1.3 support to reach the current iOS level. So for now, you can rest easy, unless the rapidly developing quantum computing becomes a thing and redefines our look at the security of the IT systems.

2. Application’s persistent data

Another crucial area of mobile security testing is the storing of persistent data in a mobile app – which seems to be an easy task. Just pick one of the available frameworks, grab the data you received from a user or BE (backend), and that’s it. Implementation-wise – all is done, but have you ever wondered if the data you just stored is properly secured and if it contains any sensitive information about the user? First of all, you should check if there is any business justification for storing such data. If, for some reason, it’s necessary for your company to run, make sure all the data was reviewed by the person appointed as the Data Protection Officer.

The next step is to identify the frameworks used for data storage. Android applications usually rely on SharedPreferences and SQLite databases. So, if you have a test device with the debug variant of the app installed and a spare USB cable at hand, you can do some research on your own. Connect to the device with ADB command, locate the data/data/your-app-package/ directory. The databases and shared_prefs directories are exactly what you are looking for.

If the app uses firebase services, you will most likely see multiple .xml files under the shared_prefs directory and .db files under the databases one. Try to locate the ones created by your developers and pull them to your workstation. You may start wondering if it’s that easy to access data of any app installed on your phone, but there is not much to worry about. Each app has its own private disc space allocated, which can be accessed only by itself. The only exceptions are debug builds and rooted devices (less than 1% of the market).

But let’s go back to the file we’ve pulled from the device a moment ago. There are two options – persistence data can be encrypted or not. If it’s encrypted – you can celebrate – as another layer of security was implemented by your developers. To verify the shared preferences, you can simply open their files in any text editor. If you see the key-value pairs in a plain text, then they are definitely not encrypted.

Mobile security testing - key areas - 4

When you want to verify an SQL database, search for an SQL viewer (there are plenty available online) and import data from the .db file. If it opens, that means it’s not encrypted but at least you can examine the scheme, browse the data manually or perform a few SQL queries to verify that everything is correct.

Mobile security testing - key areas - 5

3. Android Application package – Android build artifact

Contrary to the iOS apps distribution system, which is way more closed, though secure, Android needs some developer effort to make it less accessible to the public.

There are a few tools that can help you keep the code harder to reverse engineer:

  • ProGuard & R8 (R8 is used by default starting from Android Studio 3.4) – tools for code obfuscation – changing names to literals. Thanks to these, the code is less readable for humans and also “lighter” due to the fact that the many long names tiresomely imagined by developers are replaced with a combination of single letters. How to check if you’re using one of these in your app? Check the build.gradle-s and see if the minifyEnabled option is set to true.
  • DexGuard – the enterprise version of ProGuard used for code encryption. Not a mandatory one, but definitely something worth checking as an additional protection layer.

You should also keep in mind that API keys shouldn’t be easy to find somewhere in the .apk

This is, for me, the easiest way to check:

  • Search for your publicly available production .apk version on one of the apk mirrorsMobile security testing - key areas - 6
  • Upload it to one of the online apk decompilersMobile application security testing- key areas - 7
  • Download the decompile code to your computer
  • Use the terminal to look up some keywords that you want to make sure are not there. So, if you’re trying to make sure that API keys are not there, try searching for “api_key”Mobile security testing - key areas - step 6

4. Third-party, open-source libraries

The main question here is if the libraries used in the project are trustworthy? What if they collect some info about the user? There are a few things you can do to minimize this risk:

If you found them safe – make sure you also check the source from which you want to download them.

  • To ensure any already introduced libraries are still safe, run an automated dependency check regularly as a part of your pipelines:
    • Go to Dependency check
    • Add the OWASP dependency check plugin to gradle:
      apply plugin: 'org.owasp.dependencycheck'
    • Use the Dependency check plugin by OWASP to check libraries for known, published vulnerabilities.
      ./gradlew dependencyCheckAnalyze --info

      Mobile application security testing- key areas - 8
  • Be extra focused while checking the permissions app is asking for.
    If there is a case that the app wants permissions for something not related to any of its features, it can be a sign that a malicious library is used in the project. For example: imagine that a camera app, among the storage and camera permissions, wants to access your phone calls. This is something you should be concerned about!

5. Logging sensitive data

  • Check if your production app is not logging any requests or transactions (you can use tools for network traffic tracking from the 1st point)
  • Check your analytics/crashlytics tools – when the issue is logged in there, be sure that sensitive data is not logged along with the information about the users and their actions/crashes

Mobile application security testing – wrap up

Testing mobile security is a challenge worth accepting. Now that you have read this article, you are one step closer to taking care of it in your project. I hope it is easier for you, since you should already have an idea of where to start.

Do not be scared to begin this journey and test if your mobile app is well secured. The whole new world of mobile testing is waiting for you to discover its complexities. Read also: How to Secure your mCommerce Application.

The post Mobile Security Testing. Make the First Step! appeared first on Droids On Roids.

]]>
Communication with your Offshore Development Team – Introduction for App Owners https://www.thedroidsonroids.com/blog/communication-with-your-offshore-development-team-introduction-for-app-owners https://www.thedroidsonroids.com/blog/communication-with-your-offshore-development-team-introduction-for-app-owners#disqus_thread Tue, 13 Oct 2020 08:34:36 +0000 https://www.thedroidsonroids.com/?p=31097 Introduction to asynchronous communication between PO and an offshore development team. Learn the benefits of asynchronous communication.

The post Communication with your Offshore Development Team – Introduction for App Owners appeared first on Droids On Roids.

]]>
Are you afraid of hiring a remote development team because of a lack of control? Do you fear your money will be wasted due to inefficient communication? Do you think the time zone difference will ruin your communication?
If yes, you are in the right place.

In this article series, we’re exploring the topic of communication between the App Owner (you), and your Offshore Development Team. It contains:

  • Introduction to Communication between App Owner and Development Team – you are reading this
  • Asynchronous Communication with the Development Team – How to Do it Effectively? Guide for App Owners – to be published
  • How to Improve Communication your Development Team | Tips for App Owners – to be published

In this post, you’ll learn why communication is crucial for your app development process, how asynchronous communication works, and what benefits does it bring for you.

Why communication is hard

Before developers, clients, and Product Owners…, we all are human beings. Communication between people is difficult by nature. You probably have many examples when improper communication was the only reason why somebody got upset or sad, even though nobody had such intentions.

What exactly is communication? I’m no scientist, but to me, it’s sending messages from one head to another – leveling the information gap between people. Messages are being sent one by one. See this diagram showing how complex communication is on the scale of only ONE message:

Now think about how many parts can fail in the process:

  • Sender – maybe the sender is incorrect (for example, a non-technical project manager trying to send a technical message that a developer should have sent instead)
  • Encoding – maybe you used a wrong form of encoding (eg. used a word that the other person doesn’t know)
  • Message – maybe the message contains too much information or too little? You rarely know the answer until some feedback is given
  • Decoding – maybe one word has many different meanings and the receiver picks the one you didn’t mean?
  • Receiver – maybe the receiver should be someone else? Maybe it should be the whole team instead of one particular person?
  • Feedback – maybe there’s no feedback at all, and the sender doesn’t know if the receiver understood everything correctly?
  • Noise – maybe the sender made a few typos in your message, and the receiver misread one of the longer words in the message?

Of course, the errors on different layers add up. Now think how many messages you send and receive every day, and try to determine if the “information gap” has really been leveled or it’s just an illusion.

Why communication is important for successful software development

In IT, it gets even worse. The IT world is pretty complex by nature and, therefore, the message itself must often be big and/or numerous. This means that each level of communication has more chances to interfere with the message in the wrong way.

Think about it this way. The application that we’re going to create for you has a technical level (which is our expertise) and a domain level (which is your business problem). In order to write the perfect app for you, we need to understand your domain to a perfect degree. In fact, we can only implement our understanding of your domain. Therefore, it’s extremely important for your success to communicate your domain and ideas as efficiently as possible. Read also: What is Product Discovery in Mobile App Development?

On our side (the development team), it’s the same story. We need to communicate the progress, challenges, technical obstacles, etc. as efficiently as possible, in order for you to make the best possible decisions.

I’m a developer and, from my point of view, communication is the bottleneck of software development. Typically, for a product to be better, there is no technical limitation, it’s only the goal, problem, requirements, the idea of implementation, etc. that are not clear by some sides.

The theory of constraints advises us to improve the bottleneck. So, if you want a better product, you should improve communication in the first place.

This is especially true in 2020 when a lot of teams and companies have undergone deep changes. Even if they didn’t want or weren’t ready for it, they needed to switch to complete or partial remote work. They were forced to abandon their past communication patterns and habits, learning new ones in the process.

Before going to more precise pieces of advice, let’s introduce who you can expect in your offshore team.

Who is who & assumptions

In this article, I’m writing about the Scrum team, because Scrum is the most popular agile framework and a significant part of our craftsmanship. In Scrum, there are three roles:

  • Product Owner (PO)
  • Development Team
  • Scrum Master (SM)

Even if you decide to not use Scrum, we’ll insist on nominating a Product Owner on your side because it’s a necessary role in agile development. The Product Owner is a person, typically chosen on the client’s side, who is our decision-maker. If you need more details, you can read our blog post about app development in Scrum.

From the perspective of this article, there is a couple of important assumptions worth highlighting:

  1. The PO will most likely be onsite (this might be you, for example), while the Development Team and Scrum Master will most likely be offshore.
  2. It’s extremely important that the PO is one – and only one – person. You’ll learn why later. Get a free Ebook – Guide on how to be a great Product Owner.

The biggest mindset shift you need to employ as a remote App Owner

Effective remote communication is asynchronous. If you haven’t already, you need to switch your mindset to asynchronous communication, instead of synchronous.

What does synchronous and asynchronous communication mean?

What’s the difference between asynchronous and synchronous communication?

Synchronous communication

For synchronous communication, think of office-like interactions. Each side of a conversation needs to be in the same time (the same place is not necessary but advisable). For example, a meeting in a conference room or face-to-face interactions. Sometimes the same place is not needed (think online meeting), but in my experience it is desirable, and still requires the same time.

how synchronous communication works

Asynchronous communication

In contrast, asynchronous communication is when you don’t require participants to send and receive messages at any particular time. For example, instead of announcing some message at a meeting, you can write an email. In general, writing instead of telling is a great step towards asynchronicity.

asynchronous communication between PO and development team - illustration

To be clear: this doesn’t mean that much time must pass between sending and reception. We only allow for such possibilities in this model.

At first glance it may appear that it’s a much more costly way of communicating – people can reply much later than I need it! In practice, because of this assumption, people learn how to communicate more effectively, make reversible decisions by themselves, and waste less time in the run.

Of course, it also has lots of other benefits.

Key benefits of asynchronous communication

  • People are free to utilize their time. For example, they can read and reply to all the messages after finishing a Pomodoro (a very popular technique among programmers).
  • Asynchronous communication is long-lived. A face-to-face conversation can be hardly forwarded with exactly the same message. The same message, if written in an email, can be forwarded easily and quickly, and is also searchable, quotable, etc.
  • Because of the aforementioned “forwardability”, it’s transparent to people not present at a hypothetical meeting (and for example new members of the team in the future).
  • People can read the message as many times as they need, and take as much time as they need to reply.
  • It’s an easier way of communicating than speaking directly for people who tend to be shy in person.
  • It resolves numerous problems – time zone differences, connection issues, finding a common time slot for a meeting, etc.

When to be asynchronous

  • It is true that on a smaller scale (2-3 people) face-to-face communication (and therefore synchronous) is more efficient. It is even advisable in the Agile Manifesto – a famous paper made by developers who wanted better products. If your team is of this size, you need to reconsider some points of this guide. However, when hiring an offshore team for writing an application, you can expect a team of 4-8 people. On that scale, synchronous communication starts to be not only problematic but also too time-consuming to convey. So asynchronous communication would be better here.
  • Regardless of the team size, there are other factors that favor asynchronous communication, such as geographical differences or remote work.
  • The recommendation in this series are also valid if you want to focus on asynchronous communication for any reason (there might be many reasons for this: you need more information, you want your team to be bigger soon, you live in a problematic timezone, and so on).

Let me repeat. Your remote development team will have a higher chance of success if they are free to work and communicate asynchronously.

Wrap up

Communication is not a piece of cake, yet it’s extremely important, especially in software development. Mistakes can be made on different layers. To improve your communication with your offshore development team you have to tackle the most fundamental feature of it – that is, you have to turn it all into asynchronous communication.

If you’ve employed this mindset and understood what it is, as well as why it’s important, you’re halfway through.

In the next episode of our series: How to Communicate Asynchronously with your Development Team – 8 Tips, you’ll find a few pieces of advice on how to achieve asynchronicity. In the third episode, I’ll share a few secrets for improving communication overall and not just for asynchronous methods, so be sure to check it out even if you’re using synchronous means. Stay tuned!

The post Communication with your Offshore Development Team – Introduction for App Owners appeared first on Droids On Roids.

]]>
https://www.thedroidsonroids.com/blog/communication-with-your-offshore-development-team-introduction-for-app-owners/feed 0
How to Secure Your Mobile Commerce App | Guide for App Owners https://www.thedroidsonroids.com/blog/mobile-commerce-security-tips-2020 https://www.thedroidsonroids.com/blog/mobile-commerce-security-tips-2020#disqus_thread Fri, 02 Oct 2020 12:04:10 +0000 https://www.thedroidsonroids.com/?p=30634 To make your mobile commerce app secure, you need to act on many different fronts. Find out why securing your mobile commerce app is so important, and how to do it.

The post How to Secure Your Mobile Commerce App | Guide for App Owners appeared first on Droids On Roids.

]]>
How to develop a highly secured m-commerce app for my store? This is one of the most common questions we hear from our clients. M-commerce is gaining traction on the market as more and more users want to buy things using mobile devices, such as tablets and smartphones. Mobile commerce applications are processing more data than ever, including sensitive information regarding users and transactions.

This is why security has become such a key concern for business owners who invest in m-commerce apps. Every security breach can potentially cause users to abandon the application and stop considering a brand as trustworthy.

To make an app secure, you need to act on many different fronts. In this article, we share essential knowledge about m-commerce security that every app owner should know. Read on to find out why securing your m-commerce app is so important – and how to do it.

M-commerce security – an overview

Let’s start with the basics. What is mobile commerce?

Mobile commerce (also called mCommerce or m-commerce) covers any transactions carried out using a mobile device (a smartphone, tablet, or even a wearable device). Examples of m-commerce include shopping apps, in-app payments, and digital content purchases. Read more: What is mCommerce? Definition and Types of Mobile Commerce.

Today, consumers use mobile apps to order and pay for services and items – for instance, meals, cleaning services, or rides. Because of this, mobile commerce is often considered the next level of e-commerce, bringing the ease of online ordering and purchasing to the comforts of mobile devices.

How does security fit into all this?

Since mobile devices are now handling an increasing volume of transactions, the question of security has become paramount to businesses looking to step into e-commerce. Ensuring the security of sensitive data is essential to winning the trust of customers and building a solid reputation. This is especially true for sectors that deal with a lot of such data, with financial services and healthcare being key examples. Read also:

Since these transactions are handled on mobile devices and over the internet, m-commerce is considered to create more security concerns than traditional e-commerce. Read on to find out why.

Why is mobile commerce security crucial for your business?

Securing your m-commerce is important for various business reasons:

  1. As a provider of mobile transactions, you’re partially responsible for securing yourself against chargebacks and ensuring the safety of your data (both that of the business and customers).
  2. A security breach might cause users to abandon your application, dropping your engagement rates, and stopping your revenue stream.
  3. Security problems are going to impact the trust customers place in your brand.

It’s impossible to guarantee 100% data security coverage. No cipher is unbreakable. Does this mean that your business data may be exposed or breached? Not exactly.

The goal here is to make sure that your security measures slow down attackers long enough to make your app an unattractive target in the first place.

How long does this take? The answer usually depends on a case-by-case basis.

Example scenario: Take access to tokens as an example. An access token is a substitute for user credentials, stating that the user had passed the correct data before. If the token expires after a month and the attacker needs more time than a month to get it, we can consider the access token as secure. The user will get a newly-generated token. The old one will no longer be usable.

To develop a highly secured m-commerce system, you need to make all breach vectors difficult enough for the hacker. However, you don’t want to force the user to sign in for every session or input their payment data every time they make a purchase. This could impact the user experience negatively and cause users to abandon the app.

You need to achieve a balance between creating a safe environment for completing online payments on mobile devices and keeping the user experience as good as possible.

Read also: 9 Key Advantages of Mobile Commerce for Businesses (+ 3 Challenges)

Security threats in m-commerce

Every mobile commerce transaction is made of three parts, with each raising its own security issue:

  • the user (the person making a purchase),
  • the server (the business that owns the app),
  • the connection (the technology that brings the two above components together).

Business owners should do their best to build a security matrix* that identifies risks and vulnerabilities accurately. This is how they can target security solutions that work for their unique requirements.

* A security matrix defines how users can interact with each level of data in your application.

So, what kind of security threats should a mobile app owner know? Here are five key threats present in today’s landscape:

  • Connection – this part of an m-commerce application is the easiest one to compromise. Hackers can cause data leakages of sensitive user data or business data that could harm your company. How can you deal with it? Check out the tips listed below in the paragraph “20 best practices for securing mobile commerce”. Hint: combining Transport Layer Security (TLS) with certificate pinning makes accessing the data very hard.
  • Payments – a lack of security here could have many terrible consequences. For example, a compromised payment gateway could cause the user to pay someone else instead of your store. You will never see the money, and they will never get the product – with your reputation on the line.
  • Keyboard – if the user downloads a third-party keyboard, the content they type can be intercepted. Prevent users from using keyboards that aren’t part of their device’s operating systems by disabling this option.
  • Copying content to your application – here’s a common scenario: we store a long password in notes (disclaimer: we definitely don’t recommend that!), so once we need to use it, we simply copy it from our notes and then use it to access an app or website. Others might have access to the clipboard and intercept your password. You can notify users when clipboard content is used or send a properly formatted message with a code that is automatically placed in the password field.
  • Files saved in device memory – if someone gets a chance to use another user’s device, and your application saves its files in a public place, it’s easy to access this data. Avoid saving sensitive data in unencrypted device memory or the cache.

Read also:

20 best practices for securing your mobile commerce

How to secure your mobile commerce? Now that we’ve defined what m-commerce security means, we can zoom in on the most exposed security holes in our app. To find them, we need to change our perspective. A mobile app is a part of a complex system that includes:

  • The mobile app itself,
  • The backend (processing client requests, storing data),
  • Third-party software (analytics, payment provider),
  • The end-user (the center of your product).

The communication between these pieces of the system might need to be secured as well. Here’s a breakdown of key best practices per each area of interest:

Mobile – backend communication security tips

Use mobile-specific solutions

We can trust users more when they create an account using phone verification. Moreover, this method is more convenient for mobile apps than email, which requires opening another app/web browser.

Secure apps have additional tokens to ensure that communication comes from the mobile app. Advanced hackers might obtain these keys, but they should definitely stop some wannabes from spoofing or performing other malicious actions. We can slow this process down by hashing the keys. However, this makes the app development process and maintenance harder.

Refresh session

We can shorten the life of access tokens to several minutes and still keep the app user-friendly by introducing refresh tokens. These tokens have longer validity than access tokens and can be used to obtain a new one. Even if an attacker acquires the access token, it will soon be useless.

Log out request

We can invalidate tokens that are no longer used by signaling to the backend that we closed the session. It’s an optional step and works similarly to the ones above.

Use Transport Layer Security (TLS)

This is a must-have for all new apps. It creates an end-to-end encryption, ensuring that nobody reads our messages even if we send them through an unencrypted channel (for example, a WiFi access point without a password). Note that there are still some steps to be solved here to make it highly secure.

Remember about certificate pinning

The solution above (TLS) will not prevent MITM (Man In The Middle) attacks. In this type of attack, the cybercriminal acts like the backend, so all messages are intercepted and read. To prevent that, we can set only a few trusted certificates used for encryption with the server.

That method has one disadvantage. Since a certificate has its expiry date, developers must publish the app update with a new one before the old one expires. Otherwise, the app will not be usable. In some situations, certificate pinning is impossible or hard to maintain (connecting to some other server). We can address this with the help of the proxy server (proxying).

Avoid sending too much information

We can make it harder for the attacker to obtain all personal data by not sending unnecessary data or splitting them to many requests. Even if the attacker intercepts one request, the information stolen might not be sufficient for them to cause any harm.

Mobile app security tips

Take care of what you store on user devices

Assume that unencrypted data on a mobile device can be stolen. Any sensitive information that needs to be stored should be encrypted. Phones have already implemented secure storage for sensitive data.

We should also remove all unnecessary, temporary files as soon as possible. An app uses many tools that cache data by default. It’s best to avoid storing sensitive data in those places, too.

Use biometric authentication

Most devices support biometric authentication today. We can use it as a convenient method of access or additional security layer for confidential data. But we should never rely only on this alone. Authentication works using something we have, something we are, or something we know. A secure mechanism contains at least two of them.

Don’t forget about binary safety

Compilers can additionally reinforce the app against attempts to intercept data from the compiled source code. This prevents some attackers from spoofing attacks or learning about the app’s security flaws. A platform SDK already includes these tools, but they might not be enabled by default.

Update your libraries

Mobile systems and libraries receive updates, so the app should be up to date as well. We can prevent many attacks just by updating libraries to their newest versions and releasing them in the app update. Most of the successful attacks were achieved by exploiting an unpatched bug that had been announced to the public at least a few months prior.

Watch out for system capabilities

Some capabilities, like clipboards, can store data across all applications. There exist apps or websites that can steal data from the clipboard or place their tracking data there. Since iOS 14, the user will see every clipboard use, which helps to prevent some harmful activity. We should also consider if the app should share data with other apps – for example: can we permit a third-party app to open an unsupported file for preview?

Third-party dependencies security tips

Third-party dependencies gather lots of data, which could be a possible security risk. Keeping user data anonymous and usable for analytics is a complex task and how you do it depends on a particular app domain.

Make sure your dependency is safe

A dependency can be an incredible time-saver and can increase your m-commerce reliability. On the other hand, dependency overuse can lead to a data breach. There is a known case where a popular JavaScript library (over 2 million downloads per week!) was hacked to steal cryptocurrency from wallet apps. This example illustrates a potential threat to mobile apps as well, since JavaScript code and various associated libraries are used in mobile development, thanks to technologies like React Native.

Keep payments secure

We almost always need a payment provider for transactions. Keeping them secure and convenient requires a lot of effort. Many business owners depend on such third-party providers. It’s a great idea to offer handy methods like Google Pay or Apple Pay.

Choose reliable Analytics solutions and ads SDKs

To secure your m-commerce app, choose a reliable analytics tool or advertisement SDK. Be sure to check if the provider experienced any cybersecurity problems like data leakage recently. What’s the company’s reputation? Do large organizations use this tool? Your development team should assess it and tell you whether it’s a good match. The tool can always be audited by cybersecurity experts for final verification.

Read also: Pros and cons of using 3-rd party software in your application development

Other m-commerce security aspects to consider

Let’s say that you already have an application with a military-grade security level. Unfortunately, this is not enough. You should consider these two issues: User Experience (UX) and legal compliance.

User Experience (UX)

  • Don’t make the app too complicated for the user – remember, an m-commerce app isn’t an online banking app, so there’s no need to log the user out every 10 minutes. Such restrictions will make the app complicated and far from user-friendly. People might leave and find a more convenient way to realize their goals.
  • Follow guidelines – every mobile platform offers guidelines that include many useful tips related to the user interface and experience. They explain how to create app authentication and authorization steps in a user-friendly way.
  • Use built-in toolsiOS and Android offer some built-in solutions which can both improve experience and security. These include payment methods (Apple Pay, Google Play, in-app purchases) and sign in methods (sign in with Apple/Google). These methods require almost no action from the user – instead of filling complicated forms, the app uses the data already present on the device.
  • Look at what the big tech companies are doing – they have already solved many problems related to both security and user interface. They may have even open-sourced some of them.

Legal compliance

  • US Export Law – you can’t use some cryptographic algorithms in countries with export restrictions. Moreover, some device features might not be available in selected regions. Targeting those regions requires some substitutes or using a different app.
  • Apple/Google developer agreements – Apple App Store and Google Play Store require that users know what happens with user data and how they are processed. You should share this information in the app description or privacy policy.
  • Internal policies – smart internal policies may prevent phishing and other social attacks on users. One of them is never asking the user about the password.
  • GDPR – the European directive enforces user data security and punishes companies that allow data leaks. The m-commerce system must grant the user the right to investigate all their data without showing someone else’s data. The user can also request data removal, which is not an easy task because things like invoices or purchase history can only be anonymized. This is why the system must implement security by design.

How to develop a highly secured m-commerce app for your store – takeaways

Security in mobile commerce app development – key takeaways:

  • Security is a continuous process that responds to new challenges and threats, especially in a fast-paced domain like m-commerce. Stay up to date with the recent regulations, technical solutions, and technologies. Look at the largest companies and the entire IT sector to find the best and most suitable solutions.
  • Remember, the user doesn’t experience good security (except in some cases), but will certainly experience a data breach. As an app owner, your decisions will determine the overall security level of the app and its balance with user experience.
  • Every third-party solution might create an additional data leak. Check the dependencies and their potential outcome before using them.
  • Even an experienced development team proficient in creating secure m-commerce apps should be assisted by an external security audit to check for possible app issues.
  • Remember to inform your customers that their data is kept safe on your mobile app. The process of transaction completion needs to be marked as secure.

We hope that now you know how to secure your m-commerce. Are you looking for a development team experienced in m-commerce app development and security? Reach out to us. We have built 130+ apps for companies around the world to help them enter the mobile successfully and safely. One of the mobile e-commerce apps we’ve developed is CCC-Shoes and Bags. f

The post How to Secure Your Mobile Commerce App | Guide for App Owners appeared first on Droids On Roids.

]]>
https://www.thedroidsonroids.com/blog/mobile-commerce-security-tips-2020/feed 0
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 Tue, 15 Sep 2020 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.

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
GIF App Development – How to Develop GIF Encoding https://www.thedroidsonroids.com/blog/gif-app-development-how-to-develop-gif-encoding https://www.thedroidsonroids.com/blog/gif-app-development-how-to-develop-gif-encoding#disqus_thread Wed, 02 Sep 2020 11:50:13 +0000 https://www.thedroidsonroids.com/?p=27253 Learn how to develop GIF encoding in your app and discover helpful libraries.

The post GIF App Development – How to Develop GIF Encoding appeared first on Droids On Roids.

]]>
In this article, we’ll briefly list libraries that can help you with GIF file encoding which is an important part of GIF-maker app development process. Note that projects are constantly evolving, some get deprecated, other new ones appear.

Why GIF encoding is so complex?

It may seem that making the GIF file out of a sequence of images is just like making a video file, only the format differs. Well, nothing could be further from the truth! Keep in mind that GIF format has been developed in 1987, over 30 years ago and at the beginning, it even didn’t support animations. That’s why it has some limitations that make encoding a little bit harder.

The palette

The most significant issue is that a single GIF frame may contain up to 256 colors (including the transparent one if used). The snapshot visible at the given moment of time may consist of multiple frames. That’s because a frame may have a smaller size than the whole canvas. Additionally, a frame may contain transparent pixels. If we want to encode a frame that has more than 256 colors, we have to transform it somehow. There are a few ways to deal with that issue, some of them may be also combined.

One of them is dithering. Roughly speaking, it simulates intermediate colors by mixing more distinct ones. You can see an example in the picture below. Note that an image consists of only completely black and completely white pixels. However, dithering introduces the illusion of greyscale.

GIF encoding case study

Image having only black and white pixels with dithering

If all the frames can be stored (either in memory or in a format like a video file), we can first go through all of them, check which colors are used and how frequently (create histograms), and build an optimal palette(s). There are a few ways to create such histograms. For example, FFmpeg’s palettegen filter supports 3 different statistic modes.

Each GIF frame may have its own palette (if it does not then a global palette is used). With separate palettes, we can have more colors in the whole file. However, multiple palettes consume additional storage space and time to decode. Depending on the animation length, canvas size, and usage it may or may not be meaningful. You can read more about that in the article about high-quality GIF encoding.

Note that GIF format supports only transparency (alpha bit – pixels can be fully transparent or fully opaque), not translucency (alpha channel – fine-grained transparency level). That means if your source contains translucent pixels they will appear as either transparent or opaque in the output GIF file. Look at the following images:

GIF file encoding example

PNG file with transparency – source

GIF file encoding example

The same image converted to GIF

The timeline

Each frame can have its own delay. It is the time for which a frame is displayed. Delay is measured in centiseconds (1 unit = 0.01s). 100 FPS sounds great. However, due to the fact that GIF decoding is generally slow comparing to video (which is often hardware accelerated) the limits were introduced. The lowest values (shortest delays) are artificially increased to higher values. What is more the value after increasing is usually not the minimum one but something even higher!

For example in the environment of writing this article the effectively minimal delay is 0.02s. Everything smaller is increased to 0.01s. See animations below:

GIF with 0.01s delay (may be visible like 0.1s)

GIF with 0.02s delay

See also Animated GIF Minimum Frame Delay Browser Compatibility Study (which is also a source of the images above) for more examples in different browsers. You may be interested in the web archive copy since images on the original website are dead. Choosing the minimum value wasn’t an easy task.

Android

Devices running Android (mostly smartphones and tablets), usually have less performant hardware than PCs used at the same time, so the optimizations have significant meaning here. This means that GIF encoding in Android apps is usually done natively (using C/C++ and JNI, not to be confused with native – non-hybrid, non-Flutter apps).

Fortunately, you don’t always need to go to so low level of abstraction when you develop GIF encoding in your app. One of the most popular libraries for image/video encoding is FFmpeg. Android developer-friendly version is not provided officially. However, some wrappers do exist. At the time of writing one of the most popular is Mobile FFmpeg. Something like this will be probably all you need when you just want to produce GIF out of some input source.

If you want to manipulate on some more GIF-specific properties like disposal methods on individual frames or modify GIF file metadata you may be interested in gifsicle. Unfortunately, it has neither official Android bindings nor a well-known unofficial port. You need to compile it from the source.

Wrap-up

GIF encoding is not an easy process. Due to the fact that GIF was not designed for modern animations, we need to resort to very sophisticated techniques to achieve satisfactory results. Fortunately, we don’t need to write everything from scratch. This topic is popular enough so there are ready libraries that can be used at least low-level parts of the app. Read also an article GIF app development – Challenges and Tips, and check out GIPHY Cam – the app for creating and sharing GIFs that we’ve developed.

The post GIF App Development – How to Develop GIF Encoding appeared first on Droids On Roids.

]]>
https://www.thedroidsonroids.com/blog/gif-app-development-how-to-develop-gif-encoding/feed 0
The Pros and Cons of Rewriting an App From Scratch | App Owners Guide https://www.thedroidsonroids.com/blog/pros-and-cons-of-rewriting-app-from-scratch https://www.thedroidsonroids.com/blog/pros-and-cons-of-rewriting-app-from-scratch#disqus_thread Tue, 01 Sep 2020 13:21:19 +0000 https://www.thedroidsonroids.com/?p=29326 What are the advantages and disadvantages of rewriting a mobile app from scratch? When is rewriting a legacy app a mistake?

The post The Pros and Cons of Rewriting an App From Scratch | App Owners Guide appeared first on Droids On Roids.

]]>
Does your product have legacy code and does it suffer from all of the disadvantages that come with it? Is the average time to market of seemingly simple features is ever-soaring? Is it constantly getting harder and more expensive to find developers willing to work in the obsolete technological stack your application is using? Is your product bombarded with bugs and/or performance issues?

When these and similar questions begin to haunt Product Owners, they may face a dilemma determining whether or not to completely rewrite the application from scratch. So, when is it worth rewriting a legacy app from scratch? In this article, we will look at some points that can help you make up your mind and eventually make the right decision. Before we dive into the pros and cons of rewriting an app from scratch, let’s explain briefly what app rewriting means.

What is app rewriting?

First off, let’s define what project rewriting really means. This definition is necessary to make sure that we’re on the same page. There are already numerous articles that discuss software project rewriting. As a result, there are multiple definitions of what one considers as a rewrite.

There’s the complete rewrite (aka rewrite from scratch), and then there are functioning definitions of a partial application rewrite, also called revamping, reworking, adapting or porting. As you can see, the notion of a software product rewrite can get confusing pretty quickly.

Here, we will focus on rewriting an application from scratch. This approach comes with several advantages and also some disadvantages, as opposed to project refactoring.

For now, just keep in mind that I’m referring to a complete rewrite of an application, which can still sometimes allow for the reuse of certain bits of code. For example, the implementations of algorithms or various (properly isolated) business use cases can sometimes be easily reused, as long as the business requirements haven’t changed.

On the contrary, project refactoring focuses heavily on reusing the old code and only rewriting certain parts from the ground up. The line between the two is thin, depending on the definition you assume.

For more a more precise explanation of the refactoring process and when it’s better to choose it over rewriting, please refer to our Refactoring vs. Rewriting a Mobile App – Comparison for App Owners article.

Pros of rewriting an app from scratch

Faster iteration

The app rewrite usually also includes a redesign of the app architecture. The new architecture should ensure that the code will be easy to change and improve in the future. This will result in a faster iteration moving forward, as well as a shorter feedback loop.

Limitless & faster development

Developers won’t in any way be limited by the existing code – making it easier to use more up-to-date technologies. This will help you make sure your application is developed using state-of-the-art technologies. It’s not an empty, flashy buzzword. New technologies are the most popular ones. Software engineers love to be up to date with them. This means you will have more developers to choose from on the market, should you decide to expand your development team.

Every Product Owner of a legacy app knows just how difficult finding developers for an old language or framework can get. Apart from that, the more popular the technology, the better and larger the community around it. This means there’s more knowledge on how to deal with the bugs and problems developers stumble upon. This, in turn, means a faster app development process.

Read also: How to Speed Up Native Mobile App Development?

Avoid past mistakes

Provided that you have assembled a team of developers experienced in conducting large rewrites, the new development team will probably be able to refrain from making the same mistakes the previous developers did. For that to happen, you also need to be in full control of the business domain knowledge.

Read also: 6 Common Mistakes to Avoid when Developing a Mobile App

Refreshing the app design

App rewriting allows you to rethink the overall app design and modules, as well as its optimization. You have a great opportunity to revamp your User Journey Map and make sure that every step along the way is self-explanatory to the end-user. Remember that a well designed UX is one that needs no explanation.

Rethinking app features

You have a chance to verify whether your product solves users’ problems in the most effective way and decide what features it should really have. A rewrite is a perfect opportunity to do this, as you will probably revisit the User Journey Map or a similar document anyway.

Risks of rewriting an app from scratch

Benefits your competitors

Deciding on a complete rewrite without maintaining the old app at the same time is like giving your competitors a free year or two’s head start (for example, on building new features). That’s a lot of time from a business perspective. Entire companies have gone out of business due to such poor strategic planning.

Time-consuming

Time is a crucial resource that will be consumed during a rewrite. Some of it will be wasted unless it serves a purpose and solves critical problems. Along the rewriting process, some initially hidden business requirements will probably appear, and additional delays may happen.

Rewrites working features, too

A rewrite discards the parts of the application that worked as required. A rewrite demands that developers implement all of the features again. This is inevitable when the application gets rewritten in another language or framework, and it’s a strong point against rewriting when the product will continue to use the same technological stack.

So, when we are talking about rewriting applications using exactly the same technologies, even a piece of code that is perfectly fine will often have to be rewritten. Why? Because it likely does not fit into the new architecture. If we would leave such an old piece of code, we would immediately have to use some adapters so that the new architecture could use this old part. That is a red flag because the legacy code shouldn’t control the new architecture.

There are some exceptions – you can copy some mathematical algorithms, for example – but these are rare cases.

Wastes previous bug fixing

Previous efforts directed toward fixing bugs go to waste. The previous version of the project might have had a lot of expertise and development time devoted to fixing bugs. The developers might have been forced to work around issues deriving from the used technologies and frameworks alone. Some of the bugs in the app will always be connected to used libraries and architecture and wouldn’t show up otherwise. Undertaking a complete rewrite is as if all this effort was for naught.

Raises stakeholders expectations

You have to meet your organization’s expectations. Stakeholders from across the company will surely expect a return on investment when an application is to be rewritten. For example, it could be better UX/UI design, improvement in development speed, improved overall product performance, better app rating from the users, better user retention, or more new users in general. Product Owners have to manage these expectations. You’ll be the one to convince the stakeholders that the cake is worth the candle.

Let’s sum up the pros and cons of rewriting an app from scratch:

Pros and cons of rewriting

When would rewriting a legacy app be a mistake?

When a new team gets to see an inherited project code, it might often seem righteous to convince the client and start afresh. It so happens that it’s just not always the best possible option for the App Owner.

Moreover, rewriting an app with the same development team that produced the original version is seldom a good idea. Suppose the developers piled up too much technical debt due to various reasons (pressing deadlines, low skilled developers). If this were the sole reason, the company most definitely shouldn’t undertake a complete rewrite.

If the developers demand a rewrite decision solely in the hope of escaping the mess they are accountable for (among others), it suggests you lack reliable processes. Every App Owner should know that rewarding the team with a blank slate without taking the time to discover why these problems popped up in the first place, and possibly revamping the organizational processes, will likely lead to the same situation – creeping technical debt.

Even if you’re certain of having a great team of developers, a lot depends on the industry cycle of activity. You shouldn’t aim for a rewrite if there’s a lot of pressure from your competitors. Deciding for a complete rewrite means that releasing new features will come to a standstill for a long time.

Unless, of course, you have the time and resources to undertake a rewrite and maintain the current product version in parallel. If your business focuses on a specific niche in the market, your time to the market metric will be of utmost importance. In this case, you should harness all of your resources to make sure you will be able to secure the desired part of the market cake.

Do a background check on a potential development team for your app rewriting

As I’ve already mentioned, the crucial thing when it comes to rewriting an app from scratch is making sure that the designated team is able to live up to the expectations. Ideally, you’d like to get some insight into who the developers are, what their backgrounds are and a sense of their overall experience. You can either look for such details on professional social media, like LinkedIn, or developers’ private Github repositories.

If you decide to team up with a software development company, this becomes even easier. A company valuing transparency towards its clients will be willing to share some of these details with you. For example, you can get details about the projects in which the specific developers were involved or some metrics about client satisfaction.

Keep in mind that you might not be able to get the exact product names, as many of the projects are developed under strict non-disclosure agreements. Here, you can read an in-depth article about how to check a potential partner for your app development.

Projects that are to be rewritten come in many shapes and sizes. If you have a large, complex product, you’ll be far better off having hired a team of well-suited software engineers.

In the long run, it’s simply worth paying extra for experienced developers who have previously worked on projects with complex domains and large codebases. Such seasoned developers can lead you through the process of collecting business requirements themselves, asking you smart questions and therefore being able to quickly grasp the ins and outs of your business domain.

Make sure the team knows about your future plans and additional features

It’s agreed that this is not always feasible. Or at least not completely. That said, I’m not trying to convince anybody to go back to using the Waterfall model (which was a complete mistake for IT projects).

The thing is, if you…

  • know your domain from the business standpoint,
  • have even a vague product roadmap,
  • are able to grasp and lay an almost complete set of features out,
  • and maybe have some sort of a user journey map…

it will make things much easier for the developers and people responsible for choosing the right architectural patterns. The more you know about the planned product functionality upfront, the less convoluted the code will be in the future. Again, we’re not talking about the waterfall process but rather about the result of a well-conducted Product Design Workshop / Product Discovery.

More often than not, a software development agency will also offer a Product Design Workshop service. This is an ideal opportunity to convey your vision of the application and your requirements to the development team. A few days of these workshops will provide the team with enough knowledge for the months to come. Along with the software engineers, you can then try to trim the features to those few that are crucial for launching the application (Minimum Viable Product).

At the same time, the broader vision presented to the developers will already make them capable of planning the architecture. They will be able to structure it in a way that makes adding the new features virtually painless, drastically limiting the influence of legacy code in the future. What is legacy code, and why should it be feared? You can read more in our article focusing on the comparison of refactoring and rewriting the application.

The pros and cons of rewriting an app from scratch – conclusion

As tempting as it may seem to developers and Product Owners alike, rewriting an app from scratch is not always the best option from a business perspective. As a Product Owner, you have to take numerous factors into consideration to make sure that this is what your organization needs to thrive. Get a Free Ebook – Product Owner Guide.

Should you, based on this guide, decide that rewriting is the way to go, keep in mind that there are still a lot of caveats to consider ahead. First and foremost, you have to be sure that you are relying on a team of seasoned developers for whom this isn’t their first rodeo.

The chances of succeeding in a complex application rewrite soar in direct proportion to the experience of developers, and just how good of a team they create. Apart from that, make sure to do everything to convey your vision of the app to them. The better the team understands the business domain, the better and more efficient their work will be in the long run.

The post The Pros and Cons of Rewriting an App From Scratch | App Owners Guide appeared first on Droids On Roids.

]]>
https://www.thedroidsonroids.com/blog/pros-and-cons-of-rewriting-app-from-scratch/feed 0
Refining the Widgets Layer with Provider | How to Develop an App with Flutter – Part 6 https://www.thedroidsonroids.com/blog/refining-widgets-layer-with-provider-develop-app-with-flutter https://www.thedroidsonroids.com/blog/refining-widgets-layer-with-provider-develop-app-with-flutter#disqus_thread Tue, 01 Sep 2020 10:18:15 +0000 https://www.thedroidsonroids.com/?p=29047 Learn how to develop your first Flutter app. This time, we will focus on refining widgets layer with the provider package.

The post Refining the Widgets Layer with Provider | How to Develop an App with Flutter – Part 6 appeared first on Droids On Roids.

]]>

This article is a part of the 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 – you are reading this
  7. Internationalizing and Localizing your Flutter App

What’s more, we’ve also prepared a Roadmap that can be useful in your Flutter development journey:

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 build your first Flutter app.

Problem and solution, right away!

As we know, Flutter’s UI is declarative. We go down the widget tree and we get to know the view’s structure. This includes the parameters of particular widgets, the declared business logic, and even application logic! The basic problem in Flutter app development I’ve dealt with is that business logic tends to mix with application logic. It makes widgets hard to read in its structure and has too many responsibilities.

Because all of this, it’s also hard to test the application. That’s why, at the beginning of every project as well as when we’re getting to know about the project’s functional requirements (Product Discovery), it is the first problem that we have to deal with. In this part of our series, we will show one of the possible solutions.

We will split the business logic from the application logic with the tool recommended by Google, which is the provider package made by rrousselGit.

What is business logic and application logic? Let’s explain briefly!

At first, it will be worth briefly reminding ourselves what business logic is, as well as application logic, and why we should have as little application logic as possible contained in our widgets.

Business logic defines tasks that need to be done but doesn’t present exact implementation.

Application logic is the implementation.

One of the simplest examples of business logic can be Dart’s abstract class. This class defines WHAT will be achieved by implementing this abstract. The code within the designated methods and variables is indeed application logic, which specifies HOW the task will be done.

The widgets layer as a neat interface for developers

And now we can answer why widgets should contain as little application logic as possible. Widgets are the highest layer in Flutter application, while down below we have Elements and RenderObjects. On a daily basis, a Flutter developer will mostly deal with the widgets layer, which is an easy to read interface that tells us what could be displayed on-screen and which components we can interact with.

In the widgets layer, we will not see how Flutter’s framework plans its next animation frames, how it will refresh the Elements’ tree or even how RenderObjects will be drawn on the screen. Widgets because of which layers are placed in should be only blueprints of the application flow, which don’t define concrete implementation, so they need to only implement business logic.

Of course, achieving such a complete extraction of the application logic in the widgets layer is hard and expensive. However, we should always try to reach this state. With this brief explanation finished, we can move to the main part of the article.

Let’s introduce the provider package!

The provider is a package created by rrousselGit. It is recommended by Google as a component for simple app state management used in Flutter. Previously, they’ve been recommending BLoC pattern. Here is the most popular package made by felangel. Provideris a convenient wrapper on InheritedWidget, which significantly improves work with the data that we transfer through widgets’ trees.

In my opinion, the most important feature of this component is the unified initialization and the ability to retrieve data from InheritedWidget. Every developer should take into account that what he has written can be used by another developer and, hence, the code should be at some level written in commonly used and respected standards.

Clean code is also a well-known code. That is why we create our projects with already battle-tested architectures, as well as design patterns, and stick to code standards such as the Effective Dart style guide.

How does provider work?

Now I will describe the provider‘s flow. If you prefer documentation, just get in there buddy and you can skip this paragraph. We place provider(as a subclass of InheritedWidget) in the widget tree and declare an object that will be provided. In the next step, we just retrieve the provided object from the context with a few context extension methods defined by the package. With these methods, we can refresh the view only when the desired field of observable object changes.

Let’s get to the code!

As we already know how to use the provider and what it is, we can introduce it to our Smoge application.

I’ve previously mentioned adhering to standards. Besides the standards that are present in many projects, we also create those that we keep internally. The development team creates such rules. The provider package establishes initialization and data retrieving policies. We, as developers, need to figure out a way to integrate providers and observable models with our application.

We need building blocks, first: ProviderModel

Let’s begin with the model that needs to be injected into the provider. As the PollutionRestRepository launches requests to GIOŚ (Chief Inspectorate of Environmental Protection) API, our provider needs to inform it about the result of a particular request. This is why we need a model that is capable of indicating a change in the value that we observe. In this case, our model needs to extend the ChangeNotifier class.

The class’s name is ProviderModel. This is a generic class containing a data object. The constructor initializes this data object with the initial value.

Provider‘s ChangeNotifierProvider and ProviderWidget

If we use ProviderModel, which extends ChangeNotifier, ourprovider should be able to handle such a subclass. That is why we need aprovider that will trigger tree rebuild when the model indicates change. ChangeNotifierProvider created by theprovider package should do the work. Here, I’ve placed a widget into ProviderWidget.

This class is also generic and it is initialized with a child and function that returns theprovider model of the type declared in ProviderWidget class. In the build function, we return the mentioned ChangeNotifierProvider. Even though the lazy parameter is set to true by default, I just wanted to show this feature of provider, which initializes only when it is needed.

Because the BuildContext parameter in the build function returns the context of the previous widget, we have to be sure that the injected provider will be available from the child level. We’ve wrapped the provider’s child with Builder. Thanks to Builder, the child will be able to get the provider from context because the provider will already be below the created tree. Now we can easily wrap widgets that need provider.

PollutionProviderModelState

Let’s define a data object that will contain pollution data and will be handled by the implementation ofProviderModel. I have named it PollutionProviderModelState.

As we can see, it has fields that represent the results of requests defined in PollutionRestRepository. Every field is a type of extended result class, ProviderModelAsyncResult.

This class will allow us to control the asynchronous status of setting the nested result field and it will inform the provider about the change of a particular field from PollutionProviderModelState. Everything will be handled by a set() method that gets a Future object. It contains the Result to be handled and callback of data change.

PollutionProviderModel

The next class is the implementation of ProviderModel, which takes care of pollution data handling from PollutionRepository. It is PollutionProviderModel.

PollutionProviderModel extends ProviderModel with the PollutionProviderModelState type, which is an observable object of our ProviderModel. PollutionProviderModel contains methods that set particular fields of PollutionProviderModelState using data downloaded from object implementing PollutionRepository.

Each method invokes set() method of particular ProviderModelAsyncResult variables in PollutionProviderModelState. We get result from the repository and the callback is the notifyListeners method that originates from ChangeNotifier. Method notifyListeners calls all registered listeners about the possible change and can result in rebuilding the widgets’ tree.

Putting them together!

As we already know all of the components, we can finally add provider to the HomePage. The HomePage is initialized in NavigationContainer. Let’s wrap HomePage with ProviderWidget of the type PollutionProviderModel.

In create function, we return a build() constructor of PollutionProviderModel that injects PollutionRestRepository, which was previously placed directly in the HomePage. Now, after retrieving the provider from the context, we will be able to interact with it. I’ve changed the _buildStationName method and now it looks like this.

In the beginning, we use the BuildContext extension method, selected in order to observe changes of a particular field of ProviderModel. The widget tree gets rebuilt if an observable variable changes. Thanks to this, we can control the whole asynchronous process of downloading data from PollutionRestRepository. Observable value is of the ProviderModelAsyncResult<PollutionStation> type. If the result doesn’t contain any data, we display CircularProgressIndicator. After retrieving the data, we basically unwrap the results and display a station name or error description.

Now we have the last thing to do. We have to trigger the station name request. Flutter documentation recommends invoking any of InheritedWidgets’ methods in didChangeDependencies function, as this is the first method invoked after initState. Just for reminder’s sake, we cannot invoke BuildContext.dependOnInheritedWidgetOfExactType within the initState method.

As you can see, we’re making sure that our injected provider will be invoked only once.

Finally, results … kind of!

Let’s run the app. As you see, nothing changed. Maybe end users will not be amazed by our changes but the developer will surely be happy to see downloading pollution data logic extracted from the widget layer. The HomePage only gets information about the operation’s result and doesn’t know about any required dependencies to accomplish this task. The widget only knows what to display.

The purpose

Separating business logic from application logic is a common practice in programming, especially in commercial development. The more complex a project is, the more we benefit from this approach.

In the Smoge app, we could of course ignore these practices and make it the easiest way because we will not release this app and will not get profit from it. However, the main purpose of this blog post series is to show you how to write commercial apps that have to be easy to maintain and readable for the whole app development team.

Stay tuned for the next article in this series, it will be about writing automated tests. In the meantime, check out in10 – RSVP & ETA Tracking App which we made with Flutter.

The post Refining the Widgets Layer with Provider | How to Develop an App with Flutter – Part 6 appeared first on Droids On Roids.

]]>
https://www.thedroidsonroids.com/blog/refining-widgets-layer-with-provider-develop-app-with-flutter/feed 0
Refactoring vs Rewriting a Mobile App from Scratch – Comparison for App Owners https://www.thedroidsonroids.com/blog/refactor-vs-rewrite-mobile-app https://www.thedroidsonroids.com/blog/refactor-vs-rewrite-mobile-app#disqus_thread Mon, 17 Aug 2020 12:47:26 +0000 https://www.thedroidsonroids.com/?p=28774 Rewrite or Refactor? When is it worth to refactor your app and when it's better to rewrite it from scratch? The comparison for App Owners.

The post Refactoring vs Rewriting a Mobile App from Scratch – Comparison for App Owners appeared first on Droids On Roids.

]]>
Software engineering projects, as volatile in nature as they are, are necessary for releasing whole systems and delivering your product to end-users. They are the beasts every Product Owner has to try to tame.

During their lifetime, projects change developers and even whole teams. This is why, sometime in the future, it’s possible you are presented with a simple choice, yet one with far-reaching consequences: should I decide to rewrite or refactor the existing software?

What is project refactoring?

You might have stumbled upon the notion of code refactoring. There are numerous definitions with varying levels of complexity, usually directed to people with different technical knowledge and command of skills. From this point onward, we will talk about the most basic one and not delve into technical details too much.

So, what does it mean to refactor the whole project? Refactoring basically means to restructure the existing project functionality in order to make the future updates easier. This can include using newer versions of third-party libraries and technologies, as well as lowering the overall code complexity level. Small parts of the functionality can be rewritten but, mostly, it will involve tailoring the system functions one by one so that these features adhere to the new architectural approach.

A common misconception is that refactoring has a defined end, after reaching which the app will magically be well-structured and ready for effortless implementation in the future. In fact, refactoring is a development technique, not a project.1

Normally, we should differentiate the notions of code refactoring and a “massive cleanup effort”. For the sake of simplicity, I’ll cling to this informal terminology and use the word “refactoring” to define a big process launched upon receiving a poor quality codebase when, for some reason, the code shouldn’t or wouldn’t be rewritten from scratch.

What is project rewriting?

On the other hand, the rewriting process of a project means what you might have guessed – rewriting the code from scratch. During a rewrite, the coding process basically starts anew. The main advantage of rewriting is that the developers will not be in any way limited by the existing code. It is then easier to use more up-to-date technologies.

Contrary to refactoring, rewriting an app gives the development team a clean slate. There’s no inherited legacy code to work with anymore, whereas the app refactoring will most likely leave some of it. This is why most developers will encourage project rewriting instead of refactoring. Let’s sum up:

Code refactoring vs rewriting

Why is it necessary to decide either refactoring or rewriting?

At first glance, it may not make sense to make such a decision from a financial standpoint. But play the initial scenario out:

Your app went public and the recorded crash rate statistics are looking good. Users are quite pleased with how the app works but would like to get new features. Your app is now running on tens of thousands of mobile devices across the world. After another period of healthy, organic growth, the stakeholders decided it’s high time to introduce a new feature to the app. They believe it will have a huge impact on app usability and user experience. It makes perfect sense to add this new feature. Unfortunately, the company who has previously been responsible for delivering an implementation is either no longer there, is unavailable for more work at this time, or, for some reason, you were not happy with their work.

As a Product Owner tasked with searching for a suitable development team to continue working on your product, you have probably been advised to rewrite the app numerous times. Does it even make any sense? Isn’t the company just trying to rip you off and secure a potentially longer-lasting contract at the same time? In what way can it possibly benefit your company and the existing product? This and many other perfectly reasonable questions come to mind.

In fact, the reasons to consider a “start from scratch” or a large refactoring effort aren’t scarce at all. Perhaps the newly requested features are incompatible with the existing architecture? Maybe the codebase is simply a mess but your team inherited the project instead and are now the ones responsible for it? You might find some of these problems relatable but precise problem definition is not what matters for making a point here. What does matters is that you are dealing with legacy code and that you can be sure this legacy code will seriously hamper the development process at some point. It can manifest itself in the following impediments:

  • The developers gradually grow tired and unmotivated from having to work on a deteriorating codebase where things might easily break.
  • The new features rollout tempo slows down quite a lot due to technical debt, ultimately rendering the code impossible to work with. New features take too long and cost too much because of the interdependence of the codebase (new features cannot be isolated, and therefore affect existing features).
  • The app is more and more buggy and unstable, resulting in outraged users and, in turn, very low app ratings and possibly even poor user retention.

To sum up:

Risks of legacy codeWhat is legacy code and why does it even exist?

First of all, let’s make sure we use a common definition. Legacy code isn’t necessarily a means of describing something broken or buggy. It usually means the software is still operational and serves its purpose for the most part. Some bugs might be there but they are far and between. Legacy code might simply mean the software is built around a somewhat obsolete ecosystem or using out of date techniques. Thus, the software might not be easily modifiable to feature new business requirements. Legacy code starts to creep in for a few main reasons:

  • Missingor low-quality tests. Every developer is reluctant to introduce changes in a complicated codebase for fear of breaking something and ultimately making things worse. The risk of breaking things becomes increasingly large as the system gains new intertwined functionality.
  • Neglected regular maintenance. Usually, code doesn’t get taken care of properly because it’s difficult to get it running or because it’s become so complicated that it gets hard to work with. The two main reasons for the codebase quality deteriorating are low separation of concerns and introducing numerous quick fixes and special cases unaccounted for during architecture planning.
  • Source code is no longer accessible. Companies sometimes lose access to the source code of a vital program over time. The end result is that there’s a system in production that can’t be changed because there’s no code. That part of a system can either be treated as a “black box” and worked around in upcoming special cases, or it can be rewritten.
  • Pressing deadlines. Many developers don’t feel confident, even in their backyard, if they are pressed onto with tight deadlines. There’s really no time to properly manage code quality. Over time the technical debt gets so large it interferes with adding new features, gradually paralyzing the whole project. It’s crucial for the developer to take the matter in their own hands and inform the management that their way of doing things will eventually be harmful to the project.

“A software group starts writing a piece of software and they’re productive at it. Over the course of time, as they hustle to get features out the door, they make a mess, always vowing to clean it up later when they have the time. But, they never have the time because, with every delivery cycle, they’re able to ship fewer things because of all the problems that have developed in the code. Eventually, features slow to a crawl, and developers are increasingly miserable.” – Erik Dietrich.

Pros and cons of refactoring an app

The most noteworthy advantages of code refactoring:

  • You can take things slowly and as separate problems, one small piece at a time. This is immensely helpful in terms of preserving app stability.
  • If you abandon the process partway through, you will still benefit from it in terms of a cleaner codebase. Contrary to refactoring, a rewrite must be completed to offer any expected benefits.
  • Updates can often be shipped to users in milestones, rather than all at once a fair amount of time later. It’s possible to continue to deliver updates (not just bug fixes) to the users while still seriously improving the system codebase.
  • Any new features and bug fixes can be thoroughly tested regressively against the existing application.
  • A current project will have had its business rules refined with countless hours of actual user feedback, bug fixing, and regressive testing.

Disadvantages of app refactoring:

  • In refactoring it is harder, or most of the time impossible, to change technologies or frameworks.
  • While refactoring can improve a piece of code, it cannot easily fix underlying architecture problems.
  • One of the biggest challenges of refactoring is that, after doing the modifications, the system should meet the exact same business requirements as before. Therefore, refactoring usually involves a high amount of testing and debugging, further increasing the overall costs of such an operation.
  • Refactoring usually doesn’t involve a completely new stack of technologies. Thus, it might prove to be harder to find motivated developers to do it.

Pros and cons of rewriting an app

Deciding to rewrite an app from scratch comes with several useful perks. Advantages of rewriting the app from scratch are:

  • Learning from past mistakes and drawing conclusions. Rewriting the app from scratch, you usually redesign the app based on past experience. There’s a good chance that, if you have experienced developers – and you also have good command of the business requirements – your team will be able to avoid many of the pitfalls and mistakes made by the previous developers and create easily maintainable code. At the end of the day, it will speed you your future app development and maintenance.
  • Rewriting code from scratch can open new market opportunities, such as new users, markets, platforms, and technologies. Rewrites eliminate the unavoidable headache of attempting to adjust the old code to meet the demand for new technologies and business requirements.
  • Removing unmaintainable legacy code. Debugging or changing hard-to-maintain/unmaintainable legacy code may seriously slow your app development down. Rewriting the app from scratch is a perfect chance to remove these parts of code.
  • A new start. Developers get a clean slate. They can use new, yet critically-acclaimed technologies and frameworks. A fresh start like this makes the project motivating and positively influences productivity and overall product quality.

On the other hand, rewriting a project can pose severe problems. Disadvantages of rewriting an app from scratch are:

  • If you do only rewriting, without refactoring the existing app, users don’t get frequent updates and, consequently, user retention might get to the lowest levels
  • Deciding for a complete rewrite without maintaining the old app at the same time is like giving your competitors a free year or two of a head start, for example on new features. In software development, that’s a lot and entire companies have gone out of business due to poor strategic planning.
  • A rewrite must be completed to offer any expected benefits. Releasing an app that has smaller functionality may annoy your users and is a major setback.
  • The developer’s capacity devoted to rewriting isn’t used to support the customer, unless there are two projects held in parallel.

Read also a more detailed article about The Pros and Cons of Rewriting an App from Scratch.

When to refactor an app?

“We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand.”- Joel Spolsky

Many developers will no doubt agree with the above quote from Joel Spolsky.2 Being over 20 years old, the words have lost none of their relevance, rather the contrary. At the same time, a responsible developer will always take into account what’s best for the client’s business. A working and published product, alongside a glad client, makes up for a far greater dose of satisfaction than a product being rewritten many times and not being released as a result.

When to rewrite an app?

If refactoring the app seems to be the best solution for most of the cases, what are some legitimate reasons for deciding if an app should be rewritten? Let’s look at a few of them. You can consider rewriting an app if:

  • The current state of the code is trivial in nature and you are planning a fundamental change in the project’s architecture anyway.
  • The original project’s source code has been lost and it’s either impossible or not worth undertaking a complete recovery.
  • The vast majority of business requirements and use cases encapsulated in the original product are no longer viable or used.
  • There are very few active users of the app
  • You have some form of business rules documentation or you’ve decided to maintain the old application and develop the old and the new app in parallel
  • The technology is prehistoric and it’s getting increasingly harder to get good developers for it. If a technology is old, there are quite good chances it will have less and less proficient developers, thus making them harder to acquire and significantly more expensive.
  • The code has been inherited by a new company, it’s lacking documentation and the code is so convoluted that it renders the project impossible to work with. If the coupling of components in the code is at a very high level, chances are that changes to any single module cannot be fully isolated from other components. Therefore, a refactoring of a single component would result in a cascade of changes not only to adjacent components, but also other components scattered across the whole system.

To sum up:

App rewriting vs refactor

What is the cost of refactoring vs. rewriting an app from scratch?

Keep in mind that the total cost of redesigning incrementally is, in the long run, almost always higher than doing a complete rewrite, but the impact on the organization and the active users is certainly smaller. The cost of refactoring can be significantly smaller if there’s not really much to be done and the app can get by on minimal amounts of maintenance. If the app will not have many more features to be added in the future and can get easily get by with the current levels of stability, then going for a rewrite is a potentially catastrophic strategic mistake. If that’s not the case and you can justify and defend a rewrite, and you trustworthy developers, then do it.

It’’s important you have the vision of the app in the long run. Do you expect the app to be thriving in the market for years to come? It might make more sense to go with a rewrite instead of refactoring for now and then, in the future, being forced to rewrite anyway. It’s just the sunken cost of refactoring in this latter case.

Generally, the cost of rewriting the application and temporarily maintaining the rewritten application is less than the cost of maintaining the current system over time.

On the other hand, there’s an important implicit cost to rewriting an application. In the time you devoted to a full rewrite, your competitors might have just won an edge advantage over you, updating their solutions with better user experience or a new, highly anticipated feature. Therefore, there’s really no universal answer – each case has to be analyzed separately, preferably with mobile experts.

The takeaways

Projects developed and maintained over long periods of time usually eventually enforce the decision: whether to refactor or rewrite the app. Keep in mind that a mere time frame and some intuition are not an appropriate measure of such a drastic decision to scrap an app or rather refactor it. You must have clear, defensible, and well-understood reasons to take on this course of action.

Don’t think in absolutes for refactoring vs. rewriting code.

Moreover, you should make sure you have a mature team of developers who are willing to put themselves in your shoes. You need the kind of people that won’t just unequivocally push towards a complete rewrite for their own, temporary comfort.

The post Refactoring vs Rewriting a Mobile App from Scratch – Comparison for App Owners appeared first on Droids On Roids.

]]>
https://www.thedroidsonroids.com/blog/refactor-vs-rewrite-mobile-app/feed 0