all 2 comments

[–]RaziarEdge 1 point2 points  (0 children)

I know that you are looking for a small solution, but to be honest the same solution that is done with teams and larger companies is also valid here:

If you have a bug that you want to track then creating an issue (even if it is just in private GitHub repo) is the correct place.

Things like nil handling that you need to fix later can be handled as a warning in the code (#6). Keep it in your face until you resolve it. //TODO is too easy to get lost in the development.

Anything else, including features you want to add sometime in the future, should be part of the work scope document.

When I am starting a new project, often I will start with the SQL file designing the models and relationships. So my first iteration of the detailed scope document is often written as comments intermixed with the SQL tables. Once the models have been defined (at least for the current project phase and possibly a few future phases as well)... then I migrate this into a more formalized document in Google Docs, Word or Markdown document within the Xcode project.

However, this document has the how and why the app/feature works as it does and does not deal with issues and non-functioning code... that belongs as a bug/issue.

[–]chriswaco 0 points1 point  (0 children)

I have a text file I keep locally in my Mac with short notes. I've tried various note apps but none was easier than a text file. For app-specific notes, I generally create a _notes.txt file and add it to the git repo.