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. It detects your calls in the background, sends a notification with the call details (duration, direction, contact), and lets you save it 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. The entire value proposition depends on reliable background execution.

On iOS, CallKit handles this gracefully. You register as a CXCallObserver, and the system notifies you of call state changes even when your app isn't running. Apple's architecture does the heavy lifting — your app wakes up, processes the event, and goes back to sleep.

On Android, it's a different story. Modern Android aggressively kills background processes to save battery. The only reliable way to keep a call detection service alive is a foreground service with a persistent notification. Users see a "Callvent is monitoring calls" notification at all times. Not elegant, but honest — and it's the only approach that works consistently 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

$1.99, one-time purchase. No subscription, no freemium tier, no in-app purchases.

I thought about this for a while. Subscriptions make sense for services with ongoing server costs. Callvent has no servers. Charging monthly for an app that runs entirely on your device felt dishonest. A one-time purchase aligns the incentive: I make a good app, you pay once, done.

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.