Show HN: An iOS budget app I've been maintaining since 2011 (primoco.me)

Thanks! I strongly agree.

A local-first, offline-capable model turned out to be one of the best long-term decisions. It makes the app faster, more reliable, and usable in situations where connectivity is poor or nonexistent. Sync then becomes an enhancement, not a dependency.

It also changes how you design software: you optimize for resilience and data ownership instead of assuming a server is always there. I’m convinced more apps would benefit from this approach, especially for tools people rely on daily.

Thank you — and congrats to you as well, that’s an impressive run.

I completely agree: in a small, niche business, relationships and support matter far more than scale. Replying quickly, taking users seriously, and actually helping them goes a long way over many years. It’s probably one of the few real advantages solo developers have over larger teams.

13 years in a niche is no small achievement. Best of luck to you too, and thanks for sharing your experience — it’s always encouraging to hear similar stories.

Good question — yes, there were many major changes, both technically and visually.

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.

Thanks! That’s funny, because while it’s technically a GmbH, it’s really just me — a one-person company.

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.

Germany is not what it used to be. And Software companies from Germany are not what they used to be

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, 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.

I have been pondering on this issue as well. Budgeting apps which have integration seem to have access to too much data.

Why do we need such a detailed breakdown for personal finance. I am pondering on this idea of using under or over type prompts to capture daily expense. The app send a notification asking me did you spend $100 or less in the day. Eventual goal of all budgeting apps is to reduce spending. this simple prompt can capture immense information without needing to break it down. breaking it down to categories can be a step if there is a problem detected in the savings pattern. For that banks are already adding the feature

keen to hear thoughts on this

Good questions. - The Android version came about two years after the iOS app. iOS was always my primary focus and the main success driver. - Both apps are 100% native. No cross-platform framework and no web views. It may sound more complex, but for me it was actually simpler and more controllable that way. - There is very little shared code between platforms. Concepts and ideas are shared, but the implementations are platform-specific. - The core app functionality is almost entirely on-device. MoneyControl works locally by design. There is an optional WebApp that adds device sync and a browser-based interface, but the server side is essentially limited to synchronization.

In short: native apps, local-first architecture, with sync as an optional layer rather than a requirement.

Thank you very much for pointing this out? The correct link is https://apps.apple.com/app/id465909912

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, 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