Looks great, bought it immediately. Maybe its one of the already planned missing features, but I found a button to add a due date but none to add a start date in the tool belt…would be of great help.
1 Like
What does your start date tag look like? It’s not a standard TaskPaper tag right? @Marc
You can type any tag of your own, and they then become pickable from the @ button.
Similar to @due it looks like this: @start(2027-01-01). I think it’s a standard TaskPaper tag, Taskpaper associates it with a date - if you tag a task with @start or @due using the Tag Menu or the “Tag with” command/menu item, Taskpaper shows a date picker, similar to Papertrail when using the “Set Due Date” tool in the tool belt. This is useful because using the @start tag I can filter out tasks with future start dates using Search and then only see tasks I can or want to work on currently.
Would be great if there would be a tool that works exactly the same as “Set Due Date”, but allowing to “Set Start Date” - might even be available as a choice with a long press on the existing “Set Due Date”-Button.
(I really like the option to color text based on outline level, I activated it playing around and was surprised by how useful I found it to be.)
1 Like
Thank you, makes total sense. I’ll add it.
I’m aiming for feature parity, so is there a list of all standard TaskPaper tags?
Colour by outline level is an idea I got from, I think, an old Palm OS outliner app. It’s cool!
I wrote a bit about my big app launch.
1 Like
Matt, please send me a TestFlight invitation for Paper Trail.
Thanka,
Bob
Back at my Mac and looking at Taskpaper… The “Tag With” command gives a choice of four tags: Due, Start, Today and Done. Those also have their own command. I don’t know about more standard tags. “Priority” is an example for associating tags with values in the documentation but I don’t think this is meant to be a standard.
1 Like
I’m almost done with next changes including start tag
1 Like
Matt - please consider two small tweaks that are friction points for me:
- I would love it if the app opened up to whatever state/view I left it in. If I haven’t used it for some time, I get the opening screen with new doc / file picker. Perhaps this could be a preference setting if other people always want to start from scratch.
- I would love to be able to move the position of the “dismiss keyboard” button, so I don’t have to scroll to the right to find it. I checked and it seems like the always visible items can’t be moved using the tool belt help.
Much thanks. I am a happy tester and paid customer and appreciate all the work you put into this. Having the mobile app allowed me to reorient my workflow on Taskpaper.
Tim
1 Like
This is my personal number one wish! It would open up all sorts of possible features.
Sadly, it’s an Apple limitation on apps that adhere to DocumentGroup architecture. Kind of ridiculous, but they claim it’s a security feature, and that users should always choose the doc manually. 
I plan to spend some time to try to find an acceptable workaround that doesn’t require me to to reimplement everything I get for free. But my experiments between Aug 2025 and March 2026 proved fruitless. Even the best iOS developer I know (my friend Dave) couldn’t figure out a workaround.
I might email Apple about this, as there was no reply to my post in the dev forum.
That said:
- The app should be light enough to stay in memory for a long time if you don’t force quit it
- The picker has a recent view, so it’s only one tap to open a recent doc
- I know, I know
Fair point! Putting that on the immovable group seemed like a good idea at the time. But I see how it would be useful.
Understood about the DocumentGroup limitation. I suspect they want to force a re-open to minimize potential file conflicts, but this kind of clunkiness is a real limitation.
My two points were actually tied together. I am one-clicking via recents to re-open the doc but then I am in edit mode, when 80% of the time, I want to read the list. So then I hunt for the keyboard dismiss button to see the whole screen. Having that pinned to the left would work a lot better for me at least. Similarly a preference option to open docs in read mode vs edit would be a nice to have.
And on one more related point, I really like to be able to expand/collapse and mark items done while keeping the keyboard hidden, but the touch targets are on the small side and I often end up in full-on edit mode with the keyboard.
Thanks again for the app! Keep the polishing away!!
Tim
2 Likes
Thanks! Yeah, I see what you mean. A lot of the functions require the position of the cursor to be known and if the cursor is shown the keyboard is shown. But I’ll take a look to see if I can mark an item as done (bullet press) without those.
It’s not that, I cope with conflicts. It to prevent an unsafe document from being opened without the user consent. I’m paraphrasing.
Here’s maybe one of those angry users:
My suggestion is to go at them with positive energy. Even if they don’t respond with positivity others will see you reaction and that’s what matters most I think.
Edit Whoops, I had intended to post this to a private thread that I have with @matt, so that’s the context. I’ll leave it here though since already posted.
4 Likes
That’s OK. 
I do respond positively. Though the anger in some of the feedback has shocked me. 
I’m working hard on 1.1, features and fixes aplenty.
3 Likes
I wouldn’t worry about that – people do have bad days.
1 Like
Thanks for a great thread and launch.
Let’s move to another castle:
PSA: 1st May 2026 is the last day of the lower launch pricing. Depending on which time zone you are in I’m not sure when the cut-off is, so best to buy it sooner rather than later.
Don’t be shocked! It’s the old battle: prefrontal cortex versus amygdala…
Keep up your great work!
Oli
1 Like