InstaCal

For IT & security teams

Security & Trust

Updated November 13, 2026

This page exists so you can approve InstaCal for work calendars without taking our word for anything. It lists every network connection the app can make, explains what Apple enforces rather than what we promise, and tells you how to verify each claim yourself.

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 to googleapis.com or graph.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 .ics feed. 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 third-party analytics SDK, no third-party crash-reporting SDK, and no advertising code; anonymous usage statistics are sent by InstaCal's own small reporter to our own server (section 2). 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 — usage statistics, the last row, is the one that is on by default — every connection is HTTPS, and App Transport Security is not relaxed anywhere in the app.

DestinationWhenWhat is sent
Google Calendar API
accounts.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 Graph
login.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 servers
caldav.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
Todoist
app.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
Zoom
zoom.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, turn on place photos, or enable travel-time estimates The location text or event address, and for travel time your current coordinate, handled under Apple's privacy policy
Apple Private Cloud Compute
through Apple's Foundation Models framework (Add from Image, iPhone, iPad and Mac)		 Only when you use Add from Image — take a photo, choose one from Photos, or paste an image; on the Mac, choose an image or PDF, paste one, or drop one on InstaCal — or share a photo, screenshot, PDF or web page to InstaCal The text recognized on the page and the page photos themselves — up to four pages, each downscaled on the device to at most 2048 pixels on its longest side — with today's date. A second, text-only request sends the titles and dates of the items found, plus the titles and calendar names of events and reminders already on those days, to flag duplicates. Cropping, straightening and text recognition happen on the device first, with Apple's Vision framework. Apple uses each request only to answer it and does not retain it; nothing goes to Higher Bar or to any other AI vendor
The website a shared link points to Only when you share a web link to InstaCal from an app other than Safari (Safari hands over the page's own text, so nothing is fetched) One ordinary request for that page, as a private browser window would make it: no cookies, no sign-in, no identifiers, at most 12 MB, redirects followed only on the web. The page's text then goes to Private Cloud Compute as above
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
iCloud (CloudKit private database) When the device is signed in to iCloud, unless you choose On This Device in Task Library Your InstaCal tasks, lists, subtasks and attachments, in your own private iCloud database under your Apple ID. Task content travels as CloudKit encrypted fields and attachments as CloudKit assets, filed under random IDs; with Advanced Data Protection on, Apple encrypts them end to end. Tasks already on the device move into iCloud once, the first time; choosing On This Device afterwards keeps new tasks on the device. With Countdowns & Templates sync on, the place photos you choose (Change Photo) sync the same way: the location and your choice as encrypted fields, the photo as an asset. 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 generate an image for a countdown, in the countdown editor The description you write for a generated image, plus the same per-install random ID the feature-request form uses, to cap how many images one install can make per day. Our server forwards the description to OpenAI's image API using a key held on the server, and returns the picture. 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 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
instacalapp.com (Usage statistics)
POST instacalapp.com/telemetry/batch		 Periodically while the app is in use on Mac, iPhone or iPad, unless you turn it off in Settings → About → Help Improve InstaCal. On by default Anonymous usage statistics, sent by InstaCal's own reporter (no third-party SDK): counts of which features are used and which errors occur; the order of those actions within a session, with the seconds between them; crash and hang counts; a once-a-day setup snapshot (calendar permission state, the number of calendars and accounts per provider type as a range, and whether a few settings are on or off); app version and build, OS major version, language code, platform, and the day the app was installed; and a random install ID created by the app, not derived from the device or Apple ID. Never sent: events, reminders, titles, notes, attendees, calendar or account names, email addresses, contacts, location, search text, or error-message text. No advertising ID; IP addresses are not stored; nothing is shared with or sold to third parties. Kept at most 400 days. Turning it off erases anything waiting to be sent, and the install ID

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 third-party analytics or crash-reporting services, 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 connections are Apple's own EventKit sync, which the OS performs, and the usage-statistics report above, which you can turn off.

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 Linked to You.” Our App Store listing declares three kinds of data, each not linked to you and none used for tracking: Usage Data (product interaction), Diagnostics (crash, performance, and other diagnostic data), and Identifiers (a device ID, which is the random install ID). That declaration is a public commitment Apple requires to be accurate, backed by the privacy manifest compiled into every InstaCal binary, which declares the same three types, no tracking, and no tracking domains. 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, one CloudKit container used only for Tasks and the place photos you choose, Apple Private Cloud Compute, 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: on the device, or in Apple's Private Cloud Compute

InstaCal uses Apple's models and no one else's. There is no OpenAI, Anthropic, Google Gemini, or any other AI vendor SDK, API key, or endpoint anywhere in the app. Two features use them, and they work differently.

Quick add: on the device only

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 service.

  • 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 31 languages. No functionality routes around your choice.

Add from Image: Apple's Private Cloud Compute

On iPhone and iPad with iOS 27, Add from Image in the + menu lets you take a photo of a school calendar, newsletter or invitation, choose one from Photos, or paste an image — or you can share a photo, screenshot, PDF or web page to InstaCal from the share sheet; on a Mac with macOS 27 you choose an image or PDF, paste one, drop one on the menu bar item or the panel, or use the Share menu — and get a list of events and reminders to review before anything is added. Reading a crowded page well takes a larger model than the one on the device, so this feature uses Apple's Private Cloud Compute, through the same Foundation Models framework. There is no on-device fallback and no second provider: if Private Cloud Compute is unavailable, Add from Image does not run. The app calls this reading “Privately with Apple Intelligence.”

  • On the device first: Apple's Vision framework finds the page in the photo, crops and straightens it, and recognizes its text.
  • What Private Cloud Compute sees: the recognized text and the page photos — up to four pages, each downscaled to at most 2048 pixels on its longest side — with today's date. A second, text-only request compares the titles of the items found with the titles of events and reminders already on your calendars on the same days, along with those calendars' names, so likely duplicates are flagged in the review. Notes, attendees, locations, and events on other days are never included.
  • What Apple commits to, and lets researchers check: Apple states that Private Cloud Compute uses the data only to fulfil the request, does not retain it, and does not make it accessible to Apple; the device sends requests only to servers running software Apple publishes for independent inspection. See Apple's Private Cloud Compute security overview.
  • Nothing reaches us: there is no Higher Bar server in this flow. We receive no page, no text, and no result, and no other AI vendor is involved.
  • Web pages and PDFs: a page shared from Safari arrives as its text; a link shared from another app is fetched by InstaCal itself, once, as listed in section 2. Its text, and the text of a PDF's pages past the fourth, go to Private Cloud Compute in place of photos.
  • Only when you ask: nothing is read or sent until you choose an image in Add from Image or share one to InstaCal, and nothing is added to a calendar until you review the list. A shared file or page waits in the app's own container only until InstaCal opens it, then is deleted; one never opened is cleared after a day.

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 no calendar data to delete on our side, because none 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, weather off, and usage statistics turned off in Settings → About → Help Improve InstaCal, you should see no recurring connections at all; with usage statistics on, the only one is a periodic POST to instacalapp.com/telemetry/batch, whose body you can read in the proxy. 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.us and api.zoom.us are 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. Add from Image requests are encrypted on the device for the Private Cloud Compute servers that answer them, so a proxy can see that a request was made but cannot read it.
  • 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 lists Usage Data, Diagnostics, and Identifiers under "Data Not Linked to You," with nothing under "Data Used to Track You."
  • 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 your calendar 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. InstaCal Tasks are kept in the user's own private iCloud database with Apple unless the user chooses On This 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 image descriptions typed into the countdown editor's Generate with AI, logged with an anonymous per-install ID for rate limiting and spend accounting and kept for 90 days. Anonymous usage statistics (section 2) are not linked to a person and are kept at most 400 days. Any of the personal data is deleted on request to support@higherbarapps.com (quote the summary or description 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 (including Private Cloud Compute for Add from Image), 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 editor's Generate with AI: an image description (with an optional photo of the user) goes on to OpenAI, which involves no calendar content.

Does the app use generative AI? Which provider?

For anything touching your calendar, only Apple's (section 4). Quick add parses what you type with Apple Intelligence on the device. Add from Image, on iPhone and iPad, sends the page someone photographed, pasted or shared — and, to flag duplicates, the titles of events and reminders already on the days it covers — to Apple's Private Cloud Compute, which Apple states uses the data only for that request and keeps none of it. Nothing goes to us or to any other AI vendor, and nothing is sent until someone chooses an image to read. The single non-Apple 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?

Anonymous usage statistics, listed in full in section 2: counts of which features are used and which errors occur, crash and hang counts, a daily setup snapshot, and the app and OS version, under a random install ID. They contain no calendar content, names, email addresses, location, or typed text, are sent to our own server with no third-party SDK, are kept at most 400 days, and stop when a user turns off Settings → About → Help Improve InstaCal. Beyond that we see Apple's aggregated, anonymized App Store statistics from users who opted in to share analytics with developers. 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, the image descriptions typed into the countdown editor, keyed by an anonymous install ID, and anonymous usage statistics that contain no calendar content. 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 only usage data, diagnostics, and a random install ID, each not linked to the user and none used for tracking. 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.