I am developing an investment property evaluator app that allows the user to record information about a potential investment property and evaluates the property based on certain metrics. It uses drill down navigation and a nav controller.

My question is, when the user is entering information is is customary/necessary to include a save and a cancel button? No including the cancel button would make the coding a lot easier!

  • How will they save ?
    – Mervin
    Commented Apr 16, 2013 at 4:49
  • They will tap the save/done button, whatever I choose to call it, t save their data. I guess what I'm really asking is do I need a cancel button that gives them the option to cancel their inputs.
    – ChemDev
    Commented Apr 16, 2013 at 4:52
  • Its going to be hard to respond unless we see some screenshots or wireframes. How does someone reset a form assuming they entered wrong information ?
    – Mervin
    Commented Apr 16, 2013 at 4:56
  • I am in the process of getting screenshots together. The answer to your question is perhaps they will have no way of reseting enetered information. Would you recommend doing that for a view that has up to ten data entries?
    – ChemDev
    Commented Apr 16, 2013 at 5:01

3 Answers 3


When someone is creating a new entry, you need a way for them to abandon that entry and not create anything. In iOS apps, there are two ways of doing this:

  1. Have a 'done' and a 'cancel' button. This is the clearest option as you are explicitly offering the actions to the user. However, you still have do decide how the 'back' button behaves. Does it act the same way as a 'cancel button'? If so, why do you have a 'cancel button'?

  2. Use the 'back' button position for the 'cancel' button, and have a single 'done' button. This is functionally how many iOS apps handle things, and the method that I would recommend. Here you don't have to decide how your back button will behave, and the options are clear to your users.

enter image description here

You could use the same paradigms for creating new entries and editing existing entries. One thing that you should do in both cases is to only make the 'done' button active once there has been a change or entry. Making it active before that will only cause additional confusion.


You would need to provide a way for the user to abandon the task at any time. Otherwise they would have no option but to finish entering data and then delete the record. Suppose they tap the add button by mistake. How do they go back? Save the record and then delete? Close and re-open the app? Neither is a good choice.


If I'm entering data for a new entry, I should be able to cancel creating that entry and not have to save it, go back, then delete it. A cancel button is required here. It should also be clear how to save this new entry, "back" and "close" buttons are not going to communicate "save new entry". Use "done" like the iOS Contacts app.

If I'm editing data for an existing entry there are two options. Either I can edit directly, or there is a split between view and edit modes.

The latter, split, approach requires both "done" and "cancel", just like the UI for new entries. Contacts uses this approach.

In the edit directly case, it might be better to have neither but provide only a "back" button. If your app is about storing user entered data, that should be its main focus and it should be easy. If you can do without a save button, I would omit even that. Just save everything I put in and store it for me. Especially on iOS devices I may be distracted, have to answer a phone call, etc., and I don't want to fear losing any work when that happens.
However, if complex data is entered, or it is critical in any way, you may want to have a submit action before any changes are stored. This would require both save ("the new data is correct so please store it") and cancel ("I made a mistake").

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.