Since the early days of the App store, one of the hallmarks of a good iOS app has been how well it restored state. Before multitasking was introduced, apps completely shutdown every time you hit the home button. If you returned to the app you were just using, and found that you had to tap 5 times to get back to where you were, you probably got pissed off and stopped using that app. That meant developers had to do a lot of work to keep track of what was going on when the app was quit and restore that state when it was launched again.

Multitasking provided state management for free. Not without exception, but for many apps those sort of flip-flop actions would not cause your app to get completely shutdown and the user would return to where they were without issue. Of course good apps still need to manage state, because you never know when iOS is going to decide it’s done with you and quit your app in the background.

For my latest app, [Drafts](http://agiletortoise.com/drafts), I wanted a feature that bucked this norm. For most use cases I had in mind, the user launching Drafts was going to want and expect the “first launch” behavior – which is to open to a new, empty draft with it focused and ready for editing. This sounds easy, just do that whenever the app is either launched or restored from the background via multitasking.

That would kind of suck for certain cases as well. It’s entirely likely that while you are in the act of composing a tweet or other short text in Drafts, you might need to jump over to another app (Safari, Tweetbot, whatever) and copy some text, or check on a reference then return to Drafts. If you were in the middle of writing, and doing this sort of app flip-flop caused Drafts to put you in a new, empty Draft, you’d be unhappy. You would probably curse me personally, rant on Twitter and leave a one star review.

In order to balance these needs, I had to determine “How long is too long?” In other words, if Drafts is in the background and the user is doing other things, what is the right interval at which to timeout their editing session and assume when they returned to Drafts they would expect it to act like it was just launched and give them a new draft?

This is a subjective measurement, and not going to be perfect whatever I chose. I may change this number in the future based on feedback, but the value I ended up with is three minutes. If it has been more than three minutes since you had Drafts as the foreground app on your iPhone and you return to it the app assumes you want a new, empty draft. In my testing, this is the number that felt right to me.

Ultimately, in the cases were I have judged this value incorrectly, no harm is done. The last draft you were working on is just two taps away and you have experience a minor annoyance. I feel like it’s my job as a developer to remove as many of those minor annoyances as I can, however, because sometimes that’s the difference between an app you like and an app you love.