Aircall

Opening the app for the first time

Downloading the Aircall APK and opening it for the first time presents a clean login screen. No demo mode, no tour — just an email field and a password box. The app expects you already have an Aircall account from the web dashboard. This is not a standalone tool; it is an extension of a paid service. The dashboard login process takes about thirty seconds if you have credentials ready. Without an active account, the app offers no way to explore or test anything. That reality hits immediately. The interface is sparse but purposeful. A dial pad sits at the bottom, recent calls fill the middle, and a settings gear hides in the top corner. The onboarding experience assumes you have already set up your numbers, teams, and call routing on the desktop version. This mobile app is purely a client — a remote control for a phone system that lives in the cloud. The first call you make routes through the same infrastructure as the desktop app, using the same numbers and the same CRM integrations. There is no separate mobile number; the app uses your existing Aircall business line.

Setting up the app involves granting notification permissions and, if you want to use the GSM fallback, allowing the app to switch network connections. The permission request appears the first time you place a call over Wi-Fi. The app monitors your connection quality and suggests switching to cellular when the Wi-Fi signal drops below a certain threshold. That fallback feature is one of the few things that distinguishes the mobile experience from the desktop version. The desktop app relies entirely on your internet connection; the mobile app can hand off to the cellular network. This is not seamless — the handoff introduces a half-second audio gap — but it keeps the call alive. For sales teams taking calls in the field, that half-second gap is preferable to a dropped call.

How call recording and CRM logging work together

Call recording is automatic. Every inbound and outbound call gets recorded unless an admin disables it for a specific number. The recording happens on Aircall's servers, not on the device. This matters because the recording continues even if the app crashes or the phone loses signal. The audio file lives in the cloud. The AI transcription engine processes that file and generates a summary within a few minutes of the call ending. The summary includes key topics, sentiment scores, and action items. That summary then pushes to your connected CRM — Salesforce, HubSpot, or any of the 250+ supported integrations. The CRM integration is where the workflow gets interesting. The call log appears in the contact record automatically. The summary text fills a notes field. The recording link sits alongside the transcript. A sales rep can review a call from three weeks ago without leaving the CRM interface. The mobile app mirrors this — you can see call history, listen to recordings, and read transcripts directly on the phone.

The combination of automatic recording and CRM logging creates a paper trail that requires zero manual effort. The rep hangs up, the recording saves, the AI writes the summary, the CRM updates. No one types a note. No one copies a call ID. The workflow flows from the call to the record without interruption. But there is a catch. The AI summary is not always accurate. It misses context. It sometimes misattributes sentiment. A rep who relies solely on the AI summary might miss a subtle objection or a competitor mention. The recording is always there as a backup, but listening to a full recording takes time. The trade-off is speed versus accuracy. The automated workflow saves hours of manual note-taking but introduces a layer of machine interpretation that requires human review for critical conversations. This is the kind of detail you do not see on the Play Store page. The Play Store says "AI summaries" and "CRM integration" as separate bullet points. The real behavior — the automatic handoff from call to recording to transcription to CRM, with all its imperfections — only emerges when you actually use both features together.

Real-world performance and the bug landscape

The app works reliably for basic calling. Call quality is clear on a good network. The dial pad responds instantly. The contact list syncs without noticeable delay. But the reliability fractures around the edges. Users report frequent logouts. The app sometimes forgets credentials and forces a re-login mid-day. Notifications arrive late or not at all. The missed call counter occasionally shows the wrong number. These are not catastrophic failures; they are friction points. The kind of friction that makes a user sigh and reopen the app. The bigger complaints come from the billing and support side. Aircall charges $30 per user per month with a three-user minimum. That is $90 per month for the smallest team. The billing is annual by default. Canceling requires a support ticket. Support tickets often go unanswered for days. Users on Trustpilot describe being billed after cancellation requests. The app itself does not handle billing — that happens on the web dashboard — but the frustration bleeds into the mobile experience. The app works well enough to keep using, but the surrounding ecosystem creates a negative halo. The bug reports on GitHub highlight integration issues. The Aircall MCP integration returns stale cached data. Pagination limits cap the number of records you can pull. These are developer-facing problems, but they affect the user experience indirectly. If the API cannot fetch current data, the mobile app cannot display it.

The performance of the app on Android is mixed. Some users report smooth operation. Others describe freezing, crashing, and slow loading. The variation seems tied to device model and Android version. The app requires Android 9.0 or higher. Older devices struggle. Newer flagships run it without issue. The app uses WebRTC for voice, which is sensitive to network conditions. A poor Wi-Fi connection degrades call quality quickly. The GSM fallback helps, but it only activates when the Wi-Fi signal drops below a threshold. It does not activate based on latency or jitter. So a call can sound terrible over a congested Wi-Fi network without triggering the fallback. The user has to manually switch to cellular. This is a design choice that prioritizes cost savings over call quality. The app defaults to Wi-Fi to avoid cellular data charges. The user can override this in settings, but the default behavior is not obvious. The settings menu has a toggle for "Use cellular data for calls." It is off by default. Turning it on gives the app permission to use cellular data, but the app still prefers Wi-Fi. The actual network selection logic is not transparent to the user.

Switch to GSM: the fallback that almost works

The GSM network switching feature is one of the app's most touted mobile-specific capabilities. The Play Store description highlights it: "If your Wi-Fi network connection is unstable, switch to cellular network." The implementation is straightforward. The app monitors the Wi-Fi signal strength. When the signal drops below -80 dBm, the app displays a notification suggesting a switch. The user taps a button, and the app reroutes the call through the cellular network. The handoff takes about one second. The audio pauses briefly and then resumes. The call does not drop. The feature works as advertised, but the threshold is fixed. There is no way to adjust the sensitivity. A user with a weak but stable Wi-Fi connection might prefer to stay on Wi-Fi. The app does not offer that choice. The notification appears every time the signal dips below the threshold. This can happen frequently in a building with inconsistent coverage. The constant notifications become annoying. The user either ignores them or switches to cellular and stays there. The feature is useful but imprecise. It is a blunt instrument in a context that requires nuance. The app also does not track which network performed better for each call. There is no history of network performance. The user has to rely on memory and guesswork. This is a missed opportunity for a data-driven feature. The app could log network quality and suggest the best network based on past performance. It does not. The feature remains basic — a notification and a button. It works, but it could work better. The app ends abruptly here, with that observation hanging in the air. No summary. No verdict. Just the reality of a feature that does its job but leaves room for improvement.