I built an app that turns phone calls into calendar events

The problem

I'm a freelance developer. Half my work happens on the phone — client calls, quick syncs, follow-ups. After every call, I'd think: "I should write that down." And then I wouldn't. Two days later, I'd forget what we discussed, when we talked, or that the call even happened.

I tried CRMs. Way too much overhead for a solo developer. I tried setting reminders manually. That lasted about a week. The real issue: the gap between "call ends" and "event is logged" was too wide. Even 30 seconds of friction is enough to make you skip it.

The idea

What if the phone itself told me a call just ended — and I could save it to my calendar with a single tap? No app to open, no fields to fill out. Call ends, notification appears, tap, done.

That's Callvent. On Android it picks up calls by itself; on iOS you tap once after hanging up — from the Action Button, a widget, or your watch. Either way you get the call details (duration, direction, contact) and save them as a calendar event. The whole flow takes under 10 seconds.

Going native on both platforms

I built Callvent as a fully native app — Swift/SwiftUI on iOS, Kotlin/Jetpack Compose on Android. No React Native, no Flutter, no cross-platform framework.

This wasn't ideological. Call detection requires deep OS integration that cross-platform frameworks don't handle well. On iOS, you need CallKit. On Android, you need a foreground service with TelephonyManager. These are fundamentally different APIs with different capabilities and constraints. Wrapping them in a shared layer would have added complexity, not removed it.

The iOS constraint that became a feature

On Android, when a call ends, you can read the phone number directly from the system CallLog. You know who called, and you can auto-match it to a contact. Straightforward.

On iOS, Apple doesn't give you the phone number. At all. CallKit tells you a call happened, how long it lasted, and whether it was incoming or outgoing — but the caller identity stays locked behind the OS. This is by design: Apple treats phone numbers as sensitive data that apps shouldn't access without explicit user action.

At first, this felt like a dealbreaker. The whole point is knowing who you talked to. But I turned it into a feature: after the call, you assign the contact yourself through the system contact picker. The app never sees your address book — it only receives the single contact you select. This means Callvent on iOS has zero access to your contacts database, which is a stronger privacy guarantee than most apps can offer.

On Android, auto-matching is more convenient. On iOS, manual assignment is more private. Both are valid trade-offs, and each platform does what feels natural to its users.

Background processing is the hard part

Detecting a call is easy when your app is in the foreground. Nobody keeps a call logger in the foreground. I went in assuming the whole product stood or fell with what each OS lets an app do while it's out of sight — and I had the two platforms backwards.

On iOS, I expected CallKit to solve it. You register a CXCallObserver and you do get call state changes, but only while your process is alive. Once the system suspends the app, the observer is gone, and iOS never wakes an app for an ordinary phone call. There's no call log to read afterwards either — third-party apps don't get one. So Callvent catches the calls where it happened to still be running, which in my own use is roughly two out of three.

That gap is where the one-tap path came from. Rather than pretend the app sees everything, iOS gets the fastest possible way to log a call once you've hung up: a Control on the Action Button, a Home or Lock Screen widget, the Apple Watch, or Siri. Two seconds of my attention, and it doesn't depend on what the system feels like doing.

On Android, it's the platform that gives way. Android kills background processes to save battery, but it also offers a way out: a foreground service with a persistent notification. Users see a "Callvent is monitoring calls" notification at all times, and the app reads the system call log, so a call that arrives while the phone is in your pocket still lands. The permanent notification isn't elegant, but it buys detection that actually holds up across Samsung, Xiaomi, Pixel, and all the other OEMs that each have their own battery optimization quirks.

Android 16 (API 36) actually introduced a dedicated callMonitoring foreground service type, which suggests Google recognizes this as a legitimate use case. Callvent targets this API level.

Calendar integration: simpler than expected

Both iOS (EventKit) and Android (CalendarContract) provide solid calendar APIs. You write an event with a title, start time, end time, and optional notes — and it appears in whatever calendar service the user has configured: iCloud, Google Calendar, Outlook, CalDAV, Exchange. The OS handles sync.

This is the part I like most about the architecture: Callvent doesn't store your data. Your calendar does. If you delete the app, your logged calls are still in your calendar. There's no vendor lock-in, no export needed, no proprietary format.

No cloud, no accounts, no tracking

Callvent has no backend. Zero servers. No user accounts, no registration, no analytics SDKs, no ads. There's no data to breach because there's no data to collect.

This wasn't a marketing decision — it was an engineering one. A call logger handles sensitive communication metadata. The simplest way to keep that data safe is to never let it leave the device. Your call history stays in a local database. Your calendar entries sync through your own calendar provider. The app needs no internet connection to function.

On iOS, the only diagnostics I collect are through MetricKit — Apple's on-device performance framework that reports crash data and resource usage without identifying individual users.

Watch support

Both Apple Watch and Wear OS are supported. Calls detected on your phone sync to your watch via WatchConnectivity (iOS) or Google's Wearable Data Layer (Android). You can review and save calls from your wrist.

The sync strategy is optimistic: the watch shows the call immediately and rolls back if the phone-side save fails. This keeps the watch UI responsive even when Bluetooth connectivity is flaky.

Pricing

Free download with a 7-day trial. After that, $0.99/month, $4.99/year, or $14.99 for lifetime access.

I originally launched with a one-time purchase, but I've since moved to a freemium model. A free trial lets people experience the full app before committing, and flexible plans let users choose what works for them. The lifetime option is still there for those who prefer paying once. No cloud, no tracking, no ads -- that hasn't changed.

What I'd do differently

If I started over, I'd still go native — but I'd invest more time upfront in shared tooling. Both platforms need similar test setups (simulating call state transitions), and I built those independently. A shared test specification would have saved time.

I'd also ship Android first. Google's APIs are more permissive, which means you can build a more complete prototype faster. Apple's constraints are important to design for, but they're easier to adapt to once you have a working product.

Try it

Callvent is available on the App Store and Google Play. If you're the kind of person who makes a lot of calls and forgets to document them — this is for you.

I'm happy to answer any questions about the technical implementation, the platform differences, or anything else.