The pain of publishing Electron apps on macOS

Starting with Mojave 10.14, Apple has introduced serious changes in app publication. They are about signing and notarizing the apps. If your application is bad in the eyes of Apple, final users will see threatening messages upon the first launch. The messages would ask the users to delete the app, which is not really good for customers, right?

This is the 2nd part of the two-part article on signing and notarizing macOS Electron apps. You can find the 1st part here.

The author is an ElectronJS app developer himself, Around a year ago, faced the problem of having to notarize the app on Apple servers besides signing it. It means that you check whether the app has malware in it.

To notarize, you have to send the app, wait for 10 minutes tops, get your results, and be happy. For those who are not proficient in it, there is an article on our website. There we discuss basic concepts of publishing apps to macOS.

I began notarizing my apps and kept getting the Package Approved notification over and over and was pretty happy about it, until recently, when I noticed that the situation repeats itself. All right, I thought, let’s just notarize it once again. 

In the end, the status had over 9000 authorization errors. Invalid certificate for some files, absence of hardened runtime even an absence of executable library files from NPM.

Sounds scary, doesn’t it? That’s right, Apple is making their system tighter, more secure, and doesn’t allow publishing a threatening, from their PoV, application.

I started discovering solutions. In the end, I was able to solve the problems and understand the rules of the game with Apple deeper. Actually, there are solutions in the internet but they are spread too wide. I’ve spent a considerable amount of time amassing experience in the field and now am willing to share it with my fellow developers so that their Electron apps are notarized faster.

I faced these problems when the app was using the ElectronJS library 5.0.0. I used electron-packager 13.1.1 to build an app and exelctron-osx-sign 0.4.15 to sign it.

To sign an app, we have a certificate Developer ID Application: <TeamName> (<UniqueID>) on the Apple site. A certificate like this allows releasing apps through any online service. We use the release server Electron to do that. You are going to need another certificate to publish apps to Mac App Store.

So where’s the pain?

In errors. I’ve split all of them into subparts and showed the solution which will make you more successful in the matter. 

What Apple doesn’t like

The binary is not signed. Absence of certificates and timestamps for internal executable files

The notarization log from Apple for many internal app files had The binary is not signed error. Every executable file was a part of this, for instance, built FFmpeg and echopring-codegen libraries. which are used externally by the app. Some executable files from NPM libraries were there, too.

The solution here is simple. While signing apps, it’s important to sign all files that Apple doesn’t like with this certificate, not just the .app one.

If you use a codesign utility, it’s mandatory to list those files with a space. Use the electron-osx-sign library, activate binaries to create paths to binary files that need to be signed with this certificate.

It’s worth mentioning that this solution is also usable for The signature does not include a secure timestamp error. It’s because the certificate puts its own timestamp while signing a file.

The signature of the binary is invalid. Wrong routes in the general hierarchy of an Electron app

This error is, in my opinion. an Apple mistake. Whenever an .app file is sent to notarization, it automatically  is packed into a .zip archive. Because of that the hierarchy of some paths corrupts, thus the certificate becomes invalid for some files.

The solution is packing the file by yourself into the .zip archive, using the integrated utility ditto. It’s important to use a special flag – -keepParent, which allows saving the hierarchy of all paths during packing. So, this is the command I used for packing:

ditto -c -k –keepParent “<APP_NAME>.app” “<APP_NAME>.zip”

After this, you can send the archive to notarization.

I use electron-notarize for notarization. When the notarization is successful, the library tries to return an archive of the app, so that you unpack it and swap an .app file with a notarized .app file. However, please note that XCode spectool can’t work with archives.

The executable does not have the hardened runtime enabled.

Now let’s discuss the most difficult and interesting notarization problem. In the latest macOS versions (10.15 Catalina and 11.0 Big Sur), Apple requires that the hardened runtime is enabled to launch apps. It protects the app from malware injections, DLL attacks, and process memory space tampering. Apple wishes to protect their users, therefore this is an important requirement.

To go with this requirement, you have to use a flag –options=runtime if codesign is used or mention a field hardenedRuntime: true if you’re going with electron-osx-sign. So, I took this action and found out that using this flag completely breaks an Electron app: it either doesn’t launch or fails with a system error.

One way or another, after having spent lots of time googling, I found a set of requirements. Completing those requirements helps building in building and signing an Electron app with hardened runtime

How to build and sign an Electron app?

First of all, forget about Electron v. 5

As sad as it may sound, you have to forget about Electron v. 5 and update it to v. 6 at the very least. As the source says, hardened runtime support was introduced in Electron v. 6, so any attempts to enable it in the predecessor are doomed to fail. Besides, if you’re using electron-packager, you must update it to v. 14.0.4 for the apps to be build correctly.

Testers will probably not be happy to hear about it but there’s so much we can do. Apple sets the rules of the game, and it will be necessary to complete a full regression test of the app with a newer Electron version.

Second, create a parameter file entitlements.plist

This practice often comes in handy when creating apps in XCode entironment, but when it comes to Electron apps – not so much. Electron builder will automatically enable a deafult file with a standard parameter set. The file is an XML code and it lists system prohibitions and permissions on using different resources of the OS. This file now has to contain 2 important parameters.

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “”>
<plist version=”1.0″>



The first one, allow-unsigned-executable-memory, allows the app using raw memory. The second one, allow-dyid-environment-variables, allows using environment variables. Every JS developer knows what they are, but these variables are not exactly the same as those we use in the app. This parameter permits the Electron framework using the environment variables he needs for correct work. For example, a path to the system library libffmpeg.dylib. If this parameter isn’t in the file entitlements.plist, the app will fail on the first launch, and will show an error of that library not being where it’s supposed to, despite it actually being there.

Third, activate entitlements.plist correctly

The file must be connected during signing a built Electron app with a certificate. If you’re using codesign directly, type in a flag –entitlements, then space, then show the path to the parameter file. However, it might not work right away, and codesign will have an error unrecognized option for that flag. To deal with it, use the utility codesign not from XCode Developer Tools but from the full XCode environment with a more expanded version of the utility. Run these commands to do that:

xcode-select -print-path
xcode-select -switch /path/to/SDK

There is a simpler way, too: use electron-osx-sign. However, it’s important to note that you have to enable the parameter file in entitlements and entitlements-inherit fields, otherwise nothing will work. It’s because entitlements-inherit is responsible for the parameters mentioned for distributive frameworks, and our app actually does work on Electron framework. This framework needs environment variables with paths to system files.

Easier now?

If you develop desktop apps for macOS on XCode, you likely won’t face these issues. Apple adapts its environment rapidly. However, as it turns out, Electron apps are out there, too. It’s possible to take care of the notarization problems, and the users can be absolutely happy without seeing the warning about potentially dangerous software.

I hope that this article was useful to you. If you have any other questions on the topic, do not hesitate to contact us via the contact form!

We have also launched Instagram, so feel free to check us out there, too 🙂


How to Publish Desktop Apps on macOS? Ultimate Guide


Developing a program code always brings joy. You get the instant outcome, you may check it out and see how neat the user experience is.

However, there are some formalities that act as a buzzkill here. Some of them are about publishing an app. Windows and macOS protect their users from malicious software, therefore publishing anything and everything isn’t possible. It’s imperative that the OS knows that the software comes from the trusted developer (signing), and its code doesn’t contain threats to the user (notarizing). Windows has only signing requirements, while Apple has been checking notarization since the macOS 10.14 Mojave was released.

This article came about after having to face some troubles while publishing an ElectronJS-app for macOS, and I would like to share my experience. We will begin with some starting information. If you’ve already developed and published ElectronJS-apps, feel free to skip through this part and we will see you when the more interesting one comes out – in a week or two 🙂

A short introduction to ElectronJS

ElectronJS is a tool to easily create a cross-platform app to launch it on all popular operational systems. The library uses the Chrome V8 engine and emulates a different browser window, where you can apply your HTML code, written with ReactJS. Electron uses its own backend to interact with an operational system, for example, to show system windows. Communication between what the user sees on the screen and the Electron backend happens with events.

Building an application is also fairly simple. Electron daughter libraries are in charge here, such as electron-builder, electron-packager. As an outcome, we have a ready binary file – .exe for Windows, .app for macOS, or executive binary file for Linux

