The visual representation of one of your annotation objects.
- iOS 3.0+
- macOS 10.9+
- tvOS 9.2+
Annotation views are loosely coupled to a corresponding annotation object, which is an object that conforms to the
MKAnnotation protocol. When an annotation’s coordinate point is in the map's visible region, the map view asks its delegate to provide a corresponding annotation view. Annotation views may be recycled later and put into a reuse queue that is maintained by the map view.
The most efficient way to provide the content for an annotation view is to set its
image property. The annotation view sizes itself automatically to the image you specify and draws that image for its contents. Because it is a view, you can also override the
draw(_:) method and draw your view’s content manually. If you choose to override
draw(_:) directly and you do not specify a custom image in the
image property, the width and height of the annotation view’s frame are set to
0 by default. Before your custom content can be drawn, you must set the width and height to nonzero values by modifying the view’s
frame property. In general, if your content consists entirely of static images, it is more efficient to set the
image property and change it as needed than to draw the images yourself.
Annotation views remain anchored to the map at the point specified by their associated annotation object. Although they scroll with the map contents, annotation views reside in a separate display layer and are not scaled when the size of the visible map region changes.
Additionaly, annotation views support the concept of a selection state, which determines whether the view is unselected, selected, or selected and displaying a standard callout view. The user toggles between the selection states through interactions with the annotation view. In the unselected state, the annotation view is displayed but not highlighted. In the selected state, the annotation is highlighted but the callout is not displayed. And finally, the annotation can be displayed both with a highlight and a callout. The callout view displays additional information such as a title string and controls for viewing more information. The title information is provided by the annotation object but your annotation view is responsible for providing any custom controls. For more information, see Subclassing Notes.
Reuse Annotation Views
Annotation views are designed to be reused as the user (or your application) changes the visible map region. The reuse of annotation views provides significant performance improvements during scrolling by avoiding the creation of new view objects during this time-critical operation. For this reason, annotation views should not be tightly coupled to the contents of their associated annotation. Instead, it should be possible to use the properties of an annotation view (or setter methods) to configure the view for a new annotation object.
Whenever you initialize a new annotation view, you should always specify a reuse identifier for that view. As annotation views are no longer needed, the map view may put them into a reuse queue. As new annotations are added to the map view, the delegate object can then dequeue and reconfigure an existing view (rather than create a new one) using the
dequeue method of
You can use the
MKAnnotation class as is or subclass it to provide custom behavior as needed. The
image property of the class lets you set the appearance of the annotation view without subclassing directly. You might also create custom subclasses as a convenience and use them to put the annotation view in a known state. For example, the
MKPin subclass initializes the contents of the annotation view to a pin image.
There are no special requirements for subclassing
MKAnnotation. However, the following list includes some reasons you might want to subclass and some of the methods you would override to implement the desired behavior:
To put the annotation view into a consistent state, provide a custom initialization method. Your custom initialization method would then call
init(annotation:to initialize the superclass.
To provide custom callout views, override the
leftmethod and use it to return the views.
Callout Accessory View
If you support draggable annotation views in iOS 4.0 and later, your subclass is responsible for changing the value in the
drag property to appropriate values at key transition points in the drag operation. For more information, see the description of that property.