How We Built a Cross-Platform Music Sharing App When Native APIs Said It Was Impossible

A client came to us with a deceptively simple idea: build a mobile app that lets users share the music they're currently listening to — regardless of which player they use. On the surface, it sounds like a weekend project. Under the hood, it's a technical minefield that most development teams would dismiss outright.

Here's the core problem: modern mobile operating systems — both iOS and Android — do not freely expose what audio is playing in another application to a third-party React Native app. There is no universal API that says, "Here's the song the user is listening to right now." The sandbox model that protects user privacy also blocks exactly the kind of cross-app awareness this product required.

This article walks through the challenge, the architectural decisions we made, and the practical approach that allowed us to deliver a working product that's compatible with virtually any music source.

The Core Technical Challenge: Why "Auto-Detection" Isn't Straightforward

When our client described the feature, the expectation was clear: the app should automatically detect the currently playing track and let the user share it with friends. In native mobile development, this kind of system-level audio detection faces hard limits.

• iOS restricts background process communication heavily. A React Native app cannot query the system's "Now Playing" info reliably without specific entitlements, and even then, the data returned is inconsistent across players.
• Android offers NotificationListenerService, which can read media notifications — but this requires explicit user permission, varies by manufacturer, and breaks frequently with OS updates and custom skins from Samsung, Xiaomi, and others.
• React Native adds another layer of abstraction. Even where native modules could theoretically access playback metadata, bridging that data into the React Native JavaScript thread requires custom native code per platform — multiplying the maintenance burden.

In short, a fully automatic, universal "detect what's playing" solution does not exist in the React Native ecosystem today. Any team that promises otherwise is either cutting corners or building for a single platform and a single music player.

Our Solution: The Share Sheet as a Universal Input

Instead of fighting the operating system, we decided to work with it. Both iOS and Android have a deeply integrated sharing mechanism — the Share Sheet. Nearly every music player in existence supports it: Spotify, Apple Music, YouTube Music, SoundCloud, Tidal, Deezer, and even niche players.

The user flow we designed is elegant in its simplicity:

• The user opens their music player of choice and navigates to the track they're listening to.
• They tap the Details or Info option for that track.
• They tap Share, which opens the native Share Sheet.
• They select our app from the list of share targets.

When the user shares a track this way, our app receives a structured payload — typically a URL or a deep link — that contains enough information to identify the song. We then parse this data, resolve it against music metadata services, and present a rich, shareable card within our app's social feed.

Why This Approach Wins

The best technical solution is often the one that leverages existing platform behavior instead of trying to circumvent it.

This Share Sheet approach gave us several critical advantages:

• Universal compatibility. Any music app that supports the native share function works with our app. We didn't need to write integrations for dozens of players — the OS handles the handoff.
• No special permissions. Unlike notification listeners or accessibility services, the Share Sheet requires zero elevated permissions. This means fewer friction points during onboarding and no risk of app store rejection.
• Cross-platform consistency. The Share Sheet works nearly identically on iOS and Android, which meant our React Native codebase could handle incoming share intents with minimal platform-specific code.
• Future-proof design. New music players automatically work with our app the moment they support the system share function — which virtually all of them do.

Auto-Tracking: Going Further Where APIs Allow

While the Share Sheet approach solved the universal case, our client also wanted a more seamless experience for users who are willing to connect their accounts. So we built a secondary system: auto-tracking via official APIs.

The most mature and accessible API in the music streaming space belongs to Spotify. Spotify's Web API provides endpoints that return the user's currently playing track in real time, including metadata like artist, album, track name, artwork, and playback status. By authenticating users via OAuth 2.0, our app can periodically poll or respond to playback changes and automatically post what the user is listening to (in our case, interval polling) — without any manual sharing step.

How We Architected It

We built the auto-tracking module as a pluggable integration layer. The architecture looks like this:

• A central MusicSourceManager that defines a standard interface for any music service integration: authenticate(), getCurrentTrack(), onTrackChange().
• A SpotifySource module that implements this interface using Spotify's Web API and handles token refresh, rate limiting, and error recovery.
• A FallbackShareSource module that handles all incoming Share Sheet intents and normalizes the data into the same track format.

This means that when Apple Music, YouTube Music, or any other service eventually opens up a public API for current playback data, we can add a new source module without refactoring the app. The product is designed to scale its integrations over time, while the Share Sheet ensures it works universally from day one.

A Practical Look at the User Experience

Let's walk through two real scenarios that illustrate how the dual-approach system works in practice:

Scenario 1: Spotify User with Connected Account

Maria connects her Spotify account during onboarding. As she listens to her morning playlist, the app detects each track change via the Spotify API and displays her listening activity on her profile in near real time. Her friends can see what she's listening to, tap on a track, and open it in their own preferred music app. Maria doesn't have to do anything after the initial setup.

Scenario 2: Apple Music User (No API Available)

James uses Apple Music, which does not offer a third-party current-playback API. When he hears a track he wants to share, he taps the three-dot menu in Apple Music, selects Share Song, and picks our app from the Share Sheet. The app instantly parses the Apple Music link, resolves the track metadata, and posts it to his feed. The entire process takes under five seconds.

Both users end up with the same result — a shared track on their profile — but the path differs based on what's technically possible with their music source. This graceful degradation is key to a product that feels complete rather than half-built.

Key Takeaways for Business Decision-Makers

This project reinforced several principles that apply far beyond music sharing:

• Don't let technical limitations kill a product idea. The "impossible" label often means "impossible if you approach it the obvious way." Reframing the problem — in our case, from auto-detection to share-intent capture — opened a viable path.
• Design for the universal case first, then optimize. The Share Sheet works with every music player. Auto-tracking via APIs is a premium enhancement. Shipping the universal solution first meant the product was viable from launch, not dependent on a single integration.
• Invest in extensible architecture. By building a pluggable integration layer, we ensured that the product can grow with the market. As more music services release APIs, the app becomes more automated — without a rewrite.
• React Native is capable — with the right team. Cross-platform frameworks get criticized for lacking native-level access. In practice, a skilled team can bridge native functionality precisely where needed while keeping the majority of the codebase shared.

The Bottom Line

When a client brings you an idea that the platform "doesn't support," the answer is rarely a flat no. It's a design challenge. In this case, by combining the native Share Sheet as a universal input mechanism with targeted API integrations for platforms like Spotify, we delivered a music-sharing app that works with any player, on both iOS and Android, built in React Native.

The product launched with full functionality, zero dependency on a single music service, and a clear upgrade path as the streaming ecosystem evolves. The app is live on both the App Store and Google Play, handling tracks from any music source users bring to it.