1. The architecture, in one minute
InstaCal is a native app for Mac, iPhone, iPad, and Apple Watch, sold once through the App Store. It reads calendars three ways, all of which keep your data inside infrastructure your organization already controls:
- Apple Calendar (EventKit). InstaCal displays whatever accounts macOS or iOS already syncs — iCloud, Exchange, on-premises CalDAV — through Apple's on-device framework. For those accounts the operating system does all the networking; InstaCal only reads the local database it maintains.
- Directly connected Google and Microsoft 365 accounts. Sign-in uses standard OAuth 2.0 with PKCE in the system browser sheet (
ASWebAuthenticationSession), so InstaCal never sees your password. Tokens are stored in the Apple Keychain, and sync requests go from your device straight togoogleapis.comorgraph.microsoft.com. - Directly connected CalDAV accounts and calendar subscriptions. You can also add a CalDAV account — iCloud, Fastmail, Yahoo, Fruux, or any server whose address you type — or subscribe to a
webcal/HTTPS.icsfeed. Here InstaCal is itself the client: it signs in with the username and app-specific password you enter, over HTTPS only, and contacts the server you named and no other. There is still no Higher Bar hop in the middle; section 2 spells out exactly what those requests carry.
Two optional non-calendar connections work the same way. Todoist can be connected to show tasks beside your events, and Zoom to attach a meeting link when you create an event. Both sign in with OAuth 2.0 and PKCE from the device, hold their tokens in the Keychain, and are contacted directly. Neither is on by default, and neither sees your calendar: Zoom is told only the title, start time and length of the meeting you are creating. From InstaCal 3.9, the connection to Zoom is also certificate-pinned, so an interception proxy cannot read the Zoom token in transit, even on a device set to trust that proxy.
There is no InstaCal account to create, no Higher Bar server in the sync path, no token-broker service, and no push-notification relay — event alerts are scheduled locally on the device. The app contains no analytics SDK, no crash-reporting SDK, and no advertising code. Its only third-party dependency is one open-source keyboard-shortcut library that performs no networking.
When an employee leaves or a review changes, your admins keep control: InstaCal appears in the Google Workspace and Microsoft Entra consoles as an ordinary OAuth application that can be audited, allowlisted, or revoked centrally, exactly like any other client of those APIs.
2. Every network connection the app can make
This is the complete list. Each row happens only when the named feature is used, every connection is HTTPS, and App Transport Security is not relaxed anywhere in the app.
| Destination | When | What is sent |
|---|---|---|
Google Calendar APIaccounts.google.com, oauth2.googleapis.com, www.googleapis.com |
Only if you connect a Google account | Your OAuth token and the calendar reads/writes you perform. Scopes: calendar, userinfo.email. Client ID 94105845805-al8k2cuprtjv3m7lg6chd7ervhbknksq.apps.googleusercontent.com |
Microsoft Graphlogin.microsoftonline.com, graph.microsoft.com |
Only if you connect a Microsoft account | Your OAuth token and the calendar reads/writes you perform. Scopes: Calendars.ReadWrite, User.Read, offline_access. Client ID 8b586c35-ae06-434f-b556-ed10631c060c |
CalDAV serverscaldav.icloud.com (and the numbered pNN-caldav.icloud.com hosts it redirects to), caldav.fastmail.com, caldav.calendar.yahoo.com, dav.fruux.com, or the address you type for any other server |
Only if you add a CalDAV account | An HTTP Basic Authorization header carrying the username and app-specific password you entered, over TLS, plus the CalDAV requests you make (PROPFIND, REPORT, PUT, DELETE). Discovery asks /.well-known/caldav on the host you named, then that host's own URL. A plain http:// address is refused, and a redirect to a host outside the provider's allowlist aborts the request instead of forwarding your credentials |
| Calendar subscriptions The webcal, webcals or HTTPS .ics address you paste — including WebDAV and Meetup feeds |
Only if you subscribe to a feed, then on the re-check interval you choose (every 15 minutes to once a day; hourly by default) | A GET for that feed, with If-None-Match/If-Modified-Since so an unchanged feed transfers nothing. If you filled in the optional username and password, an HTTP Basic header goes with it — and is dropped rather than followed if the feed redirects to a different host. webcal is upgraded to HTTPS, plain http:// is refused, subscriptions are read-only, and a feed is abandoned past 20 MB |
Todoistapp.todoist.com, api.todoist.com |
Only if you connect a Todoist account, to show its tasks beside your calendar | Your OAuth token and the task reads/writes you perform. Scope: data:read_write. Sign-in is OAuth 2.0 with PKCE and no client secret; the client is identified by a public metadata document we publish at instacalapp.com/oauth/todoist-client.json, which Todoist reads from our site — none of your data passes through it |
Zoomzoom.us, api.zoom.us |
Only if you connect Zoom, and then only when you add, change, or remove a Zoom meeting on an event | Your OAuth token and the meeting itself — its title, start time, length and time zone. Scopes: meeting:write:meeting, meeting:update:meeting, meeting:delete:meeting, user:read:user. Public client ID Ro5paaLpTsykD2kxWaB1Yg, PKCE, no client secret shipped in the app. From InstaCal 3.9, every connection to zoom.us and its subdomains is certificate-pinned through App Transport Security (NSPinnedDomains): the chain must end in one of a fixed set of public root certificate authorities (Zoom's is currently DigiCert Global Root G2), so a root installed by a proxy or TLS-inspection appliance is refused |
| Weather Apple WeatherKit or api.weather.com (The Weather Company) |
Only if weather is turned on; refreshed at most hourly | A coordinate — your device location or a fixed city you choose — plus language and units, to the one provider you select |
| Apple Maps (MapKit) | Only when you type in a location field, view an event map, or enable travel-time estimates | The location text or event address, and for travel time your current coordinate, handled under Apple's privacy policy |
| iCloud key-value store | Only if you use settings sync | Appearance and behavior preferences, plus your countdowns and event/reminder templates — synced through your own Apple ID, never visible to us |
| instacalapp.com (this site) | Once per app version, to show the What's New page | Platform and app version in the URL — no identifiers, no calendar data. The in-app view uses a non-persistent store, so no cookies are kept. Our server stores no IP addresses or user agents; traffic is counted only as anonymous daily aggregates |
| instacalapp.com (Countdown photos) | Only when you search for a stock photo or generate an image for a countdown, in the countdown editor | The search words you type, or the description you write for a generated image, plus the same per-install random ID the feature-request form uses, to cap how many calls one install can make per day. Our server forwards the search to Unsplash or Pexels and the description to OpenAI's image API using keys held on the server, and returns the results; the stock photo itself is then fetched by your device straight from the provider's image host (images.unsplash.com or images.pexels.com), and choosing one sends that provider the download credit its license asks for. If you add a photo of yourself to a generated image, that photo (resized on the device) is held by our server only while that one image is being drawn, forwarded to OpenAI for it, and deleted the moment the drawing finishes. The finished picture is kept only on your device, in the app's shared container, so its widget can draw it. No calendar data, no account, no location. Our server logs the search text or description with the random ID for the daily caps and for spend accounting; see the privacy policy for retention |
| instacalapp.com (Request a Feature) | Only when you send a request from Settings → Request a Feature | What you type into the form — a category, a one-line summary, optional details — plus, only if you add them, a reply email and a screenshot (resized on the device before it is sent). The app version, OS version and hardware model ride along so the request can be read in context, together with a random ID created for this purpose and kept on the device, used only to cap how many requests one install can file per day. No calendar data, no account, no location. Each request is stored on our server and relayed to the people who build InstaCal; see the privacy policy for retention |
One thing on that list can look surprising in a proxy log: Todoist and Zoom register https://instacalapp.com/oauth/todoist and https://instacalapp.com/oauth/zoom as their redirect URLs. Those URLs are never fetched. The system's ASWebAuthenticationSession HTTPS callback matches them on the device — using the app's associated-domain entitlement for instacalapp.com — and hands the authorization code straight to the app, which exchanges it with Todoist or Zoom directly. Our site publishes no handler for either path. Google and Microsoft sign-in uses a custom-scheme redirect (com.rcg.calendarbar) and touches our domain not at all.
Separately, the sign-in sheets for iCloud, Fastmail, Yahoo, and Fruux offer a help link to that provider's own documentation. Following one opens your default browser, outside the app.
What is deliberately absent: no analytics or telemetry endpoints, no crash reporters, no ad tech, no CDN-hosted scripts inside the app, no license-activation server, and no developer push servers. If a work calendar never enables weather or a direct account connection, InstaCal's only recurring connection is Apple's own EventKit sync, which the OS performs.
3. What Apple enforces, not just what we promise
Most of the guarantees above are not self-attestation — they are enforced or verified by Apple's platform and distribution rules:
- App Store privacy label: “Data Not Collected.” Our App Store listing declares that the developer collects no data from this app. That declaration is a public commitment Apple requires to be accurate, backed by the privacy manifest compiled into every InstaCal binary, which declares no tracking, no tracking domains, and no collected data types. The one thing the app ever sends us that a person typed is the optional Request a Feature form (section 2) — user-initiated, infrequent, and sent only when you press Send, which is the case Apple's optional-disclosure rule for feedback forms exists for.
- App Sandbox. The Mac app ships with the App Store's mandatory sandbox; iPhone, iPad, and Watch apps are always sandboxed. InstaCal can touch only what its entitlements grant: network client, calendars, contacts, location, WeatherKit, iCloud key-value storage, and its own app group. The Mac widget extensions have no network entitlement at all — they can only read the snapshot the main app writes.
- OS-level consent. Calendar, reminders, contacts, and location access each require an explicit system permission prompt, and every grant is revocable any time in System Settings → Privacy & Security. The operating system, not the app, is the gatekeeper.
- Signed, reviewed distribution. Every build is code-signed to Higher Bar, LLC, reviewed by Apple, and delivered only through the App Store's update pipeline. There is no self-updater to vet, and Apple can revoke a malicious binary globally.
- Manageable deployment. Because InstaCal is a standard App Store app, IT can purchase, deploy, update, and revoke it through Apple Business Manager and any MDM, like any other managed app.
4. AI that never phones home
InstaCal's natural-language event entry ("Lunch with Sam Friday 1pm") uses Apple Intelligence on the device — Apple's FoundationModels framework on macOS 26 and iOS 26 — not a cloud AI service. There is no OpenAI, Anthropic, Google Gemini, or any other AI vendor SDK, API key, or endpoint anywhere in the app.
- What the on-device model sees: the single line of text you typed, your calendar names, the current date, and your language — nothing else. Your existing events, notes, and attendees are never put into any AI prompt.
- Nothing retained: the model session is discarded after each parse. Because the model runs on the device, "zero data retention" is structural — there is no AI vendor to have a retention policy.
- Fully optional: on systems without Apple Intelligence, or with it turned off, InstaCal falls back to its built-in on-device parser, which works in 12 languages. No functionality routes around your choice.
5. Where data lives on the device
- Every credential lives in the Apple Keychain — OAuth tokens for Google, Microsoft, Todoist and Zoom, and the app-specific passwords you enter for CalDAV accounts and password-protected subscriptions. Each is one generic-password item keyed to that account, and none is marked for iCloud Keychain sync. No password or token is written to preferences or into the event cache; the account list holds only labels, server addresses, and usernames.
- Cached events. For each directly connected account InstaCal keeps a local mirror of a fixed six-year window — 1 January two years before the current year up to 1 January four years after — so the panel opens instantly and a dropped connection never blanks the day. It is written as JSON under Application Support inside the app's sandbox container (
InstaCalNext/remote-events), never anywhere else on disk. Widget and Watch snapshots live in the app's own app-group container, readable only by InstaCal's extensions. - Disconnecting an account erases its local copy. Removing an account deletes its Keychain item, its cached calendars and events, any cached Todoist tasks, and its meeting-link records in one step. The events themselves stay where they always were — on the provider.
- Encryption at rest comes from the platform: FileVault on macOS and iOS file-based data protection, the same protections that cover Apple's own Calendar database. The cache and the Keychain items get it for free by living where they do.
- Apple Watch receives its snapshot device-to-device over Apple's Watch Connectivity — no server involved.
- Deleting the app deletes its local data, subject to normal Apple backup and Keychain behavior. There is nothing to delete on our side, because nothing was ever sent to us.
6. Verify it — don't take our word for it
Every claim on this page is falsifiable with tools your security team already uses:
- Watch the traffic. Point Proxyman, Charles, mitmproxy, or Little Snitch at InstaCal. With no accounts connected and weather off, you should see no recurring connections at all. Turn features on one at a time and you'll see exactly the hosts in section 2 — and nothing else. If you ever observe a host not on that list, that's a bug: report it and we will fix it. One exception is deliberate: from InstaCal 3.9, connections to
zoom.usandapi.zoom.usare certificate-pinned. A proxy that decrypts TLS will see those two host names and nothing more, and InstaCal will refuse the connection, so Zoom meeting creation fails while the proxy is decrypting. If your network inspects TLS, exempt those two hosts for Zoom to keep working in InstaCal. - Read the entitlements.
codesign -d --entitlements - "/Applications/InstaCal.app"prints the sandbox and permission grants described in section 3. - Check the label. The App Store listing's privacy section is Apple-hosted and states "Data Not Collected."
- Point a CalDAV account or subscription at a server you control. You will see an HTTP Basic header over TLS and nothing else. Answer with a redirect to a different host and InstaCal aborts rather than resending the credential; offer an
http://address and it refuses to connect at all. - Audit the OAuth grant. After connecting a test account, InstaCal appears in Google Workspace's or Microsoft Entra's third-party app reports with exactly the scopes listed in section 2.
7. Certifications, honestly
We do not hold SOC 2, ISO 27001, or FedRAMP certifications, and we won't pretend a badge where there isn't one. Those audits primarily examine the controls around a vendor's servers, staff, and hosted customer data. InstaCal has no servers holding customer data, no staff with access to your calendar, and no hosted service to audit — the surface those certifications exist to measure is absent by design.
What we offer instead is a smaller, verifiable claim: your calendar data never reaches us. Section 6 shows how to confirm it in an afternoon, without our cooperation. For organizations that need paperwork, we will complete your security questionnaire (SIG Lite, CAIQ, or your own form) on request — most answers are "not applicable: no customer data is stored, processed, or transmitted by the vendor," and we answer the rest specifically.
8. Answers for security reviewers
Where is customer data hosted?
Nowhere by us. Calendar data stays with the provider your organization already uses — Apple, Google, Microsoft, or the CalDAV/subscription host whose address the user entered — and on the user's device. Higher Bar Apps operates no database of customer content.
What is the vendor's data retention policy?
We hold no customer calendar data, so there is nothing to retain or delete. The only personal data we ever process is email correspondence a customer sends to support, retained as ordinary business email; feature requests a customer chooses to send from the app's Settings — kept while they are being considered; and the search words or image descriptions typed into the countdown photo picker, logged with an anonymous per-install ID for rate limiting and spend accounting and kept for 90 days. Any of it is deleted on request to support@higherbarapps.com (quote the summary or search you sent).
Who are the subprocessors?
None in the SaaS sense — there is no service of ours to subprocess for. The third-party services the app can contact, each user-chosen and direct from the device, are listed in section 2: Apple, Google, Microsoft, The Weather Company, Todoist, Zoom, and any CalDAV server or calendar feed the user chooses to add. The one flow our server relays on a user's behalf is the countdown photo picker: a search goes on to Unsplash or Pexels, and an image description (with an optional photo of the user) goes on to OpenAI, none of which involves calendar content.
Does the app use generative AI? Which provider?
For anything touching your calendar, only Apple Intelligence, on the device (section 4); no event content is sent to any AI service. The single cloud AI feature is opt-in and unrelated to calendar data: the countdown editor's "Generate with AI" sends the description you type — and, only if you add one, a photo of yourself — through our server to OpenAI's image API to draw a poster picture. Nothing is sent until you press Generate, and OpenAI receives no identifiers, calendar content, or location.
What telemetry does the developer receive?
None from the app. The only usage information we ever see is Apple's aggregated, anonymized App Store statistics from users who opted in to share analytics with developers — it contains no calendar content and no identities. Our website counts page views without cookies and without storing IP addresses or user agents.
How is authentication handled? Is there SSO?
There is no InstaCal account to authenticate. Direct Google, Microsoft, Todoist, and Zoom connections use your existing identity with that provider via OAuth 2.0 with PKCE — so your SSO, MFA, and conditional-access policies apply automatically, and your admins can revoke InstaCal's grant centrally at any time. CalDAV accounts and password-protected subscriptions are the exception: those protocols have no OAuth, so InstaCal asks for a username and an app-specific password you generate at the provider, sends it as HTTP Basic over TLS, and keeps it only in the Keychain. It never asks for a primary account password, and never sees one for an OAuth provider.
What happens when an employee offboards?
Suspending the employee's Google/Microsoft account or revoking the OAuth grant immediately cuts InstaCal's access, and revoking an app-specific password does the same for a CalDAV account or an authenticated subscription; a device wipe removes local caches and Keychain items. There is no vendor-side account to close.
What is your breach-notification process?
Because we hold no customer calendar data, a breach of Higher Bar Apps cannot expose it; the most a breach of our server could reveal is the text of feature requests people chose to send, with a reply address where one was given, and the search words or image descriptions typed into the countdown photo picker, keyed by an anonymous install ID. If any future change gave us access to personal data, we would update the privacy policy before it took effect, and we would notify affected users of any incident consistent with applicable law.
GDPR / CCPA position?
For calendar content, we are not a data processor or controller — the architecture prevents us from accessing it. The app's Apple privacy manifest and App Store label declare no data collection. Requests concerning data held by Apple, Google, Microsoft, or The Weather Company go to those providers; a lightweight DPA covering the little we do process (support email, feature requests sent from the app, and countdown photo searches) is available on request.
How are updates delivered and vulnerabilities patched?
Exclusively through the App Store's signed update pipeline, with the release history public on the What's New page. Security fixes ship the same way and reach all users automatically.
Will you complete our security questionnaire?
Yes. Email support@higherbarapps.com and we will return completed SIG Lite/CAIQ-style answers, typically within a few business days.
9. Reporting a vulnerability
If you believe you've found a security issue in InstaCal or on this website, email support@higherbarapps.com with "Security" in the subject line. We aim to acknowledge reports within three business days, and fixes ship to all users through App Store updates.
We support good-faith security research: if you make a reasonable effort to avoid privacy violations and service disruption while investigating, we will not pursue action against you for it. A machine-readable contact is published at /.well-known/security.txt per RFC 9116.
For the formal statement of the app's data practices, see the InstaCal Privacy Policy.
10. Where to get it
Everything on this page describes InstaCal as it ships, and section 6 is there so you can check it rather than take our word for it. The app is distributed only through the App Store, on one universal purchase covering Mac, iPhone, iPad and Apple Watch.
InstaCal on the Mac App Store On iPhone, iPad and Apple Watch
Evaluating InstaCal for a team? Email support@higherbarapps.com and we will return completed SIG Lite/CAIQ-style answers and a DPA covering the little we process.