---
title: "How to build a song recognition feature into your mobile app"
description: "A practical guide to adding music recognition to an iOS or Android app with the AudD API — capture, recognize, present results, and handle the edge cases."
slug: "/resources/articles/build-song-recognition-mobile-app"
section: "articles"
keywords: [audd, song recognition, mobile app, ios, android, music recognition api, shazam clone]
---

# How to build a song recognition feature into your mobile app

Song recognition shows up in social apps, radio apps, and anywhere users hear
music they can't name. Building it from scratch means massive music databases,
complex fingerprinting models, and substantial infrastructure. The shortcut is
a recognition API: you get to market faster without giving up accuracy or
reliability.

## How song recognition works

Song recognition derives a unique audio fingerprint from a brief sound clip.
The fingerprint captures what makes a recording acoustically distinct, then
gets matched against a reference database of known tracks.

The flow has four parts:

- **Capture and processing.** Your app records audio from the device
  microphone, converts it to a workable format, and extracts the relevant
  features — handling varying sample rates, background noise, and hardware
  differences along the way.
- **Fingerprint generation.** The captured audio becomes a compact fingerprint.
  With a hosted API, this happens server-side: you send the clip, the service
  fingerprints it.
- **Database matching.** The fingerprint is compared against the reference
  database to find a match. Users expect results quickly, so speed and
  precision both matter.
- **Metadata retrieval.** On a match, the response carries the track details —
  artist, title, album, release date, and streaming links — which is what your
  users see.

## Planning the architecture

Before implementation, decide how recognition fits your app's experience.

**Define the use case.** Different apps need different approaches:

- **Real-time recognition.** Discovery tools need instant results — the user
  taps a button and wants an answer. A short clip to the standard endpoint
  returns in under two seconds.
- **Background monitoring.** Radio or content tools run continuous recognition,
  identifying multiple songs over time. For a live source that never ends,
  AudD streams fit better than repeated clip recognition.
- **Batch processing.** Some apps work with pre-recorded files where thorough
  analysis matters more than latency — a good fit for the enterprise endpoint,
  which returns every recognized track in a long file with timestamps.

**Design the experience.** Plan for three things:

- **Visual feedback** — an animated waveform or pulsing button shows the app is
  listening.
- **Error handling** — not every sample matches; plan for noisy environments,
  obscure tracks, and dropped connections so failures don't feel broken.
- **Result presentation** — album artwork, streaming links, and quick save or
  share options make a result screen worth returning to.

## Why an API instead of building from scratch

Building your own recognition stack offers total control but demands real
resources: licensing agreements to assemble a catalog, deep signal-processing
and machine-learning work to reach commercial-grade accuracy, and serious
compute and storage to handle fingerprints at scale.

An API lets you focus on your app while leaning on established technology:

- **Faster development.** Skip catalog building and model training; integration
  is days, not months.
- **Accuracy you don't have to earn.** A hosted service has already tuned its
  matching against real-world audio at volume.
- **Automatic updates.** Database and model improvements arrive without work on
  your side.
- **Managed scale.** The provider handles infrastructure as your user base
  grows.

When evaluating APIs, weigh database coverage (AudD covers over 160 million
songs, plus a custom catalog for your own audio), recognition speed, audio
format support, and metadata depth.

## Sending audio from the client

On mobile, the request flow is the same standard networking you already use.

On **iOS**, configure `AVAudioSession` and capture with `AVAudioRecorder` or
`AVAudioEngine`, request microphone permission with a clear explanation, then
upload the clip with `URLSession`. Parse the response into your model types and
cache recent matches.

On **Android**, capture with `MediaRecorder` or `AudioRecord`, request the
runtime permission, and send the request with `OkHttp` or `Retrofit`,
configuring sensible timeouts. For continuous recognition, use a foreground
service with proper notification handling.

In both cases the server-side call is small. The simplest path is to upload
the recorded clip to your own backend and call AudD from there, keeping your
token off the device. A backend handler with the Python SDK:

```python
from audd import AudD

audd = AudD()  # reads AUDD_API_TOKEN; get a token at dashboard.audd.io

def identify(clip_url: str):
    result = audd.recognize(
        clip_url,
        return_metadata=["apple_music", "spotify"],
    )
    if not result:
        return {"matched": False}
    return {
        "matched": True,
        "artist": result.artist,
        "title": result.title,
        "album": result.album,
        "song_link": result.song_link,
    }
```

A no-match comes back as a successful response with an empty result, not an
error — branch on it explicitly so a quiet room reads as "try again," not a
crash.

## Optimizing recognition

A few factors affect accuracy, speed, and cost:

- **Sample duration.** A short clip is enough for the standard endpoint; you
  don't need long recordings. The endpoint caps uploads at 10 MB, so trim the
  clip before sending rather than streaming a long capture.
- **Noise reduction.** Light filtering helps in challenging environments — a
  high-pass filter removes low-frequency rumble while preserving the music.
- **Normalization.** Normalize levels so recognition performs consistently
  across playback volumes and recording conditions.
- **Caching.** Cache results locally to avoid repeat calls for the same content,
  with sensible expiration.
- **Offline handling.** Queue requests when connectivity drops and send them
  once it returns, rather than asking the user to start over.

## Handling edge cases

Robust recognition handles failure gracefully:

- **Unknown songs.** Some audio won't match. A message like "We couldn't catch
  that one — try holding the phone a bit closer" beats a generic error.
- **Poor audio quality.** Give actionable feedback: move somewhere quieter,
  turn up the volume, or wait for a cleaner moment in the track.
- **Network issues.** Retry transient failures with exponential backoff; hold
  the request locally where you can. The AudD SDKs already retry idempotent
  reads and parse responses leniently, so a missing optional field degrades to
  null rather than throwing.
- **Permissions.** Be upfront about why you need microphone access; clear
  explanations increase grant rates, and you should handle a declined
  permission gracefully.
- **Privacy.** Recognition processes audio server-side, so communicate your
  data-handling practices clearly.

## Testing

Test beyond the quiet room:

- **Devices.** Different models, microphone qualities, and OS versions.
- **Environments.** Noisy spaces, echo-heavy rooms, distant or low-volume
  sources — real users rarely listen in ideal conditions.
- **Content diversity.** Niche genres, non-English tracks, lo-fi recordings,
  and live versions, so you understand how the feature holds up across the range
  your users will throw at it.

Set a response-time baseline early so you catch regressions before users do,
and validate recognition against known content periodically.

## Conclusion

Adding song recognition to a mobile app is more approachable than it looks. You
don't build fingerprinting models or negotiate with labels — a recognition API
handles the hard parts. The work that matters is around the call, not in it:
sample deliberately, treat no-match as "try again" rather than an error, and
test in the noisy rooms your users are actually in.

---

**Related**

- [Build a Shazam-style "name that song" feature](/resources/recipes/shazam-clone)
- [Standard, enterprise, or streams: how to choose](/resources/concepts/standard-vs-enterprise-vs-streams)
- [Identify music in Instagram and TikTok content](/resources/recipes/instagram-tiktok-music-id)
- [API reference](https://docs.audd.io)