Sorry, the fact that you don’t memory manage it is pretty much the main idea – you also don’t deallocate your app delegate or AVAudioSession. It was switched to a singleton because it was too error-prone for many developers to have the responsibility to not create multiple instances, i.e. setting up and tearing down led to lots of support cases because unlike many kinds of objects that aren’t based on singular physical resources like a mono microphone, you can’t have more than one input stream for OEPocketsphinxController and that was difficult for some to work with.
setActive: is the way that it is because on its first call it provides the opportunity to initialize with any passed-in settings if that hasn’t happened before, and on its second call any future cleanup can be added without an API change. Otherwise the setup would occur at the time of making the first call to OEPocketsphinxController and could result in the first call not taking effect depending on what the initialization state was. In this respect it is architecturally similar to AVAudioSession. Currently the TRUE call can cause things to happen and the FALSE call doesn’t, but that is an implementation detail, has been different at times in the past, and is constructed that way specifically in order to allow it to painlessly change in the future without breaking anything.
OEPocketsphinxController shouldn’t be holding on to memory in a stopped state since all cleanup is currently done when stopListening is called, so it shouldn’t affect your app unless you’ve created a strong link with some other part architecturally.
Do you want to discuss what the reason for wanting to deallocate it is? Maybe I can help, or maybe you are encountering an issue that should be looked at on my end.