I don't have an iPhone to try this, but I've been a long time time user of Tasks.org on Android and particularly because it supports CalDAV and works so well offline.
However, while we are on the topic of planning apps, you should know the Todoist added the best use of AI I've ever seen. It's called Ramble mode and you can just talk and instantly it'll start showing a list of tasks that update as you go. It is extraordinary. I'm considering switching away from tasks.org for this one feature.
That’s cool! Slight fear of replicating the Dropbox comment here, but all you really need to do is run whisper (or some other speech2text), then once the user stops talking jam the transcript through a LLM to force it into JSON or some other sensible structure.
"once the user stops talking" is a key insight here for me. When using this I wasn't intentionally pausing to let it figure out an answer. It seemed to just pop up while I was talking. But upon experimenting some more it does seem to wait until here's a bit of a pause most of the time.
However it's still wild to me how fast and responsive it is. I can talk for 10 seconds and then in ~500ms I see the updates. Perhaps it doesn't even transcribe and rather feeds the audio to a multimodal llm along with whatever tasks it already knows about? Or maybe it's transcribing live as you talk and when you stop it sends it to the llm.
Anyone have a sense of what model they might be using?
I cannot remember off the top of my head the exact number and am clearly too lazy to google it but there is a specific length of time in which, if no new noises pass through, the human brain processes it as a pause/silence.
I want to say 300ms which would coincide with your 500ms example
This is definitely dependent on individuals. It’s a reason during some conversations people can never seem to get a word in edgewise, even if the person speaking may think they’re providing opportunities do so. A mismatch in “pause length” can make for frustrating communications.
I am also too lazy to google or AI it but it’s something I remember from when I taught ESL long ago.
Irrelevant to this post, but Morocco switching to UTC does not change the number of hours fasted as that is based on sunset and sunrise so not really a religious "hack" but more similar to daylight saving (work hours remain same).
I’m with the parent on this. I don’t mind subscriptions if a service is provided that justifies the recurring cost. If it’s a local offline app then I don’t see it justified. Price it accordingly or at least give an option for one-time.
But yes, sub vs non-sub model is a very divisive topic. Personally would never subscribe to something like a offline local todo list
One way of looking at is that subscription software helps align developer interests with dedicated users. It's easier to retain users than it is to get new users, so developers are incentivized to build features/make improvements for existing users to keep them as happy users. In a pay once upfront model developers are essentially only incentivized to build features that attract new users.
The issue I see is that for certain apps, such as one I am currently working on and hope to publish soon on iOS, is that they do require a lot of maintenance once published even if there were no server costs. Given the amount of work I already put in it and how much more will be necessary even just to keep the app correctly running in the future, I don't really see what other monetization approach would make sense for me. Actually, I would even argue that selling an app without a subscription might (sometimes) be setting wrong or blurry expectations: if a user accepts to pay today a single time, how long are they expecting updates for? Will it only be basic bug fixes or also major new features? With a subscription, I feel like at least if they are unhappy with my app, they won't really have lost anything and can just unsubscribe, since they had basically accepted, IMO, that the money they put in my app each period of time is only for the service and potential updates in that small period of time and not future changes.
A one time cost is fine if you don’t mind the app breaking next time Apple updates iOS. There is an ongoing cost to ensuring the app continues to work.
The maintenance effort required on iOS is substantial. About a quarter of your full-time year needs to be dedicated to it.
On desktop, you can just publish your software and slowly see it age as you work on your next big release. On iOS, it ages every year at brutal pace, and your new sales will plummet while you work on your next big release, meaning your revenue crashes much faster.
Even worse, the iOS App Store has no notion of paid upgrades, and publishing a new app is basically like starting from scratch as far as discoverability goes. So when you finally have your next big release ready, it's like launching a completely new company.
Apple really wants developers to make subscription apps that ship frequent iterative changes, and other business models just simply don't work well on their mobile platform (on Android it's even worse btw).
I’m not paying for the human that made the app. I’m paying for the app, aka for an advertised thing with an advertised feature set for a specific price. If I deem the value I get for the price worth it, I will purchase the thing from you.
I will however not pay you monthly just because “the dev needs to eat too” if there is no service provided that justifies the monthly ongoing cost.
there are a lot of apps that do this though… eg. git tower. Sketch. Etc. Not saying that I like it or anything. Maybe its the combination of local first + an app that seems to be trivial (I am sure it was not but if you hear "daily planner" I think its reasonable to assume that its less complex than a git client and/or an app like Sketch).
I think someone that can afford to publish on the most expensive app publishing platform can afford food all the time. There are no poor iOS developers.
hmmm... a planner is one of the few things that i'd like to have access to regardless of what i'm using...
One of the few things i don't mind and even slightly prefer to be online first for seemless sync (with the ability to edit and add to offline ofcourse)
Local-first should mean that you do have it regardless of what you're using. Point 2 in Ink&Switch's original essay is "Your data is not trapped on one device".
FWIW, the term "local-first" wasn't coined by Ink&Switch so different people have different understanding of the term.
But, Ink&Switch rule regardless, I love what they're doing and everyone would be better off doing "local-first" in the way they suggest, don't get me wrong.
Sounds good, doesn't work. How would I sell a major version on a store like the Apple or Google app stores [0]? How will I fund my salary as well as my employees' salaries from only major versions, what if people buy now but not later on, do I lay them off? For what it's worth I do offer lifetime plans that are basically 2 to 3 years of the annual plan, as that's the expected lifetime value (LTV) of some of my apps.
There used to be a lot less expectation of post-sale maintenance of consumer software in the era where sales rather than subscriptions were the norm. There was also tolerance for higher up-front prices, and for much of that period sales depended on marketing through and validation by a narrow set of relatively trusted discovery channels, which customer the perceived risk to buyers. Now everything is untrusted, no one wants to pay much upfront but everyone expects ongoing support over they've got the thing. I’m not saying subscription is the only thing that works, but it's pretty easy to see that the calculus facing the average vendor has shifted tremendously over time.
fwiw the expectation of post-sale maintenance would not be nearly as egregious if companies were not regularly pushing new updates that cause new issues
Well, on mobile the underlying operating system is moving so fast that companies must continue to update their apps or else they stop working. It's the absolute inverse situation to the backwards compatibility story of Windows. That kind of backwards compatibility is a wet dream for every mobile developer.
It's a bunch of things. In the old days, if you bought software in a box for your OS (let's say DOS), you didn't expect it to need to be updated. It also continued to work just fine and maybe you didn't update your OS that frequently or had security issues to worry about. Nowadays, iOS gets updated every year and APIs get deprecated, and users update, so you have to maintain the app after initially shipping it.
A lot of people also expect the software to add features over time. In the old days, you'd ship a brand new major version and charge people for that and stop working on the old one. With the App Store, I suppose you could technically abandon the old version and sell a whole new version, but then all your old users will be annoyed if the app is removed from the store or no longer works when they update their OS. You could gate new features behind a paywall, and I know some apps do this, but then it adds to the complexity of the app as you have to worry about features that work for some users but not others.
I think people also expect software nowadays to be cheap or free, I think due to large corporations being able to fund free stuff (say gmail) by other means (say ads or tracking users). That means users would balk if you asked them to pay $50 for your little calendar app, so if you did ask for a one-time payment, it would be $5-$10, which is nowhere near enough to recoup whatever time you spent, unless you hit it big. Hitting it big nowadays with an app is difficult since there's so much competition in the App Stores and everyone has raced to the bottom to sell apps for pennies.
That's fine, people like you aren't my customer anyway and thus do not need to be listened to. Free users generally have value if they can convert to paid, because nothing is truly free in life.
If this were available on macOS as well, and did sync via iCloud I'd be all over it. It's a great model for a calendar/task manager but I really don't want to have to squint at my phone screen while using it.
Thanks. I'm happy to share that iCloud sync and MacOS app is something that already in the plan for future development. In the meantime, if you have an M-series Mac, you should be able to run the app directly on your Mac since I've enabled Mac Catalyst support.
I fail to see features that default iOS calendar app already has. The UI seems really simple and there is dozens of amazing calendar apps that have been on the market for 10+ years of features in this price range.
It looks well done. It is a shame that people posting reviews can be such dickheads. Out of the 4 public reviews, 3 are 1 star and only one of those is because of an actual issue. One is because the app isn’t right for them. The other because they wanted dark mode (really? You like the app enough to care that it doesn’t have dark mode but still gave it a 1 star?)
For 20 bucks a year without any sort of cloud servers to pay for, I'd expect dark mode at the very least. The app looks nice of course, but it's priced quite steeply.
If you charge a premium, customers will have high expectations.
I don't have an iPhone to try this, but I've been a long time time user of Tasks.org on Android and particularly because it supports CalDAV and works so well offline.
However, while we are on the topic of planning apps, you should know the Todoist added the best use of AI I've ever seen. It's called Ramble mode and you can just talk and instantly it'll start showing a list of tasks that update as you go. It is extraordinary. I'm considering switching away from tasks.org for this one feature.
Here's a short video of it: https://www.youtube.com/watch?v=DIczFm3Dy5I
You need paid (free trial is ok) and to enable experiments before you can access it.
Anyone know how they might have done this?
For Android and Windows users, you can try my todo app “Hamsterbase Tasks”.
It's open-source and supports self-hosted. Available on web, Mac, Windows, Linux, iOS, and Android.
Do you support calDAV? I looked briefly but didn't see it. A good calDAV client is something I'd pay for.
That’s cool! Slight fear of replicating the Dropbox comment here, but all you really need to do is run whisper (or some other speech2text), then once the user stops talking jam the transcript through a LLM to force it into JSON or some other sensible structure.
"once the user stops talking" is a key insight here for me. When using this I wasn't intentionally pausing to let it figure out an answer. It seemed to just pop up while I was talking. But upon experimenting some more it does seem to wait until here's a bit of a pause most of the time.
However it's still wild to me how fast and responsive it is. I can talk for 10 seconds and then in ~500ms I see the updates. Perhaps it doesn't even transcribe and rather feeds the audio to a multimodal llm along with whatever tasks it already knows about? Or maybe it's transcribing live as you talk and when you stop it sends it to the llm.
Anyone have a sense of what model they might be using?
I cannot remember off the top of my head the exact number and am clearly too lazy to google it but there is a specific length of time in which, if no new noises pass through, the human brain processes it as a pause/silence.
I want to say 300ms which would coincide with your 500ms example
This is definitely dependent on individuals. It’s a reason during some conversations people can never seem to get a word in edgewise, even if the person speaking may think they’re providing opportunities do so. A mismatch in “pause length” can make for frustrating communications.
I am also too lazy to google or AI it but it’s something I remember from when I taught ESL long ago.
https://boundaryml.com/
LLM to types and done
> Morocco runs on UTC+1 most of the year but switches to UTC during Ramadan to shorten the fasting day
Unrelated, but I love coming across religious "hacks" like these that communities have developed over the years.
A similar one is the fishing line that jews tied around New York to get around the rules of Sabbath https://www.npr.org/2019/05/13/721551785/a-fishing-line-enci....
Irrelevant to this post, but Morocco switching to UTC does not change the number of hours fasted as that is based on sunset and sunrise so not really a religious "hack" but more similar to daylight saving (work hours remain same).
I think you left this comment on the wrong article ;)
Haha yes, but it was unrelated either way
Indeed I did, thanks!
how many accounts do you have, my guy?
Only 2.
Moroccan here. We used to switch timezones 4 times a year, and I guarantee you it was exhausting!
I'm sorry, I like the look and the idea but... why is a subscription necessary for a local-first app?
The price isn't mentioned anywhere on the website and I don't have an iPhone, but I am curious, how much is it?
I suspect the guy enjoys some food every now and then
I’m with the parent on this. I don’t mind subscriptions if a service is provided that justifies the recurring cost. If it’s a local offline app then I don’t see it justified. Price it accordingly or at least give an option for one-time.
But yes, sub vs non-sub model is a very divisive topic. Personally would never subscribe to something like a offline local todo list
One way of looking at is that subscription software helps align developer interests with dedicated users. It's easier to retain users than it is to get new users, so developers are incentivized to build features/make improvements for existing users to keep them as happy users. In a pay once upfront model developers are essentially only incentivized to build features that attract new users.
“Still not selling the imprint of my anus? Here’s another five bucks!”
i.e.
It’s sad I can’t use Google’s task manager (both because it sucks, and I can’t trust it),
but that’s life.
The issue I see is that for certain apps, such as one I am currently working on and hope to publish soon on iOS, is that they do require a lot of maintenance once published even if there were no server costs. Given the amount of work I already put in it and how much more will be necessary even just to keep the app correctly running in the future, I don't really see what other monetization approach would make sense for me. Actually, I would even argue that selling an app without a subscription might (sometimes) be setting wrong or blurry expectations: if a user accepts to pay today a single time, how long are they expecting updates for? Will it only be basic bug fixes or also major new features? With a subscription, I feel like at least if they are unhappy with my app, they won't really have lost anything and can just unsubscribe, since they had basically accepted, IMO, that the money they put in my app each period of time is only for the service and potential updates in that small period of time and not future changes.
This used to be handled by selling full-version upgrades and providing patches between versions for free.
A one time cost is fine if you don’t mind the app breaking next time Apple updates iOS. There is an ongoing cost to ensuring the app continues to work.
Why would it break next time Apple updates iOS? Will the developer not want new sales on that updated iOS ?
The maintenance effort required on iOS is substantial. About a quarter of your full-time year needs to be dedicated to it.
On desktop, you can just publish your software and slowly see it age as you work on your next big release. On iOS, it ages every year at brutal pace, and your new sales will plummet while you work on your next big release, meaning your revenue crashes much faster.
Even worse, the iOS App Store has no notion of paid upgrades, and publishing a new app is basically like starting from scratch as far as discoverability goes. So when you finally have your next big release ready, it's like launching a completely new company.
Apple really wants developers to make subscription apps that ship frequent iterative changes, and other business models just simply don't work well on their mobile platform (on Android it's even worse btw).
I have a fully offline app and I offer the users two options (in addition of using a "basic" version for free)
- monthly subscription
- or pay one time fee of ~ 6-month subscription and own it forever
To be honest, in this case the subscription is cheaper for the average user, because most cancel in under six months.
So it's ok to pay for machines but for the humans working on something then no?
I’m not paying for the human that made the app. I’m paying for the app, aka for an advertised thing with an advertised feature set for a specific price. If I deem the value I get for the price worth it, I will purchase the thing from you.
I will however not pay you monthly just because “the dev needs to eat too” if there is no service provided that justifies the monthly ongoing cost.
there are a lot of apps that do this though… eg. git tower. Sketch. Etc. Not saying that I like it or anything. Maybe its the combination of local first + an app that seems to be trivial (I am sure it was not but if you hear "daily planner" I think its reasonable to assume that its less complex than a git client and/or an app like Sketch).
I think someone that can afford to publish on the most expensive app publishing platform can afford food all the time. There are no poor iOS developers.
Everything will cost you, in Apple's ecosystem. This is just another line on the tab.
hmmm... a planner is one of the few things that i'd like to have access to regardless of what i'm using... One of the few things i don't mind and even slightly prefer to be online first for seemless sync (with the ability to edit and add to offline ofcourse)
Local-first should mean that you do have it regardless of what you're using. Point 2 in Ink&Switch's original essay is "Your data is not trapped on one device".
https://www.inkandswitch.com/essay/local-first/
FWIW, the term "local-first" wasn't coined by Ink&Switch so different people have different understanding of the term.
But, Ink&Switch rule regardless, I love what they're doing and everyone would be better off doing "local-first" in the way they suggest, don't get me wrong.
Totally get that. I'm planning to support more platforms, and I'm glad to say that iCloud sync is already in the plans for future development.
Love the app, hate IAP / subs model
That's the only sustainable model these days, speaking as a mobile dev myself.
Sell me a major version every couple of years, would far prefer that. IAP and subs just feels scammy and lazy.
Sounds good, doesn't work. How would I sell a major version on a store like the Apple or Google app stores [0]? How will I fund my salary as well as my employees' salaries from only major versions, what if people buy now but not later on, do I lay them off? For what it's worth I do offer lifetime plans that are basically 2 to 3 years of the annual plan, as that's the expected lifetime value (LTV) of some of my apps.
[0] https://news.ycombinator.com/item?id=45810856#45815972 (this comment gets it right on why you can't do this on said app stores)
What changed that made selling software (as opposed to renting) work before that prevents it from working now?
There used to be a lot less expectation of post-sale maintenance of consumer software in the era where sales rather than subscriptions were the norm. There was also tolerance for higher up-front prices, and for much of that period sales depended on marketing through and validation by a narrow set of relatively trusted discovery channels, which customer the perceived risk to buyers. Now everything is untrusted, no one wants to pay much upfront but everyone expects ongoing support over they've got the thing. I’m not saying subscription is the only thing that works, but it's pretty easy to see that the calculus facing the average vendor has shifted tremendously over time.
fwiw the expectation of post-sale maintenance would not be nearly as egregious if companies were not regularly pushing new updates that cause new issues
it is a problem of ones own making
Well, on mobile the underlying operating system is moving so fast that companies must continue to update their apps or else they stop working. It's the absolute inverse situation to the backwards compatibility story of Windows. That kind of backwards compatibility is a wet dream for every mobile developer.
It's a bunch of things. In the old days, if you bought software in a box for your OS (let's say DOS), you didn't expect it to need to be updated. It also continued to work just fine and maybe you didn't update your OS that frequently or had security issues to worry about. Nowadays, iOS gets updated every year and APIs get deprecated, and users update, so you have to maintain the app after initially shipping it.
A lot of people also expect the software to add features over time. In the old days, you'd ship a brand new major version and charge people for that and stop working on the old one. With the App Store, I suppose you could technically abandon the old version and sell a whole new version, but then all your old users will be annoyed if the app is removed from the store or no longer works when they update their OS. You could gate new features behind a paywall, and I know some apps do this, but then it adds to the complexity of the app as you have to worry about features that work for some users but not others.
I think people also expect software nowadays to be cheap or free, I think due to large corporations being able to fund free stuff (say gmail) by other means (say ads or tracking users). That means users would balk if you asked them to pay $50 for your little calendar app, so if you did ask for a one-time payment, it would be $5-$10, which is nowhere near enough to recoup whatever time you spent, unless you hit it big. Hitting it big nowadays with an app is difficult since there's so much competition in the App Stores and everyone has raced to the bottom to sell apps for pennies.
Weird. Things3 seems to be doing great without it
The exceptions that prove the rule.
I hope you don't mind my $0.00 annual mobile spend as a result.
That's fine, people like you aren't my customer anyway and thus do not need to be listened to. Free users generally have value if they can convert to paid, because nothing is truly free in life.
If this were available on macOS as well, and did sync via iCloud I'd be all over it. It's a great model for a calendar/task manager but I really don't want to have to squint at my phone screen while using it.
If the developer checked the enable the Mac Catalyst destination in the Xcode project, you should be able to run it on your Mac.
Thanks. I'm happy to share that iCloud sync and MacOS app is something that already in the plan for future development. In the meantime, if you have an M-series Mac, you should be able to run the app directly on your Mac since I've enabled Mac Catalyst support.
When I open this in the Mac app store, there is a download button, so I'm guessing it works on both iOS and macOS due to catalyst.
Look into NotePlan.co it syncs with iCloud and has native MacOS and iOS apps. I love it.
Looks awesome! I will give it a try. Wondering what's ur monetization plan though.
I fail to see features that default iOS calendar app already has. The UI seems really simple and there is dozens of amazing calendar apps that have been on the market for 10+ years of features in this price range.
> I fail to see features that default iOS calendar app already has.
presumably local-first
How is iOS calendar not local-first
What does that mean?
Looks nice. I will give this a try today
Thanks. Would love to hear how it goes. Let me know if you have any feedbacks.
It looks well done. It is a shame that people posting reviews can be such dickheads. Out of the 4 public reviews, 3 are 1 star and only one of those is because of an actual issue. One is because the app isn’t right for them. The other because they wanted dark mode (really? You like the app enough to care that it doesn’t have dark mode but still gave it a 1 star?)
For 20 bucks a year without any sort of cloud servers to pay for, I'd expect dark mode at the very least. The app looks nice of course, but it's priced quite steeply.
If you charge a premium, customers will have high expectations.
It is not a binary system. If every time an app misses a feature you want you rate it a 1 star, it completely devalues the rating system.
[dead]