Here's an updated patch that integrates some of the feedback that has been received so far. 

Notable changes:

* The code now works for ARMv7. Unfortunately, the price for this is a new  libffi_ios_aarch source directory, containing generated source tree for the ARM64 platform. I've been working with the libffi community to address the compilation problems that exist in trunk, but so far, this hasn't resulted in a fix for the problems that have been introduced in their trunk code.

* I looked into merging the libffi_ios and libffi_osx directories, but this proved to be harder I thought because of legacy PowerPC support. libffi still ships PowerPC sources, but they're no longer included in OS/X builds, because Apple stopped supporting PowerPC with OS/X 10.6 (released in 2009; the last PowerPC Apple hardware was shipped in 2006). As a result, it's difficult to find compilation instructions, and even harder to find actual hardware to test builds. If support for PowerPC architectures (on OS/X) was deprecated, this would make merging the libffi_ios and libffi_osx a trivial activity.

* I've audited plat_ios/IN.py, and can now confirm that it *is* identical between platforms.

* I have looked into replacing Setup.* with some sort of post-configure procedure as suggested by @doko. Unfortunately, it's not that simple. The problem is that there is already 2 places where the build requirements for a built-in module are defined. Modules/Setup contains one set of instructions (although those instructions are often commented out). The second set is hard coded into setup.py. 

The versions in setup.py are probably more reliable (as they're the ones actually used for most platforms), but you need to have a working Python to access them. However, at the "post-configure" point, you don't have a working Python, so there's a bootstrapping problem.

I've refactored the Setup.ios-* definitions so that there's less duplication. There's now a Setup.embedded that contains the common build instructions for all the modules without platform-specific build instructions. Setup.ios-* just contains the platform-specific build instructions (in much the same way as setup.py has configure_ctypes_darwin).

To work around this completely, we'd need to either introduce the need for a bootstrap Python so that a post-configure setup could access the build instructions contained in setup.py, or massively refactor the process of building modules so that there was a set of build instructions that both makesetup and setup.py could use.