A daily task app is judged on the day you miss one.
Any daily task app looks fine on a day you do everything. The design shows up on the day you do not: does the unfinished task appear tomorrow, or stay in the past where it belongs? Getting that wrong is how a list turns into a wall of red nobody reads, which is the same failure mode behind most abandoned internal team apps.
This page is about recurrence and carry-over: how repeating tasks should be generated, why the answer to a missed task is different for medication than for an invoice, and what that means for the data underneath.
See the missed task problemThe short version
Carry-over is a property of the task, not a setting.
Some tasks are events tied to a moment and cannot be done late. Others are obligations that survive the day. One global switch gets half of them wrong whichever way you set it, so put the rule on the task.
For recurrence itself, generate on the day from a stored rule rather than creating a year of rows in advance, and keep a small override table for the exceptions.
The missed task decides the design
Ticking a carried-over task records that you did it, and for anything time-bound that is simply false. A fridge temperature logged a day late is not a late reading, it is a reading that never happened. In a food business that distinction is the whole point of the log.
Meanwhile an unsent invoice that quietly stays in yesterday is money you have forgotten about. Same app, opposite requirement. Which is why the decision belongs on the task, alongside its recurrence rule, rather than in settings.
Record when it was done, not when it synced
If a task is completed with no signal, the completion time has to be the moment the person tapped, not the moment the record reached a server hours later. Storing the server time quietly rewrites history and it is very hard to notice until someone audits a log. The same problem shows up in a habit tracker app, where a streak depends entirely on which clock you believed.
Try it
Which of these should carry over to tomorrow?
Decide for each one. The point is not the score, it is that a single global setting gets some of these wrong no matter which way you set it.
Take the morning medication
Send Tuesday's invoices
Record the fridge temperature
Call the customer back
Put the bins out
Recurrence is a solved problem, borrow the solution
Every daily task app eventually meets the same requests: every weekday, the last working day of the month, every second Tuesday. These are not new. The iCalendar specification, RFC 5545, defines a recurrence rule in section 3.3.10 that already expresses all of them, and it has been argued over for two decades.
You do not have to implement all of it. But taking its shape, a frequency, an interval, and a set of qualifiers, saves you from inventing a worse version of the same thing and makes exporting to a real calendar possible later.
| Approach | Edit one occurrence | If the rule changes | What you store |
|---|---|---|---|
| Generate every occurrence up front | Yes | Old rows keep the old rule | Thousands of rows nobody opens |
| Generate on the day, from the rule | Not directly | Tomorrow follows the new rule | One rule per task |
| Generate on the day, plus an override table | Yes | Tomorrow follows the new rule | One rule, plus the exceptions |
What today means, and why it is harder than it looks
Every daily task app has to answer one question constantly: is this task due today. It sounds like a comparison between two dates, and it is not, because a date on its own does not identify a moment in time. The same instant is Tuesday in one place and Wednesday in another.
RFC 3339 is the reason this is tractable. It defines the timestamp format the rest of the internet uses, including an explicit offset from UTC, and it is worth following exactly rather than inventing a shorthand. Store instants with their offset, store the user's time zone separately, and decide the day boundary in the user's zone rather than the server's.
There is a second boundary worth choosing deliberately: when your day rolls over. Midnight is the obvious answer and the wrong one for a lot of people, because a task finished at half past midnight belongs to the day that just ended in every sense except the arithmetic. A configurable rollover, often four in the morning, costs one setting and removes a whole category of complaints about streaks.
When the list is longer than the day
Every daily task app eventually shows someone forty items and expects them to feel motivated. They do not. They close the app, and the app has failed at the only thing it was for.
The fix is not a better sorting algorithm. It is deciding, in the design, how many things the app is willing to show as today. Some apps cap it and put the rest behind a deliberate action. Some show everything but visually separate what was chosen for today from what merely became due. Either works. What does not work is a flat list that treats a task you picked this morning and a recurring item that rolled over eleven times as the same kind of thing.
Rollovers deserve their own decision too. A task that has been postponed eleven times is telling you something, and the useful response is to surface that rather than silently move it again. Showing how many times an item has moved turns a guilt pile into information, and it costs one integer per task.
When building your own is the right call
It usually is not. There are hundreds of good task apps and most people should use one. The cases where building wins are the ones a general app cannot express: a task that belongs to whoever is on shift rather than to a named person, a completion that requires a photo or a second signature, or a routine driven by a machine's hours rather than by the calendar. The nearest relative of that last one is the chore tracker app, where the same rules apply to a household instead of a team.
Newly is an AI app builder: describe the app, including the carry-over rule per task, and it builds and ships a real mobile app you own. Plans start at $25 a month, there is no free plan, and iOS builds ship through App Store Connect.
Decide early what happens with no signal, because it changes how completions are stored rather than how they look. What happens with no signal goes through the options.
Questions people ask about daily task apps
A daily task app shows what is due today and records what was done. The interesting part is not the list, it is the rules underneath it: how a repeating task is generated, what happens when one is missed, and whether yesterday's unfinished work appears today or stays in the past where it happened.
Describe the routine you actually keep
Including which tasks are allowed to follow you into tomorrow and which are not.
Start building