How to Really Port Your Mac App to iPhone

First, an apology: My last post about porting Mac apps to iPhone was full of lies. I’m really sorry. If you got the impression, that Mac apps can automatically be ported to iOS in two hours while you’re playing Counterstrike — sorry, I totally made that up. Nothing is automatic, and you should rather quit playing Counterstrike, if you want to get serious work done, and none of us play Counterstrike at all, so there’s that. (1)

I also understand that some of my fellow developers have been furiously updating their IDEs in order to get access to both the “cross-device feature” checkboxes and the Google/Windows deployments. So I’m here to tell you that I made these up, too. You can stop searching now, they’re not there, you’ll have to manually port your code — sorry. I’ll offer you a drink, if we ever meet at WWDC.

Then I would like to apologize to those of you who I led to believe their assumptions about app development in general and updating to new hardware and OSes were legit. That post was all about you, yes, but I obviously made you feel as if you’re right when thinking that as soon as new iPads arrive, and as soon as new OS versions get released, developers would just need to tick a few boxes and hit “release”. I obviously made you feel as if you’re right in assuming that features which look and feel the same on Mac, iPad and iPhone literally are the same. As I did with the Split View example, for which I’m really, really sorry. Split View on Mac is a totally different beast than Split View on iPad, and as I said, I’m sorry to have implied otherwise. I can’t offer you all a drink, because you’re such a vast and diverse group, so you’ll just have to accept my sincerest apology instead, which I hope you’ll do.

I also feel that I need to apologize to our group of 500 beta testers. Some people were led to believe that we really are finished for months and are just sitting on the release for sake of building anticipation. This, obviously, must mean the beta test was forged, which in turn must mean our testers were playing along our dirty game of hold-up. Thanks everybody for testing and reporting, you know it was true, it was awfully important, thank you, you’re a big part of this, you rock!

And to those of you who quit their day job because I made it sound so dead simple to create a mobile app and offer it on the app stores: Remember that you first need to have a Mac app to actually port it to another platform! And Mac apps are really hard to create, because you have to do them from scratch — and not literal scratch, mind you, but from… how do I say, so it won’t get misinterpreted? You have to actually write code and create icons and such things. And you probably have to learn Swift and some design. The technology to create awesome apps from real scratch is not there yet. So, good luck still!

But seriously: How *Did* We Port Ulysses to iPhone Then?

Short answer: A year of working our asses off. That simple. A bunch of highly talented people doing night shifts, weekends, never giving up, never satisfied, always trying to push the envelope, to optimize, and never shy to throw a working solution in the trash if it turns out to be “just not good enough”.

This, as you should be able to guess, takes time.

If you’re really interested, let me tell you that the new button row alone took a couple of weeks, because of all the different implications every code- or design-change would have in all the various states Ulysses can be shown on your devices. iPhone 4, 5, 6, 6 Plus, iPad, iPad Pro, all in portrait and landscape. That’s 12 versions, and that’s the easy part. We show dynamic content on the bar, such as counters and search and tons of markup commands. Now add Slide Over and the various Split View sizes on iPad, active/passive state of the app, external keyboards and the desire to make it all look and behave exceptionally well — this is work, people. Work.

The button row alone took us several iterations — fully implemented iterations, of course, because we need to test, not guess — until we felt satisfied on iPhone. We then went back to iPad and decided to kill our existing implementation and go with the system’s shortcuts bar instead. This may sound like a simple swap of button positions, but our own button row had advanced features, such as tap’n’swipe, key repeat etc., and we had lots of buttons, none of which had to compete for space with predictive text input.

It was a tough decision, because it meant stripping some features, but on iPad we now manage to keep our shortcuts across split views. This is no easy feat, given how split view actually works, and how the keyboard gets accessed by two different apps at different times in varying sizes. By moving our keys to the system’s shortcut bar, we were also able to get rid of a lot of stupid redundancies such as B/I/U or multiple Undo buttons — and multiple bars, of course. We also tried a lot of different things to accommodate for some of the system bar’s shortcomings, and we’re still not completely happy, but we ultimately just went with it and said: “Well, so be it”. And even this, let’s call it… acceptance… even this takes a lot of time and effort. Heated debates. Tests and prototypes. Work.

From iPad Pro to iPhone and Back Again

Now, granted, we already had an iPad app, so it’s probably still hard to understand what took us so long to update that app for iPad Pro — it’s “just the new keyboard, after all”, right? And the larger screen. And Split View. But one of the split view sizes is pretty much 1:1 iPhone portrait, so in order to solve Split View on iPad, we had to first solve iPhone. And in order to solve iPhone, we had to solve the button row. And navigation. Organization. Attachments. Export. Backup. And since it’s an iPhone, well, we had to solve iPhone landscape, too, with the 6 Plus featuring multi-column layouts, and the 4s being as tiny as it is.

