An object that manages the content for a rectangular area on the screen.
- iOS 2.0+
- Mac Catalyst 13.0+
- tvOS 9.0+
Views are the fundamental building blocks of your app's user interface, and the
UIView class defines the behaviors that are common to all views. A view object renders content within its bounds rectangle and handles any interactions with that content. The
UIView class is a concrete class that you can instantiate and use to display a fixed background color. You can also subclass it to draw more sophisticated content. To display labels, images, buttons, and other interface elements commonly found in apps, use the view subclasses provided by the UIKit framework rather than trying to define your own.
Because view objects are the main way your application interacts with the user, they have a number of responsibilities. Here are just a few:
Drawing and animation
Views draw content in their rectangular area using UIKit or Core Graphics.
Some view properties can be animated to new values.
Layout and subview management
Views may contain zero or more subviews.
Views can adjust the size and position of their subviews.
Use Auto Layout to define the rules for resizing and repositioning your views in response to changes in the view hierarchy.
A view is a subclass of
UIResponderand can respond to touches and other types of events.
Views can install gesture recognizers to handle common gestures.
Views can be nested inside other views to create view hierarchies, which offer a convenient way to organize related content. Nesting a view creates a parent-child relationship between the child view being nested (known as the subview) and the parent (known as the superview). A parent view may contain any number of subviews but each subview has only one superview. By default, when a subview’s visible area extends outside of the bounds of its superview, no clipping of the subview's content occurs. Use the
clips property to change that behavior.
The geometry of each view is defined by its
bounds properties. The
frame property defines the origin and dimensions of the view in the coordinate system of its superview. The
bounds property defines the internal dimensions of the view as it sees them and is used almost exclusively in custom drawing code. The center property provides a convenient way to reposition a view without changing its
bounds properties directly.
For detailed information about how to use the
UIView class, see View Programming Guide for iOS.
Creating a View
Normally, you create views in your storyboards by dragging them from the library to your canvas. You can also create views programmatically. When creating a view, you typically specify its initial size and position relative to its future superview. For example, the following example creates a view and places its top-left corner at the point (10, 10) in the superview's coordinate system (once it is added to that superview).
To add a subview to another view, call the
add method on the superview. You may add any number of subviews to a view, and sibling views may overlap each other without any issues in iOS. Each call to the
add method places the new view on top of all other siblings. You can specify the relative z-order of subview by adding it using the
insert methods. You can also exchange the position of already added subviews using the
After creating a view, create Auto Layout rules to govern how the size and position of the view change in response to changes in the rest of the view hierarchy. For more information, see Auto Layout Guide.
The View Drawing Cycle
View drawing occurs on an as-needed basis. When a view is first shown, or when all or part of it becomes visible due to layout changes, the system asks the view to draw its contents. For views that contain custom content using UIKit or Core Graphics, the system calls the view’s
draw method. Your implementation of this method is responsible for drawing the view’s content into the current graphics context, which is set up by the system automatically prior to calling this method. This creates a static visual representation of your view’s content that can then be displayed on the screen.
When the actual content of your view changes, it is your responsibility to notify the system that your view needs to be redrawn. You do this by calling your view’s
set method of the view. These methods let the system know that it should update the view during the next drawing cycle. Because it waits until the next drawing cycle to update the view, you can call these methods on multiple views to update them at the same time.
For detailed information about the view drawing cycle and the role your views have in this cycle, see View Programming Guide for iOS.
Changes to several view properties can be animated—that is, changing the property creates an animation starting at the current value and ending at the new value that you specify. The following properties of the
UIView class are animatable:
To animate your changes, create a
UIView object and use its handler block to change the values of your view's properties. The
UIView class lets you specify the duration and timing of your animations, but it performs the actual animations. You can pause a property-based animator that is currently running to interrupt the animation and drive it interactively. For more information, see
Manipulations to your application’s user interface must occur on the main thread. Thus, you should always call the methods of the
UIView class from code running in the main thread of your application. The only time this may not be strictly necessary is when creating the view object itself, but all other manipulations should occur on the main thread.
UIView class is a key subclassing point for visual content that also requires user interactions. Although there are many good reasons to subclass
UIView, it is recommended that you do so only when the basic
UIView class or the standard system views do not provide the capabilities that you need. Subclassing requires more work on your part to implement the view and to tune its performance.
For information about ways to avoid subclassing, see Alternatives to Subclassing.
Methods to Override
UIView, there are only a handful of methods you should override and many methods that you might override depending on your needs. Because
UIView is a highly configurable class, there are also many ways to implement sophisticated view behaviors without overriding custom methods, which are discussed in the Alternatives to Subclassing section. In the meantime, the following list includes the methods you might consider overriding in your
init- It is recommended that you implement this method. You can also implement custom initialization methods in addition to, or instead of, this method.
init- Implement this method if you load your view from storyboards or nib files and your view requires custom initialization.
layerUse this property only if you want your view to use a different Core Animation layer for its backing store. For example, if your view uses tiling to display a large scrollable area, you might want to set the property to the
Drawing and printing:
Layout and Constraints:
requiresUse this property if your view class requires constraints to work properly.
Constraint Based Layout
update- Implement this method if your view needs to create custom constraints between your subviews.
gesture- Implement this method if your view handles touch events directly and might want to prevent attached gesture recognizers from triggering additional actions.
Recognizer Should Begin:
Began: with Event:
Moved: with Event:
Ended: with Event:
touches- Implement these methods if you need to handle touch events directly. (For gesture-based input, use gesture recognizers.)
Cancelled: with Event:
Alternatives to Subclassing
Many view behaviors can be configured without the need for subclassing. Before you start overriding methods, consider whether modifying the following properties or behaviors would provide the behavior you need.
add- Define automatic layout behavior for the view and its subviews.
autoresizing- Provides automatic layout behavior when the superview’s frame changes. These behaviors can be combined with constraints.
content- Provides layout behavior for the view’s content, as opposed to the
frameof the view. This property also affects how the content is scaled to fit the view and whether it is cached or redrawn.
background- Set the view’s color rather than drawing that color yourself.
Subviews - Rather than draw your content using a
drawmethod, embed image and label subviews with the content you want to present.
Gesture recognizers - Rather than subclass to intercept and handle touch events yourself, you can use gesture recognizers to send an Target-Action to a target object.
Animations - Use the built-in animation support rather than trying to animate changes yourself. The animation support provided by Core Animation is fast and easy to use.
Image-based backgrounds - For views that display relatively static content, consider using a
UIImageobject with gesture recognizers instead of subclassing and drawing the image yourself. Alternatively, you can also use a generic
UIViewobject and assign your image as the content of the view’s
Animations are another way to make visible changes to a view without requiring you to subclass and implement complex drawing code. Many properties of the
UIView class are animatable, which means changes to those properties can trigger system-generated animations. Starting animations requires as little as one line of code to indicate that any changes that follow should be animated. For more information about animation support for views, see Animations.