Author here. Thanks for sharing this. It seems they released an updated version of this analysis last year [1]. It matches what I saw when analyzing the IPA. I tried to do a deeper analysis on the code itself using several tools, including Google's own bloaty [2] which was not very useful without symbols, classdumpios [3] which revealed something like 50k interfaces starting with "ComGoogle", and Ghidra [4], which I left running for a day to analyze the binary, but kept hanging and freezing so I gave up on it. Perhaps comparing the Android and iOS code could lead to something more fruitful.
Bell Labs had a simpler alternative in IFFE [0], that consisted of a single shell script [1]. You would specify any required headers, libraries and tests in a simple text file [2].
I came across this after listening to several 320kbps MP3 files and found that they sounded noticeably worse than 256kbps AAC versions. Support for AAC is widespread now and it should be preferred over MP3 [1].
If you're using this for testing, it's likely that you haven't fully locked down your server yet. It's not an exploit in itself but it potentially makes the server a target. No reason to do that until and unless it's required.
Before going to Rust, run `node --cpu-prof main.js`, and open the profile in chrome://inspect -> DevTools for Node -> Performance tab. It will tell you what's taking time and it may not be what you expect.