And I just know you’re curious as to why it took us “so long” while other writing apps were updated in a quicker fashion. I don’t know about the other devs’ processes, but I believe that once you get your hands on the new version, you’ll actually feel the love and polish that went into it. This is not just a blown up variant on iPad Pro — this is desktop-class kick-ass. And it’s not just a shrunk, stripped down version on iPhone, either — this is not “Ulysses Pocket”, this is the full experience, everything. Ulysses in your pocket.

And let me tell you again and once and for all that Ulysses is a completely different app than your average Markdown editor. Most of these editors need only look into a folder and load the text files contained within. Then perform some display magic. Ulysses has inline images and footnotes, and attachments such as goals and notes and keywords and PDFs. It has additional data/info such as glueing and persistent states of group sorting and collapsing (nested groups and filters to begin with). It has extensible export options and themes, allows for multiple Medium accounts and offers fully-fledged, almost hardcore ePub/DOCX/PDF export of whole groups and/or multiple sheets at once, with downloadable styles and then some. This all syncs rather seamlessly across all your devices, with zero setup, truly automatic, from Mac to iPad to iPhone and back again, with almost full feature parity on all your devices.

There is not a single text editor on iOS that even comes close in terms of data complexity, let alone interaction layers. This is not, I repeat: NOT your average Dropbox Writer with a button row. And yet we still manage to make it seem rather simple and effortless. Yeah, I’m proud.

If you look at the finished product, you may very well think it all looks so self-evident. “How could it ever have been different”, you may ask. And that’s great, because then we’ve done our job right. But again — this is work, people. Hard work. (2)

Still Serious: From Review to Approval to Availability

We submitted Ulysses 2.5 to Apple for review on Friday, February 26th. We submitted both a Mac version and the new universal iPhone/iPad version. Needless to say, we want both versions to release at the same day. Upon submission, we had no clue how long it would take to get approved, and we usually get rejected at least once for some small oversight or such. Current review times were at an all-time low, but you still never know.

Based on our estimates, we should have been approved by March 4th, give or take a day. Given the importance of our iPhone release, we also placed some stakes on getting featured on the App Store — if not on both, then at least on iTunes. This means a timed release defined by the App Store team.

Now, with a release such as ours, you want to get the attention of the media. You want to get the word out, but of course you need hard facts. You can’t just email a press release going: “Submitted, dunno when it will go live, if at all”. Well, you can, but… you know. So we needed to decide on a release date. As stated, we believed to be approved on March 5th at the latest, hoped for a feature, and since we’d rather play it safe, we took no chances and set an even later date in our press release.

We had no idea that we’d get approved within three days, but even if we did, it wouldn’t have mattered, because between submission and release there’s quite a lot of other work to do: Finishing up the new website for example. The afore-mentioned press releases. Blog posts. Emails. Twitter. Promotional art. Art for the possible App Store feature. We’re a small team, it takes a lot of scheduling to get everything done in time, and while I write this, we’re still working on the website.

Luckily, we’ve worked really hard over the past several years to be in a position where we no longer need to worry about “losing” a week of sales. We understand that you would have updates rather sooner than later, but please also understand that we would rather have an approved update sitting for a week, then to get into all kinds of timing troubles with press and web and Apple and kids and family. We’ve been there, it’s no fun.

So: Ulysses 2.5 will be available very soon, as in very soon, as in “it’s almost there”. But I’m also here to tell you that some days make more economical sense than others, and that, after all, we need to pay the rent. So: We keep the right to release when we see fit, and you’ll just have to roll with it. So: Roll with it.

Last Not Least: Apple

Dear folks at Apple. I understand that my original post may have left an impression as if I was making fun of your development tools and/or the nomenclature of certain features in your SDK. As if I was mocking terms such as “Auto-Layout” or criticizing the steps it takes to actually port a Mac app to iOS.

That was not my intention. I won’t apologize, because, well, it was not my intention, there is nothing to mock, and because I believe it’s almost impossible to read this sort of criticism into my post, if you have some confidence and are not just skimming through.

Although… you do make it sound rather easy in your marketing material, but that’s another post altogether.

Ok, everybody — we good?

1) I love Counterstrike, please don’t go that route, please don’t…

2) And we’re far from finished. Bugs and glitches aside, what you get now is a solid foundation on which we will continue to build. See you there!