The same tap on the same screen produces two different sounds depending on whether the user is in a banking app or a puzzle game. This is not a stylistic preference. It comes from a fundamental difference in what the sound is for and who the user is in each context.
Most UI sound design articles treat apps and games as the same problem with slightly different aesthetics. They are not the same problem. A game UI sound is part of an experience the player deliberately entered. An app UI sound is often something the user would prefer not to hear at all. Those two starting points produce completely different design decisions.
This article is about where the two diverge and what to do about each difference. The general system for designing UI audio is covered in How to Design Game UI Sounds, and the specific case of notifications is covered in How to Make Notification and Alert Sounds for Apps and Games. What follows is the comparison between the two contexts.
The User Did Not Choose the Sound
The first and largest difference is the user's relationship with the audio.
A player who launches a game has opted into an audio experience. They expect sound, they may be wearing headphones, and they have implicitly agreed that the game's audio is part of what they are doing. A UI sound in a game is contributing to something the user asked for.
A user who opens a banking app, a note-taking app, or a shopping app has not opted into anything. Most apps are used with the phone on silent, and many users experience any app sound at all as an intrusion. In this context, an app UI sound has to justify its existence every time it plays.
The practical consequence is that the bar for adding a sound to a mobile app is much higher than for a game. A game can have fifteen UI sounds and the player will accept all of them. An app with three UI sounds will produce complaints. The most common design decision in app audio is not "what should this sound like" but "should this have a sound at all."
This is not a rule that games should follow. It is an observation about where the two contexts differ. Games can afford more UI audio because the user wants it. Apps cannot, because the user tolerates it.
How the OS Environment Changes the Design
A game owns its audio environment. When the player is in the game, the game is the only thing producing sound, and the game controls the mix.
An app shares the audio environment with everything else on the phone. Notifications, alarms, music playback, incoming calls, voice assistants, and other apps are all producing sound simultaneously or interrupting each other. An app UI sound that is fine in isolation can conflict with the user's notification tone, their alarm, or the podcast they are listening to in the background.
The design implications of this are specific.
App UI sounds should be quieter than game UI sounds. The app does not control what else is playing, and it should not try to dominate. A game UI sound can be mixed to cut through the game's own music and effects. An app UI sound should sit under whatever else the user is listening to.
App UI sounds should not assume audio focus. On both iOS and Android, playing a sound can interrupt or duck background audio depending on how the app requests audio session priority. An app that pauses the user's podcast to play a click sound will lose that user. Games are granted audio focus as part of launching; apps are not.
App UI sounds should respect silent mode correctly. On iOS, sounds played through the standard audio session are silenced when the ringer switch is set to silent. Sounds played through the playback audio session are not. An app that plays UI sounds through the playback session will make noise even when the phone is on silent, which is a recurring source of one-star reviews.
Length: Why Apps Can Often Use No Sound At All
A game UI sound serves a feedback function. The player needs to know the tap registered, the menu opened, the toggle flipped. Without the sound, the game feels disconnected from the input.
An app UI often has visual feedback that is already sufficient. A button that visibly changes color when tapped does not need a sound to confirm the tap. A menu that slides open does not need a sound to confirm the slide. The visual feedback loop is complete on its own.
This is why many well-designed apps have no UI sounds at all, or only a very small set. The default behavior of a modern mobile app is silence. Sound is added only when there is a specific reason: a confirmation that the user needs to notice, an error they need to be alerted to, or a moment where the app is doing something the user cannot see.
A game, by contrast, defaults to sound. Removing all UI sounds from a game is a stylistic decision that changes the experience. Removing all UI sounds from an app is the normal default that most users expect.
The number of sounds each context actually needs reflects this. A game with ten interactive UI elements might have ten UI sounds. An app with ten interactive elements might have two, or none.
Emotional Register: Neutral vs Expressive
The emotional register of a game UI sound is part of the game's identity. A cozy farming game has warm, soft UI sounds. A competitive shooter has sharp, aggressive ones. The UI sounds are expressions of the game's character, and changing them changes the feel of the game.
App UI sounds have a much narrower emotional range. The acceptable register is roughly "neutral to slightly positive." An app UI sound that expresses joy is uncomfortable. An app UI sound that expresses aggression is a design failure. The user did not ask for an emotional experience from their banking app.
The exception is apps that are designed as experiences: meditation apps, habit trackers, journaling apps, children's educational apps. These have more latitude because the user's relationship with them is closer to a game's relationship with its player. But even here, the emotional range is narrower than in games.
The specific design consequence is that app UI sounds tend toward sine and triangle waveforms in the mid frequencies with small intervals. Game UI sounds have access to the full palette, including square waves, wider intervals, and more extreme pitch ranges. The reasons for these preferences are the same as those described for notification sounds.
Accessibility: A Bigger Deal in Apps Than Games
Accessibility matters in both contexts, but the requirements differ in ways that affect UI sound design.
App accessibility standards assume that the user may be using a screen reader, may have hearing loss, or may be operating the phone entirely through voice or gestures. In these contexts, UI sounds are supplementary to the primary feedback mechanisms. An app that relies on sound to communicate state is an app that fails for some of its users.
The practical consequence is that app UI sounds should reinforce what the visual interface already communicates, not replace it. A toggle that says "on" visually should not need its sound to tell the user the state. The sound is a bonus for users who hear it, not a requirement for using the app.
Games have more latitude here because games have many other ways to communicate state. A visual cue on the screen, a change in the game world, a haptic response. The sound can carry important information because it is not the only channel.
There is also a technical side to this. Both iOS and Android have accessibility settings that reduce or disable motion and sound effects, and both have APIs for detecting whether the user has enabled "reduce sound effects" or similar preferences. Apps that respect these settings are considered better-behaved than apps that do not.
Interaction Frequency and the Fatigue Problem
A game UI sound is triggered by the player's action, and the player sets the pace. A player who taps a menu button ten times in a minute is choosing to do so. The sound is a consequence of an action the player decided to take.
An app UI sound is also triggered by the user's action, but the app's usage patterns can produce much higher frequencies. A user typing in a notes app might produce a keyboard click sound hundreds of times per minute. A user scrolling through a feed might produce a scroll tick sound continuously. These are not the user choosing to interact; they are the user doing what the app is designed to support.
The consequence is that app UI sounds have a much stricter repetition tolerance than game UI sounds. A game UI sound that plays a few dozen times per session is unremarkable. An app UI sound that plays a few hundred times per session has to be designed for that frequency, which usually means shorter, quieter, and less distinct.
Many apps solve this by simply not having sounds for high-frequency interactions. A keyboard click sound is rare in apps, even though it is common on desktop. A scroll tick is even rarer. The default is silent because the alternative is annoying.
Building a UI Sound Set for Each Context
The design process is different enough that the working order changes between apps and games.
For a game UI: start with the categories. Click, hover, toggle, confirm, cancel, error, notification. Assign an emotional character to each based on the game's tone. Build a shared base tone and derive the variations from it. Test the full set in gameplay context. The full process is covered in How to Design Game UI Sounds.
For an app UI: start with the question of which interactions need sound at all. Most will not. Identify the small set of moments where the visual feedback is insufficient or where the user needs to be alerted to something they cannot see. Design only those sounds. Keep each one short, quiet, and emotionally neutral. Test with the phone on silent, with background music playing, and with the screen reader active.
The single most useful rule for app UI sound design is to start with silence and add only what is necessary. The single most useful rule for game UI sound design is to start with the game's character and design sounds that express it. These are opposite starting points, and they produce opposite results.
What Each Context Can Learn from the Other
The two contexts are not in competition, and each has useful constraints that the other can borrow.
Games can learn from apps about restraint. Many games have more UI sounds than they need, and trimming the sound set to only the sounds that carry information produces a cleaner experience. A game that removes its hover sound entirely, for example, often feels more focused than one that plays a tick every time the cursor moves across a menu item.
Apps can learn from games about emotional consistency. A well-designed game UI sound set feels like it belongs to one game, with a shared tone and pitch range across all the sounds. Many apps have UI sounds that were chosen independently for each screen, and the result sounds like a collection rather than a set. Applying the game approach of deriving all sounds from a shared base would improve most apps that have multiple UI sounds.
The technical side of mobile audio, including file size constraints and format choices, is covered in How to Optimize Game Sound Effects for Mobile Devices. Those constraints apply to both apps and games, and the design decisions should account for them from the start rather than as an afterthought.
Create a UI Sound for Either Context
Open the SfxMaker generator and build a short UI sound. For a game, experiment with a distinct character. For an app, keep it short, quiet, and neutral. The same generator covers both.
Open SfxMaker Generator →Common Mistakes
- Treating an app UI as a game UI with less audio. The relationship is different, not just the amount. An app UI sound that is a quieter version of a game UI sound still feels wrong, because the emotional register is off.
- Adding UI sounds to an app because other apps have them. Most apps do not need UI sounds, and the ones that have them are often criticized for it. The default should be silence.
- Using the playback audio session for app UI sounds on iOS. The sound will play even when the phone is on silent, which is a common complaint. Use the ambient or standard session instead.
- Designing game UI sounds without a shared character. A set of UI sounds that do not share a tone or pitch range sounds like a collection rather than a set. The game feels less cohesive as a result.
- Ignoring accessibility in either context. Sounds should reinforce the visual feedback, not replace it. An interface that requires the audio to be usable is broken for some users.
- Testing app sounds with the phone's volume turned up. Most users run their phone at partial volume, in silent mode, or with background audio playing. The sounds need to work in those conditions, not in the loudest possible scenario.
How to Decide Which Approach Fits a Project
If the answer to "is this an app or a game" is not obvious from the project description, three questions tend to resolve it.
Does the user want to hear sound? If the user chose this experience for its entertainment value, it is a game context. If the user chose it for a functional purpose, it is an app context.
Is the sound reinforcing something the user already knows, or adding new information? If the sound is confirming what the visual interface already shows, the app approach applies. If the sound is part of how the user understands what is happening, the game approach applies.
Would the user be annoyed if the sound played every time? If yes, the sound should not exist in the first place. If no, the design can be more expressive and more prominent.
The categories are not strict, and some products sit between them. Meditation apps, habit trackers, and children's apps fall somewhere in the middle, and they can borrow from both approaches. The key is to identify where the product sits on the spectrum before designing anything, because the design decisions follow from that position and are difficult to reverse later.