I am trying to make a 3D audio player with a retro cassette-like interface. The first thing is to make audio playable smartphone-wise, even when the game is in the background or when the screen is locked. The second is to allow the game to process its logic. I have playlists that the user combines via 3D tapes, dropping them in the "play next" bin, which is then executed with colliders, etc. I also have some features with 3D audio, which requires the scene to run in the background and send audio outside (considering audio players and audio listeners for 3D audio).

Is it possible to do these things I want using Unity?


The actual answer to your question is, no you can't implement all the above features. That is, you can't implement them using Unity only.

Potentially, you can implement all the above features, both for the Android and iOS platforms. However, this requires you don't build the project within Unity. Instead, you need to: Export the project to Android Studio/Xcode. Add the additional features. Finally, create an app build.

Android and iOS development follow different workflows, and their export processes differ as well.


Activities vs. Services

Android apps mainly consist of Activities. They are the main building blocks for most apps. They have a lifecycle and manage callbacks and high-level logic. Usually, Activities feature the app UI and invoke events on user input. By design, they are active as long as they have focus and stop when users close, minimise them or switch to a different app.

On the other hand, Services perform tasks and long-running operations in the background. Users never interact with Services. If a Service is there to provide a service (pun not intended) or expose some data, there's a delegated Activity to receive that data and display it to users. In the case of audio streaming, the Service is only playing the audio, while an Activity or a widget can call functions on it to stop and resume playback.

Unity apps are Activities. Then, implementing background music playback in your app requires you to add it yourself, for Unity doesn't provide these low-level features. But, Android Studio does.

In this discussion on the Unity Forums, user diogo_gc seems to have implemented a working solution successfully. They exported their Unity project to Android Studio, implemented the discussed code, and built the app. The discussion end dates back to 2018, so it's likely not to be obsolete yet.

Exporting the Project

The Android export process is straightforward. You select Gradle as Build System, enable the Export Project checkbox, and click the Export button.

The official Unity documentation describes this process in the Exporting the Project section. Also, this Unity support article discusses the same argument in detail, including how to later migrate a project to Android Studio (thus, how to import an existing Gradle project).


An iOS app structure and architecture are quite different from Android. There might be similarities and correspondences amongst components, but in the end, they follow diverse philosophies. If you want to read more about it, you can check this article on the overview of iOS apps.

But, can it be done?

Yes, iOS devs too found a solution to work this out. Of course, there's no reason not to allow background music playback on this platform as well. However, as said above, you'll need to create a different implementation only for iOS, since the features you want to add work on a lower level than what Unity has to offer.

This whole discussion on the Unity Forums involves different proposals and further fixes to implement background audio playback. The last messages date back to 2021, which is very promising.

Exporting the Project

Anytime you build an iOS app, Unity creates an Xcode project. Then, you just need to load it within Xcode itself and build the app. Before doing so, you can also tweak some settings or even add new features. You can find more information about the structure of a Unity Xcode project in the official documentation.

Finally, the BackgroundModesOptions exposes some flags to tell iOS what the behaviour of your app is going to be when it is running in the background. It's likely not intended to be used on its own, but combined with additional programming in Unity and/or Xcode.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .