Mixen Privacy Policy

Last updated 4 February, 2026

This privacy notice for the Mixen iOS App (“the app”) from Mastfrog, LLC (“we”, “us”, “our”), describes how and why we might access, collect, store and/or share (“process”) your personal information when you use our services, including when you:

Download and use the app
Engage with us in other ways, including any marketing or events

Mixen iOS App Privacy Policy

We don’t collect your personal information. We don’t want to or need to.

The app, Mixen, is an audio player that scans your audio files on your devices and provides convenient ways to organize and annotate it. Your data always stays on your devices - nothing about it or what you do with it is sent to Mastfrog, LLC by the app. It does not contain any sort of tracking technology, nor will it in the future.

If you give tha app permission to, it will access iCloud folders in your Apple account, for purposes of locating audio files to play. All information obtained by doing that remains on your device and/or in your iCloud storage. We never see it.

Anonymous Metrics

We use iOS’s built-in analytics and metrics support to obtain anonymous information about feature use, app and user behavior, app crashes or issues and similar in order to know where to focus our efforts when improving the app, bug-fixing or prioritizing features. The following list describes the anonymous metrics are sent to our server once per day, and how they are used:

Metrics Period Start and Duration - The time period the metrics represent activity during. This simply allows us to organize and analyze all of the subsequent data points:
Unique Install ID - A random number generated on first start associated with an install of the app on one device. Contains no personally identifying information. This allows us to differentiate metrics from different devices so that trends can be aggregated over time.
Unique Customer ID - A random number generated on first start the first time the app is run and shared across the user’s devices in iCloud. Contains no personally identifying information. This allows us to understand how many of our customers use the app across multiple devices, and thus how to prioritize feature development that specifically benefits users who have more than once device.
IP Address - The IP address the metrics were received from. This allows us to know in approximately what parts of the world we have customers, and therefore what languages and locales we may want to add localizations for, or in what regions we may want to advertise in.
Plays - the number of times the app began playing an audio file during the collection period. This allows us to know what is typical and outlier for our users and helps prioritize feature development.
Playlist Plays - the number of times the app began playing an audio file due to the next song coming up in the playlist. This allows us to know how much the app is being used for general listening over a period of time versus to play specific songs explicitly, which helps us prioritize feature development.
Background Audio Play Time - the amount of time the app spent playing audio while not the foreground app during the collection period. This helps us to know how to prioritize features like automotive control iteroperability and graceful handling of audio interruption.
Foreground Time - the amount of time the app was the active app on the device during the collection period. This helps us to know how the app typically gets used and where we should focuse efforts on interactive or background audio features.
Background Time - the amount of time the app was running but was not the active app. This helps us to know what is the typical run-session duration and how to prioritize things like memory-use when in the background to ensure good user experience.
Device Kind, Model and Version - The specifics of what kind of device the app is installed on. This help us to know how to prioritize UI development where the presetation is different for large- and small-screen devices; and to identify if there are model-specific bugs that need addressing.
iOS Version - The operating system version running on the device. This allows to identify model-specific bugs, or problems that only show up on a newer version of iOS which need to be addressed.
App Build Version - The internal version number of the app. This allows us to know, in the case of crashes, if they are specific to a particular release, as well as how rapidly new releases get adopted.
Locale - The language, such as English or Spanish, that the device is set to. This lets us determine what locales it might be advantageous to translate the app into.
Song Count - The number of songs in the song library. This helps us to know, in aggregate, the size of music library the app needs to be able to support and the typical size it should be optimized for.
Audio File Count - The number of audio files in the song library. This helps us to know, as with songs, what is typical and what to optimize for, and lets us know how heavily the multiple-drafts-per-song features are used, in order to support what users actually use in future development.
Tag Count - The number of tags in the music library. This too helps direct future development, based on what is typical and outlier for our users.
Notes Count - The cumulative number of notes in the song library. This helps us understand what usage patterns are typical for the notes features, and helps direct future development.
Folder Count - The number of folders the app is set up to scan for audio files. This helps us to understand what is typical and what to optimize for.
Notes Interactions - The number of edits to notes during the metrics collection period. This allows us to understand how much the notes features are typically actively used.
Audio Files Added - How many audio files were added to the song library during the metrics collected period. This allows use to know usage patterns, and how frequently users add files, in order to better target future features and user interface development.
Library Location - Whether or not the song library metadata is (privately) shared in iCloud between the user’s devices.
Subscribed - Whether or not the user has a paid subscription. This allows us to differentiate between the usage patterns of non-paying and paying customers, and understand what usage patterns make users more or less likely to subscribe.
Cumulative Audio Playback Seconds - The total number of seconds the app has played audio for since installation. This statistic is useful in promotional materials, and to understand adoption and usage growth over time.
Cumulative Number Of Plays - The total number of times the app has begun playing an audio file since installation. This statistic is useful in promotional materials, and to understand adoption and usage growth over time.
ICloud Available - Whether the device is logged in to iCloud. This allows us to understand how much to prioritize iCloud-related features in development.
Normal Exits - Number of times that app was shut down (this most often happens by the OS killing the app to free memory to run other apps) during the collection period. This is useful primarily in concert with the subsequent two exit-related statistics:
Memory Related Exits - Number of times the app exited specifically because the operating system needed memory. This lets us know if, looking at trends after a release, if changes in that release have impacted the typical memory footprint of the app on user devices.
Crashes - Number of times the app exited abnormally - as in, due to programmer error, during the collection period. This lets us know if there are bugs we need to urgently fix.
Updated - Whether or not the metrics period contains data for more than one app version. This allows us to know, on releasing a new version, the rate of uptake and how many installs of the previous version still exist in the wild, which is helpful when making infrastructure decisions.
Test Flight - Whether the app is a beta-test version, so we can differentiate between issues in release versions and pre-release versions, and not mistake issues in beta versions for issues in production versions.
Developer Mode - An internal only flag indicating if the build was an internal development build, so artifacts from our own testing do not get mixed with and confuse our understanding of the usage patterns of customers with our own usage patterns.

We do not sell information about our customers to third parties, and we do not collect any information about you from third parties.

If you provide contact information via email or this web site, requesting contact, it will be retained in order to contact you.

Questions about this policy may be directed to info@mastfrog.com

We reserve the right to alter this policy in the future.