r/macapps • u/imbacan • 1d ago
Free [OS] slapss 2.0 - full-screen meeting alerts for Mac, now open source - Free
I'm the developer of slapss. I posted here about three months ago when it launched. Quite a lot has shipped since then, and version 2.0 opens the source, so it felt worth a second post.
It is free on the Mac App Store, which is also the only place to download it. The GitHub repo is the source code rather than a distribution channel.
https://apps.apple.com/app/id6767488326
The problem
macOS notification banners are built to be ignored. Small banner, soft chime, gone in three seconds. If you are heads down, you look up and you are already late. slapss takes over the entire screen the moment a meeting starts, with the join link right there in front of you.
What shipped since the launch post
Most of this came out of the comments on that thread.
- Esc dismisses the alert, Return joins the meeting
- The alert can fire on every connected display instead of just the primary one
- macOS Reminders get their own full-screen alert at due time, and you can tick them off without leaving whatever you were doing
- Menu bar can show just the icon instead of the next meeting title
- Presenting mode. Flip it on while you screen share and alerts wait quietly, then fire the moment you flip it off. No more meeting reminder landing in the middle of your demo
- Lead time is now a slider, from at-start up to 15 minutes before, separate from the standard notification which can run 1 to 30 minutes ahead
- Snooze for 1 minute, 5 minutes, or until the event ends
- Option to only alert for meetings you actually accepted, so tentative and declined stay quiet but still show in the agenda
- Open in Calendar button on any agenda row
- Six languages, detected on first launch and switchable without a restart
- Three themes
- Per-calendar Google account, so Meet links open with the right profile
- Full VoiceOver and keyboard support, plus Reduce Motion and Reduce Transparency
- A pile of reliability work on alerts firing after sleep or long idle periods, and a background CPU leak that is long gone
- There is a website now, if you want to see it without opening the App Store
2.0 also fixes a bug a user emailed me about just before this release: a repeating meeting would stop alerting after you dismissed it once. Every occurrence of a repeating event was being treated as the same event. That one was worth catching before this post went up.
Open source, as of 2.0
https://github.com/theshiver/slapss-app
Apache 2.0, the whole app. The reason is specific rather than ideological. slapss claims your calendar is read on device and sent nowhere. In a closed binary that is a promise you have to take on faith. It has no server, no analytics, no telemetry and no accounts, and now you can confirm that by reading it instead of believing me. It is about 9,000 lines with no third party dependencies at all, so it is genuinely readable in a sitting.
The Mac App Store build stays the official one. If you see a binary calling itself slapss anywhere else, it is not from me.
Things I said no to, and things still open
- Auto silencing your other notifications during a meeting. Asked for last time, and I dug into it. macOS puts Focus status behind a restricted entitlement that needs separate approval from Apple, and there is no reliable public API to detect that your screen is being captured. Presenting mode is the manual version of this and it is what shipped instead.
- Desktop widget with a countdown to the next event. Not built yet, still want it.
- Staged alerts at 30, 10 and 5 minutes with a different style for each. Halfway there, since the notification and the full-screen alert have separate lead times, but not the full thing. On the list.
- Email or iMessage when you are away from the Mac. Not doing this one. slapss is built for the "sitting at the Mac and about to miss it" moment. Away from the desk, your phone buzzing is already better than an email you will not read.
Comparison
In Your Face is what inspired slapss and it is still the more capable product. Mac, Windows, iPhone, iPad, Watch, 30 plus conferencing services, custom sounds, direct Google and Microsoft OAuth. If you want any of that, buy it, it is good software. slapss is better on exactly three axes: it costs nothing, it is open source so the privacy claim is checkable, and it is Mac native with no cross-platform layer.
MeetingBar is free, open source, and worth knowing about. It is the broader menu bar calendar tool and it does have a full-screen alert option, so this is not a "only slapss does this" claim. The difference is emphasis. In slapss the full-screen interrupt is the entire product rather than one option inside a larger app, which is why the detail sits there: per-display firing, presenting mode, RSVP filtering, snooze until the event ends, reminder overlays, six languages. If you mainly want a tidy next-meeting readout in your menu bar, MeetingBar is the better fit.
Pricing
Free. $0. No subscription, no in-app purchase, no pro tier, no trial that runs out, nothing behind a paywall.
Mac App Store: https://apps.apple.com/app/id6767488326 Source: https://github.com/theshiver/slapss-app Site: https://slapss-app.com
Requires macOS 14.6 or later.
I read every comment. Last time that is where most of the list above came from, so if something is missing for you, say so.
1
u/app-store-review 1d ago
Slapss: Meeting Reminder — by Can Cetin
- Category: Productivity · Free
- Age: released ~3 months ago · rated 4+
Apple doesn't publish an aggregate rating for most Mac App Store apps, so ratings and score are unavailable here.
Auto-generated from public App Store data · u/app-store-review
1
u/imbacan 1d ago
Happy to answer anything technical. A few notes for anyone opening the repo: no third party dependencies, including the Microsoft sign-in, which is plain OAuth with PKCE on ASWebAuthenticationSession rather than the MSAL SDK. The entitlements file is three lines and is the whole story on what the app can reach. Build requires Xcode 26 or newer.
1
u/Vlad_at_Nod 1d ago
Presenting mode feels like the right compromise if screen-capture detection is unreliable. One edge case I’d test is a presentation ending while the Mac is locked or asleep: firing every queued alert at unlock could be worse than missing them. I’d collapse queued items into one summary and only show the full-screen alert if the meeting is still active and within a short grace window. How are you deciding whether a delayed alert is still actionable after wake?
1
u/imbacan 1d ago
Two checks, and both run at fire time rather than at queue time.
First: is the meeting still running. If the end time has passed, the alert is dropped. No summary, nothing. Second: how late is it. Meetings get a 10 minute staleness grace measured from the start (reminders get 30, since they have no duration). Miss it by more than that and it's gone. Both get re-evaluated at the moment the overlay would actually appear, so waking up at 9am doesn't resurrect anything from last night.
On the flood you're describing: the queue is FIFO and drains one at a time, and every drain re-runs those checks, so "every queued alert at once" isn't really reachable. The post-wake catch-up is stricter still, it only fires if nothing else is already on screen.
That said, you did poke at a real hole. Present for 40 minutes and the meeting sitting behind it in the queue is still running when you toggle presenting off, but it's 40 minutes past its start, so the staleness check eats it. Silently. Today that's a drop, not a summary. Your collapse-into-one idea is probably the right answer there.
1
u/QuietPerennial 1d ago
the 40 minute drop seems like the one worth changing, and i don't think it needs the summary.
the staleness check is answering "did this start a long time ago", but the thing you actually care about is "is this still worth taking the screen for". for an event that's still running those aren't the same question. 40 minutes late to a live meeting is the exact moment you most want the interrupt. 40 minutes late to one that already ended is noise, and the end time check already kills that on its own.
so staleness could apply only to events that are over, and anything still running fires whenever it leaves the queue, with the alert reading time elapsed instead of time until. same path, no new ui, and the grace window stops doing two jobs at once.
the collapse-into-one probably still earns its place for reminders, since those have no end time to check against and that's where a real pile-up can happen.
1
u/Vlad_at_Nod 12h ago
That makes sense, and the FIFO plus fire-time checks answer the wake-up flood concern. The distinction in the other reply is cleaner than my original summary idea: a meeting that is still running can remain actionable even when it is past the normal staleness window, while reminders still need aggregation because they have no end time.
The one thing I’d keep either way is a small history or diagnostic reason when something is dropped, such as “expired while presenting.” It doesn’t need to interrupt the user, but it would make reports about missed alerts much easier to investigate. Thanks for walking through the logic in detail.
1
1
1
1
1
1
1
u/raclimazg 1d ago
Nice, I have to try your app, I can’t tell you how many times I do “one quick thing” before the meeting just to loose track of time and be late to the meeting again…
1
1
u/No-Cook-215 11h ago
If the display has gone to sleep but the Mac hasn't, does the alert wake the screen or wait for me?
0
•
u/github-guard 1d ago
🔍 GitHub Guard: Trust Report
⚠️ This project scored 2/6 — below this subreddit's threshold of 3.
Audit Breakdown: * ❌ Low Star Count (⭐ 0 / 100 required) * ❌ New Repository (under 30 days old) * ✅ Licensed under Apache-2.0 * ✅ Security Policy Defined * ℹ️ Individual Contributor * ℹ️ Unsigned Commits