Lessons learnt whilst writing a development environment for iOS
The past six months I have been working on a Lisp editor for iOS as a side project (Lisping). It has been great fun, and building IDEs for touch screen's is a project I believe in. Portability, ease of use, and low cost will guarantee a tablet's place (whether iOS, Android or windows based) as my travelling companion for many years to come, so being unable to code on a tablet is unthinkable for me.
Unfortunately the current generation of source code editors are slow and inefficient for coding. Lisping is my take on the solution, but it is a large market and I want to see a wider range of higher quality products. I'm not finished with Lisping, but I would prefer to writing projects on an iPad, not writing an iPad IDE on my desktop, so with a inflated opinion of my own wisdom I am sharing the biggest lessons I have learnt whilst building developer tools for iOS.
Don't fight the cloud
I learnt this one the hard way. I like to feel that my iPad is computer, and that it should be capable of everything a computer is capable of including onboard execution of an interpreted language. Technically speaking this is true, but Apple's terms of service have shackled the device for developers so much that it is unrealistic to build a good development environment that is also capable of executing code on iOS.
As an example, in the first version of Lisping I included an embedded Scheme editor rather than executing code offboard. This seemed a faster, more convenient approach than cloud execution, and in terms of execution speed and usability it is. However, to quote Apple Apps that download code in any way or form will be rejected, so I had to disable the code to import a file from an email or dropbox. Execution is immediate, but as a result the user has to copy/paste code from an email to import it, which overall has harmed the product. Needless to say I'm not repeating this mistake with my current series of updates to include Clojure, where all execution will be offboard. Most likely I will move Scheme execution offboard in the future as well.
It is frustrating to make as fundamental a design choice as this solely to circumvent cretinous review guidelines, but if you want to build developer tools rather than complain about Apple policies, you need to accept very early on that the cloud will be part of your product.
In the case of iOS IDEs you are lucky because your target market is composed of grownups (in the coding sense of the word anyhow). They know the situation as well as you do, and they will be grateful for a good product. Criticism of Apple imposed flaws in its design will be directed at Apple rather than you.
The iPad doesn't have a keyboard
This is the mistake almost every editor makes, whether it is designed for prose or code. The iPad doesn't have a keyboard, it has no up/down/left/right keys, no escape or tab keys, and the standard gestures for moving the cursor and selecting text are lame, so don't try to rewrite Visual Studio, Textmate, XCode or even Vim in iOS with the system supplied textviews and controls. It is a touchscreen platform, build a touchscreen editor.
The phrase "easier said than done" was coined for advice like that. In Lisping I went with the approach of editing the parse tree. It works great for Lisp, a language built around its parse tree, and I am keen to try it for Python, but I doubt it would be appropriate for the iOS C++ IDE I yearn to download (or if necessary write). Whether it is to your taste or not, it's approach is undeniably focussed on the iPad's touchscreen.
Aside from experimentation, writing and rewriting, I don't have any sound advice for exactly how to build the great touchscreen editor, but I can tell you that it will exploit the touchscreen the way that Vim exploits your keyboard.
Keyboard accessory views are a necessary evil and there is no easy way around syntax highlighting
There are two fundamental technical limitations with iOS's UIKit that any aspiring IDE developer must work around. The first is that you can't configure or subclass the system keyboard (why not Apple? seriously, what harm would it do?), and secondly that UITextView has no support for syntax highlighting.
The system keyboard does come with "keyboard accessory views", a thin strip along the top of the keyboard you can use to add extra keys. It is ugly and reduces the editable area, but unless you want your users to get RSI from swapping back and forth between the three keyboard pages, you must provide an accessory view.
Syntax highlighting is the real problem - UITextView will not display an attributed (syntax highlighted) string, and you cannot override its drawing code in a sensible manner. There is a nice workaround, for small snippets of text, a promising but incomplete drop in replacement for UITextView, and the sprawling OmniGroup framework that I couldn't bring myself to link into my code. Sorry, but if you want syntax highlighting, you will have to write your own text editor. It is a painful experience, but console yourself with the fact that Apple's UITextView is lame for editing code anyhow, and this is a chance for you to start from scratch and get it right.
Posted on 14 Jul 2012
Slide to code blog is licensed under a Creative Commons Attribution 3.0 Unported License.
Based on a work at http://slidetocode.com/blog/.