I started building an iPhone app to help identify tasks and follow-ups hidden inside everyday messages.
Appointments, payments, delivery notices, things someone asks you to do by Friday. The kind of messages you read, understand, and then sometimes forget about.
At first, I thought extracting dates and finding actionable text would be the hardest part.
I was wrong.
Finding a date isn't the same as understanding it
Consider this message:
"Your appointment is on October 15. Please confirm by October 12."
Two dates, but two different purposes.
October 15 describes an event. October 12 is the deadline for an action.
A date extractor can identify both correctly and still fail to understand what matters.
In NLP terms, extracting dates is only the first step. The harder part is identifying the intended action and understanding how each date relates to it.
A useful interpretation might look like this:
{
"event": "Appointment",
"event_date": "2026-10-15",
"action": "Confirm attendance",
"action_deadline": "2026-10-12",
"action_required": true
}
Conceptual example only — not an actual Reply Radar model response or internal data schema.
The difficult part isn't producing structured data. It's making sure the structure reflects what the message actually means.
And then there's another problem: not every message actually requires the recipient to do something.
A delivery confirmation, a completed payment notification, and a request for payment might contain similar words. But they shouldn't all become tasks.
That's where I started spending more time than I expected: distinguishing useful information from something that actually needs attention.
Starting with Turkish
I began with Turkish, my native language, and most of my testing has been in Turkish.
One interesting part of Turkish is how much meaning can fit into a single word.
Take "konuşuruz," roughly meaning "we'll talk."
Depending on the context, it might suggest a future conversation. Or it might just be a polite way to end one.
Would you create a reminder from that?
Not necessarily.
The same problem exists in English, but the expressions and grammatical structures differ.
Reply Radar can analyze English messages too. The challenge isn't simply adding English support. It's making the interpretation reliable across languages and different ways people express intent.
Why I chose on-device processing
Messages often contain information people would rather keep private.
That's why I wanted users to decide which message text or screenshot to share with the app.
The analysis runs on the iPhone. Raw message content isn't sent to a server for analysis, and the app doesn't monitor conversations in the background.
I'm relying heavily on Apple's built-in on-device capabilities.
But keeping processing on the device doesn't automatically make language understanding easy.
Recognizing the words is one thing.
Understanding whether those words represent an unfinished task is another.
Thinking about Apple's evolving AI models
Apple's on-device AI developments, including the evolution of Foundation Models in iOS 27, are interesting for developers working on problems like this.
But I see a few challenges worth paying attention to.
What happens when a model interprets a deadline as an event date?
How should an app respond when the context is ambiguous?
What happens when a language has different levels of model support?
And how do we keep the results predictable as the underlying models change?
These are questions I'm continuing to explore, not problems I consider fully solved.
In my experience, getting a model to return a plausible answer is only the beginning. Deciding whether that answer represents the user's actual intention is much harder.
A small problem, but an interesting one
The app I've been building is called Reply Radar.
It's not intended to replace a calendar or a full task manager.
The goal is narrower: help people notice the tasks, dates, and follow-ups that might otherwise remain buried in messages.
I'm still learning where this approach works well and where it needs improvement.
What surprised me most was how quickly a fairly small productivity idea turned into an exercise in language, context, and reliable on-device analysis.
And that's probably what has made the project worth continuing.
For anyone curious about the project, I've put together a small website explaining what Reply Radar does: Reply Radar — Project Website.
Writing note: This article was prepared with AI writing assistance and is based on my experience developing and testing Reply Radar.
Top comments (0)