You wrote and built an app. Ready to publish and send to the customer?

Unfortunately, not. For the users to launch an app, a developer certificate is necessary. This is a so-called digital signature of the app. It protects the program by mentioning who the author is. Apps with digital signatures are verified and are less-provocative to the system, antivirus programs, and firewalls. Software like that rarely ends up in quarantine.

If the app isn’t signed, macOS will politely ask to move the file to the bin.

macos notification unverified app
MacOS user warning about unverified apps

Windows will notify the user that the developer is unknown and you’re at risk.

Windows notification unverified app
Window user warning about unverified apps

Do not scare your user with these messages, better go and get that developer certificate! Add it to the keychain of the OS you are making a signature for. Later, use the certificate to sign the app. XCode Developer Tools on macOS provides codesign to do that. Electron-builder and electron-packager libraries supply you with their wraps to sign an app. You just have to let them know that you’re willing to sign an app with that particular name after the building is completed. More than that, macOS has one more way to do so: a separate wrap library electron-osx-sign.

Got the certificate, signed the app. Anything else?

Yep. Notarizing is the next step. It means that you have to check the code on the Apple servers to verify that there is no malware in it. Otherwise, the user will see this upon the first launch:

MacOS notification for non-notarizated
MacOS user warning for non-notarizated applications can scare users away

To send an app for notarization, Apple ID is necessary. That’s your login email to and an Apple ID password from

XCode altool provides utility for notarization. Unfortunately, it’s not in the XCode Developer Tools pack, so we have to install the full XCode. That moment when you don’t use XCode, like, ever, but you need it so you kiss goodbye to around 30 Gb of memory 🙂

We send the application using the command:

xcrun altool --notarize-app --primary-bundle-id "<id>" -u "<appleid>" -p "<app-specific password>"

Anything works as primary-bundle-id. It doesn’t affect notarization at all. For instance, mention com.electron.<appName>.

Notarization takes about 5-10 minutes. Apple will give you a unique RequestUUID. Use it to check on your notarization status. For that, use the command:

xcrun altool --notarization-info <RequestUUID> -u "<appleid>" -p "<app-specific password>"

The whole history can be checked with:

xcrun altool --notarization-history -u "<appleid>" -p "<app-specific password>"

Electron developers have expanded electron-builder and electron-packager libraries by adding a notarization process into the general workflow. There is also a separate wrap library electron-notarize which does exactly the same things. Basically, you need for things ready: built and signed .app application, appleId, appleIdPassword, appBundleId.

If a notarization tool doesn’t stumble upon anything bad in the app, your status will turn to Package Approved with a status code 0. Otherwise, Apple will give you the Package Invalid status and a status code 2. Fear not, friends, as every “bad” notarization has a log attached. All problems are mentioned there, as well as the directories of the files that stopped you from publishing right away.

If notarization is successful, congratulations! You’re ready to release your app.

When you have that last piece of the jigsaw, everything will, I hope, be clear (Albus Dumbledore)

When starting developing a desktop app on ElectronJS, think about the certificate to sign the app in advance. Don’t forget about the notarization, either. If you skip these parts, the potential amount of software users will drastically reduce because of conflicts with an operational system.

The 2nd part of this text will be released soon, and it will touch on the problems one might face when notarizing an app on macOS. See you then!


How to make work atmosphere friendlier?

There is no right answer to that question. However, the Fora Soft team is willing to share our knowledge with you. The knowledge that we have been nurturing for several years.

We also provide some COVID-era solutions, so make sure to check them out, too!

Make communication between employees less formal

When there are no barriers that formal communication brings, it’s easier for your team members to share things about their problems and say their opinion on things during Scrum meetings.

We tend to demolish those barriers with the help of monthly office parties with a ton of pizza involved. Formality becomes a difficult concept to maintain when you are sitting at the same table consuming that saucy pizza 🙂

Как сделать так, чтобы в коллективе было комфортно работать, image #1
Doesn’t look too formal, does it? 🙂

Fun fact: it’s easier for people to start a dialog after they’ve established a visual contact, hence our choice of food. To get a bite of that delicious thing, you just have to hold the slice near to your face. Thus, we do not only have a great time eating pizza during the working day but also improve the working atmosphere.

In COVID times, we meet in Zoom instead, but weekly, not monthly. 

Make your workspaces comfortable

Place them so that there is a distance of 1,5-2 meters between employees. That way the coworkers will find themselves within each other’s social distance. Read more about proxemics, the study of human use of space, on Wikipedia.

Comfortable distance between workstations allows employees to be open for discussion while still having enough private space around.

There is no correct way of setting devices, it all comes down to personal preferences. Your task as a manager is to give your team the furniture that they can easily adjust.

Эти довольные лица говорят сами за себя!
These happy faces speak for themselves!

In COVID times, we work remotely. Each project team meets in a video call daily to compensate for the lack of communication. Effectiveness has even improved – we now talk more.

Lower distance between the boss and the team

In some companies, the boss doesn’t get enough trust and may even be feared by employees instead of respected. To make the relationship less formal, our CEO goes around the office and greets every and each employee face-to-face.

He can do this all day

We also have an Open Door principle: if the CEO’s door is open, you can come into his office and rap with him about life ask some questions, or suggest a way to improve the processes in the company.

In COVID times, it’s Open Skype principle instead 🙂 (poor CEO)

Be clear about the company’s / project’s aims

Every member of a project team needs to know where the project or the company is going. It helps them plan their development and stay updated on perspectives.

In Fora Soft project members discuss upcoming features, their feasibility, and possible improvements together in a comfortable conference Skype room. In COVID, we do that on daily video meetings.

Тут зарождаются легенды
Legends are born here

The company’s aims for the year are announced at the New Year’s party and monthly objectives are hanging in the dining room, which is – no surprise here! – the most visited venue in our office. In COVID, the CEO shares company’s aims at Thursday’s general company video meetings on Zoom. We post recordings on Instagram – catch a moment to see 🙂 They are in Russian, but you can feel the atmosphere.

That’s all, folks! Feel free to use our methods to establish a great working relationship with your colleagues! If you have any other questions on the topic or just wishing to share your secrets, don’t hesitate to contact us via the Contact form!


Why cut features and launch the product early or what is MVP?

Many of our customers come up to us asking if we could make an MVP for them. Yep. Even big corporate clients want what used to be a startup fad — and what is now an industry standard.

But what is an MVP? The abbreviation, standing for Minimal Viable Product, is used to imply you hit the market before you’re done with all the features. Why is it that popular then? Is it a fancy way of saying “whatever works is fine”, a bargain solution for low-budget projects… or a misused football term after all?

What is an MVP?

Speaking of minimal viable products, let’s get started with setting on the viability criteria. For a software piece, viability definition may lie within the range of “not crashing on launch” to “being able to compete against the leaders”. 

Within the Lean Production Methodology, where the MVP concept originated, V stands for “bringing value to the user”. That’s why they often read MVP as Minimal Valuable Product.

The MVP is the right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction, and sales, but not so big as to be bloated and risky. Technically, it is the product with maximum ROI divided by risk. The MVP is determined by revenue-weighting major features across your most relevant customers, not aggregating all requests for all features from all customers

Frank Robinson, the author of the term

So, MVP is basically a killer feature, and the simplest buttons and handles one might need to make use of it. You cut all the bells and whistles off your concept, strip it of all the fancy design extras, and anything that is not crucial – as simple as that.

Why would you go for an MVP?

Here’s an example. Imagine you’re a fan of a particular sport — let’s say, boxing. And you want to become the new Muhammad Ali. So, you start training with all the passion and dedication and whatever else you may find in movies about Rocky Balboa. The question is: when will you take on your first fight?

Option one. You train for ages until you feel like you are two hundred percent fit and ready.

Option two. You get some pretty basic training and jump into the ring as soon the coach is sure you’ll make it to the last round without kicking the bucket. As soon as you are viable for the ring. 

Option one is tempting: if things go well, you’ll plow through the underdogs and face the big guys without losing your breath. Option two appears hurtful: if things go well, you will win. But should you win or should you lose, you won’t leave without a bruise.

