DottieNote 1.3.5 was a stability release focused on task display and calendar behavior.
Calendar and overview fixes
This release fixed an issue where adding a task could create multiple items with the same name on the calendar. It also addressed cases where daily tasks or tasks without an end time appeared only once in the overview.
Tags and task creation stability
Tag creation could sometimes cause the app to become sluggish. That issue was fixed, along with cases where newly added tasks did not display correctly or produced errors.
The release also polished the interface and interactions so everyday use felt smoother.
A calendar has to be trustworthy
The value of a calendar view is trust. Users open it to understand what is happening today, this week, or later. If duplicate task names appear, or tasks without an end time show incorrectly, users begin to wonder whether something is missing.
That uncertainty makes a task tool feel tiring. People came to confirm their plan; they should not have to check whether the system displayed it correctly.
Version 1.3.5 handled these issues so the calendar could become a place users feel comfortable checking again.
Stability is part of the experience
Tag creation lag, tasks not appearing after being added, and strange list states may not happen every day. But when they do happen, they quickly reduce patience with the whole task system.
That is why this release focused on fixes and interaction polish instead of adding another new feature. For an early product, spending time on these small-seeming problems matters more than constantly opening new doors.
Later work on task recovery, database structure, and sync state followed the same idea: users should not have to care about the internal implementation. They should be able to confirm that their tasks are there, the state is accurate, and the next step is available.
Fixes change how people use the app
Once the calendar and task list feel stable, users become more willing to put real tasks into the app. Otherwise, they keep a backup note somewhere else, or open DottieNote by first checking whether anything has gone wrong.
The fixes in 1.3.5 reduced that extra checking. They helped DottieNote move closer to a daily tool, rather than an early experiment users still have to supervise.
Release notes should be clear about this kind of work. When users read a fix list, they are also deciding whether the team takes daily friction seriously.
Display bugs are trust bugs
In a task product, display issues are not only visual. If a task appears twice, disappears from the wrong view, or fails to show after being added, users immediately start doubting the data.
Even if the underlying data is safe, a display error can still break trust.
So the work in 1.3.5 went beyond interface cleanup. It repaired the relationship between user and task system: when someone gives the app a task, the app needs to show it accurately.
Later improvements to task recovery and iCloud status communication follow the same principle. Data has to be trustworthy, and the interface has to be trustworthy too.