If a third-party is creating an app for you then it needs to be resigned with the correct certificate and profile for your account.
Code signing your app assures users that it is from a known source and the app hasn’t been modified since it was last signed. More info at apple.com.
Each app requires a unique bundle ID, which is a reverse domain identifier for the apps. For example if we had a support app it could use: com.ocasta.support for the App Store or com.ocasta.internal.support for an enterprise app.
If this doesn't match an existing convention we may require it changed - it's worth discussing before the final build. In some cases we may allocate this for you.
Important: do not add the bundle ID to your Developer Portal which makes it unavailable to us! If you've done this in error (Xcode can enthusiastically do it for you) please delete it from the Developer Portal.
Although the app will be resigned, it still requires a valid signature to be built correctly. We recommend using a wildcard developer certificate and the Release build configuration. Perform an Archive then deliver the app to us. Depending on whether it's an App Store app or Enterprise app follow the process below.
App Store Apps
If your app is being distributed through the App Store please supply the app as an Xcode Archive. This includes any symbolic links to support the App Store's crash reporting and allows a seamless resign and upload flow.
For each updated build through the App Store, including TestFlight builds, the build number needs to be incrementally bigger.
If your app isn't going to the App Store but being deployed directly to staff devices (for example, through an MDM) it's preferable to receive the developer signed app as a .ipa file.
Supplying the App
Upload the app to us through the App Resigning form. Put a note in with the name of the app and client if it's not obvious.
Let us know if your app uses special entitlements such as push notifications or iCloud and if you're storing data securely in the keychain as this will require a different provisioning profile to be created.
- Ensure the product name and executable name as this can sometimes appear when the app is installing (especially for Enterprise builds).
- Make sure all variants of app icons are included in the app bundle.
- If you're planning to test the app through TestFlight or need a live and enterprise install let us know as this could require two build configurations.
- Make it clear if your app is built with a non-standard tool, such as Xamarin or Cordova. These tools bundle the apps differently which requiring a different resigning approach.
- For app's that aren't built with the latest version of Xcode let us know.