Weasel Words

You're probably here because Craig Scott (me) has sent you a link - which probably means you're unhappy with the recent Markdown changes in iThoughts v4.

If you can spare 5 minutes, I will attempt to share my rationale for the changes below.

I guess the first thing to point out is that downgrading is not possible. This is not the decision of an arrogant developer - it's a fact of life on the AppStore (Apple do not allow downgrades.) There is also no way I can send you a link to the previous version (Apple don't allow any app to be distributed outside the AppStore.) If you purchased the app recently then you might be able to get a refund - but that's at Apple's discretion (I can't issue refunds - Apple don't let me.)

So no safety net then! I knew this when I started out with the changes. I knew that some people would be unhappy and yet I still pushed ahead. Not that it helps you, but I spent a long time making this decision. That's because I believe this change is required in order to push the app forward over the next few years.

Why make the change?

The previous 'text engine' uses the built in Apple system (NSAttributedString) for managing rich text. This stores everything in one big lump (text, font, color, images, paragraph styles etc.) This has worked well for a couple of years - but it's begining to creak at the seams.

• People are attempting to store many more images in notes. Saving images alongside the text and fonts in one big blob is becoming unwieldy. File sizes are increasing, load times are slowing and some maps are even rendered unreadable due to other limits in iOS and OSX.
• People are asking to store more document types (PDF, DOCX, XLS etc) inside their maps. The Apple system only really supports embedded images.
• People are attempting to save/manage many more hyperlinks in their maps. Link management using the Apple engine is not good.
• People are making much greater use of the Style feature in iThoughts. Having the formatting (font, color etc) and the content (text) all lumped together makes it difficult to style the text reliably and efficiently. This slows the app down as it attempts to determine which style fonts/colors to apply to which bits of text and when.
• It is proprietary. Nothing outside Apple can decode it. This makes it unsuitable for 'cross platform' sharing of information (Android, Windows etc.) It also makes it a 'deprecation risk'. If Apple choose to change the format or stop supporting it then your data is locked away in a format that can no longer be read.

Why Markdown?

Clearly I needed to find a replacement 'text engine'. One that separates the styling, text and images. One with great hyperlink support that can handle any type of embedded document. The best solution would probably be HTML - but who wants to write raw HTML? That's where Markdown comes in. It was designed with this in mind - enabling 'normal people' to generate HTML type output by writing in plain(ish) text. Markdown is also just plain text - so it will never be 'deprecated' and it can be read on any platform. It is also blisteringly fast to load, save and process. Perfect?

The downsides (of Markdown)

• Markdown can appear a little 'techie' (with the various ** and _ punctuation characters strewn throughout the text.)
• Markdown doesn't enable you to set specific fonts or colors (it keeps the text and styling separate.)
• Markdown doesn't like whitespace, so attempting to line things up using space characters doesn't tend to work.

How can I justify such a far reaching change?

This is tricky. I hope the above has convinced you that change was necessary and that my choice was sensible. But that doesn't help those people who have lost out. In situations like this I need to go with the majority and in my estimation:

• Most people don't do any formatting - they simply enter text into a map and go with whatever Styling is set as default. They will not notice any change.
• Some people do simple formatting - bold, italic, underline etc. They will notice a slight change (Markdown punctuation characters appearing randomly in their text.) This is a one off inconvenience as they get used to the new system.
• Some people carefully craft their text formatting. These people stand to lose (and gain) most. For some the loss of tight control over font/color will be a show stopper. For those who wanted better support for bulleted lists, images, links, embedded documents then this change will be more welcome.

Why not support both engines and let me decide?

I won't lie - this would be technically possible. However, text handling is such a fundamental part of the app that supporting both schemes would effectively mean 2 apps within one - each with a different user interface, set of features and file format. This would be confusing for users and onerous to develop/maintain. Sounds like I'm being lazy? Not really. If the app becomes onerous to develop/maintain then the net result is more bugs and a slower pace of innovation - which benefits nobody.

Doesn't help much if you're one of those people who have lost out. All I can say is sorry and urge you to experiment with Markdown a little - you can get some cool effects! I do plan to keep improving this whole thing so if you have some specific requests then I may be able to 'extend' Markdown a little or find some other approach.

Some links that may be useful:

• Markdown Howto
• Markdown spec
• Markdown 'playground'

PS: This whole web page is written in Markdown then converted to HTML.