Mobile softphone, fit for White Label: how we did it
Recently we took part in a BTC (Big Telecom Conference) on Asterisk & VoIP and there announced a long-awaited softphone application for Android as well as a softphone app for iOS, no less long-awaited either :)
And this is what we’ve said.
Who needs a mobile softphone
Windows and macOS form an office ecosystem: these operating systems are for secretaries, lawyers, book-keepers, contact center agents, supervisors and their big shots. This is why in our product line there are solutions both for Win and macOS.
Meanwhile many companies have traveling employees with smartphones: salesmen, engineers, drivers, freight forwarders, you name it. Do they interact with clients, do they phone them? Sure, that goes without saying. Do employers need the opportunity to connect a company smartphone with a PBX? No doubt.
For this reason we often get asked about a mobile softphone: such questions came both from companies with “travelers” and telecom providers. It’s clear why the second pays attention too: they want to make business on the first offering not only desktop solutions but Android and iOS versions as well… ideally under their own names and logos.
According to our guys, workers not parting with smartphones look that way. Indeed, if the smartphone is the only channel and calls are plenty and need to be responded… well, you know :)
When a critical mass of the questions reached, we thought: why not? And decided: we’ll do it. We'll do a mobile softphone fit for White Labeling!
Development problem statement
The key issues were the following: what’s better for backend; languages and frameworks to choose; does cross-platform approach have right to life. And last but not least — what about app’s deep sleep: it’s very annoying when an app cannot wake up from sleep mode; besides, this is fraught with missed calls and lost clients. (Looking ahead, we’ve coped with it successfully too but that’s a subject of another separate post.)
Technology stack: framework, language, and experience of others
Sorting through technologies, we’ve found out something interesting about Acrobits, Zoiper (they have mobile apps too), WhatsApp, and Telegram which can also be referred to as softphones (with some exaggeration though) as there is RTP traffic.
For example, we discovered that for Windows all they are written in Java (language) and Kotlin (framework); for macOS that’s Swift and Objective-C respectively.
As for the backend, everyone has their own way: WebRTC, PJSIP, or even something self-written. What did it give us? Just a premonition that our way will unlikely be a cakewalk :)
Choosing between cross-platform and native
We raised the question: what if there will be one codebase for iOS and Android? Is it better? (We supposed yes because of halved work and the amount of code.) Is it easier?
Then we tried out many different combinations: WebRTC and PJSIP acted as the basis for data transfer, and already mentioned Swift and Kotlin as native languages. We also tried three cross-platform frameworks: Qt, React, and Flutter. What we finally got had both pros and cons. In no case there was no flawless victory however one pair turned out to be an unequivocal underdog: Flutter + PJSIP combo didn’t work at all.
The offspring of Flutter and WebRTC turned out to be more viable, but only just. We dug deeper (might get lucky?) but gave it up soon: one day we walked across some repository where there was an attempted solution. The community tried to solve the issue similar to ours… and the source code already had 8 000 lines wherein it seemed to be just a beginning.
At that moment, we got thoughtful and started feeling doubts.
So we stopped the experiment. This made Flutter the first who has left the project.
Then we dealt with the next squad of guinea pigs for interbreeding, namely PJSIP, WebRTC, and React, a cross-platform framework.
In both pairs we got something working (a pro in the piggy bank of pros!). But there seemed to be an uninspired movie trailer: all punchlines already shown, trash remains. We just couldn't shake the feeling that various drawbacks are bound to come out (life is not all beer and skittles, there are pros and cons too!). Let’s call it intuition. A volitional decision was made to exclude React from consideration.
So the list was shortened to one candidate from cross-platform party (Qt), one from Android-native (Kotlin), and another one from Apple (Swift). They were to clash in the final battle.
Show me your face
We decided that the first (and probably the one) fight will be with the green people representative. The competition rules are: we assemble a mobile softphone on Qt and Kotlin; in both cases equal effort to spend; then we compare the results. Should Qt get lost, it automatically makes Swift a winner too. If Qt wins, there must be one more direct struggle: Qt vs Swift. In other words, the cross-platform essence should prove the superiority whenever, otherwise it defeats the point of using.
Speaking of, look who's here and guess who’s who.
Qt is on the left, Kotlin is on the right.
At first sight, they look similar. But looking closely you discover strange shadows under the buttons, adhesion to the left side, and other details which appear while using. Little things, and the Devil there.
Sure, the left interface can be improved. Yes, technical details could be fixed. But there is extra work whereas the key criteria is equal resources spent (time and efforts).
So the cross-platform Qt ceded powers to native languages, and this in turn meant we should make two codebases i.e. double work… of course if we need quality. Sure, we need: quality is our second name. We love clients and take care of them.
Nowadays
Today we have a good-looking and stable mobile softphone fit for White Label and ready to be sold under your name and logo. The Android version is written on Kotlin, and the iProne’s one is on Swift. As an alarm clock that provides timely awakening and prevents missed calls, we employ a PUSH-server.
Ladies and gentlemen, that means whether you need a White Label Mobile Softphone — you know what to do. (Just let us know and send a message to info@softphone.pro 😉)
And let the mobility force be with you 📱
YOU MAY ALSO LIKE
Blog Paid softphone VS free dialers
Blog Softphone actually: what people say
Blog SIP vs VoIP, dialers VS softphones: differences and similarities
Help How to improve SIP call quality
