Another approach just occurred to me: rather than obfuscating the source, which could potentially be considered by Apple to be “an attempt to circumvent a legitimate security review process” (cough), we add a build-time option that removes the code we know to be problematic.
The Mac folder would contain a diff that described the changes that need to be applied to the source tree (in this case, removing support for the itms-server URL from parse.py; but it could be extended if needed).
configure would then gain a --with-app-store-patch option. This would be disabled by default on most platforms (including macOS), but enabled on iOS. If enabled, it would apply the patch before building the standard library. The option could also accept a file (i.e. ,--with-app-store-patch=path/to/patch), so if App Store rules change at some time in the future after the maintenance window for a particular Python release has closed, there’s still a supported option for distributors to provide an updated the patch.
Yes - this essentially reproduces something that could be trivially reproduced by distributors - but it has the advantage that CPython as a project can provide an official list of changes known to be required for App Store compliance.
Does that sound any more palatable?