The new version 5 of SubEthaEdit, the Apple Design Award winning text editor for macOS, is now available free of charge in the App Store and as direct download. The complete source code with history going back 15 years is also available under the MIT License.
This release fills me with great pride and joy. SubEthaEdit always has a special place in my heart. It is where my journey as a developer in the Apple ecosystem started. I owe it the position I am in today. This connection is why I'm taking the time to maintain it again and try to lead it towards a long lasting future. Therefore I think it is worthwhile looking at how everything came together.
It all started with the initial set of peers at our university at the end of 2002: Ulrich Bauer, Martin Ott, Martin Pittenauer and me. As university students we wanted to build something real. So we searched for a project to grow into a fully grown app. Motivated by the Apple Design Awards competition, we challenged ourselves with a fitting deadline to do submit an entry.
At that point in time there weren't many good native text editors on the platform, so doing a general purpose text editor was always an aspiration of mine. I had recently switched from my old Acorn RiscPC over to the Mac, and was really missing my then beloved StrongEd (fair warning that website is quite a sight, as sadly most of the RiscOS ecosystem is and almost always was in terms of style).
I was playing around with the existing text editors, but BBEdit really wasn't for me (and at this time very Carbon, and as such looked dated and did not integrate too smoothly into the new OS X). Personally I went with MacroMedia's Dreamweaver as the least bad option for my web development work.
Luckily one of us dug up an old Xerox Parc Paper that showed how latency free live collaboration can be done. At that time it fit perfectly with the newly released Bonjour technology to allow for networking without configuration between Macs. That was super exciting and we quickly got to a point where we could see this technology as viable and so we went on to build our application.
It was with great joy that we submitted our freely available work, then named Hydra, to the awards, and with even more joy that we won in the student category we applied in.
At that time we didn't charge any money for it. Only at the end of our university careers, the three remaining of us started out our luck as TheCodingMonkeys to live the dream of a Mac indie studio. We all started out doing this part time, the transition from free software to paid shareware did not support more than one person at that time. And while it was fantastic to see SubEthaEdit being used in conferences all over the world, the financial aspects weren't looking great for us.
Marketing wise we shoehorned ourselves into the collaborative aspects, and failed to communicate the fact that SubEthaEdit was a great general purpose text editor of its own right. Worse, the commercial start of SubEthaEdit was overshadowed by the then not yet released TextMate. This was mainly based on David Heinemeier Hansson's well deserved hype of the initial ruby on rails videos featuring it. So we lost the race for the second most popular text editor on the platform (BBEdit still got the first place because of Mac users loyalty and steady development), and therefore the commercial success too.
SubEthaEdit icon history. Unused initial draft, Hydra, SubEthaEdit 2.x, 3.x-4.x, now.
It was at this point that we began struggling a little. While we had enough success to sustain one person, we were not on track to support more than that. Developing and maintaining SubEthaEdit easily consumed most of our time though. It is by that fact, that we all had still day jobs. And while we dabbled in other product ideas (one of the bigger ones a more creative writing based collaboration tool codenamed 'Fenchurch') we didn't get to produce any.
Fenchurch prototype mockup.
Instead we got another lucky break. The great folks at Panic were planning their then secret Coda, and were looking for something they could base their editing engine on. And that influx of financial support was what enabled us to become a real working company. We are forever grateful to Panic for this, as they essentially gave us this opportunity. This was the point in time when Martin Ott, our third co-founder left us, and we started venturing to build Carcassonne for iOS. Another project of mine that was very close to my heart. I have been a board game geek from my early teens on, and joining this with my professional world was just a fantastic opportunity. It also gave me the opportunity to do real production work with Erlang.
The success of Carcassonne also had a somewhat unfortunate side effect for us: With still no real viable long term business story for SubEthaEdit it moved more and more on the back burner. We still maintained it and brought it up to the App Store eventually, but sadly it couldn't prove its financial viability. A big shout out goes to Lisa Brodner and Michael Ehrmann, who took the bulk of the work to create the 4.x releases.
And while it served us well, even for our own development – SubEthaEdit was our main editor to develop it, in the times of Project Builder with external editor support – it did not plant roots in any specific community. And with Xcode slowly getting better, moving to the single window layout only and providing all the Project aware metadata we couldn't, even our own top use case went away. However, we are still very fond of it and use it for all things scripting and of course text creation and collaboration.
Fast forwarding to 4 years ago, I left TheCodingMonkeys to try my luck in the US working for UIKit at Apple while Martin Pittenauer took over the company. It was with both surprise and delight that I experienced how SubEthaEdit still resonated with many of my colleagues there. Even with the success of Carcassonne, SubEthaEdit seemed to have been the product that was part of many of their pasts.
So now that I'm back to a more independent life I feel that SubEthaEdit deserves a future. Although I'm not rejoining TheCodingMonkeys, we are on good terms and we were able to make an arrangement that hopefully proves beneficial to everyone. From today on SubEthaEdit will be free and open source.
What was the focus for this release?
- Bring the code base into a state that builds fine and fully supports macOS Mojave
- Generate a nice repository with as much history as possible, both for reference and educational purposes (Fun fact: SubEthaEdit started out in Subversion, had a long time in Mercurial and very much later moved on to git)
- Update and or remove dependent libraries, support current Mojave features
- Get into shape for dual App Store and Website download releases, so contributions can have a quick turnaround time
- Remove the dependency on the Website for system integration, e.g. the see tool and authorization scripts are now part of the distribution
What are my hopes for the future?
- Attract contributors to ensure a long term thriving ecosystem
- The free availability both in and out of the App Store should reduce the barrier to entry to the collaborative use cases in education, pair programming, etc, leading to good bug reports and use cases that are worth investing some future development in
- Support for more languages, modes and contributions thereof
- Longevity of SubEthaEdit as a product
So I hope you all share and enjoy this release, file bug reports, enhancement requests and contribute the scripts, modes and styles you make.
Ken Kocienda: "Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs" ⚓
I had the great fortune to work alongside Ken for a short while, and he is one of the few people who really have a tight grasp on what Apple and its products are all about. I'm not through the book yet, but even just after the first chapter it is a clear recommendation if you want some insights on how product decisions came to fruition back then.
Ken is a fantastic inspiring public speaker and as such I'm very happy he narrated the audible version himself.
There is a lot of non-commercial Ken based content out there as well, all worth your time and worth pointing you towards it.
- 2011: "Writing Easy-To-Change Code: Your Second-Most Important Goal As A Developer"
- 2012: "Basics+Habits: Building Your Software Projects To Last"
- 2014: "A Strategy for Great Work"
I immediatly put it for a spin, and it is really fantastic. I have been using the desktop version for a while to produce nice app icons for my own prototype projects. So of course I wanted to try if this works nicely on the iPad as well. My test subjects were the following 3 icons:
In case you were wondering, these are already the result as nice SVG export. It took me just few hours to produce them, all on iPad and half of it on a train ride. I intentionally put in a more nostalgic icon with more details to have more variance.
I created this hopefully helpful artboard (which has the examples as turned off layers in them) for your free use: Monkeydom iOS App Icon Template v1.afdesign
Note the v1 as I probably haven't used all the features to the max yet, and I might update that here. However, with the symbol feature, pixel preview, export persona, layer effects, easy grouping and masking, great bezier tools, it is an powerful template for me already.
One sore spot is, that the "global color" feature is missing from the iPad version currently, which I tend to utilize a lot to be able to adjust my color schemes after the fact.
tl;dr: I like vector graphics, I hate most vector packages, I've used an Acorn for far too long and Affinity makes me very happy.
Vector graphics and system support thereof have been dear to my heart since the beginning of my personal computing time. I started out using CorelDraw on Windows 3.1 in the early nineties, which introduced me to the subject, but otherwise was not a great experience.
After my short Windows/PC exposure I took the rather unusual turn to the Acorn Archimedes and Acorn RiscPC. RiscOS, its operating system, has system wide vector graphics support. This includes a data format, as well as anti aliased vector fonts. It was put to great use in the desktop publishing and word processing products on that platform, which were way ahead of the curve for a very long time.
What blew me away though, was Computer Concepts's Vector graphics package, ArtWorks. Their raw speed, live-antialiasing, and simple direct manipulation interface (as far as I know this is where the now standard direct line for gradients came from). Sadly even before the demise of Acorn, this package was discontinued (interestingly over the lack of a great C++ compiler). It went on to be PC only as Xara, then was bought by Corel to become CorelXara and later Xara again. The technology is still great, but it was mangled through so much marketing hotchpotch (just look at the current website) and windows interface paradigms, that it's quite a mess.
So I stayed with my little RiscPC for as long as I could stand it (2000), and eventually I moved to the Mac with the first white iBook. And while MacOS X was slow as a dog at that point, the deep integration of fully anti aliased Fonts and Quartz2D/PDF were so promising to me (and I was doing web development, so a unix on your laptop didn't hurt either) that I made the jump. Although in the early 10.1 times I did use the iBook more as a server for my web development driven by my RiscPC.
And while there was a great charting tool with OmniGraffle, somehow, nobody really took up the bait to provide a real alternative to the IMHO still horrible user experience of Adobe Illustrator. Even the more bearable tools like Freehand did get killed over time.
For a while I used Lineform and tried to be content with it, sadly Freeverse did not really maintain it and it died. Sometimes there were other short term contestants. Most of the apps never really got anywhere, or had humongous bugs and speed problems with big documents, etc. The last one I could slightly stand before Affinity Designer was Sketch. However, I did have my fair share of fighting with the interface and bugs there too.
This is why it makes me unbelievably happy, that Serif plays the long game, and that it created an engine that doesn't make me afraid of working with my apps, or wait to a response. And while I'm not in print or professional asset creation, these suite of apps (and I'm looking forward to Publisher), is what drove my private creativity with computers, and helped me generate semi-professional to professional looking things.
With the fantastic displays and devices, and these apps, I'm having a blast doing that again. This for me, is part of the joy of using computers, when they just are a great tool to help me create what I want to create, and couldn't without them.
During my life as a software engineer there only have been a few occasions where the design and principles of a language struck me as inherently beautiful and consequently inspired me to work with them.
- Lua for its simplicity, modularity and clear design goals that are followed through.
- Objective‑C / Cocoa for its very simple object oriented extension to C, with a great tradeoff of being a consistent and clear while still having optimal inter-op to the existing world of C and C++. And of course because of Cocoa and its design principles, purpose and empowerment.
- Erlang/OTP for being the most powerful implementation of the actor model, its concept of lightweight processes, and its ease to build distributed system. And due to being purely functional, the eye opening benefit of always having all the state necessary to analyze and fix any crash.
- Ruby (on Rails) for being an going all in, everything is an object, dynamic, object oriented scripting language. Rails for adding fantastic model view controller abstractions on top of it, and for such great use of the dynamism of the language. Amongst other parts, I'm still in awe of Builder for the XML view part.
None of those languages / language framework combos are perfect. But they all have one thing in common: A well defined set of carefully chosen design goals that are tailored towards certain usage scenarios. And those goals give guidance when using it, move you towards consistency and greatness when writing in and for them.
So now contrast that to Swift. First of all: Which question did it desire to answer? Think about it. There is no one clean answer. It just wanted to be better, more modern, the future – the one language to rule them all. A first red flag for anyone who ever tried to do a 2.0 rewrite of anything. From the outset, it wanted to be a silver bullet:
- It should scale from App/UI language down to system language.
- It should inter-op with existing Foundation and Cocoa, but still bring its own wide reaching standard library, adding a lot of duplication.
- It is functional, object-oriented and protocol oriented all at the same time.
- It wants to be strongly typed, but at the same time so convenient in type inference, that it falls over its own feet while trying to grasp simple expressions, and they become too complex to manage. By design.
- It is compiled and static, but emphasized the REPL and playground face that makes it want to look like a great scripting solution. Which it isn't.
- It seems to have been driven by the needs of the compiler and the gaps that needed to be filled for the static analyzer. Those seem to have been super-charged instead of catering to app developer's actual needs: efficient, hassle free, productive (iOS) App development.
- It is meant to offer progressive disclosure and be simple, to be used in playgrounds and learning. At the same time learning and reading through the Swift book and standard library is more akin to mastering C++. It is quite unforgiving, harsh, and complex.
On top of that it chose to be opinionated about features of Objective‑C, that many long time developers consider virtues, not problems:
- Adding compile time static dispatch, and making dynamic dispatch and message passing a second class citizen and introspection a non-feature.
- Define the convenience and elegance of nil-message passing only as a source of problems.
- Classify the implicit optionality of objects purely as a source of bugs.
At the same time it failed to attack, solve and support some of the most prominent current and future computing problems, which in my book all would be more important than most of the areas it tries to be good in:
- overall API interaction complexity
- actual App and UI development
- developer productivity
It keeps defering the big wins to the future while it only offered a very labour intensive upgrade path. Without a steady revenue stream, many apps that would have just compiled fine if done in Objective‑C, either can't take advantage of new features of the devices easily, or had to be taken out of the App Store alltogether, because upgrading would be to costly. If you are working in the indie dev-scene, you probably know one of those stories as well. And while this is supposed to be over now, this damage has been done and is real.
On top of all of this, there is that great tension with the existing Apple framework ecosystem. While Apple did a great job on exposing Cocoa/Foundation as graspable into Swift as they could, there is still great tension in the way Swift wants to see the world, and the design paradigms that created the existing frameworks. That tension is not resolved yet, and since it is a design conflict, essentially can't be resolved. Just mitigated. From old foundational design patterns of Cocoa, like delegation, data sources, flat class hierarchies, over to the way the collection classes work, and how forgiving the API in general should be.
If you work in that world you are constantly torn between doing things the Swift/standard-library way, or the Cocoa way and bridging in-between. To make matters worse there are a lot of concepts that don't even have a good equivalent. This, for me at least, generates an almost unbearable mental load. It leads to writers block and/or running around in cognitive circles trying to answer questions on how to best express the problem, or make Swift be happy with my code.
To add insult to injury, all this attention is taken away from solving and focussing on the actual problem: writing a great app or framework that is a joy to use. Whereas Objective‑C/Cocoa always strived for maximum developer productivity and purpose.
Yes, Swift code might end up being more correct in the end. It also might alert you to edge cases early on. However, the flip side is it inhibits your creativity while writing. When starting out to program, the way I enjoy working, I don't yet know how the API is best expressed. So I try out different ways to express it until I find a sweet spot. Then I go back and unify accordingly.
Swift actively distracts me in that endeavor by making me answer questions I really don't want to answer right now. Yes, stuff might be less correct in the meantime, but heck that is what I want during the design phase. Find my concept, sweet spot, iterate, pivot quickly.
So my opposition to Swift is very deep – on a fundamental design level. I see it as the devil on your shoulder, always fighting for your attention away from your problem domain, back to how everything is completely correct, or more swifty. And at the same time it is very unforgiving towards bigger change - ever tried to switch code from objects back to structs, or vice versa?
Objective‑C had and has nice progressive disclosure there, you can start out to your prototyping and then slowly get help from the tools to refine it when you found your sweet spot. Turn on more warnings, run the static analyzer, optimize hot spots towards C or C++.
It is 4 years in now. It is not too late to pivot and take everything that has been learned and form that into the developer experience in an evolution of Objective‑C that really caters to the goals and ideas of the platform. In my opinion, a lot of the "lofty goals" haven't been achieved, and as discussed, should even be non-goals. Just imagine a world where Objective‑C would have gotten the same amount of drive and attention Swift got from Apple? It is not a big leap to see that everyone would be better off right now. Swift just ended up being a jack of all trades, master of none. (I defer my own ideas for a Objective‑C 3.0 evolution to a potential later blog post, as this is nuanced as well.)
I would love to see a pivot like that, but to be honest, it does seem quite unlikely at this point. That's not to say that an ecosystem with swift at the heart will not produce something one can be productive and content with. However, for me at least, it definitely does not fall into the delightful category of the language/framework combo's I mentioned at the beginning. This, to me, is as a sad and unnecessary regression.
So given my clear opposition to Swift, where does my personal journey go now? Luckily there are a few promising avenues to explore:
- Rust – a strongly typed language with a clear direction and purpose. I don't like the strong type system world very much in general, but for lower level hard problems it clearly serves a purpose. I both want to get a clear grasp of those benefits, and wander more in the lower level world.
- Elixir/Phoenix – this looks like the perfect mind meld of rails and erlang to me. Hope it is as good as it sounds.
- I won't leave the Apple eco-system completely. Even with all their flaws, Macs and iOS devices are still and will be best of breed in many ways. However, I will have a strict no-Swift policy on any of my own future software projects and hope that this is still feasible.
In essence, the current free 2 play model equals a slot machine in a bar. It preys on the poor people who get hooked, tries to hook them as quickly as it can, and in pure business logic, tries to get as much out of them as possible.
Where insult comes to injury is if you look at the App Store revenue numbers. No matter when you look at the top grossing lists, the first 3-10 titles are free 2 play titles. So most of our bars have turned into casinos by now already, trend rising. That is very shortsighted, bad for customers, bad for Apple and bad for the industry.
And for me it just boils down to: I don't want to build slot machines.