How to verify App certificate at runtime?

I saw that we can receive some useful information from embedded.mobileprovision. However, it looks this file does not exist when we install app from AppStore.

That’s correct. A profile is not needed when deployed via the App Store because your app has been re-signed by Apple. Remember that a provisioning profile is only necessary to allow third-party code to run, and the App Store applies all the necessary checks before it re-signs your app. See TN3125 Inside Code Signing: Provisioning Profiles for more background on this.

Is there any way to verify Developer certificate … to make sure that the App is installed from correct Developer account?

Not in any supported fashion.

I am asking a solution to project my application is stolen by re-compile source or something like that.

You need to think more clearly about the thread model here. If someone is re-compiling your app from stolen source there’s no point adding code to check the app’s integrity because the attacker will just remove that check. They have your source code after all.

With regards other threats, “something like that” is kinda vague. Most folks who ask about that are worried about the app being run on jailbroken devices devices with unauthorised modifications. What we recommend in that case is App Attest. See Establishing your app’s integrity.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks @eskimo for quickly response and your suggestion

Do you have any idea to avoid re-compile from IPA or APP file as you mentioned on jailbroken devices. Is there something like HASH key and it will be changed if be re-complile?

avoid re-compile from IPA or APP file

The .ipa file etc. do not contain the app's source code, so the app cannot be recompiled from that.

It can be modified in other ways, though, so...

Is there something like HASH key and it will be changed if be re-complile?

That's what AppAttest does. But it's only useful if your app has some sort of server communication, i.e. the app sends an AppAttest-signed request to your server, which can check it. If there is no server communication it doesn't help. Note also that AppAttest is not supported on all devices, specifically if an iOS app is run on a Mac in "made for iPad" mode AppAttest is not available. Apple tells us that an AppAttest failure is just a factor that we should take into account, not a definitive yes/no. Which makes it much less useful than it would be otherwise.

Fundamentally, my advice has always been to avoid app types / demographics where piracy is a problem. There was a great Dilbert where he says "We will be targeting this type of customer..." and he is pointing to a chart where it says "Rich/Poor", "Smart/Stupid". If you can come up with an app that rich stupid people will buy, they will neither be motivated to pirate it, nor will they have the skills to do so.

The other bit of advice is to avoid apps where you actually have costs associated with pirated users, i.e. server costs or royalties that you pay to third parties. If you have royalties to pay, make sure that your contract only requires you to pay royalties for legitimate users. And try to ensure that your server costs are either fixed, or minimal.

endecotp has addressed the main thrust of your question but I want to specifically address this:

Is there something like HASH key and it will be changed if be re-complile?

As endecotp mentioned, recompilation is not a concern here. However, I want to be clear about something: If you try to take a hash of your program before you upload it to the App Store and then check that hash at runtime, you will run into problems. While the App Store doesn’t recompile your app, it does re-sign it, and that will change any hash you calculate.

In the past folks have attempted to get around this by only hashing parts of their app, but that generally doesn’t end well:

• There’s no supported way to determine which parts to hash. The App Store reserves the right to modify your binary at will, and they don’t document how they do that.

• Even if that weren’t a problem, you still have the issue that, if the hash doesn’t cover the full app, it doesn’t offer complete protection.

This whole strategy of checking hashing on your own binary is a non-starter IMO.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"