I'm designing a view that contains a plain table view with a single fixed row. I want this row to let the user choose an item from a list I navigate to, then navigate back, and then tap a button next to the former view's table view to update the rest of the view's content.

My question is: my table views does not fill the whole screen's width, because I've set a button next to it that is not part of the table's cell, and I thought I could design the view this way but then I've read this from the iOS Human Interface Guidelines:

Plain tables display rows that extend the full width of the screen.

Does this mean that table views with less width than the screen's won't be allowed? I tried to find an example of a plain table view that doesn't fill the whole screen's width in any existing app, but I didn't succeed.


EDIT: This is a mockup of what I have


I have a subview at top of the screen of more or less the same hight of the navigation bar, as if it were another bar, and there I have my plain table with an only cell (in image looks like grouped table... I could even consider having a grouped table instead of plain), and next to the table, I have the button I mentioned.

Tapping on the cell presents modally another view controller with a list in a grouped table where user can choose an item. Then, back to the view in the mockup, user taps the "Go" button and the content of the rest of the view is updated.

I think such table cell would be a good place for a drop-down list, but since in iOS there isn't any control like that... I thought having a table view with an only cell and a button next, but out of the table and the cell, would be a good idea. However, the text I found in Apple's Human Interface Guidelines doesn't make me clear if they will allow me to have a plain table this way, with a width not filling the screen's width.

So, if I can't have my view designed like this, how could I solve this user experience situation, if I don´t have a drop-down list control in iOS?

Thanks again

  • You'll have to clarify what you are trying to do with a diagram of some sort. I have a feeling that the fact that you need a button next to a table view is indicative of some other kind of workflow problem. You're correct in that putting a button next to a table row is non-standard and likely shouldn't be done.
    – Sullivan
    Sep 3, 2013 at 20:15
  • @Sullivan You're right... updated my post
    – AppsDev
    Sep 4, 2013 at 3:17

2 Answers 2


Not sure about how your design looks exactly. But when I got a design idea I believe in, I choose to assume that Apple will too. I try to submit it the way I want it, and worry about the reject when it happens, instead of in advance.

There are examples of apps in the App Store that have lists/tables with cells that do not fill the width of screen. For example the Chrome menu (hamburger icon).

enter image description here


I think (not completely sure) what the guide is saying is that it'll extend the width of the table according to the width of the screen (when screen orientation changes). What you can do to get around it is to change the background of the table cell so that it doesn't appear to fill up the screen.

  • Adjusting the width of the table view in Interface Builder or programmatically to fill only a part of the screen's width is not a problem, in fact I did, but I'm not sure if this will be rejected or, as you say, the docs are referring to adapt the width to orientation changes...
    – AppsDev
    Sep 4, 2013 at 5:31

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.