>> but unfortunately the phone became a brick
So it protected the password pretty well without any code, yes? 😉
You can't actually solve your problem deterministically. The password is in (at least) two places: (1) the NSData object returned by [[DummyEnc sharedInstance] decDummy], where it's a UTF-8 string, and (2) the NSString object referred to by tempStr, where it's a UTF-16 code unit array.
Both of these use some kind of underlying storage (in general) for the actual data they contain, and you can't (in general) force that data to be overwritten.
For the NSData object, the best you can hope for is that its underlying buffer is overwritten by something after it's returned to the malloc pool and later reused. (Returning it to the pool will overwrite part of it, probably, but not all.) If it's really a NSMutableData object, you might be able to overwrite the underlying data yourself, before releasing it.
For the NSString object, the situation is similar, in that if it's really a NSMutableString you might be able to cause the underlying data to be overwritten. However, unlike NSData, there's no direct API for this, and you can't be certain that changing the value of a NSMutableString overwrites its internal buffer, instead of freeing it and allocating a new one.
Furthermore, you don't know for certain whether your code is causing any temporary copies of the data to be created. Perhaps not, but it's implementation dependent.
The only absolutely safe way is brick the phone. You seem to have discovered that solution empirically. 🙂