Unless you specified that your software has to be secure against TLS interception even in the case of a jailbroken/rooted machine - which I hope you didn't, because that's impossible and a fool's errand to attempt - your pentester has... no idea what they're talking about and I hope you didn't pay them much for it.
SSL Kill Switch 2 isn't a weakness in your SSL implementation, and it isn't a vulnerability in general. It's a tool for - on a fully rooted device - straight-up modifying your app's use of system libraries. It in no way qualifies as an app vulnerability, for the following reasons:
- The "attacker" needs to already have control of the operating system (not even normal user control, but actually root privileges). There is no possibility of securing a user-space app against a malicious OS.
- It requires malicious action on the part of the ostensible victim of any attack (the user, whose app login tokens or whatever are supposedly at risk). Unless you're trying to keep stuff in your app secret even from the user of jailbroken phones - which, again, indicates some bad choices in your design, and a lot of wasted time in your future trying to implement unspoofable jailbreak detection and/or snake-oil code obfuscation - pinning is to protect the user; it's incoherent to think of them as the attacker of their own secrets.
- The actual attackers can't do this. On a non-jailbroken phone, apps can't modify each other (or system libraries) at all. Even on a jailbroken phone, apps are still secure against remote attacks (at least, to the extent that the OS is secured against remote code execution in general; if the user has SSH enabled with a weak password, that's a vulnerability but it isn't your vulnerability). An "SSL pinning bypass" implies that an attacker is able to get your app to make an insecure connection, and even jailbreaking doesn't do that unless the attacker's code is already executing on the device.
- There's nothing wrong with your code. It's quite reasonable to assume that your app will operate in an environment where the system TLS APIs do, in fact, create secure connections (and allow you to pin the cert or key of the server, as per their API contract). You could do something like bundle your own copy of OpenSSL and use that for the connection, instead of the system library, but you don't need to and it wouldn't really help anyhow (the "pentester" would just modify that instead).
Don't get me wrong, actual pentesters test on jailbroken devices specifically so they can do things like run SSL Kill Switch and disable pinning (or TLS in general). But that doesn't go in the report as a vulnerability. It's a way to find vulnerabilities - such as that your app is using hardcoded secrets, or is vulnerable to deserialization attacks, or that your server is vulnerable to an authorization bypass, or so on - but it isn't itself a vuln. Saying it is would be like saying a web app is vulnerable to XSS because the user can install an extension that injects scripts into the page. This is obvious, unavoidable, not your fault, and outright stupid to flag as an issue unless you're somehow trying to hide secrets even from the app's users.