Quick note on the current stack for my iOS app, SendLog

Around one year ago, I started a small private side project mainly to learn about AI-assisted coding and to make sure I have hands-on experience with the tools that are supposed to fundamentally change the way we work as software engineers.

The app I released is called SendLog, a kind of activity tracker for rock climbers. My first post about it is here. The app itself you can find on the iOS app store. It has significantly grown in functionality over time (e.g. it now also has a backend to sync between Apple devices) and obviously my stack also has changed considerably based on my experiences and learnings.

What also has changed is my development process. Here is some update, a bit unstructured and without proper linking:

Harness: Really like pi from Mario Zechner, works well for me. For code diffs I use VSCode.

Model Provider: I have a GitHub Copilot Pro subscription (the cheap one, 10$ per month with mostly covered my needs, some additional premium requests from time to time, but surely I never paid more than 20$ per month). This will change definitely with GitHubs new charging model, which would increase my estimated costs based on current (very moderate) usage by a factor of 10. Now way. Looking into OpenRouter now giving me access to cheaper models.

Model: Mostly Claude Sonnet 4.6. Started experimentation with DeepSeek V4Pro which is a fraction of the costs. First experiences are not bad, although context windows seem to fill up much faster. Also got some strange artefacts. Kanji anyone?

Skills/Custom agents: I tried a lot of different things but most of the time don’t use these any more. Didn’t see that much benefit. Most of the time I just use the standard planning agent, try to keep changes small and make sure features are split into smaller, individually testable commits. Some times I use the superpower skills, but very sparingly. Skill invocation is kind of hit and miss. I use one custom skill for uploading new iOS builds to TestFlight. This is very convenient but ultimately is just am automation script using FastLane.

Spec driven development: Tried SpecKit for a while but ultimately found it too cumbersome for my application.

Hooks: I use them way more now in an attempt to have better guardrails. Mainly git hooks though. Linters are invoked pre-commit, SonarQube pre-push with a quality gate. I use the SonarQube Community edition with the Open Source Swift plugin.

I think hooks will play a very important role in the future as they are deterministic. Another hook I have configured in pi is a preToolsUse hook that checks that commit and push commands are never executed with the -no-review option. The model tried to circumvent my git hooks that invoke the linters multiple times although the instruction file/agents.md file explicitly required it. So I learned (which should have been obvious) that everything that is included in an instruction file just goes into the context and thus is non-deterministic. Hooks really help here.

MPCs: no MCPs used, I had one to check dependencies but replaced it by a script that checks for latest versions directly on GitHub, more efficient, less tokes, less training data for Context7

Backend Sync: Google Firebase/FireStore - convenient SDKs for iOS and Web, supports Apple Authentication, good free tier - does all I want and need for the moment. The initial plan to use iCloud was abandoned because of the lack of a proper JavaScript SDK for the web app.

Graphify: There is something else, I am currently experimenting with and this is graphify. It is an Open Source tool that builds a graph representation of a repo/codebase. Something like a GraphRAG infrastructure. The graph representation is queried before each read tool invocation by the harness and should guarantee that the agent does not need to explore the whole repo for useful context. Graph updates happen with every commit. It is supposed to reduce token usage considerable after the initial effort/token burn to build the graph. I don’t have any real world data but the concept sounds reasonable. There are other ways to achieve similar results, I think CodeScene ( a commercial static code analysis tool) can do something similar using a MCP.

That’s it more or less, all pretty straight forward. I did some significant refactoring, extracting shared functionality and improved testability, Sonar shows green light, which is good.

I still don’t do full code review but again, the app is kind of trivial although it has already around 10K lines of code.

If somebody is interested helping to port the app to Android, get in touch. Another failed experiment of mine :-D.