Planning a week on a Mac, not just recording it

The calendar is full and the week still does not work. Every commitment is recorded, the alerts fire on time, and Thursday afternoon still collapses into three meetings that were never meant to sit next to each other. Nothing was forgotten. The week was simply never planned, only logged after the fact. That gap is what sends people looking for a planner instead of a calendar, and it is why the usual roundups are unsatisfying: they compare interfaces when the difference that matters is structural.

A planner has to answer a question a calendar never asks. Not "what is happening on Thursday" but "what is left on Thursday, and is it enough." Everything below is organised around which apps can answer the second question on macOS, and what it costs to find out.

A calendar records commitments, a planner allocates what is left

Most calendar software is built around the event. Something is agreed with other people, it gets written down, it appears in a grid, and the grid is a record. The unclaimed time between the events is drawn as empty space, which is exactly backwards: that space is where all the actual work has to fit, and it is never as large as it looks.

A planner treats the unclaimed time as the subject. Tasks get put into it as blocks, so a list of fourteen things that would take eleven hours cannot quietly coexist with a Tuesday that has four hours open. The moment the work is drawn on the same grid as the meetings, the arithmetic becomes visible, and the choice stops being "when will this get done" and becomes "which of these does not happen this week."

This is why a to-do list running next to a calendar never quite solves the problem. Two surfaces, each internally consistent, disagree about how much time exists. The disagreement only surfaces on Thursday afternoon.

The practical test for a planner is whether unscheduled work and scheduled events share one grid. Apps that keep them in separate panes are calendars with a task sidebar. Apps that let a task be dragged onto the grid and become a block are planners. Both are legitimate, but only one of them will change how a week turns out.

Where the data lives decides more of the behaviour than the interface does

On macOS there are two ways a calendar app can get events, and the choice shapes what the app can and cannot do.

The first route is the system calendar database that macOS maintains. The app reads whatever accounts have already been added on the Mac, which means setup is trivial and the app inherits the system sync. Itsycal works this way, and its own site describes it as integrating with the Mac Calendar app. The inheritance cuts both ways. If macOS is not syncing a particular Google calendar, the app cannot show it, no matter how good the app is.

The second route is connecting to the account directly. Notion Calendar and Morgen both do this. The app signs into Google, Microsoft, or iCloud on its own terms, keeps its own copy, and is not limited by what the system happens to be syncing.

The distinction explains a class of problem that gets blamed on the wrong thing. A shared calendar or a secondary Google calendar that appears on the web but never on the Mac is usually a sync selection issue rather than an app defect. Google's help documents a calendar sync page that controls which calendars are passed through to Apple Calendar, and notes that calendars listed under "My Calendars" sync automatically while others have to be ticked. Switching planners will not fix that. Ticking the calendar will.

Refresh frequency belongs to the same layer. Google's instructions for Apple Calendar point at the Refresh Calendars setting on the Accounts tab to choose how often the two sync. An app that reads the system database is bound by that interval. An app that talks to the account itself sets its own.

What the shortlist costs and what it runs on

Prices and platform support as listed on each vendor's own page on 21 September 2026. Flexibits shows Premium pricing in local currency, so the figure on screen depends on the region.

App	Price as listed	Platforms listed	Tasks on the same grid
Apple Calendar	Included with macOS	macOS, iOS, iPadOS	Scheduled reminders can be shown in the calendar list
Fantastical	Free tier, plus Flexibits Premium in Individual, Family and Team plans with a 14 day trial	Mac, Windows, iPhone, iPad, Apple Watch, Apple Vision Pro	Yes, including iCloud Reminders, Todoist and Google Tasks
BusyCal	49.99 USD, 14 day free trial, also offered through Setapp	macOS 12.0 or later, iOS	Yes, integrated with Reminders
Notion Calendar	Free	macOS, Windows, iPhone, Android	Notion database items shown alongside events
Morgen	15 USD per month billed yearly, 30 USD billed monthly, 14 day trial	Windows, macOS, Linux, mobile, browser	Yes, with task tool integrations
Itsycal	Free	macOS 11 or later	No, it is a menu bar calendar

Itsycal belongs on the list for completeness rather than as a candidate. It is deliberately tiny and does one job. Apple Calendar sits in a more interesting position than it usually gets credit for: Apple documents a Scheduled Reminders checkbox in the calendar list that shows reminders from the Reminders app inside Calendar, with timed ones placed at their time and all-day ones at the top, and reminders can be created and completed without leaving the calendar. That is genuinely one grid. What it does not offer is a way to take an undated task and place it as a block, which is the move that makes a plan.

