At my current freelance job, I’m part of a team that works on a popular journaling app. One of the earliest takeaways from this role so far has been coming to terms with how vital this app is in the lives of its customers.

A journal isn’t just for jotting down your daily appointments. It’s for taking notes in class, recording prayers transcribed during a once-in-a-lifetime pilgrimage, recording your poetry and more, so much more! The thing it all has in common is, this data is deeply personal, and a critical situation if it goes missing.

And I cringe to report this, but sometimes data loss happens! This app has tens of thousands of users, and sometimes, through crossed messages or user error, data disappears. Lately, I’ve been doing a bit of customer support and interacting directly with the customers who have lost journals. It’s hard: the first ticket I received, I felt that fist of hard panic right in the gut, like it was my own data.

As the developer of an app that handles user data, you are placing yourself in a unique position of trust. Your customers are investing your app with their data, which is their time, their sweat, and sometimes their innermost feelings. It can be deeply personal!

So as I continue working on PupperPost, I’m finding myself thinking about how to contend with the potential for things to go disastrously wrong for my customers. A blog app isn’t a personal journal, but data loss is still a possibility! If a customer writes me an email saying their post is gone, what can I do? The time to think about that is now.

So if you’re building an app that does more than show the weather, here are some ideas to consider building in now, before you ship.

Add Data Recovery

If your app handles user data on-device, it may or may not sync that data to a remote backend (iCloud or your own service). PupperPost relies on its backend to be the “single source of truth” — when you hit Save while editing a post, it’s immediately posted to the web service. It doesn’t have a local copy, which comes with a host of very complex synchronization issues.

But the problem with being a “single” source of truth, is that if something goes awry, that backend record can sometimes become an empty field! Just like that, all your labour in crafting that long blog post is gone. For me, that’s The Worst Possible Thing. So my solution is to create backups locally. When you save in PupperPost, you are also creating a “snapshot” of that post content. And if the worst happens, I provide a way for customers to access those snapshots. In my case, it’s a long-press (really long — five seconds!) on your avatar beside the title field.

This will let you view any of the stored snapshots — the first is most likely your preference — and copy any text out of it.

Instrumenting and Logging

When customers have a problem, they should have a way to get in touch! Building a mechanism inside your app gives you the opportunity to include log files from the app, which can include diagnostic information to help you figure out what happened.

Here are some ideas of the kind of data you can include in your logging:

• Device data: model and OS version
• Free RAM at the time
• Event log data: by instrumenting your app with significant events, you can get a good idea of what the user was doing in the moments leading up to an issue. Make sure to include a timestamp with each event!
• Snapshot of the local file system and, if relevant, the remote database

Panic’s Nova has a nice panel for sending this information in. It doesn’t show the diagnostics that are being submitted, but the UI around it all is lovely:

Another downside of this flow, is that hitting “Continue” opens a web page. I’d love for it to stay in the app.

Make Backups of Your Database

If your application relies on a central hosted database — as PupperPost does — you’ll want to make sure that you’ve got backups of that. This is, of course, table stakes when hosting any application, but it bears mentioning here because regular snapshots of the main database can also be mined for lost customer data.

In my case, I have a script that pushes a copy of the whole database to a backup location off-site on an hourly basis. I sometimes go there to look upon my lovely rolling backups, and smile.

So those are my current strategies that help me sleep at night. I hope they help you too!