However, there is a but. “If things go well” is the critical part in both scenarios. Once you enter the ring, reality comes at you fast. What if you figure out you missed something in your training? What if those in the ring are still trained better? What if the blows you receive hurt too much (shocker!)? Or – why not – what if what you deemed boxing and your passion was actually wrestling, so all your great punching skills are totally inapplicable? You’d better know that in three months than in ten years after you put your gloves on for the first time.

So, MVP is a reality check done the quickest and the cheapest way. It’s not actually cutting functions, but ensuring they are needed before you spend time and money on those.


The MVP-centric approach grows popular as marketing skills become commonplace for entrepreneurs, no matter which is their sphere. TTM is the reason for that. TTM, or Time-to-market, is one of the key metrics for a new product. Time is always money, but when the market launch countdown is ticking, every minute costs you cash in many ways.

  • You want to pay for what others will pay for.

With all the research and insight behind it, the great idea your new product is based on is still a hypothesis until proven. It’s not like you already know the market craves your product, but you assume it is. There are no other means to make this hypothesis a fact but to check it on real customers. The earlier you hit the market, the quicker the feedback is on what would make your product more desirable.

  • Your product might be lucrative, but before it is in the market, it earns nothing.

With all the variety of monetization models available today, your product may be able to generate revenue long before it’s done and ready. Think of World of Tanks, the videogame that earned billions while being still in beta, or of all the mobile apps that are paying back the investments made. Ad-supported or subscription-based, bought in a one-time purchase or enhanced via microtransactions, your product might add some green lines to your bank account report as soon as it can deliver any value to your clients.

And yes, while the scope is small yet, you are safer in your experimenting with monetization models per se. No matter what, your missed revenue numbers will be the least frustrating.

Think of almost every successful software product. Yes, even the hardcore enterprise one would work. They never start as a one-size-fits-all solution, but as a demanded yet simple tool designed to perform a specific task.

  • Take a turn before you’ll have to brake for that 

Developing a complicated product before learning you have to adjust it to the market is not only about losing money on features discovered to be undemanded. The more had been done before a pivot, the more has to be done to perform one. You only have to remove seats and add panels to make a cargo van from a microbus, but should you try turning a Corvette into one, you’ll end up building it from scratch.

OK, are there any real-life MVP cases?

Telegram grew popular before it got the channels, stickers, secure calls, and bots. In the beginning, all it had was a boringly simple messenger with awesome encryption. It could do less than competitors, but it could keep your communication secure. MVP? Betcha.

SAP, the first ERP software coming into one’s mind, started from a pretty simple accounting system, which didn’t sport even 10% of what it has now. The term MVP was not even coined in by that time, but in fact, that was it – a basic solution, offering a new approach on quite a limited scope.

Zappos, the mid-2000 iconic apparel e-store began as a guy buying footwear on your demand from regular stores and sending it by mail. As simple as that. 

Moreover, an MVP may prove an idea before you spend zillions on can even become a business even before you expect them to do it!

Dota and Counter-Strike, as lucrative as they are now, began as community mods for popular games (Warcraft III and Half-Life, respectively). No ginormous teams of developers, designers, and community managers, no weekly content updates or events: they offered the very basic setup needed for a new gameplay pattern. A Minimally Playable Product.


There is a mnemonic rule designed by Eric Rice, the author of the famous “The Lean Startup”: you take your first idea for an MVP, then cut that in half, and cut it in half again – and there you got what actually is an MVP.

For those hesitant on cutting, here’s another – not that brutal – rule of thumb we nurture here in Fora Soft.
You have to ask yourself three questions.

  • What is your favorite part of your big idea?
  • What do you need to use it?
  • If you had only 30% of your budget, what would you make first?

You may even put your imaginary budget threshold lower than that, until what fits it retains the uniqueness of your product and the very basic usability. Once you understand that you can’t push it down anymore, you got the MVP.

If it is still a complicated task like it may be, as you definitely love your idea, you can start with MVP-izing actual projects. Try to think about what makes Instagram, Google Docs, or your favorite game what they are. Take a shot on imagining they didn’t have all the features they boast now. Where is the border between “I’d go without this feature” and “Oh, it won’t be useless anymore”. 


Once you develop a vision of your product’s MVP, you start revving your engine. Time is money, so you want your Minimum Viable Precious right away.

Setting your step towards the MVP on your own is where you might run into a dilemma. On one hand, coding or testing in a rush never results in good code. On the other hand, the MVP stage is somewhat forgiving to the code quality — if it works, it works.

It’s up to you to find the balance between those, but the golden rule is: no matter how much duct tape is there under the hood, the user experience for the killer feature should be streamlined and lovely.  Whatever buggy and irrelevant to the key functions should be demolished mercilessly. Whatever is crucial and buggy should be a priority.


Well, everyone remembers the copycat cases – it happened to the MSQRD app, who’d had its minute in the limelight before every competitor got their own masks. Or Snapchat with its fading posts, which turned to be a fading fad (pun intended).  

That’s the concern faced by everyone taking (or sugging taking) the MVP path. If there is a killer feature, isn’t delivering a quick-and-basic product the simplest way to unwantedly hand it to bigger competitors, who’d wrap it up in glossy paper and grab your market in no time?

The short answer is yes. It is. If your killer feature is that great, all the big companies gonna copy it. Or release their own renditions already being in development. But the first one to release is the first one to win the audience — and is able either to retain it, entering the top league (like Zoom or Miro, the COVID-era superstars whose leadership is yet to be shattered). 

And even if the blue chips roll out their own, more refined solutions… Remember what happened to MSQRD? Facebook bought it. For a much bigger sum than they invested in development.


  • To check your idea and be able to refine it before there’s too much money spent;
  • To make the audience like your product before it is even totally complete;
  • To start earning before you’re done spending;
  • To make your product become a synonym to its killer feature. 

Can Fora Soft help you with an MVP?

Most certainly! On the MVP stage, it’s not just skill but experience that matters. A developer with a massive background in a certain area (media processing, streaming, and low-latency solutions in our case) is a shortcut to an MVP. Our developers, absolute pros cut the time-to-market, as they already know solutions for typical time-guzzling problems. Please, feel free to contact us via the Contact form, and we will get back to you right away!


How to report on testing

QA testing meme

The article is based on How is the testing going by Michael Bolton.

Imagine that a Project Manager has approached you with a question “how is the testing going?”. We will let you know how and what to answer in this article.

An inexperienced tester will dive into numbers straight away, and his answer will sound like this: “Why, everything’s cool. I’ve completed 234 test cases out of 500. 16 automated tests out of 100 have gone down”. This here is a bad answer. Dry numbers with no context whatsoever do not reflect the state of the product, thus, useless. They do not help the manager decide what to do next and how the team should proceed. 

An experienced tester has to provide his team with useful information that will help assess risks correctly and set up the priorities.

How to present information?

At Fora Soft, we present the useful information in this order:

  1. Explain the state of the product. What serious problems we’ve encountered, why they are serious, and how they can affect our customers. This information helps the team understand what to deal with first
  2. Explain how the testing is going. What still needs testing, what has already been tested, what we will not test and why is that. It’s important to mention how the testing was being done, what environment was used and why. This data is mandatory to assess the risk of receiving problems in the untested product areas and correct the testing plan, should the need arise
  3. Explain why we test the way we do it. Why the tests we’ve chosen are more effective than those we haven’t. When time and resources are limited, it’s crucial that we choose the right testing areas and sort out priorities
  4. Let the team know about the problems we’ve encountered during testing. Namely, what makes testing harder, what may cause us to miss bugs, what could help us make testing faster and simpler. If your team knows about your problems, they can help you

The main task the tester has is finding problems that put the product’s value in danger and reporting on those problems to the project manager and the team. Providing this information in a timely manner allows creating a high-quality product without missing deadlines.

To catch any problem that endangers the product’s value quickly, we use test plans and test strategies. Stay tuned to find out how the plan and strategy are created!

Do you want to learn more about our processes and how we do things? Do not hesitate to contact us via our contact form! It is right here 🙂


How to estimate the server cost for a video platform