Account support is worth checking against the accounts actually in use rather than assumed. Fantastical lists Google, Microsoft 365, Exchange, iCloud, Todoist and CalDAV. Notion Calendar states it syncs with Google Calendar accounts, Outlook calendars, and Apple iCloud-synced calendars. Morgen lists Google Calendar, Outlook, iCloud and a set of task tools. An Exchange account at work and an iCloud account at home is a common combination that narrows the field quickly.

Entering the plan has to be faster than skipping it

A planner only works if the plan gets entered, and the friction of entry is the single most common reason the habit dies in week two. Typing a sentence and having it parse into a block is not a luxury feature. It is the difference between planning on a Monday morning and abandoning planning on a Monday morning.

Natural language entry is now common. Fantastical is built around it, BusyCal offers it in several languages with suggestions drawn from past events, and the pattern is the same everywhere: a sentence goes in, a structured event comes out. What varies is how much of the sentence survives. Titles and times are handled well almost everywhere. Locations, durations, attendees and repeats are where the implementations separate.

The other half of entry speed is how quickly the app can be reached at all. A planner behind three clicks gets consulted once a day. A planner reachable from a keyboard shortcut gets consulted between meetings, which is when replanning actually needs to happen. Whatever is chosen, the shortcut should be set on day one, and the way events get entered is worth testing with the messiest sentence available rather than a clean example.

Blocks that did not happen have to go somewhere

Every plan is wrong by Tuesday. That is not a failure of planning, and an app that assumes otherwise will be abandoned. What separates a planner that survives contact with a real week from one that does not is what happens to a block when its time passes and the work inside it is still undone.

There are three behaviours in circulation. The block can simply expire, leaving a coloured rectangle in the past that describes something which never occurred. The block can stay visible and follow the current day forward until it is completed, which is how task systems tied to due dates usually behave. Or the block can be rescheduled explicitly, by the person, as part of a short review.

The first behaviour quietly corrupts the record. A week of expired blocks looks, in hindsight, like a week that went to plan, and the hours that actually went missing leave no trace. Nothing can be learned from it, so the same over-commitment repeats. The second behaviour is honest but can accumulate into a wall of overdue items that becomes easier to ignore than to clear. The third takes five minutes a day and is the only one that keeps the plan and the record in agreement.

BusyCal describes tasks as displaying on their due dates and carrying forward until completed, which is the second behaviour applied to tasks rather than blocks. It is worth knowing which of the three a candidate app does before the first week ends, because the answer determines whether Friday's review is a source of information or a tidying exercise.

The hour that disappears is usually travel

The gap between a 10:00 meeting across town and an 11:00 call is not an hour. It is an hour minus the trip, minus finding the room, minus the three minutes of setup. Calendars draw it as a full hour anyway, and the plan built on top of that drawing is wrong by thirty to forty minutes before the day begins.

Most planners handle this in one of three ways. Some ignore it entirely and leave the reader to pad events by hand. Some allow a travel time field on the event, which macOS supports, so the block on the grid grows to include the trip. Some calculate the trip from the location and adjust automatically.

For anyone whose week contains any movement at all, this single behaviour outweighs most of the feature lists. Two blocks that abut perfectly on screen but cannot both happen is the specific failure that makes a plan collapse by Wednesday, and no amount of colour coding compensates. Checking how a candidate app handles travel time between events before committing is faster than discovering it in production.

Five working days is enough to know

A planner cannot be evaluated from screenshots, and a month long trial is longer than needed. Five days is enough if the test is defined before it starts.

Set it up on a Monday with every account that matters, not just the easy one. Plan the week on Monday morning, in blocks, including the work rather than only the meetings. Then let the week happen and look at three things on Friday.

First, how many blocks survived the week unmoved, and where the moves clustered. Clustering around mid morning usually means travel and buffers were not accounted for. Second, whether the plan was ever reopened mid day. A plan that is only touched on Monday is a wish list. Third, whether anything had to be typed twice, in the app and again somewhere else. Duplicate entry is the reliable predictor of abandonment.

Free trials make this cheap. BusyCal, Fantastical and Morgen each list a 14 day trial, and Notion Calendar and Itsycal are free to keep. Running the same week twice with two candidates is unnecessary. Running it once, deliberately, answers the question.

What to change first

Before installing anything, open the calendar sync settings and confirm the Mac is actually receiving every calendar that matters, because a planner fed incomplete data will produce a confident and wrong plan. Then pick one candidate, plan a single week in blocks rather than events, and judge it on Friday by how much of the plan held. If the answer is that travel and entry speed are what break it, a calendar built for entering events by speaking or typing a sentence is the narrower thing to try next, and the comparison against other Mac calendars sets out where each one stops.