> Access to private APIs for example is not preventable at runtime due to the way Objective-C works.

That's on Apple side to fix this, you can compare that to the browser which has a proper sandbox model without private APIs.

Apple's browser sandbox uses iOS-private APIs to work, plus it runs in a separate process which again is not something normal apps can do. Nor can Apple–UI frameworks all but have to be in-process and there is nothing you can do to prevent people from calling into it in unintended ways.

Access to private APIs is also impossible to prevent in screening since it’s trivial to obfuscate

Not sure if it's impossible but from experience it's very difficult to bypass Apple's screening process.

They can class-dump the Mach-O binary, disassemble and inspect the performSelector: calls or even just run the apps in an ARM emulator and watch for alarms whenever the reviewer manually goes through the app.

> from experience it's very difficult to bypass Apple's screening process

From experience, it is trivial to bypass review. Trivial.

> They can class-dump the Mach-O binary, disassemble and inspect the performSelector: calls or even just run the apps in an ARM emulator and watch for alarms whenever the reviewer manually goes through the app.

The vast majority of apps don't go through anything close to this. At most, Apple runs a class-dump equivalent on every binary, nothing more–and you can even see it catch legitimate selectors every so often! If you think about it, this isn't surprising, because you need to have a (large) team of actual reverse engineers do this kind of thing or set up a good automated malware analysis platform, both of which Apple is fairly behind at.

Screening private API fundamentally has nothing to do with how Objective-C works and everything to do with leaving private API out in places where an application can call them–the same process that an app is running code in. Switching away from Objective-C is not going to solve this problem.