What's Up With Remembary
Jul 27, 2015 11:22

Remembary is a big part of my life. I use it almost every day. It contains over a decade of diary entries, half of them copied in from my handwritten journals. It's the way that I reconnect to my past and think about the future.

The last update deployed to the App Store was on January 24, 2014. This is over a year and a half ago. The version in the store hasn't been updated for iOS8 - it hasn't even been updated for iOS7. Why is that? Don't I care about my own software?

I actually care a lot. I care so much that I want to produce the best, most stable and reliable product that I can. I've also been working on the app quite a bit since the last update - in fact, I've dedicated entire months and have even turned down paying work to get Remembary updated for the latest iOS features.

So why is Remembary still an iOS6 app?

The full-time job that pays $30/week

The first thing to know is that, contrary to common perception, it's very difficult to make a living in the App Store. Remembary frequently shows up in "Top Grossing" charts, but averages about $30 to $50 a week. Some weeks it makes no money at all. Even when the app has been featured on nationwide TV or newspapers, the resulting spike in sales, which is enough to push it to #1 on some charts, only lasts a few days and totals to about $400.

I realized early on that Remembary wasn't likely to make me rich and I've been okay with that. Building and selling and promoting and supporting a product is an amazing experience and has been great for me professionally in terms of building up my portfolio and my reputation. It's also deeply satisfying to know that something I've made is used by people every day to record and reflect upon their lives.

That said, I have to approach Remembary like an indie musician or an amateur novelist: I'm creating something that some people might love, but the odds of making much money from it are very small. I have to do it for the pure passion of it.

... and I have to do something else to put food on the table.

Keeping up with all the changes in iOS every year, especially over the last few years with the introduction of "flat design" in iOS7 and all the new APIs and even new languages in iOS8 and iOS9, can be a full-time job, but since it only pays a fraction of what it takes to make a living, I have to take on other paying work and try to find the time to work on Remembary in the gaps between other projects and commitments.

Updating for iOS7 - then iOS8

The biggest change with iOS7 was new constraint-based layout and a new aesthetic approach based on thinner fonts and a flatter look. With iOS8 this became even more important, especially with the rumours of multiple-sized devices and even split-screen support coming down the pipeline. This was all exciting, but it would require completely rebuilding and rethinking every single UI component in the application - over 16 screens worth of sometimes quite complex layouts. A favourite feature of the app is the over a dozen bit-perfect full-screen themes with rich textures and subtle details like watermarks and frayed edges. Not only did this not fit with the new aesthetic, but I'm still figuring out the best way to scale or resize these images to work with split and variable-sized displays.

Rich Text Nightmare

In the summer of 2014, I cleared my work schedule and turned down paying work for over a month to finally dig in and get Remembary up to date. iOS8 was now in the pipeline and I had heard that it supported many new enhanced rich text features. Rich text (bold, italic, underline, colour, and embedded images) would obviously be a great feature for a diary app - many competing apps had tried to support rich text through allowing Markdown or HTML tags, but this wasn't WYSIWYG, which I consider to be of prime importance in any modern app, especially an iOS app.

I started doing research and it turns out that while iOS8 did support new rich text features, they were only "easier and more powerful" in comparison to the previous versions of iOS, where you had to build your own rendering engine essentially from scratch. Managing rich text turned out to require an awkward combination of advanced object-oriented approaches and vintage 80s-style C bit-flipping. For example, to check if a piece of text is bold, one can't simply call an "isBold" method against an object, like one would expect in a modern API, but instead one has to do a string match against the font descriptor for "bold" or "strong".

