Fat OpenSSL

You don't want to. You definitely don't want to combine the simulator binaries with the native ones. Nor do you even need to bother with i386. I'm not as confident on iOS platforms and binaries, but you really have only 3 left. It is not like you need to build these things on a regular basis. Just lipo them together once and you're done.

Thank you for your reply. I've looked at the lipo man page, but I'm at a lost on how to use - create in this case. As you suggest, I'll focus on iPhoneOS11.4-arm64.sdk, iPhoneOS11.4-armv7.sdk and iPhoneOS11.4-armv7s.sdk, but each one of these has an include and lib subfolder which contain libcrypto.a and libssl.a.

This is my first attempt a creating a fat OpenSSL binary. Do the header files in the include subdirectory need to be included when using lipo? I can't find anything about this on the internet. My experience using Terminal is limited. Can you point me towards a source of information or list the steps to create the fat binary? Thank you.

lipo just operates on object files. You can run it on static libraries or executables. But you have to run it on the lowest-level files, not the top-level bundle, and not any include files. When you run lipo, you can specify the full path to any input files and put the output wherever you want.

But include files are a completely different thing. If you have some code or 3rd party framework that links against those libraries, then you can just link to a fat binary and be done with it. But if you need to compile your own code (or some code generated by a 3rd party product), then you have to be really careful to use the proper incude directories. Those can't be lipo'ed together. Many open source projects are built using autotools and the headers may be platform and architecture specific. This can complicate matters when Xcode is building a universal binary, but you have header paths that are different for the different architectures.

Maybe take a step back and ask why you are doing this. This is advanced stuff. Is there an easier option?

Thank you for your patience. My only objective is to implement on-device receipt validation for iPad(4th gen. A6X chip) through iPad Pro (A9X chip) using openssl-1.1.0h. My app works fine with the A6X chip (iOS 10.3.3). Excluding this chip would mean losing a considerble portion of the market. I've written most of the code for server-to-server receipt validation, but the on-device approach avoids some problems and costs associated with server validation.

I've noticed that the iPadPro uses the ARMV8-A chip. Does the iPhoneOS11.4-arm64.sdk cover the ARMV8-A chip? If so, I believe all I need are lipo instructions to create a fat binary for the libcrypto.a and libssl.a files in iPhoneOS11.4-armv7.sdk and iPhoneOS11.4-arm64.sdk.

I appreciate your time and help.

Perhaps I can help. Please email me.

(my email address should have been mailed to you as the OP if you are following this thread. I edited it out.)

Decoding the receipt on the device is the best way of assuring it is a valid purchase because the onboard receipt is signed with a device-specific UUID.

Now that Apple does not include a unique transactionIdentifier in each receipt (e.g. restoreCompletedTransaction and a repurchase) there is no way of assuring security. You can no longer reject a receipt with a duplicate transactionIdentifier because it could be an appropriate transaction.

Thank you for your reply. There is a green-colored checkmark atop the "Following" label at the top of my page, my e-mail address is correct, and I've reviewed "Using Email Updates" in the forums support, but I haven't received your e-mail.