Right, they used ibapi when I first started using it. I was surprised as well when I went back to it a couple weeks ago. Looks like various parts were gradually reimplemented to the point where now there is no dependency on ibapi.
There's still dependency on it for the data structures. Anyway, I haven't found any problems with it. I would be more paranoid about me creating bugs with things out of order to be honest.
I just had a cause to look at my ib_insync implementation and I'm actually pinned to a specific commit that still uses ibapi, so I should probably be OK. Edit: also they continue to use ibapi to decode the fields, so they are just not using the EWrapper/EClient monstrosities. This is good news, I may upgrade soon!
Are you sure? The current commit (f61c33f) of decoder.py in ib_isnync looks nothing like the file of the same name in version 9.76 of ibapi. I'll admit I haven't looked through either one too closely, so it's possible there's some shared core logic I'm missing. I also don't have a good sense of how frequently IB changes the message format. It could be all the different version checks are quite old and it's been stable for a while. I agree it's unlikely to cause problems, just a rare chance of a catastrophic error that I have to weigh against the higher likelihood of errors trying to code it myself. If I went that route I would probably end up with a similar interface to ib_insync. There are a few other reasons I'm considering it. I'll likely be moving some of my trading to TOS soon, and it'd be nice to have one interface with different backends. I'd also like to be able to record messages during a trading day and play them back in a testing environment.