Are you planning on a creating video software, such as video conference, webinar, telemedicine or elearning platform? Let’s see how much you’ll have to pay monthly to maintain it.

In this article, we’ll explain how to estimate a video streaming platform’s infrastructure cost. We’ll start with an algorithm and finish with examples. If you don’t have technical background, you can calculate using the examples.

How much does a month of a video program cost: calculation algorithm

The combined cost is based on the cost of traffic, data storing, and the server itself.

  • Traffic – the information that goes through our servers. In general, it’s audio and video streams.
  • Data storing – storing video conference recordings.
  • The server itself is the computer with the project. When one server isn’t enough because of too many users, people would use many servers instead.

Traffic costs

Let’s start with the cost of traffic: with video streaming it’s more expensive than data storage and the server.

Let’s calculate how much traffic will go through our server in a certain period of time.

We don’t count incoming traffic, only outgoing. This is because most providers either provide unlimited free incoming traffic, or their prices are so low that they can be neglected.

To calculate the amount of traffic that will be consumed when streaming a video, you need to understand the size of the video file to be streamed. Let’s assume that a file of 1 gigabyte will consume 1 gigabyte of traffic.

You can use the table below.

Select a resolution. The right column shows how many gigabytes will be consumed per hour when streaming video in the selected resolution. The numbers are obtained with the help of a calculator. If the table does not have the necessary values, take the data from there.

Now that we have an idea of how many gigabytes an hour of video is, we need to calculate how many times the video will be downloaded from the server.

Suppose this is a streaming service and users watch the video on the site. Then, if two people watch the video, the traffic will be spent twice: the video will be watched 1 time by each user.

For services with one streamer and 20 viewers traffic equal to the size of 20 files will be spent per hour: the video will be transferred from the server to each of the 20 viewers.

In the case of a video chat for 4 people, the video size must be multiplied by 12. 4 people in the chat and each receives 3 videos of the other interlocutors from the server.

The size of the video multiplied by the number of downloads of that video from the server. Now we have the amount of traffic that is consumed per 1 hour of time. Multiply it by price per gigabyte of traffic provided by our provider: AWS, DigitalOcean. If the servers are physically in our possession, it can even be our ISP.

Voila, we got an approximate price for traffic. But that’s not all: there are still costs for video storage and the cost of renting the server itself.

Price for storing data

If you don’t keep your stream recordings, feel free to skip this section.

Storage costs for data that doesn’t include recorded video are usually so low that they can be neglected in the approximate cost calculation. We rent a server to host the site. A disk space of a couple dozens of GB, that’s available on the server, should be enough in most cases.

But if the data exceeds a few tens of gigabytes, it’s stored in a separate storage unit. It is paid for in addition.


  • An app with a huge audience, like Instagram. They need extra storage, although they don’t store video call recordings because users upload a lot of photos and videos, and there are a lot of users.
  • Video conferencing application for a local bank for 3 branches, they store video conferencing recordings. They do not need additional storage: the recordings are stored at the same time in such a size that the server memory capacity of their site is not exceeded.

First, let’s calculate the size of files to be stored on the server. The algorithm for calculating the size of one video file is similar to the calculations above, but it doesn’t matter how many people view the file. All that matters is how many such videos to store.


  • If you store a video conference recording for 4 people, you will need space equal to 4 video files – one for each participant’s video.
    You can combine all the videos into one and store it in an optimized form. The size of the files on the server would be 2 or more times smaller. But this feature needs to be developed, so discuss it with your developer.
  • If we store videos like YouTube, one file will be stored for each video. If there is functionality to change video quality depending on the user’s internet speed, one file of each quality will be stored.

Now take the size of one video, multiply it by the number of videos to be stored.

This value is multiplied by the price of storing GB of data on your server.

If it is your own computer, you can directly calculate the cost of HDD/SSD you will need to install there.

All that remains is to calculate the cost of renting or maintaining the server itself.

The cost of server

The server is the place where the program itself is located and where user data is stored. For small projects, 1 server can be used, and where there are many users, several servers can be used.

The cost of servers strongly depends on the type of project and the number of users, but you can use the tips below as an example.

In the early stages of project development, you can get by with one server for $50 per month.

If there is video conferencing or video streaming, it is advisable to have a separate server for the media server.

If there are many conferences, you can automatically create new servers on the fly for the duration of the video conference and delete them when not needed. They have a price per hour of use. If you know that price for your server, use it. If not, you can charge about $0.3 per hour for each video conference. This is the average price for the first few Amazon EC2 c5 servers from Amazon’s September 2020 calculator.

Examples of video software monthly cost calculation

#1: Video conference for 9 people


Let’s take the resolution 640×480 – the optimal format for video chat (4:3) – the picture is composed and the face is in the middle of the screen.

According to the table in the “Traffic Costs” section above, this is 0.11 GB per hour. This is what 1 hour of video takes one way. A total of 72 streams will be sent from the server – 8 videos for each of 9 users.

Multiply 72 by 0.11 GB, you get 7.92 GB.

Traffic on AWS costs differently depending on the amount of traffic and where clients are physically located. For our approximate calculations, an average cost of $0.09 per GB will do. Multiply 7.92 GB by $0.09 and you get $0.71 per hour.


Let’s say we want to store video conference recordings. One video will be stored on the server where all other videos will be merged.

Let’s assume the new video will have a resolution of 1280×720 (this is enough to see everything) and will take 0.88GB according to the table.

We take the General Purpose SSD from Amazon S2 from Amazon S2. It costs about $0.1 per gigabyte per month as of February 2022. Multiply the video size in GB by the cost to store one GB (0.88 * 0.1), we get ~$0.088 for each hour of video. This will have to be paid every month that our video is stored on the server.


Here you can take $50 for the server for the platform itself and USD 0.30 for each hour of server rental for the video conference itself.

A server that costs $0.30 can host 5 or more conferences at the same time, but for pessimistic estimates we can assume we have only one video conference.

The total cost is

  • $0.71 per hour for traffic.
  • $0.088 per month for storage of one hour of recordings
  • $50 a month for the server for the site and $0.30 an hour for renting a server for the videoconference itself

$0.71 and $0.30 can be added: both prices are for each hour of an active video conference. You get $1.01 per hour of videoconferencing.

How to calculate how much a month it will cost to maintain such a chat? You need at least an approximate number of videoconferences per day/month.

Let’s say we have 4 hours of video conferences a day. Multiply 4 hours by $1.01, you get the cost per day: $4.04. Multiply the cost of daily service for 30 days, you get the cost per month: $121.20.

To store all the recordings, we would need to store 4 hours * 30 days = 120 hours of video. We will pay $0.088 * 120 = $10.56 a month.

Let’s add up all monthly costs: $121.20 + $10.56 + $50 = $181.76

#2: Webinar with 2 streamers and 50 viewers

Let’s take 720×480 resolution – a suitable option for streaming. A good balance between quality and economy.

According to the table from the section “Traffic costs” above, it’s 0.44 GB per hour. That’s what 1 hour of video takes one way. There will be 102 video streams sent from the server – 2 videos for each of 50 users and 1 video for each streamer.

Multiply 102 by 0.44 GB, you get 44.88 GB.

Traffic on AWS costs differently depending on the amount of traffic and where clients are physically located. For our approximate calculations, an average cost of $0.09 per GB will do. Multiply 44.88 GB by $0.09 and you get $4.04 per hour.


We have two streamers. The server will store one video with videos of both streamers merged.

Suppose the new video will have a resolution of 1280×720 (this is enough to see everything) and according to the table will take 0.88GB.

We take the General Purpose SSD from Amazon S2. It costs about $0.1 per gigabyte per month as of February 2022. 0.88 * 0.1, we’ll pay ~$0.088 for every hour of video each month it’s stored on our server.


Here we can take $50 for the server under the platform itself and $0.30 for each hour of video streaming.

In fact, a server that costs $0.3 can host more than one streaming session at a time and there may be more than 50 viewers, but for pessimistic calculations, we assume that we only have one streaming session. We will still have to use such a server for that.

Total costs

  • $4.04 for each hour of streaming traffic.
  • $0.088 per month for storage of one hour of records
  • $50 a month for the server under the site and $0.30 per server for each hour of streaming

