I understood that there was no way to deal with it. is your Objective-C code using ARC? I already mentioned. My library is built with non-ARC. I attach a file which is history of refference counter of inputSteam in Leaks. Could you check it to make sure? Thank you. needNewBodyStream_completion_handler_leaks.txt

I created and tested a sample from the built-in template using ARC as you told me, the leak occurred as well. When using the GET Method, no leaks occured, and when using the POST Method, leaks occured. To use Objective-C with the iOS App, I chose the Storyboard as the interface. You can download my sample and Leaks results from the following URL. Sample project(TestHttp) https://1drv.ms/u/s!AjI_SS2OaUbdgRVXDWnuxp4q1F7r?e=tKolBb Result of Leaks(inputStreamLeaks.trace, Run 1 ... POST Method, Run 2 ... GET Method) https://1drv.ms/u/s!AjI_SS2OaUbdgRI64XG2IFjOm2RW?e=qPudv7 You can find out if it has been leaked by searching word "input" from the Result of Leaks. You will see the leaked MyInputStream with a reference counter of 1 only in Run 1. Please confirm if it is indeed a problem on the OS side and if there is really no workaround. Thanks.

I have submitted a bug report. I'll also consider using a TSI. Thank you so much for your answer.

The variable ret was not initialized in main.cpp. If you do not fix it as follows, the result of executing a.out, echo $? will be undefined. int main(void) { int ret = 0; ret = func(ret);

Thank you for the related article and for your efforts. Considering that the Xcode linker (BSD linker?) does not allow symbols to be referenced across objects, I guess the only way is to overwrite the entire object file. Fortunately, one object file is generated from one .cpp file, so it is possible to create an object file with partially different functionality by compiling it with another preprocessor macros. Of course, function override-like things can be realized. Conversely, unfortunately, in non-Makefile Xcode builds, the list of object files (.LinkFileList) is specified before the library flag -l is specified. This is not a problem in many cases, since the overwriting library can be specified before the target library. Thanks.

I've gone off on a tangent with an unnecessary post, but it's safe to say that it's resolved for now. Thank you very much.