Show HN: An iOS budget app I've been maintaining since 2011
21–30 of 61 posts
Re: Show HN: An iOS budget app I've been maintaining since 2011
#22Nice project! I built a CLI budgeting project a long time ago, and what made me stop using my own project was the lack of automated integration with my bank accounts. At that point I had many credit cards, multiple bank accounts, in different currencies, and integrating all expenses was just too much manual work. I wish financial institutions were better at automated exports of your financial data, given the right pe…
Re: Show HN: An iOS budget app I've been maintaining since 2011
#23Re: Show HN: An iOS budget app I've been maintaining since 2011
#24Nice project! I built a CLI budgeting project a long time ago, and what made me stop using my own project was the lack of automated integration with my bank accounts. At that point I had many credit cards, multiple bank accounts, in different currencies, and integrating all expenses was just too much manual work. I wish financial institutions were better at automated exports of your financial data, given the right pe…
it's very sad that in Europe we have laws to guarantee "open banking" but in practice it's only B2B
Re: Show HN: An iOS budget app I've been maintaining since 2011
#25Nice project! I built a CLI budgeting project a long time ago, and what made me stop using my own project was the lack of automated integration with my bank accounts. At that point I had many credit cards, multiple bank accounts, in different currencies, and integrating all expenses was just too much manual work. I wish financial institutions were better at automated exports of your financial data, given the right pe…
In practice, though, I found them less useful for budgeting than expected. A bank statement tells you how much was spent and where, but not what the expense actually was. “$100 at a supermarket” could be groceries, pet food, a lawn mower, or business expenses — that context is what makes budgeting meaningful, and it usually has to be added manually anyway.
At that point, entering the expense directly with the right category often turned out to be simpler and more accurate for me. Automated access would still be nice for reconciliation, but it’s not the silver bullet it’s often perceived to be.
Re: Show HN: An iOS budget app I've been maintaining since 2011
#26My personal bias is that anytime I see on a software company's website footer that they're a GmbH, I know it will be selling high quality, durable, reliable software ;) Congrats on your continued success!
I originally set it up mainly for risk separation. Before the apps, I was developing backup software, and having a legal structure felt like the responsible thing to do. It also looked more professional at the time. Whether I’d do it again today, I’m honestly not sure.
That said, keeping personal and business finances clearly separated has definitely been a good decision in the long run.
Re: Show HN: An iOS budget app I've been maintaining since 2011
#27Nice project! I built a CLI budgeting project a long time ago, and what made me stop using my own project was the lack of automated integration with my bank accounts. At that point I had many credit cards, multiple bank accounts, in different currencies, and integrating all expenses was just too much manual work. I wish financial institutions were better at automated exports of your financial data, given the right pe…
That’s a fair point. Automated bank imports sound essential at first, especially with many accounts and cards. In practice, though, I found them less useful for budgeting than expected. A bank statement tells you how much was spent and where, but not what the expense actually was. “$100 at a supermarket” could be groceries, pet food, a lawn mower, or business expenses — that context is what makes budgeting meaningful…
Re: Show HN: An iOS budget app I've been maintaining since 2011
#28The questions that come to mind for me: 1. How long after releasing the iOS app did you start on an Android version? 2. Are you using some kind of cross-platform framework, or are the apps mostly “mobile-friendly web views”? 3. How much code is shared between the three architectures? 4. How much of the app functionality is “server based” instead of “on device”?
In short: native apps, local-first architecture, with sync as an optional layer rather than a requirement.
Re: Show HN: An iOS budget app I've been maintaining since 2011
#29As a German - I'm sure you've looked into integrating FinTS and therelike? What made you decide not to integrate any of that?
In practice, though, I found them less useful for budgeting than expected. A bank statement tells you how much was spent and where, but not what the expense actually was. “$100 at a supermarket” could be groceries, pet food, a lawn mower, or business expenses — that context is what makes budgeting meaningful, and it usually has to be added manually anyway.
At that point, entering the expense directly with the right category often turned out to be simpler and more accurate for me. Automated access would still be nice for reconciliation, but it’s not the silver bullet it’s often perceived to be
Re: Show HN: An iOS budget app I've been maintaining since 2011
#30Interesting! I know next to nothing about iOS development, but surely there have been major changes in frameworks and expected look (often connected)? Which changes were there over the years and how and when did you follow them? Did it turn out good or bad to follow early / late?
On the technical side, the biggest shifts were things like Objective-C → Swift, ARC, Auto Layout, size classes, Dark Mode, and more recently SwiftUI. I generally didn’t jump on everything immediately. My rule of thumb was: adopt new frameworks once they’re clearly stable and proven in real apps. Being too early often meant rewrites; being too late meant technical debt. A slightly conservative approach worked best for me.
Visually, Apple’s HIG evolved a lot: skeuomorphism → flat design → more layered, content-first UIs. I followed those changes gradually. Smaller visual updates happened continuously, but larger redesigns only when there was a real user benefit or a technical reason. Version 10 is one of those bigger moments where design and architecture changes aligned.
In hindsight, following a bit late rather than very early turned out to be the better tradeoff. Users value stability and consistency more than being on the absolute cutting edge, especially for a long-term app they rely on daily.