Try editing a task on ios mobile. Touch the task and wait for the cursor to appear. Now try to move the cursor. 95% of the time the task starts sliding making editing almost impossible. It is enough to get me to go back to Workflowy. I canāt believe what a poor UX decision this was. Was it zeal to match other apps? Was it obsession with something cool? Compromising basic functionality is no way to add features. Itās terrible. The so called solution is to add a confirmation? I suppose this reduces accidental deletion or completion, but that only tells you there is something wrong with sliding to begin with. It looks like there is no intent to fix this unfortunately. Get rid of it, or make it an option in Settings. Iāll immediately turn it off, or just go use Workflowy.
Hey I understand your frustration but please hold off the hostility!
Thatās one way we could fix the issue. An alternative Iād propose is to disable swipe actions when thereās a cursor focus. I think this is a good solution because when a user intend to swipe and complete/delete, they will need to click on the confirmation, which de-focuses and hides the keyboard. So given a de-focus happens regardless, I think itād be a better experience if swiping only works when there is no focus and the keyboard is hidden.
Of course an option in the settings page can still be useful. Weāre open to discussion on that one.
Understandably it doesnāt feel useful at all to you, but this was suggested many times by other users as a way to complete or delete items without having to wait for the keyboard to pop up, press the complete/delete button on the toolbar, and tap away to hide the keyboard.
The implementation could use some improvements for sure, but if youāve been following our development you should know that we actively fix issues like this when itās reported.
The confirmation was added because some people accidentally completed/deleted parent level items with lots of children items. All this without knowing it happened, so you can see the frustration when they realize half their stuff was nowhere to be found.
Thereās always a trade-off between making things easier to do, and accidentally doing it. I donāt think that means thereās something wrong with sliding. In fact, many other apps does it this way - not saying thereās no downsides but there must be some merit to the design if itās that popular.
I also donāt understand why you use such a tone. Youāre using our product for free, weāre happy you want to voice issues with it. Weād be happy to make our product better with your help, but your threats to use Workflowy is completely uncalled for. Please donāt do this again.
Thereās restraint and then thereās Shida. Different class. 
Nice one Shida
You are correct about the hostility. I was very frustrated. Iām a UX designer (18 years, award winning) working on applications so my tolerance can be quite low. But seriously, it wasnāt that hostile, Iāve heard much worse. This has been in Dynalist for quite a while and it is very frustrating, which tells me there is no hurry to address it. While you re-iterated what I discussed, you didnāt address the problem, except for my suggestion (make it an option). You did feel the need to discuss my tone, but not a solution. While Dynalist is free, that is also part of the marketing plan, which makes sense.
Of course, the internet is full of dark and scary places. We only strive to keep our discussion forums civil and free of hostility. Think about it this way: by being hostile, you donāt achieve anything here other than venting your frustration. We donāt intentionally want to ruin your day by not fixing this issue, but in return we ask for your respect to not intentionally direct your anger at us.
Maybe I missed it but has it been reported by another user? I personally havenāt ran in to this (admittedly I work on my desktop way more often than use my phone).
I think it may have coincided with iOS 13ās new selection manipulation mechanism that weāre only aware of it now. Previously there were handles you would drag with, which I believe did not trigger the swiping action.
I did address the problem:
An alternative Iād propose is to disable swipe actions when thereās a cursor focus. I think this is a good solution because when a user intend to swipe and complete/delete, they will need to click on the confirmation, which de-focuses and hides the keyboard. So given a de-focus happens regardless, I think itād be a better experience if swiping only works when there is no focus and the keyboard is hidden.
Actually, you missed the point.
Whatās the point that I missed?
Hi Rick,
Fellow user here (paying user). Welcome to our community, and it IS a community. This forum is great for itās open, friendly, discourse and for users helping each other. Weāre very fortunate in having the active participation of the devs and, beyond that, their active listening and passion to improve the product.
This is your first post and you chose to use it make an unpleasant attack on the Developers for something that was frustrating you. You then compounded this by, explaining, rather than apologizing, for your tone. Can I suggest that, if youāre new to a community, you take the time to gauge the way it works before posting? Whatās acceptable and normal in one community may not be so in another. If it helps, here are the forum guidelines. If you find it difficult to present your frustrations in a civil way then maybe a closed channel would be more suitable for you. Feedback can be give here .
Is Dynalist perfect? Absolutely not. Do users get frustrated? Of course. However, more than any other software product or service Iām currently using, or have used in the past, the team care about getting it right and are committed to doing so.
I hope you will persevere with Dynalist and find it as indispensable as I do. Perhaps, you will even post again and give us all the benefit of some of that āaward winningā experience. 
Take care. Be nice.