$4.04 and $0.30 can be added because both prices are per streaming hour. You get $4.34 for every hour of streaming.

How do we calculate how much it will cost per month? We need at least the approximate number of streaming sessions per day or month.

Suppose we have 4 hours of streaming a day. Multiply 4 by $4.34 and you get the cost per day: $17.36. Multiply by 30 and you get the cost per month: $520.8.

To store all the recordings we will need to store 4 hours * 30 days = 120 hours of video. We will pay $0.088 * 120 = $10.56 per month.

Let’s add up all monthly costs: $520.8 + $10.56 + $50 = $581.36.

#3: 1-on-1 video chats via p2p


In the case of p2p calls, all video goes directly between users, bypassing the server. Therefore, you don’t have to pay for traffic.

This is true when a p2p connection is technically possible to establish. It is not possible only in about 10% of cases. In those cases the connection will go through the server and not directly. So 90% of the calls will be free and 10% will have to be paid for. Let’s calculate how much exactly.

Let’s take the resolution 640×480 – the optimal format for video chat (4:3) – the picture is composite, and the face in the middle of the screen. According to the table in “Traffic costs” above, this is 0.11 GB per hour. This is what 1 hour of video takes one way.

In total 2 streams will be sent from the server – 1 video for each of 2 users.

Multiply 2 by 0.11 GB, you get 0.22 GB.

Traffic on AWS costs differently depending on the amount of traffic and where clients are physically located. For our approximate calculations, an average cost of $0.09 per GB will do. Multiply 0.22 GB by $0.09 and you get $0.02 per hour.

You should pay only for 10% of calls so 1 hour of video chat will cost $0.002.


We have 2 people in the chat. There will be 1 video stored on the server where the videos of these two people are combined into one.

Let’s assume the new video will have a resolution of 1280×720 (this is enough to see everything) and will take 0.88GB according to the table.

We take the General Purpose SSD from Amazon S2. It costs about $0.1 per gigabyte per month as of February 2022. 0.88 * 0.1, we’ll pay ~$0.088 for every hour of video each month it’s stored on our server.


You can take $50 for the server and not take an additional server for video streaming, as the server for $50 will be able to handle more than 1000 simultaneous p2p chats.

Total costs

  • $0.0002 per each hour of video chats
  • $0.088 per month for storage of one hour of recordings
  • $50 per month for a server under the site

How do I calculate how much it will cost per month? You need at least an approximate number of video chats per day/month.

Let’s suppose we have 100 chats per day.

Multiply 100 by $0.002 to get the cost per day: $0.2. Multiply by 30 to get the cost per month: $6.

To store all the recordings you would need to store 3000 hours of video. We will pay $0.088 * 3000 = $264 per month.

Add all costs per month and you get $56 without all records and $320 with all records on server.

Calculations are very rough. We give them to get at least a rough idea of the cost of running a video program: it costs about $10 or $1000 or $10,000. If, after the calculations, your business comes out to 0 – do not start it. The margin should be substantial.

Have any more questions? Contact us using the contact form and we’ll get back to you with a response ASAP!


Testing automation in iOS

According to Businessofapps, mobile apps become more and more popular. They offer more functions that are in need of testing. This is a crucial process in development. No one wants to use a lousy app that keeps crashing or working bad, right? Also, what if there’s a payment function in an app? Working with a product that can let you down when you send money somewhere isn’t a good idea.

To improve the quality of an app, we need to test it. It’s believed that the developer’s eye eventually starts swimming and they can miss some problems. So, we have testers for that. To increase the speed of testing and implement a system in it, testers automate the process.

Let’s take a look at testing automation using iOS apps as an example. Nowadays, mobile apps have way more functionality than before, so testing takes more time, too. And don’t forget that there are many kinds of iOS devices out there, which increases the time spent on testing even further! To guarantee that an app works correctly on all devices, many tests need to be done, which makes the process longer and more expensive. Testing automation is out there to deal with it because testers won’t need to check some functions manually. It’s enough to write a script and edit it from time to time. Sounds good, doesn’t it? Nothing is perfect, though, so let’s turn to the pros and cons of this method:


  • Concurrent testing on multiple devices
  • Faster testing process
  • No human factor. Sometimes, bugs might appear that are difficult to catch. Even if a tester is able to catch those, they can not always understand what the cause was. Automated testing may help with the precision of understanding
  • Testing transparency. When the testers swap, old scripts stay, and the testing process will continue as intended. Regression testing stays the same, too. If you need to change something, or if a new tester wants to check the application logic, the script will work as documentation. This is one of the main advantages


  • When iOS updates, you have to wait for the automated testing tools to update, too
  • The tester needs to have special knowledge about automated testing scripts. The company needs to teach employees to do that or hire more expensive ones

The auto testing tools have pros and cons about them. It’s difficult to find a perfect tool, and oftentimes you need to sacrifice convenience in working with a tool or with its possibilities.

When you need automated testing

Do you even need it? The answer is “yes”, if:

  • Your app has too many functions and features, and you are going to support it while adding new things along the way. Why do you need auto testing then? New functionality can conflict with the old one. For example, you’ve introduced a chat and calls broke. To find out the problem, the tester has to test the whole app manually. It takes a lot of time, and the tester is at risk of missing something else! Auto testing helps avoid that problem, as the tester won’t have to test everything after introducing each feature.  Whatever stayed the same will be checked automatically, as long as you launch them and then collect the data. It helps reduce the testing time and the development costs
  • You are going to adapt the app for each new iOS version and take advantage of new system possibilities. Every iOS update can break something within the app. Even if you never planned to update the app in the near future, it might be that you have to. In that case, automated testing will help with that. After that, you’ll understand what it was that broke and be able to solve the problem. Obviously, you wouldn’t add automated testing with this sole purpose, but they will help a great deal if they are already implemented
  • There are testers on your team that possess some knowledge of automated testing. They at least have to know some popular programming language if you go for, say, Appium. Or, they have to know Swift if your choice is XCTest / Earl Gray / KIF. Testers also need to know all the possible testing methods and needed tools. If your employees only know how to manually test apps and have no knowledge of programming languages whatsoever, you will either have to teach them or hire new ones

However, writing automated tests is programming, although you’re not writing new functions for your app but rather a program that goes through your product and checks it. It is expensive. It won’t be worth it to add automated tests if:

  • The app is small. It doesn’t have lots of functions and it is easy to test it manually. With that being said, you are not planning on adding new functions on a constant basis
  • The app is supposed to be developed and distributed within a short period of time, such as those for the World Cup-2018 or the Olympics-2014
  • The app changes frequently. The functionality is unstable. For instance, a startup that looks for its client and keeps changing the main features

Tools for automated testing in iOS

After finding out the main advantages and disadvantages of this approach, let’s take a look at the tools.


Apple developed a fully native tool that is out there only for testing iOS apps. Since it is native, external dependencies won’t be there. You develop tests in Swift or Objective-C, which helps developers and testers interact more effectively. However, developing in those languages isn’t that simple. It might be that testers will turn to developers to ask for help far too often, which will make work a bit chaotic. 

There is a test recorder, too. It records real actions with an app and creates a test out of them, but using it is actually quite hard. It isn’t very accurate and it’s best to use it as an assisting tool while developing main tests in Swift or Objective-C. XCUITest/XCTest also works in a separate stream, doesn’t read the state of an app. Therefore, delays in updating the data may lead to an impossibility of seeing requested elements.


The Framework by Google. It requires tests in Objective-C or Swift. The framework synchronizes requests, UI, and streams – that’s the advantage of it. However, EarlGray isn’t very popular because you can only test iOS apps with it. It isn’t very different from XCUITest, yet it is not native, so testers would rather use XCUITest.


KIF is a framework that has to be added to the project to use it. Objective-C or Swift are the testing languages. Its realism is its main competitive edge. KIF can simulate interaction with a user, therefore it’s very good for UI testing.

You see the iOS-only tools above but when mobile development is in question, oftentimes the developers go for both iOS and Android apps. So no wonder there are cross-platform tools for automated testing.


