- Backblaze: Get a free 15 day trial!
- Pantheon: Get ready for Gutenberg. Sign up for a FREE account today.
Max Seelemann is one of the founders and developers of Ulysses, one of my favorite Mac and iOS apps. I am excited to talk to him today because it is a different perspective on the software developing process. Ulysses is software I use nearly every day to write up show notes, scripts, articles, and more. I was keen to hear how they built it and the decisions they made throughout the 15 years(!) of development.
Question of the week: What app do you use it for writing? Let me know on Twitter @jcasabona or e-mail me at firstname.lastname@example.org
Hey everybody. Welcome to episode 97 of How I Built It. Today I’m talking
to Max Seeleman. From Ulysses. Ulysses is one of my favorite Mac and iOS
apps, and I am excited to talk to him today because it is a different
perspective on the software developing process, something different than
what we usually do. Ulysses is software I use nearly every day to write up
show notes, scripts, articles, and more. I was keen to hear how they built
it over Ulysses.
So sit back and enjoy the show, we recorded this around the time of WWDC. I
know Ulysses has done a lot of really cool stuff since then to integrate
with Mac OS and iOS 12. Just cool to hear about their process. But first, I
want to tell you “that this episode is brought to you by Pantheon and
Backblaze. You’ll hear about Pantheon later on in the show, for now, let me
tell you about Backblaze.
This episode is brought to you by Backblaze. As someone who works online
all the time from home, I know how important offsite backups are. That’s
why I use Backblaze. For just $5 a month you can fully back up your Mac or
PC no matter how much space you need. It’s all unlimited. They make it
super easy to do it, too. Just install their app on your computer, and they
take care of the rest. That’s why they’ve already backed up over 600
petabytes of data. You’ll learn more about them later in this episode, but
do yourself a favor, and start the backup process now for just $5 a month.
Go to Backblaze.com/buildsomething.
: Hey everybody. Welcome to another episode of How I Built It, the podcast
that asks, “How did you build that?” Today, my guest is Max Seeleman. We
just went over this before. He is the co-founder and lead developer of one
of my favorite iOS apps, Ulysses. Max, thanks for joining me today.
: Yeah, absolutely.
For those listening who don’t know who you are, or what Ulysses is, why
don’t you give us a little rundown. Who are you, what do you do, what is
I’m the co-founder and lead developer of Ulysses, and it’s a project we’ve
started 15 years ago already, and it’s a writing app. It’s for creative
writing, and it helps you focus on your text, it helps you to organize your
text and makes it very easy to get it out wherever you want it. Be it on a
blog, or e-mail, PDF, Word files. Doesn’t matter. And that’s it. The idea
is, it’s your one-stop writing solution for everything you write.
Yeah. I can attest to that, since using Ulysses I think I’ve opened up Word
once or twice? It’s my favorite thing. It’s got great markdown support and
things like that too. I did not realize that you were 15 years old. Did you
get your start on the Mac, or was it–?
Yes. We have two generations of Ulysses, but the first generation launched
July 1st 15 years ago.
Yes. A very long time. It was 10.1 times.
Wow, that’s fantastic. Let’s see, 15 years ago, that’s around 2003. If I’m
doing my math correctly.
That’s great, that gives me really good context for the rest of these
questions. Because the next one is, how did you come up with the idea for
The way it all came to be was, my partner Marcus, whom I didn’t know at the
time he wanted to write a book or a novel. And he was looking for tools he
could do it with, and to quote him, he only found apps for developers and
secretaries. Where apps for developers would be BBEdit and secretaries
would be Word.
And he didn’t like any of those, so he came up with an idea for a writing
app and then went on a mailing list to find someone who could do it. And I
was in school at that time, but I said, “I can do it very easy.” And it
took quite a while to get it done, but that’s how we started, and we’ve
never finished or stopped since then.
Wow, that’s fantastic. Around 2003, even fast forward to when I discovered
Ulysses which is now less than a year ago. I listen to AppStories and the
folks over at Relay FM who is where I found out about Ulysses from. In my
opinion, there’s not a great writing app like Ulysses which includes
markdown and export to PDF. I used Editorially a few years ago and was a
big fan of that, but they closed their doors about a year later. I imagine
back then the landscape was even worse.
It was different, it wasn’t necessarily worse. There were fewer users, but
those that were there were very much into buying apps. It was a different
time, and I would say people would be spending more on apps, and now that
more common users have joined all the platforms, and especially since
iPhone became a mass market, I would say it’s changed a bit. But it was
okay back then, and there are a lot of developers that have been around for
very long. For example, The Omni Group, they got started in the ’90s.
I mean, there was no Apple back in the ’90s. Same was for us, in 2003 Apple
was still really doomed. But it was okay, and I also didn’t have to make a
living of it. I was still in high school when we started, so it was a nice
extra income and I could afford stuff that other students couldn’t. Like,
getting a PowerBook G4 was a nice thing I did in the second month or so
after we had the initial sale. Then over the years I’ve kept to finance my
university with it and was able to do just that.
I need to say university in Germany is pretty inexpensive compared to the
US, and it’s all publicly funded. Or you need to come up with and cover for
your housing and your food, and that was doable. I was able to go to WWDC
every year, so that’s what it did for like a decade, and only then did we
decide to take it full time. It’s been always a hobby project for all the
time, and only then we decided to take it full time.
Wow. That’s also incredibly interesting. I do want to back up before we get
to that next point. It was 2003 when you made this app, and like you said,
Apple– they weren’t the Apple of today.
How was the decision process? How did that go when you said, “We’re going
to develop this app for the Mac and not for Windows”?
We both had Macs, and we met on a Mac mailing list.
A Mac Pro, Pro User mailing list. And that’s it. That’s how it came to
decide we were going to do it with Mac. Because we only had Macs, and we
love the Mac, and that’s probably still the main reason why we haven’t
expanded to Windows or something else yet. Because that’s what we use,
that’s what we love, that’s what we know, and I’m not sure if I want to go
to other platforms because I’m not there.
That makes sense, especially when you’re building an app that people are
probably going to use every day. You want to understand the platform that
you are on, and you don’t just want to shove something out the door that’s
half of what it is on the original platform.
Cool. What was the initial feature set like? Did you talk to your
co-founder and say, “We need these things”? Did you do other research? I
know when I was in high school I was like, “I’ll just build this and see
me, but he is 15 years older. When we started, he was as old as I am now.
That’s also an interesting thought, but still. He had come up with a
complete concept. He was already done. He was cavalier in teaching me about
it, like, “Can I make interface suggestions?”.
And then I would say, “Yeah. I’ve scribbled something, what do you think?”
And he’s like, “Take a look at this completely finished interface mockup,
and let’s build an exact copy of that.” He was already done with the
concept. Then we didn’t talk to many people until we launched because it
was already at that time extremely opinionated. Already.
In 2003, that’s the same year where John Gruber invented Markdown the exact
same year when we launched, and we launched in 2003 a plain text app. It
was a parallel development, and it was a trend that was going on in the
internet to switch to plain text writing with markup.
And that’s when John Gruber came up with Markdown in 2003, and the original
Ulysses wasn’t using Markdown because there was no Markdown back then,
because it just came out. It used a different kind, its own markup, but it
was plain text. That was already quite a revolution because we were getting
shitloads of e-mail telling us, “Go rich text. Rich text is the way to go.”
Yeah. Wow. I’m glad that you mention that too, because for people online
today, Markdown has existed just as long as anything else.
Yeah, right. Exactly.
So that’s cool. Ulysses launched as a plain text editor, and you added
Markdown and a bunch of other features later. Let’s jump and let’s fast
forward a little bit to your decision to go to iOS. Was that a pretty easy
decision? Were you like, “The iPhone is out now. People are going to want
to write on that.” Or–?
When the iPhone came out our original take was, “Nobody will write on a
phone.” That was 2007 or something, that’s also quite a while ago already.
So we didn’t do much with the iPhone, and also the SDKs weren’t able to
handle all of the stuff. But then what happened was the iPad, and for the
iPad, Marcus said, “We can’t bring Ulysses to the iPad. But I have
organized an idea for a gesture-based UI.”
This idea of sheets, and stacks of sheets which you then can pinch to
spread them out, you spread the stack by pinching it out, and you close it
back by squeezing. Then that became Daedalus, so when the iPad came out, it
still took us a year because we were still doing it part-time in our free
time. But that was what became Daedalus, our writing app for iPad, which
the first version was not even doing Markdown.
It was just plain text because even then it wasn’t very feasible to do
Markdown or any highlighting or formatting, as an app developer, on an
iPad. Then when iOS 7 launched, I forgot the year. Apple introduced new
APIs, that’s when it did a flat design. Then they finally brought over the
APIs we were using on the Mac to iOS, and that was the trigger.
We can now take our code and bring it to iOS, and we don’t need to rewrite
the whole app to make it work on iOS. And that was the point where we said,
“No idea how we are going to get this thing on an iPhone, but let’s bring
it to iPad.” This also took us a year to get the Mac version working on an
iPad, but it turned out good.
And once we were done with the iPad version, interestingly we knew how we
would go to the iPhone. Initially, we had no idea how to go from Mac to
iPhone because the size difference is so huge, so immense. But we were able
to go from Mac to iPad, and once we were there, we were able to go to
Today’s episode is brought to you by Pantheon. WordPress 5.0 and the new
editor Gutenberg are coming. Are you prepared? Do you want to learn about
the changes in advance? Pantheon has gathered resources to help you
prepare, including webinars and tutorials. Pantheon also has made it easy
and free to try Gutenberg with your site before the official launch. Visit
Pantheon.io/Gutenberg. Let them know that How I Built It sent you. Now,
back to the show.
You made this transition from Mac down to iPhone with iOS 7 you got the
APIs that you needed. Today as I use it, I use it primarily on my iPad.
I’ll use it on my Mac as well. Is there feature parity, pretty much,
between the two? Or are there some differences?
There are some minor differences, but nothing major. The platforms are
different, so it has slightly different features here and there. But we
also claim that it’s almost feature parity. There’s only very few things
missing from either side, and we’ve worked, and it took us quite a while
from the original iPad version which launched three and a half years ago,
three years ago? Three years ago. It took us easily two years to get to a
feature parity because the Mac app was so huge already. But we’re there
Gotcha. Awesome. When you first launched, I know a lot of apps are going
subscription-based now. Which is what you guys do. It’s a very reasonable
price, especially if you rely on it every day. Were you always
subscription-based, or was it a one-time fee at some point?
In 2003 nobody would talk about subscriptions.
That’s one thing, and the other is we originally didn’t– it was never a
question. You would make a paid app, and you would at some point make a
paid update. We fail at that. We had a decade of learning about how not to
make paid updates, and we eventually succeeded. But the platform has
changed so much, and the need to go to subscription has only evolved over
time. Then the situation changed., and then we had to do the switch. But
initially, it was not a thought.
Gotcha. And like I said today, there’s a lot of that. I’m a developer, I’m
a web developer, and I can see the reasons why. You’re creating. You don’t
expect somebody to buy one pair of jeans, and then get every new pair of
jeans for free. You have to buy each new pair of jeans.
There’s a lot of issues involved. But it’s the platform, and it’s
ever-evolving. There’s a new OS every year, there’s new devices every year,
and people want to have the newest stuff on the newest phones on day one.
Getting that done means constant improvement, constant development, and
then we’re like, “Half of the year we’re only busy with adapting to the new
OS and newer devices, and there’s no way to realize that without a
subscription with a paid update.” That is that as part of the reason.
Yeah. This is great, so we have a good baseline for the history of Ulysses
and how it works today. Why don’t we get to the title question, which is
how did you build it? We could talk about how you built the first version,
and we could talk about the iOS version, I know that you are the lead
developer. Do you have a team of developers? Just whatever you’re most
comfortable talking about.
Interestingly, the original version is quite similar to today’s version.
Xcode was then still called Project Builder. It’s the same toolchain. It’s
Apple’s toolchain that we used. It’s still Objective-C today, no Swift. The
reason for that is we started out when there was no Swift, and now we have
a huge code base that we can’t port or something.
So we would only add parts of Swift to it, and then the tooling support for
that is not so optimal. I like Objective-C, and there’s a bunch of reasons,
I can see us going to Swift sometime in the future but not now. Our team is
totally into knowing exactly how we need to build things, with Objective-C
and all the tools that we have.
Objective-C is the classic language. It’s not like we’re seeing a
performance hit because you’re not using Swift. At least, as an end user, I
don’t see one. It’s a very snappy app for all the platforms I use it on.
If that were the case we would probably be more inclined to go to Swift,
but that won’t happen any time soon.
Yeah. You mentioned that you do have a team. How do you manage that team?
You said that you have a big code base. I know that managing a big code
base with many developers can be difficult.
Over the years we will often do one big repository where everything is in
there, and then we do pull requests. Everybody does their own features and
makes pull requests, just like when you deal with a team. We are all on
site, so we talk through, we do weekly standups, we used to do sprint
meetings. You could also do that when you’re remote, but we preferred– I
don’t know, I like to work with people in the same room and be able to
punch down directly when something goes wrong. But seriously, just being
able to look at each other’s screen. Just lean over and, “This and that.”
“Yeah, exactly.” Not like, “I need to schedule a call.” And then–
“Let me share my screen,” Or whatever
Yeah. It’s much easier to talk to each other, and then also the benefit is
that it can be a bit annoying when other people are talking, but you can
also overhear a conversation and then chime in when you know something that
the others just forgot to talk about. That makes a few of the discussions
very efficient. That’s good. And then we will use Jira for a backtracker
and sprint planning system, and we have Bitbucket server running for the
code, and Bambu for continuous integration. We’re really into the Atlassian
stack. Those are great tool. They’re not cheap, as soon as you hit the
10-user barrier they are not cheap, but worth it.
This episode is brought to you by Backblaze. Earlier I mentioned the
importance of offsite backups, and how for just $5 a month Backblaze can
get you unlimited space on their servers. You may be wondering, how easy
are restores? Not only can you access backups from their mobile apps, use
their desktop app to initiate restores, and share backup files through
links, but you can even do a restore by mail. You can buy a backup on a
flash key or a hard drive, and they will mail it to you. Send the hard
drive back, and get a full refund. Don’t get caught without a backup. For
just $5 a month you can get unlimited backups with Backblaze. That’s like,
one drink at Starbucks. Visit Backblaze.com/buildsomething to get started
today. That’s Backblaze.com/buildsomething.
Another question I’m interested in because I’m a web developer, it’s pretty
easy to test my medium, relatively speaking. I have browser stack, and I
have a couple of computers that I test on. What’s it like testing your app?
Do you go back and support certain versions of iOS, do you need to do
different testing for iPhone and iPad? What’s that look like?
Yeah. We need to test all the versions. We are supporting 3 Mac OS versions
back to 10.11, which I would love to get rid of but there’s still too many
users on that, so we can’t cut it off. And then we need to test all the
iPhone device sizes, so we have iPhone SE, iPhone 7, 7+, iPhone 10. All the
iPad sizes, iOS 10, iOS 11. Big mixture of devices and for big releases, we
do a beta test where we get so many people that we hope that we cover all
of the devices, and in addition we need to test all the languages.
That’s maybe something you don’t necessarily do for a web app, but we have
ten languages, so we need to test it in Russian, and we need to test in
Chinese, and other stuff. So before that, we do a beta test where a lot of
things get fixed or tested already. But before every single release, even
the point releases, we do something like a final check where we sit down
for an entire day with the development team, and we play through every
single feature. That takes a day. It’s so damn exhausting, and you can’t
You’re completely wasted after 4 hours of breaking your app all the time.
And we have all the devices, all the device sizes, we have all the OSs, and
we play through every single feature on every OS on every device, and in
multiple languages. We test it all out, and we always come out with a long
list of things that have always been broken. That is also quite funny.
Whenever we go over it, we end up with a list of 30, 40, 50 items of things
that– Most of those are small things like, “The alignment has gone broken
here half a year ago, and this text doesn’t sound well. We need to rewrite
But then there are some bugs that have always been there, and we do a final
check to make sure that everything that is very obvious to find has been
ruled out as a bug. We’re not shipping an update where we have bugs in
there that are super easy to trigger. We still ship bugs, and we even ship
bugs knowingly. I know nobody wants to admit that, but we ship bugs
knowingly because you can’t always fix all the bugs. Only if you don’t look
for bugs, can you can say, “We have all bugs fixed.”
If you don’t write the bugs down you get reported, then you can say, “We
have no bugs on record here.” We have a lot of bugs on record, and we
always try to fix as many as we can, but at some point, we need to make the
cut. The quality and stability is key to our process. For big releases, for
beta, and then really getting down to all the functions. People rely on it,
so it’s not a game or something. We need to focus on the quality.
Yeah. I was going to say there, “Find me a developer who says they just
shipped something with no bugs and I’ll show you a liar or just the
greatest programmer that’ ever existed.”
It’s only the former.
Exactly. That’s great. Testing sounds like a big event for you, and
rightfully so because like you said, people rely on this. You just rolled
out as we record this, version 13 of Ulysses?
I know that you just rolled out a few big features, but what are your plans
for the future? As we record, this WWDC is just a few days away. This
episode’s coming out several weeks after that. We will know what was
announced as people listen to this, but what are you looking forward to?
I don’t have a vision for what Apple will be doing next, I’m just open.
We’re going to see next week. We are adopting new features as they fit the
app. If they don’t, there have been years where we had to do a lot and have
been years where we had to do nothing. I’m curious to see what this year
is. Finally though, this the first year in 15 years of me making software
professionally, where we’re not in the middle of a development cycle over
It has happened every single year since, we always had the plan made,
“Let’s ship this before WWDC so we have a blank sheet of plans when Apple
comes and shows us the new OSs,” and it never happened. We’ve always had a
big update in July or August and that completely messed with our plans for
the new OSs, and then the whole year got mixed up. But this time we are
ready. No plans or concrete plans at the moment. We have ideas for what to
do next, but we will hold out until next week to see how it affects our
Fantastic. I will be sure to keep an eye on things like I said. I feel like
I’m gushing, but I use Ulysses every day. Again, I’m very excited to hear
the stuff that you guys are doing and that you guys have worked on.
We have we have a very long list of feature requests. We have over 1,000
different features requested in our backtracker, and we get requests by
multiple thousands of people. We count all the features and how much was
which feature requested, and that is our roadmap. We’re not sharing it
publicly, because then you commit to something, and then people come and
say, “Two years ago–” We had that before. But we will be hunting down the
most requested features, which is titles, and which is linking between
sheets. These are two of the most requested features. We have our own,
again, as well. We’ll get to those later.
Gotcha. I was going to ask, is there a certain threshold for you to say,
“This feature has been requested enough,” or is it some combination of it
getting requested enough, and it fits into the overall vision of Ulysses?
Because I can see 1,000 people saying, “You should have this,” but it
doesn’t make sense for the app. You talked about Windows unless you become
a Windows user we’re probably not going to see a Windows version of the
The features that get requested often totally makes sense. We don’t have
anything that gets requested very often that doesn’t make sense. They’re
all fitting the bill of the app, and the difficult part for us is to figure
out how to edit to the apps so that it’s not getting bloated. That’s also
something we’ll be talking about shortly, Marcus might be doing a blog post
about it because we spend so much time on making sure that everything we
add doesn’t bloat the app or water down the interface.
We’d spend days or weeks trying to make features in a way that they are
easier to use than before, and simpler to use than before, and make the UI
even less complicated while adding features. Not adding new UI at all,
always trying to avoid that. And that is really what takes so much time in
getting that done. That is the hard part also about all those features that
get requested, they makes sense, and I can see us adding them, but I know
how much time it will take to get them out.
Because all the features, the more features you have, every new feature has
some interlink edge to everything else, you have. And the more you have,
the more interlinkages you get with every new feature, it’s exponential,
and that is what makes it, so complex going forward. It gets harder with
every single release to add new stuff because you need to fix all those
links. Adding the feature, it turns out is only half the time. Getting the
rest of the app adjusted, so it perfectly suits the feature is the rest of
the half of the time. Because we had something like new deadlines-to-goals,
and then we now need to ship an update.
Because of course, people want to filter for goals with deadlines or show
me everything that has deadline. You can’t do that now, but all those
interlinkages. You need to update all the filters, all the interfaces. If
you want to make it not feel plucked on and halfway thought-through, then
every single feature gets more complex. So from that point of view, we have
so many features requested that we theoretically could go with that for
That’s it, our backlog of things that we wanted to do would last for years,
and we go where it hurts the most at the moment. That’s it. We’re going,
“We need to do that.” I hope that we’ll get some of the most aggressive
features done over the next year so that we get maybe a bit more freedom to
wade out into more complex future things. But for now, we’ll still work on
those obvious omissions, as people tend to say.
That’s fantastic. Thanks so much for that insight. We are coming up on
time, so I’m going to ask you my favorite question which is, do you have
any trade secrets for us?
Trade secrets. I don’t know. Maybe realize that there’s no shortcuts. That
would be my big secret. People always hope that there’s shortcuts, but in
my experience and I think I can say that with 15 years’ experience, there
is no shortcuts. Every shortcut you take will bite you back later.
Everything you do will come back at you at some point. If you want to work
on one thing for a very long time, if you do a new thing every other year
or something, then maybe not.
But if you try to work on something for really long because you love it a
lot, then you always need to think about, “How can this bite back?” And
every shortcut you take, every technical that you take, you have to pay
back, and it gets more and more expensive over time. That is why we always
try to build the right solution and not the quick solution, because once
you have done too many quick solutions, then there will be no solutions
I like that. That is excellent advice for development and life. Max, thanks
so much for joining me today. I appreciate it.
Thank you very much for having me.
Thanks again so much to Max for his time. It was really interesting to hear
his development process and how it’s changed over the years, and how the
team over at Ulysses moves with those changes and everything that goes on
with Mac and iOS. While I wish they did have a Windows app, I understand
why they would want to focus in closely on the Apple ecosystem. Check out
Ulysses in the App Store for both Mac OS and iOS. I am a huge fan of it.
Thanks again to our sponsors Pantheon and Backblaze, definitely check them
out. Pantheon is offering you incredible hosting for free to get started,
and Backblaze is offering you unlimited offsite backups at $5 a month.
There’s no price on peace of mind, but $5 a month is insanely low. Totally
My question of the week for you is, what app do you use it for writing? If
you blog or you write scripts or whatever it is you need to do to get your
thoughts down online, what do you use? I use Ulysses every day, and I’d
love to hear the tools that you’re using. Let me know on Twitter @jcasabona
or e-mail me at Joe@HowIBuilt.it.
You can also join the Facebook community over at HowIBuilt.it/Facebook. I
ask the question over there too, and you’ll have the opportunity to discuss
with other listeners. I want to build a strong community for this podcast
and Facebook is the place to do it.
As always, for all of the show notes head over to HowIBuilt.it/97. If you
liked the show, head over to Apple podcast and leave us a rating and
review. It helps people discover us, and friends, it’s been working. I
appreciate your support on this. Thanks so much, and until next time, get
out there and build something.