Privacy
What data MiniCycle collects, and what stays on your phone
A period app sits on a sensitive subject, so it is fair to ask where the data goes. MiniCycle's answer comes in two parts that people often fold into one. Your cycle data, meaning the dates, the notes, the activity markers, and the settings, stays on your phone. Separately, the app includes Firebase Analytics, which logs how the app is used: that a screen opened, that a tab was tapped, that a record was saved. Those are two different streams, and the second one is built to carry none of the first. Here is the whole split in plain terms, including the parts an honest answer has to admit it cannot promise.
Two streams that get confused for one
The mix-up is understandable. Stored on your device and nothing leaves the app sound like the same claim, but they are not. MiniCycle keeps your cycle records local, and it also sends usage analytics. Both are true at the same time.
So the honest summary is not that MiniCycle collects nothing. It is that the thing most people worry about, their period dates and their notes, is not what the analytics carry. The events describe how you move through the app, not what you wrote down in it.
What stays on your phone
Period dates, daily notes, sexual-activity markers, and your cycle settings are stored locally on the device by default. There is no MiniCycle account to create, and no MiniCycle server holding your history.
If you turn on iCloud Sync, a copy goes to your own private iCloud account through Apple CloudKit, so you can restore it on a new iPhone signed in to the same Apple ID. That copy lives in your iCloud, not on a MiniCycle server. MiniCycle does not run a sync service of its own.
What the app's analytics actually log
The app includes Firebase Analytics, Google's free app-measurement SDK. Google's own documentation describes how it works: add the SDK and data collection begins automatically, capturing a set of standard events while letting the developer define custom ones. In MiniCycle those events cover app opens, screen and tab navigation, calendar interaction, broad record-action categories, settings changes, notification-permission results, and whether optional iCloud Sync is on.
The purpose of that data is usage patterns. Which screens get opened, where people tap, whether a setting gets changed. It is the same shape of product-interaction data that Apple's privacy framework lists as app launches, taps, and clicks.
What those events are built to leave out
This is the part that matters for a cycle app. The analytics events are designed not to include your period dates, the text of your notes, your sexual-activity markers, your exact cycle settings, exact notification times, or your cycle history. A record-action event records that a record was created or edited. It does not carry the date you logged or what the record was.
So a period was saved on some day is the shape of the signal, not your period started on the 12th. The line is drawn on purpose. It is what lets the app see that a feature gets used without seeing your cycle.
Why on-device and collected are not the same word
Apple draws a specific line here, and it is worth borrowing. In Apple's terms, data processed only on the device is not collected at all. Collect means transmitting data off the device and keeping it in readable form for longer than it takes to handle the request. Your cycle records sit on the on-device side of that line.
The analytics events sit on the other side. They do leave the phone, bound for Google's Firebase. That is the whole reason this post pulls them apart rather than waving at the word privacy. The useful question is never whether anything leaves the phone, but which thing, and carrying what.
The website is a separate system
The site you are reading this on uses Google Analytics to count page views and see where visitors arrive from. That is the website, not the app, and the two are not joined. Website analytics do not include any in-app period dates, notes, or cycle history.
It is easy to blur because both involve Google. But a blog page view and an app record are different data sitting in different places, and neither reaches into the other.
What this can and cannot promise
An honest version has limits. Firebase Analytics is a third-party SDK, so the usage events go to Google under Google's terms, not to MiniCycle alone. The design keeps cycle content out of those events, but it is still analytics, and designed not to include describes the intent and the implementation, not a courtroom guarantee.
Local storage is also not the same as airtight medical privacy. Device backups, your iCloud settings, screenshots, and a shared or unlocked phone all still matter, and none of those are settled by where the records sit. The app's stance is narrow, and meant to be plain: keep the cycle data on the device, send only usage signals built to carry none of it, and say out loud that a third-party SDK and the website analytics are part of the picture. The full wording is in MiniCycle's privacy policy.
A worked example of one analytics event
Picture logging a period start on a Tuesday. On your phone, MiniCycle saves the actual date, and that date is what the calendar and the predictions read from. To Firebase Analytics, the app reports something far thinner: a record-action event, the broad category that a record was created. The Tuesday is not in that event. Neither is the note you might attach to it, nor whether it replaced an earlier entry.
Run the same thing through Apple's definitions and the split is clean. The saved date is processed on the device, so by Apple's wording it is not collected. The record-action event leaves the phone, so it is, and it shows up as the kind of product-interaction data Apple lists as taps and launches. Same tap, two very different traces.
Frequently asked questions
Does MiniCycle upload my period dates? No. Period dates, notes, activity markers, and settings are stored on the device by default, and the analytics events are designed not to include them. If you turn on iCloud Sync, a copy goes to your own private iCloud, not to a MiniCycle server.
So MiniCycle has no analytics at all? It does. The app includes Firebase Analytics for usage events, and the website uses Google Analytics. The accurate claim is not no analytics, but that the analytics are built to carry usage signals rather than your cycle data.
Can I turn the analytics off? The events are usage analytics rather than account data, and the cycle content is kept out of them by design. For what each data type is and how it is used, the MiniCycle privacy policy is the reference, and Apple's App Store privacy details explain the data categories.
Is local storage the same as private? It helps, but it is not a full guarantee. Device backups, iCloud settings, screenshots, and a shared phone all still matter regardless of where the records sit.
The one-line version
MiniCycle keeps your period dates, notes, sexual-activity markers, and cycle settings on the device by default, with no MiniCycle account; optional iCloud Sync stores a copy in your own private iCloud through Apple CloudKit, not on a MiniCycle server. Separately, the app includes Firebase Analytics, which logs usage events such as app opens, screen and tab navigation, calendar interaction, broad record-action categories, settings changes, and notification-permission results.
Those analytics events are designed not to include your period dates, note text, activity markers, exact settings, exact notification times, or cycle history. In Apple's terms, on-device data is not collected, while events sent to Firebase are. The website separately uses Google Analytics for page views. It is still analytics through a third-party SDK, not a no-data guarantee, and the full wording is in MiniCycle's privacy policy.
MiniCycle is built for a clean iPhone period calendar, local records, simple statistics, and a home screen widget.
View on the App Store