JavaScript is a language for tests with Detox. It can access the memory and control ongoing processes. The framework works with emulators and real devices and uses native methods right on the device. It also uses EarlGray and is considered to be really good at testing apps written in React Native, because React Native uses JavaScript, just like Detox. It allows for writing the same tests for Android and iOS.


Appium is the most popular tool nowadays. It allows testing apps regardless of the platform, type, and system version. Writing tests for each platform is possible using unified API, without transforming an app into a special, network-compatible kind. Appium doesn’t require adding to the app source code. It’s working as a separate tool. Let’s take a look at its advantages:

  • A big number of languages for tests: Java, C#, Python, Ruby. It means that Appium doesn’t only work with Objective-C or Swift, so all testers will be able to create tests
  • An app doesn’t need re-compiling or changing it for automation’s sake. It’s important because the test source code and the app source code aren’t in the same project, and they are developed separately. These two don’t depend on each other, so one can avoid many problems. For example, if somebody wrote the tests incorrectly and they don’t compile, it won’t affect the app in general
  • It is cross-platform. The testers can develop tests for iOS and Android in the same environment, in the same language. They can even re-use the code. It saves time and money
  • Wide functionality. You can launch and stop the app, check the visibility of elements on the screen, and use gestures. Simulator and real devices work with Appium

Appium has some disadvantages, too. It is essentially a superstructure over native iOS and Android drivers. The tests can break more often due to the mistakes in the superstructure code. It’s important to notice here that Appium is very popular, develops quickly, so arising problems will be likely solved in the future.


Automated tests gain popularity in mobile development. They have advantages and disadvantages. Introducing automated tests is worth it when the benefit outweighs the costs. It is not magic, it’s still development, but you’re not developing new functionality but the ways to test the old. If an app has many functions and you keep updating it, but the majority of functions stay the same with each version, take a look at automated testing. After spending money once, you will save more later on.

Testers won’t have to test everything manually with each update. You only changed the teacher’s profile, but all courses, login, payment, booking, admin dashboard have to work the way they did?  The automated tests will have to work for it then. If they didn’t, it means that your small update broke something, now you have to figure out what. If the tests went through – be happy, because the tester will only manually check the teacher’s profile instead of the whole functionality.

We took a look at the tools that enable automated testing. It’s worth saying that we didn’t talk about all the tools out there. There are still paid, unpopular solutions or solutions that are not supported by the developer anymore. Whenever you choose a tool, consider the application’s peculiarities, check if there will be an Android version of the app. Also, consider your tester team! 🙂

We at Fora Soft also use automated testing for some of our projects and find success with it. Do you want to learn more about this topic? Message us using the Contact us form!


What iOS developer should know. The hiring process at Fora Soft

In this article, we will explain how Fora Soft hires people. What an iOS developer should know and what interview stages they complete. Besides, you will also find out about how we carry out the mentoring process and how programmers progress.

Minimal hiring requirements

A developer should know:

  • OOP. This is a programming methodology based on representing a program as a combination of objects
  • Swift, Obj-C (reading the code). Swift is a programming language developed by Apple, and they use it to write programs for all their products. Obj-C is a previous language that Apple used for the apps. Even now one still can create objects with it but people mostly use Swift. However, one needs to at least read Obj-C, as older projects are written in it, and they need support
  • iOS SDK. Knowledge of main frameworks, such as UIKit (work with graphic representation), Foundation (work with network and date), AVKit (work with media), MapKit (work with maps), CoreLocation  (work with geolocation)
  • Apple Guideline. For an app to be approved for AppStore, it has to answer Apple’s requirements. Read Apple documentation to find out more
  • AutoLayout. This is a mechanism for page-making in the app, it is responsible for placing interface elements on the screen
  • Multithreading. It’s important for an app to complete many processes simultaneously. For example, to make a request into a network and show the data loader
  • SOA (REST API, Web Socket). To work with the network, one must understand its organization
  • Git. The version control system is out there to make the project work easier and make it possible to put a group effort into it. Besides, it allows keeping several versions of the same document. It’s also possible to return to earlier versions, determine who and when made a change, etc.

The selection and recruitment process

It consists of

  1. A candidate sends their CV to an HR
  2.  HR looks at the CV and calls the candidate if the CV meets the requirements
  3. HR speaks about the company and answers questions. Then an interview happens, where HR tests the candidate’s professional qualifications. The questions are related to the specific position.
  4. If the candidate answers the questions successfully, he is invited to join the next stage – a technical interview with an HR and team lead. The lead does the talking here. He asks not only about the job itself, but about the IT world as well. It’s important to know how well-rounded the candidate is. The HR then conducts an office tour
  5. We invite almost all candidates who passed Step 4 to complete a test assignment within a week
  6. The candidate sends the assignment, which the team lead reviews and sends feedback to the HR. Here the decision whether we invite the candidate to the final interview arises
  7. The CEO attends the final interview. The candidate receives some specific assignment, for example, developing a video call system. The candidate has to explain how they’d like to proceed with the task
  8. We send an offer

When I find an employee who turns out to be wrong for the job, I feel it is my fault because I made the decision to hire him.

Akio Morita, Sony founder

As you can see, Fora Soft takes the hiring process very seriously. Let’s take a look at the statistics that the HR department has provided.

JavaScript statistics (relevant for 1,5 months):

  1. 500 candidates
  2. 20% pass the phone interview – 100 people
  3. 40% pass the face-to-face interview – 40 people
  4. 30% complete the test assignment and the technical interview with the team lead – 12 people
  5. 90% pass the final interview with the CEO – 10 people


  1. 50 candidates
  2. 50% complete the phone interview – 25
  3. 20% complete the test assignment and the technical interview with the team lead – 5 people 
  4. 20% complete the final interview with the CEO – 1 person

To sum it up:

We send an offer to 10 JavaScript developers out of 500, which means 2%

We send an offer to 1 iOS developers out of 50, which is again 2%.

We just showed you the numbers. Go with any output you deem fit 🙂

Mentoring process

The mentor is responsible for:

  • Code review. The new programmer creates a separate branch for it, according to Git Flow. Upon completing the task, the new programmer makes a merge request, and the mentor checks the result. The good mentor will pay attention to the logic behind completing the task, leave their feedback, and send it back for the refinement. If the mentor is satisfied with everything, the merge into the development branch happens. Thanks to this mechanism, it’s possible to see how the new programmer progresses. Over time, the number of comments goes down, and the code immediately ends up in Develop
  • Meetings about the developer’s weak and strong suits. After some time, the mentor will form a professional portrait of the new developer, based on the code, approach to tasks, and other teammates’ feedback. As soon as the portrait is ready, the mentor and the developer talk about everything. These meetings happen quite often, approximately once a month
  • Informational basis (Q&A). The new developer can always ask a mentor for help
  • Task distribution. The mentor determines what the new programmer can do now and what is too early for them. The difficulty of assignments grows as the developer grows

How constant development happens

  • Development plan. Every developer creates the plan of the aims. What is it? We take a period of time and create goals for each month. For example, read book X, learn technology Y, watch conference Z. Upon the completion of each milestone, we put a mark. That way it’s easy to see how the developer progresses
  • A gradual increase in task difficulty. The mentor gives tasks to the developer depending on their difficulty. The good mentor will never assign something the new programmer can’t complete. Over time, the difficulty grows
  • Lectures within the company. Anybody can host a lecture. Found an interesting technology? Learn it yourself and let others know!
  • Collective meeting attendances. We keep an eye on the IT world and meet-ups in other companies. We attend those events together, and then create a short review on them


From the statistics, one can understand that we have very high requirements for candidates, and there’s a reason.

The team guarantees the high quality of Fora Soft products. First, we make hiring decisions carefully. Second, this is a culture of constant development. We keep a close eye at new colleagues and their code, help them find themselves in the company, level up their skills.

Thanks to that, our products have such high quality.

You have to love your work. To do that well, you have to enjoy your work. We at Fora Soft are driven by that desire – do things awesomely. We realize what kind of a person is and whether we pursue the same goals during interviews. We never leave a new employee to be eaten by projects. We are always close to guide, give advice, and just look after.

With all that said, our clients are always happy, which makes us happy, too. We created a cool product and made the client happy? The end-user is also happy because of what we did? That’s the goal we pursue.