What little documentation available seemed to assume that one was already an expert in text-rendering technology, but I finally found some useful guides at raywenderlich.com and managed to make some solid progress. Remembary could now support rich text of various kinds, finally users would be able to emphasize parts of their text. However, I quickly ran into problems: assigning italic or bold doesn't work for all fonts - the custom handwriting and typewriter fonts that I had included in Remembary and which were some of the most popular features of the app often only had regular modes. This makes sense - Jane Austen never needed a bold version of her handwriting, and you would need a whole new typewriter if you wanted to use italics on a vintage Underwood - but it was a big frustration for me in Remembary. If a user added bold and italic to regular text and then switched to a font that didn't support those features, the highlights would be clobbered and they would stay gone if they went back to their original font. This was unacceptable behaviour for a diary app, so after all of that work, I pared it back to only support underline, which works for any font and is still valuable as a means of highlighting text. Not as fancy as I had hoped, but still useful.

No new feature goes unpunished

However, rich text also automatically supports embedded images. At first I thought this would a great feature: users could tap on the pictures from that day to add them directly into their diary, mixed in with the text. Building this took some work and it ran a little slowly, but it was an exciting breakthrough and it looked great. But adding images turned out to have all sorts of cascading problems:

  • exporting the diary into a data format to be re-imported elsewhere was now much more complicated since Remembary now had to store potentially megabytes of embedded binary data along with the diary text.
  • even worse, the natural thing to try to do with text that has image support is to copy and paste images into it from elsewhere, or take copy this mixed content and paste it into an email or a Pages document or some other environment. Considering that this is something that people have been able to do in Mac OS since the 1980s, I assumed that this was a mature, solved problem. It turns out that every program has to build its own custom data format for copying and pasting anything more complicated than plain text. Even when I was able to handle this in a limited way, the resulting images would end up being too large for the diary page yet also inaccessible to my code so I couldn't resize them properly.

I happened to be sharing an office at the time with one of the best iOS development shops in the country, and I got one of their best developers to take a look at this rich text / copy-paste situation. His analysis included phrases such as "this is definitely non-trivial," "I can't guarantee that when pasting from other apps everything will work properly," and, "this might be something that you have to wrestle with every time a new version of iOS comes out, possibly even minor revisions."

Remember, this is a part-time job that pays far below minimum wage.

Day job

Around this time, a new potential client came along with a technically challenging Ruby on Rails / JavaScript project with a very generous budget. I had to decide whether to go with them and replenish my rapidly shrinking bank account, or to double down on Remembary with all of its technical headaches at $30/week. As I found myself debating whether my salary for the month should be $250 or $500, the choice of taking the money project seemed pretty clear.

It turned out to be refreshing to wrestle with a complex project based on software that I understood and which wouldn't change under my feet every few months. Getting paid has been nice too.

So I've been working very hard on this client project for the last few months - as well as a side startup that is already making almost as much as Remembary but with a much larger potential upside. iOS development is complex enough that I can't just pop into it for half an hour at the end of a day - it takes a lot of mental space to change gears enough to be productive in iOS, and that requires a non-trivial amount of time and energy.

The Future - Remembary 3.0 (or at least Remembary 2.9)

The heavy lifting part of both projects is finally wrapping up and I'm starting to find myself with a bit of extra time on my hands - time I hope to start dedicating to Remembary.

The new iCloud Photo Library is a perfect for Remembary, with almost instant access to any pictures in your library without having to take up dozens of gigabytes in your machine. The preliminary tests of Remembary with this new library are encouraging - although, once again, the only tutorials that I could find explaining how the new APIs work had bugs in them that made them crash when I tested them on my device.

So, I'm still working on Remembary. The dreams of an earth-shattering 3.0 release with full rich media support have gone up in smoke, but I am aiming for a simpler update which at least uses the newer layout frameworks and obvious APIs like the new photo library.

The best way to support a living iOS application is regular updates, adding small features every few weeks or so. The major changes required for iOS7 broke that pattern and I'm still trying to pick up the pieces before new versions of the OS break things even more. The next update should at least get Remembary on a proper foundation so I can move forward with more frequent updates in future.

I'm still using Remembary every day, like I have for five years. I plan to continue doing so for many more.