At least you guys are trying your best with what you have, so thatās fine. You donāt really have a choice on Safari, or perhaps other browsers, since they all have to use the same engine on iOS.
I think a floating one is fine, as I donāt have to constantly move back and forth. It should be rigid in the sense that it appears as long as text is selected. Sometimes if you move the mouse away from the body (upon selecting text), itāll disappear.
In the app we have some more control as we can listen for some native events. All that is simply impossible on mobile Safari.
[quote=āErica, post:63, topic:34ā]
The iOS floating toolbar is a workaround because Safari is special like a snowflakeā¦ on Android it has always been fixed. [/quote]
Coming from an Apple fanboy perspective 
, Safari is a bit of workā¦but thatās true of the whole OS and platform. These are some reasons to think about the process of thinking about hiring an iOS guy/girl for the team. You know your business - but hopefully iOS/Mac OS users make up a good paying percentage of the total user population.
I know I have no plans to move to Android and might consider Windows 10 (Mobile) if Microsoft could ever get their act together.
I donāt think thatās too hard, itās just a matter of having the money to compete with larger companies. As a bootstrapped startup that isnāt making enough money to pay for the full-time work that Shida and Erica put in, it has a ways to go before they invest time in developing native apps for iOS or hire an engineer.
I agree with you here. The ROI would be pretty good.
Since what Erica said directly above is that itās impossible on Safari, but not on the native app, I guess thatās a good compromise for now (once most of the bugs are fixed).
Yes, I love both Ulysses and iA Writing regarding their typographic decisions. I am really annoyed by āchanging mode.ā It gives me a pause and I find it distracting. (The very same reason I donāt like writing descriptions in Trello) I read through the comments, and understand Erica doesnāt like the idea of **bold text** because it looks like <div>text</div>, but like the Latex formatting and all these advanced features Dynalist offer, you need to focus on the makers, what makers really want. (writers, programmers, designers, all who make things professionally)
I am okay with WYSIWYG style, but I just think switching mode makes users unproductive.
Iām a big Markdown fan, but regarding Dynalist I have a couple of factors to bear in mindā¦
Iāve tried Typora, but I donāt think it fells under the traditional WYSIWYG category. When you press Ctrl+B, it basically just inserts asterisks for you, rather than applying the format directly. With a WYSIWIG editor like Google Docs, youāll almost never seen the ācodeā thatās responsible for the formatting. You just see it.
I believe @Matt_Groth was talking about a way to switch between WYSIWYG mode and Markdown mode, which is kind of different from what Typora does.
Hi Erica, Just saw this reply.
I was actually referring to the way they treat mathematical equations - the small popup/preview with live update of the MathJax (or Katex) rendering.
WYSIWYG pls
Iām curious, is there any timeline for this feature now? Maybe releasing public due-dates for features is a bit much for you guys, but is it being worked on or are other things higher-priority right now?
We donāt have a public due-date for this, and itās not being worked on at the moment, unfortunately. Our time is spent on improving mobile and capturing right now. Stay tuned for this in the future! 
Hi,
I would also to express my remarks
I really would like to have something similar to Bear (mac) or at least like typora.
If You will do it that will be awesome (from my perspective )
Currently for me itās a bit annoying if I select node and I see something like /some text instead /** some text ** -> of course w/o /
I donāt like that text is changing once I edit the node I really prefer that * stars or __ will be constantly visible but with font color light grey. Thatās tiny visible.
some text `Rest will remain as it is now.
@Erica, You would like to do it similar to what I describe ?
Our current plan is to not use Markdown at all and use all WYSIWYG. I think the pattern you described is pretty new (Bear & Typora) but not traditional WYSIWYG. WYSIWYG is more like Word or Google Docs.
I hope that makes sense!
Bummed to hear this! Markdown is great when implemented Ulysses style! One of my main drivers for switching from workflowy to dynalist was the markdown support.
The best software has some degree of learning curve!
Mediocre software just makes an icon for everything (Iām looking at you, MS Word and Google.)
For what itās worth, I love the appās current support for Markdown. Itās one of the features that drew me to the product.
Switching between rendered mode and plain text is annoying. Any updates?
Sorry, no updates yet as this is a huge undertaking 
I like this idea, as long as markdown formatting still remains as it is.
Say, toggle to use visual or markdown formatting.
@Luke @Craig_Oliver What is good about Markdown? Keeping the option of markdown for those who want it would probably be good, but, I lack an understanding of why someone might want it.
@Erica, Iām not sure I understand.
Does āOne way formatting via markdown, ā¦ā imply implementing the same formatting mechanics as seen in Dropbox Paper and Quip in such a way that the markdown syntax is only used as āshortcutsā to implement the style/commands under the hood?
If so, then I wouldnāt personally be opposed to that as long as performance isnāt compromised for larger and heavily nested lists. However, the only condition would be such that the WYSIWYG mode remains still somewhat āĆ la Markdownā in the sense of only very select formatting options are available and apply simple rules (i.e. limited).
For example, font style and size selection are not a rich text feature (you canāt mix and match Arial and Helvetica with 12 and 16 pt font within the same file - these are the sources of pure evil within gDocs, mWord, and any more complicated document processors).
Also, currently the headings are implemented somewhat WYSIWYG mode, assuming because of potential tag conflicts, is there any use for them other than stylistically (bold and larger)? Like, are they used to anchor which items to appear in an outline in the side pane for example (Iām pretty sure thatās not the case right now, but that would be very cool).