What Chat Solutions to Choose? Firebase Vs SendBird Vs Node.js +

People frequently come to us with a request to create a text chat. Some of them want a messenger with a chat being the main or the only function. Others need to add chat into different projects, such as telemedicine. In this article, we’ll take a look at the most popular options for chat creation.

All solutions for chats can be split into two categories:

  1. Ready-made chat platforms, such as Firechat, SendBird.

They have prepared functionality for main chat options. The developer needs to put a small effort and time to add a chat into an app or a website. But the behavior of functionality has strict borders by a platform creator, and possibilities for customization are limited.

  1. Technologies for exchanging data between client and server, such as Firebase Cloud Messaging, Node.js +

They allow building a very flexible chat solution upon them. Those technologies take time to implement but offer unlimited possibilities for customization.

All the four solutions are cross-platform, they work on the web, iOS, Android.

Firebase Cloud Messaging

Firebase Cloud Messaging is a platform for information exchange between a mobile app and a server. It’s widely used for notification send-out, and it can be used to build a chat on its foundation.


  • Free for products with up to 100 simultaneous users.
  • As a Google product, one can expect stable work when used correctly
  • With comprehensive documentation and high popularity, developers can find any answers quickly, which saves time and money
  • No need to buy an additional server, you can do everything on the Firebase server
  • Thanks to the Firestore database, the servers will automatically come into existence or be eliminated when they are not needed, which will save you a ton of money. Node.js and will make you create scaling separately
  • Data is cached by default and is available for search in chat offline


  • Difficult search inquiries are difficult or impossible to realize

For example, inquiries like “find all messages with “Hello!” that a user received last year from all users whose nicknames start with an A”.

The thing is when using Firebase Cloud Messaging, you are limited in choosing a database. It’s either Firebase Realtime Database or Firestore. 

Firebase Realtime Database is a NoSQL database, where data is stored as JSON. It has lots of advantages compared to traditional SQL databases. The possibilities for creating a new search inquiry are limited by a developer to keep productivity levels.

To deal with that problem, Google came up with the Firestore database. It’s a NoSQL database but its search and data structuring possibilities are vastly increased. However, difficult search inquiries still pose a bigger problem than those in SQL databases or NoSQL databases like MongoDB. Some of them are impossible, others will take much more time to develop.

  • Up to 200k simultaneous users in Firebase Realtime Database, up to a million in Firestore

Firebase Realtime Database is limited by 200k connections in the database. It’s roughly the same as 200k simultaneous users. Firebase developers think out of 10 million active app users there are 200k of those who would use the app at the same time.

Firestore offers up to a million users at the same moment.

  • Paid from 100 simultaneous users

When using Firestore, the cost is determined by read/write operations in the database. The more data is there, the more expensive it will be. For instance, by Firestore calculation, a small up (50k installations and 5k active users daily) the usage cost will be $12-14 a month. For a big app (10 mil installations with 1 mil active users daily), the cost will be $2951,52 monthly. There are borders within which Firestore is free to use.

With Firestore Realtime Database the cost is determined by the amount of data stored in a base and downloaded from there – approximately $5 a month for each stored gigabyte and $1 a month for each downloaded gigabyte.

Therefore an app that processes many read/write in the database operations, it will be cheaper to use Firebase Realtime Database.

The most profitable option would be to use Firebase Realtime Database for one type of data and Firestore for another.

For example, for a typical e-commerce app, operations that involve reading a list of goods will run every time a user opens the app, and the number of operations will grow as more people use it. The size of the list, however, won’t depend on the number of users. For an app like that, the most profitable option would be storing the list data in Firebase Realtime Database (to not pay for multiple read operations), and storing the user data in Firestore, as storing 1 gigabyte of data is cheaper there (source).

Using Firebase Cloud Messaging is free itself, which means that you only pay for using the database, hosting, and authentication.

  • Works slowly when searching offline

In Firestore, if there are hundreds of documents in the base, the offline search will be slower, which will worsen the UX. For instance, in a chat with a hundred channels, when you have to find one without internet access, the search will work noticeably slower.

  • The developer needs experience working with NoSQL to build a convenient and effective database structure

Firestore has a limit of 1 write operation in a second for 1 document. The document is a structural part of a Firestore database. The Firestore database consists of documents organized in a collection. The document is practically a set of “key-meaning” couples. It is actually a flexible limitation: if you go for 10 read operations at the same time once, Firestore will process them correctly. If, however, you keep sending thousands of requests into the base at a rate of more than 1 per second, Firestore will return errors for some requests.


Firechat is a framework for chat creation, and it was made by the Firebase team using Firebase as a foundation. Firechat uses Firebase for authorization, sync, storing data. Firechat provides API for a chat, that allows user authentication; forwarding messages, images, and files; group chats creation, sending out invitations. Here are the links to their official website and project code.


  • Saving time and money on developing

A ready-made API for the chat main functionality allows not to create a realization of those functions by yourself

  • Same advantages as with the Firebase Cloud Messaging


  • Not all functions are possible to realize

If you use a ready-made API for the chat functionality, you can only realize the functions in offers. For instance, it doesn’t support showing unread messages, deleting messages, and has a limitation of 100 users in the chat group. The full functionality list is difficult to find, but you can get an impression by their API methods here 

  • Same disadvantages as with the Firebase Cloud Messaging

Firechat only uses Firebase Realtime Database from the box. There is no choosing a database, like in the Firebase Cloud Messaging, Firebase Realtime Database, or Firestore.


Sendbird is a ready-made chat platform. It offers a multitude of prepared features, including an indication of the number of unread messages, blocking users, and admin dashboard.


  • Many functions

Lots of features are already realized and work right away: message or file exchange, invitations, users blocking, typing indication, editing messages, automatic translation, admin dashboard, group chats for up to 100 users

  • A ready-made UI with limited customization possibilities

Creating a UI and its design isn’t necessary. Sendbird offers standard UI options, which you can use as is. You can also apply your own design on top of the standard one, changing the color and form of chat components. So, we can simply add Sendbird with default settings into our product and get a char with a default design. Then, customize some components whenever the need arises.

  • Scales automatically

You don’t need to worry about having too many users so your server doesn’t catch up to the number of requests, New servers will create themselves. Sendbird supports more than a million simultaneous users. It uses AWS.


  • You can’t realize all functions

Chat and functionality behaviors are strictly set.  A user logs in and gets access to a list of channels. They can choose an existing channel or create their own. Channels are either public or private. Users can exchange messages in either one.

This is the standard structure for the majority of chats. If you need something more exotic for your product, it will be really problematic to realize that with SendBird. Some functions are outright impossible to implement, others can take much more time than if they were created from scratch, for example, with Node.js and For example, you can’t create threads to answer a message, like in Slack.

  • Not all available functions can be realized the way you see it

SendBird provides more customization opportunities than it seems. There are serious limitations, too. For example, SendBirds allows storing additional information about any user, but not more than 5 parameters. Let’s say, those will be a name, last name, city, sex, weight, eye color. So, it is not nearly enough for dating chats

  • Not as popular as Firebase and

Popularity is an important metric when choosing a framework. The more popular a framework is, the more developers using it are out there. It helps get important resources, support, answers. If other pros and cons are equal, this will help make the development faster (and cheaper if you pay for time)

  • Price

Depends on the number of users. The base package costs $400 monthly for 5k active users. With 100k active monthly users, the price will go up to $5000. Or even $7600 if you also want automatic message translation and advanced moderation. For products with more than 100k users, the price is decided individually. There is a 30-day trial period

Node.js +

Server platform Node.js, going with the real-time data exchange library helps build a chat with unlimited customization possibilities.


  • Allows realization of any functionality

The developer has full control over all components: interface, logic, and server data and endpoint can be whatever is needed. For instance, it helps organize threads to answer chosen messages, which you can’t do in SendBird. You can implement message deleting, which is nowhere to be found in Firechat.

  • Scales

Provides an opportunity to realize automatic scalability that depends on the load. It’s possible to do on AWS and other ready-made solutions, such as Oracle. However, scalability isn’t provided right away, it has to be developed by a programmer.

  • You can choose the database type that suits your product best

