Take the 2-minute tour ×

Are we allowed to modify the subviews of a default iOS control, like the UIDatePicker? My app has a minimalist/flat UI, and the default Date Picker doesn't match that style. The only way I could find to modify it was to iterate through its subviews and hide the ones that add shadows, etc., like so:

UIView *background = (UIView *)[[self pickerViews].subviews objectAtIndex:0];
background.hidden = YES;

Is this allowed or will it get my app rejected? I'm not actually messing with the control or its function whatsoever, just its appearance.

share|improve this question
It is not recommended, because in future apple might change something in UIDatePicker and your code may crash/or show an unexpected behavior then. –  iDev Feb 21 '13 at 0:53

3 Answers 3

up vote 2 down vote accepted

While you may not get rejected right away, you may see unexpected behavior in the future when the control's subviews change. It might be a better idea to work up your own custom control, or find ways in the public API to get close to the appearance you want.

share|improve this answer

It isn't really a "private API" — it's entirely documented in the SDK. However, you are relying on behaviour that is not documented (namely that subview 0 is the one you want to hide), so you need to be careful.

Your code has two potential problems:

  • It will hide the wrong view if the order changes (checking the view class is commonly used to guard against this somewhat)
  • It will crash if the picker has no subviews (this seems unlikely to happen; it's much more of an issue when you access views at e.g. index 6).

There are also two additional things you need to do:

  • Keep a list of anything you've done that are liable to break in future OS releases.
  • Check that things still work in iOS betas, and do so early!
share|improve this answer
Thanks for the detailed answer. I may have to end up going with this, as I have no earthly idea how to make a completely custom date picker control. –  bmueller Feb 21 '13 at 5:12
One question - you said that "checking the view class is commonly used to guard against this". What did you mean by that? –  bmueller Feb 21 '13 at 6:21
For example, getting the UIWebView's scrollview (on older iOS versions) can be done by iterating over subviews and returning the first that is a UIScrollView. Hiding the "shadows" can then be done by iterating over the UIScrollView's subviews and hiding those which are a UIImageView (this also hides the scroll indicators, but may be what you want). While this might fail on an OS upgrade, it's unlikely to crash or hide the web page content. –  tc. Feb 21 '13 at 20:06
Checking [view isKindOfClass:[UIImageView class]] is traditional. –  tc. Feb 22 '13 at 2:54
You could do [NSStringFromClass([view class]) isEqualToString:@"_UIOnePartImageView"]... –  tc. Feb 22 '13 at 6:28

Its not recommended to change the things which are not exposed through API. In future apple may remove the subviews at that particular indexes. Its better to avoid this kind of approach. Try to look for other options in-terms of UI or implementation.

share|improve this answer

Your Answer


