Database Reference
In-Depth Information
You can use Enterprise licenses solely for in-house distribution, but inside of that
limitation they are very flexible. You can even use tools like Testflight to distribute
Enterprise-signed applications, or set up your own web server with the appropriate
meta-data to let your users download them directly in-house. Of course, you can also
distribute it via email and iTunes, the same way you can distribute Ad Hoc binaries.
A Gotcha With Enterprise-Based Development
One problem you're almost certainly going to run into while using an Enterprise license
to do beta-testing of apps you plan to deliver to the App Store is
key interference
. If
you've done enough iOS development, you've almost certainly run into issues where
you had an old, stale provisioning profile hanging around or multiple copies of your
development key in your keychain, and you couldn't sign your app because XCode
complained.
This problem comes home to roost if you have both an Enterprise license (which, re-
member, you can't use to sign apps for the App Store) and a normal distribution license.
The problem is that they will be signed by different keys, but the keys will both have
your organization as the name of the key. This confuses XCode, which thinks that you
can only have one key at any one time assigned to a given entity. The solution to this
problem involves creating multiple keychains using the Keychain Access tool, each one
of which has the key and certificates for the Enterprise or Distribution profile, but not
the other. You also need to make sure that neither key or certificate appears in the login
or system keychains.
Another issue is that you can't use the same bundle identifier for both builds, because
Apple won't let provisioning profiles for different developers share the same bundle
identifier. Unfortunately, Apple requires that you use two entirely different developer
accounts for the Enterprise and App store profiles. You need to work around this by
dynamically changing the bundle identifier based on the build type. I have specific build
configurations for each (one called App Store, and one called Enterprise). You can see
an example in
Figure 7-6
.
I create a user defined variable called
APPLICATION_BUNDLE_IDENTIFIER
, with different
values for the different build configurations (
Figure 7-7
). Having done this, you can
now use a special hack to create both Enterprise and App Store builds. You need to set
Expand Build Setting in Info.plist File
to
Yes
, as well.
Now, in your app's
info.plist
file, change the
Bundle Identifier
to
${APPLICATION_
BUNDLE_IDENTIFIER}
(shown in
Figure 7-8
). Now, depending on whether you specify
the App Store or Enterprise build configuration (which is available as a parameter in
xcodebuild
), you will get a different bundle identifier.