For instance, if in the future product you are going to realize many difficult search inquiries, you can choose the SQL database, instead of using Firestore or Firebase Realtime Database that don’t support these functions

  • The chat works quickly

Client and server exchange messages directly, which results in fast work. When you use Firebase Cloud Messaging, the message goes from your server to Firebase server, and only from there will it travel further to the device. It’s important to mention that, though, that if there is a 0,5s delay, it’s not critical for a text chat.

  • Free to use

Open-source free solution – you don’t have to pay monthly for this technology. But please note that you have to pay for a server rent, where your product is based. However, this cost is usually way lower than that of Firebase Cloud Messaging or Firechat. We will discuss forecasting server costs in a different article.


  • Requires more time and money, as the developer creates all functions from scratch
  • Not everyone can develop the chat. You will need someone with the relevant experience

To sum it up

Ready-made platforms will give you quick results because the functionality is already there. But you are limited to those functions.

Node.js and allow creating any chat you need but each function will have to be developed from zero. It takes time and money.

What to choose?

The first thing to think about, when answering this question, is what kind of solution fits you and your company best.

  • If your chat requires a minimum base functionality, you don’t have high level of requirements to it, then Firechat or a Firebase Cloud Messaging-based solution is the way to go
  • When you expect a chat to be more advanced, take a look at SendBird. Compare monthly payments to SendBird against creating a chat from zero on Node.js and
  • If there are a lot of requirements for a chat or you need lots of customized options, Node.js and are your friends!

Why at Fora Soft we recommend Node.js +

Developing the chat functionality on Node.js + takes about 40 hours. Embedding and customizing a prepared one requires around 24-32 hours.

Ready-made chats charge you every month. It is more expensive than paying just for servers in the case of Node.js + A little increase in the development costs is usually recouped in a few months.

In exchange, they:

  • Are not bound to any limitations. They can implement any functionality in the future
  • Do not depend on third-party components that developers can just stop updating someday, and your chat will stop working.

To find out more about chat creation, do not hesitate to contact us!


Native or cross-platform application?

Whenever you create an iOS application, the question you ask first is usually “Do I have to develop a native solution using Swift or go with a cross-platform app?”. You will be able to answer this question, as well as understand the advantages and disadvantages of the both options, after reading this article.

video conference app

Short description of cross-platform solutions

React Native

Facebook created and supports this platform. React Native helps develop cross-platform mobile apps on JavaScript. With that being said, developers are free to use up to 70% of the code between different platforms, such as iOS and Android.


Flutter is a young yet promising platform. It has attracted attention from big companies that developed their apps. Flutter’s simplicity is comparable with web applications, and its speed is equal to that of native apps’. The programming language that goes with Flutter is Dart, which compiles into a binary code. That allows operation speed to be comparable to Swift’s and Objective-C’s.


Xamarin is a framework for cross-platform mobile application development, which uses the C# language. Microsoft bought Xamarin in 2016, made the source code of Xamarin SDK open, and included it into IDE Microsoft Visual Studio.

Short description of native solutions


Objective-C used to be the main language of development for iOS until not so long ago. This language is a superset of C, that’s why the compiler Objective-C fully understands C-code. Therefore, an app created with Objective-C can be very fast. Objective-C also has object-oriented programming, which helps make programs that you can easily scale in the future if needed. However, this language is quite old. Stepstone created it in the 1980s. Apple, on the other hand, is a very progressive company, so it wasn’t a huge surprise when they introduced a new programming language in 2014 – Swift.


Swift is a language that allows writing applications for phones, desktop computers, and servers. The compiler is optimized for productivity, and the language is optimized for development, with no compromises from each side. Swift has years of development behind it, and it’s still moving forward, constantly learning new opportunities. When it was just released, the community split into two parts. The first one believed that there was nothing better than Objective-C. The second one rooted for Swift and tried to use it to create apps. Now, after several years of development, it’s safe to say that when it comes to creating iOS apps, Swift is language #1.

Advantages and disadvantages of cross-platform solutions

The idea of writing an app for iOS and Android simultaneously does draw attention to itself. However, nothing is perfect.


  • Simplicity. Choose between JavaScript, C#, or Dart as the main programming language. More developers can work with those, which will simplify the development process
  • Speed and cost of development. You only need one team of developers to create an app that will look the same on both iOS and Android. When you need to create an app for the both platforms quickly, this becomes a substantial advantage.


  • Safety. Almost all cross-platform solutions have an open source code, and any thief who knows how to program can look at it, find the weak spots, and hack your app. It’s also important that a cross-platform app connects with the backend via usual HTTP-calls, and thieves can easily intercept your data and use it for their advantage (read more about it here)
  • The difficulty of work with iOS native functions. Swift developers have integrated useful modules into the language. You can work with audio, video, phone camera, location, Bluetooth with those modules. When developing a cross-platform app, the work with these functions is more difficult. For example, to add an AR-object on a video from a camera or demonstrate a screen during an online call, you need to develop additional modules. It increases the time spent on developing, making it more expensive
  • Speed and interface responsiveness. When an app that shows some data (for example, an online shop or a newsfeed) is developed, the speed of a cross-platform app is equal to a native one, but it will often be lower. If your app supports calls, video chats, AR, it works even slower compared to a native app. Users won’t like it if they miss half of what their interlocutor was speaking about, or if they are unable to catch their favorite Pokemon due to low interface responsiveness.

Advantages and disadvantages of native solutions

According to research conducted by Andrew Madsen’s blog, out of 79 most popular non-game applications in the App Store, about 53% are written in Swift, and the other 47% don’t use Swift. It’s important to mention that somebody from that 47% can be using Objective-C, which is a native language, too.

There is also research by, which says that ⅔ of all apps are native, for both Android and iOS. Why is that?


  • All peculiarities of a platform are considered. No doubt that developing an app for the both platform at the same time is convenient, but each one of them is individual. Requirements for safety, interface design, and payment system integration differ. For example, system elements that iOS and Android have are absolutely different (the example is on the image below). The user expects to see elements familiar to the platform.
ios and android differences
iOS and Android design differences
  • Speed and interface responsiveness. Native-written apps work faster. It’s a lot more convenient for a user to use an app where the animation is smooth, touching buttons is processed instantly, and they can scroll the screen without freezes, while quickly loading content. It is very important as people are actively using apps nowadays to go shopping, visit doctors, attend business meetings. No one would want their screen to freeze in the moment of payment or during important meetings. These things can make the user look for an alternative
  • No obstacles to updating apps or widen their functionality. Platforms evolve, they add new functions, and apps must support them. An iOS update can completely break an application. Unless cross-platform app developers release a new version, the app may not be working, and there is nothing you can do about it
  • Access to own functions and private API platforms. Swift developers have integrated useful modules into the apps, as we’ve mentioned earlier. Whenever you want to create an app with online conferences, AR, or sharing via Bluetooth (push ads upon entering a Bluetooth tracker area or money transfer in bank apps), the developers won’t have to create these modules themselves, which saves time and money
  • Safety. The source code of operating systems and native ways of development is closed. Gaining access to it is impossible, unlike cross-platform apps with an open source code that anyone can access.


  • You need to create two applications
  • You then need to support these two applications


Cross-platform and native ways of development have advantages and disadvantages to them. There is no multi-purpose tool that will be better everywhere. When choosing development tools, take an app type, app’s and platform’s peculiarities, your money, and goals into consideration.

For example, go for a cross-platform solution, if you:

  • Are limited in time and money
  • Need your app to look the same on all platforms, despite their peculiarities
  • Don’t need your app to use platform-specific functions like working with the phone camera, difficult animations, photo and video editing, Bluetooth, online calls
  • Don’t require your app to be extremely safe

Examples: news apps, pizza ordering apps, a beauty salon registering apps, online shops.

On the other hand, go for native tools if your app:

  • Is supported during a long period of time
  • Uses a phone camera, difficult animations, Bluetooth, video and audio calls, streams
  • Requires support for new platform functionality after the platform update
  • Has different design on different platforms
  • Looks the way the platform guidelines recommend
  • Is demanding to safety
  • Requires high speed of work and interface responsiveness, however new and powerful a device is.

Examples: e-learning, medicine, internet TV, video chats, video surveillance, augmented reality.