You don't need to set it to nil . It is supposed to be constructed from an autoreleased pointer (assuming it was constructed correctly, it will release itself). At the same time, don't hold onto it past the current stack frame. The AutoreleasingUnsafeMutablePointer does not keep the object alive. When the enclosing autorelease pool is popped, the wrapped object will be released and probably deallocated. Like the name says: it is unsafe.

Avoid problems by never creating AutoreleasingUnsafeMutablePointer yourself in Swift (edit: except when it's really an UnsafeMutablePointer and the C header import has made a mistake, see below). If you're using it correctly, it should be transparent glue between Swift's inout and an Objective-C return-by-pointer parameter.

You generally create a var matching the contained type and pass it in by inout .

e.g. if you want to call the function:

func someFunction(obj: AutoreleasingUnsafeMutablePointer<AnyObject?>)

then you invoke it like this:

var myObject: AnyObject? = nil someFunction(&AnyObject)

and everything will work out.

I'm not aware of any other situation where you should hold an AutoreleasingUnsafeMutablePointer . I don't think you should be manually constructing one at all on the Swift side except as nil . It is precariously difficult in Swift to construct an AutoreleasingUnsafeMutablePointer with non- nil contents since the only way to autorelease is using Unmanaged .

Responding to your update...

The objc_getClassList function signature is a glitch in Swift's automatic C importing. It incorrectly assumes that a Class * parameter should be imported as AutoreleasingUnsafeMutablePointer<AnyObject?> . You really just need an UnsafeMutablePointer which you can get from an array: