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.

Bundle Naming

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.

Signing

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.

Enterprise Apps

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

Send an email to our support address with a link to download the ipa.

Entitlements

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.

Tips

  • 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.
Did this answer your question?