I've had a query about developing an app for members of an association and I can't determine from the Enterprise Deployment guide if this is an appropriate method for deploying the app.
Members own their own devices, so can an enterprise app be deployed while allowing the users to continue to use their own Appstore logins?
At any point, do the devices have to be physically connected to a machine running iTunes that is owned by the association or can a provisioning profile be distributed via the web or email? I see that profiles found in certain directories (e.g., ~/Library/MobileDevice/Provisioning Profiles/) will be automatically installed, so can the profiles and the app simply be emailed to members?
The Enterprise Deployment guide contains a lot of instructions on locking down the device. Can this be ignored?
I've had a query about developing an app for members of an association and
I can't determine from the Enterprise
Deployment guide if this is an
appropriate method for deploying the
app.
Sounds right for the type of deployment you're talking about. Just be aware if you're have the enterprise developer account you won't be able to do App store deployment with the same account.
Members own their own devices, so can
an enterprise app be deployed while
allowing the users to continue to use
their own Appstore logins?
Yes, Appstore apps and enterprise apps can coexist on the same device.
At any point, do the devices have to
be physically connected to a machine
running iTunes that is owned by the
association or can a provisioning
profile be distributed via the web or
email? I see that profiles found in
certain directories (e.g.,
~/Library/MobileDevice/Provisioning
Profiles/) will be automatically
installed, so can the profiles and the
app simply be emailed to members?
You can get the app binary and profile to the members anyway you like. Snailmail a CD... stick a USB drive on a pigeon... As long as they have access to the iTunes they sync their devices with, they'll be able to install your app.
The Enterprise Deployment guide
contains a lot of instructions on
locking down the device. Can this be
ignored?
Not sure which guide you're referring to. Please include link.
You need the devices UDID which is included in the provisioning profile for the app, that allows that device to run the app
Related
How can I restrict a particular app from being installed via iTunes from device using Mobile Device Management or via other objectivec ways?
MDM has a feature to prevent installation of ANY apps. However, it doesn't have a feature to target (prevent installation) of some specific apps.
Apple's Mobile Device Management Protocol Reference states on page 44 at the bottom
Third-party enterprise applications require provisioning profiles in order to run them. You can use MDM to deliver up-to-date versions of these profiles so that users do not have to manually install these profiles, replace profiles as they expire, and so on.
To do this, deliver the provisioning profiles through MDM instead of distributing them through your corporate web portal or bundled with the application.
Does this mean that I should remove or unbundle the embedded.mobileprovision from the application before installation?
Or does it mean,
Installing the provisioning profile via an MDM server separately before installing the app?
If the answer is the first one, how does one remove the embedded.mobileprovision without breaking the app. If the answer is the 2nd, does subsequently updating the app mess up the profile installed by the MDM server?
Second one. The MDM server installs provisioning profiles on the device before installing the app. It's generally part of "setting up the device" with the MDM.
Installing or updating the app after that point would be done through the MDM, so everything stays hunky dory.
Updated provisioning profiles get put up on the MDM (by developer/admin), then the MDM app on the user's device notifies the user of an update. They tap the update button and the new profiles get downloaded and installed.
EDIT 3/12/14: Apple has introduced the Device Enrollment Program(DEP) which now allows for "no-touch" installation of MDM provisioning profiles, setting up supervision and silently installing apps without ever taking the device out of the box. The system is based around:
Company account buys all devices (Apple maintains list of which serial numbers belong to company/account)
Company tells Apple which MDM has permission to make changes.
Company links MDM to Apple.
MDM now sends requests to Apple, which sends requests to device.
This will allow us to only screw, er setup, devices we bought. There are ways to "switch" ownership of devices/serial numbers of they were not all bought under the same account.
Can anyone enlist the all deployment methods along with some description and requirements?
I know there are methods to use iTune and methods to avoid iTunes, you can use App Store or not, etc.
Four Options Plus the obvious webapp choice:
Developer Deploy: Deploy from XCode using the build and run function to a connected device. The provisioning profiles is only valid for a max of three months, and it's required to have the device connected to the computer to run. Really, only for debugging.
Ad-Hoc Deploy: Signed with a Ad-Hoc Distribution Certificate for up to 100 pre registered devices. Requires the UDID of all those devices perfor packaging. Can be deployed using either itunes on the device users computer of via a link that points to the right safari file. Check this blog for more info about ad-hoc install per Mobile Safari Parade of Raind
Appstore: Well, yeah. It's kinda, you know. Right.
Enterprise Appstore: Grab a Enterprise Certificate by apple, costs 300$, and you can do the same you can do with ad-hoc Deploys, but without preregistering the devices. However, you're only allowed to use this method for In-house (inside the company) deployments!
Try this:
[PDF] http://manuals.info.apple.com/en_US/Enterprise_Deployment_Guide.pdf
http://www.airplaysdk.com/docs.php?url=/main/programmertools/mkbfilesettings/deploymentoptions.html
Quick deployment of an app after build without running
I'm trying to figure out more details on how apps are distributed to users when under the Enterprise developer program. The Enterprise Deployment Guide states:
If you develop an application that you want to distribute yourself, it must be digitally signed with a certificate issued by Apple. You must also provide your users with a distribution provisioning profile that allows their device to use the application.
What I want to know is how is the provisioning profile is created so that a specific device is allowed to use the app? Is this done by adding device UDIDs into the profile as per the standard developer program? Or some other means?
Provisioning profiles are managed thanks a website provided by Apple. It will be possible to generate and download Provisioning profiles from this website.
Then, if you sign an application with the Enterprise program licence, you will be able to install it on any device. You just have to send to the user your application and the provisioning profile.
Regards,
I was under the impression that when you use a development provisioning profile for a build of an app, only the specified developers can deploy that build to a phone.
But I just deployed a build that uses a development profile to a phone using Xcode Organizer, even though I'm not one of the valid developers for that profile. One of my colleagues, who doesn't even have Xcode installed, did the same with his phone using iTunes.
In that case, why not use a development provisioning profile for distributing your app to e.g. your QA team, instead of ad hoc distribution?
EDIT: Please read the part in bold carefully before answering. I'm not asking a basic "how does this work" question. I've made a lot of development, ad hoc, and app store builds, and now I find that I seem to have made some wrong assumptions.
There's one situation in which you need an Ad Hoc profile, and that's when you want to test Push Notifications.
If you test Push Notifications on a Development Provisioning Profile, your push notifications need to be sent using the Development Push Notification Certificate for your SSL connections to Apple's sandbox APNS server.
If you want to test Push Notifications using your Production Push Notification Certificate and the live APNS servers, you'll have to deploy your app to a device using a Distribution Certificate and Ad Hoc Provisioning Profile (which includes doing the Entitlement.plist steps, which you can ordinarily skip if you were only using Developer Provisioning Profiles).
Also note that when you deploy using an Ad Hoc profile, your device token will be different from the one you use when you're using the development profile. This the recommended way to test APN because there's no back end changes that need to be made between the Ad Hoc build and the final live deployment on the AppStore.
Ad-Hoc is not for developers, but for testers. Who do not have iPhone SDK / XCode, iTunes only.
(The answer is: you can install ad-hoc app without developer certificate, and can't do it with development app)
Method 1: Install from XCode
The Development Provisioning Profile requires you to run the app (initially) from within XCode.
This has the side-effect of marking the device as being used for development, but also requires you to connect the iPhone/iPod Touch to the machine running XCode. Once you run the app from XCode, the app is installed on the device and you no longer need to be connected to the machine to run it. (Until you want to update the app.)
Method 2: Install from iTunes
An Ad-Hoc provisioning profile allows you to give the app to anyone and let them install it themselves using iTunes. You send them:
the app, and
the Ad-Hoc Provisioning Profile
They select these two and drag them onto iTunes. Then sync.
Later, you can give them an updated version of the app only (without the Ad-Hoc Provisioning Profile, since they've already installed that on their device) and they can drag the new app onto the iTunes icon to install the new version.
One limitation to Ad-Hoc distribution, is that it requires you to enter each Device ID into the iPhone Development Portal. And there is a limit to 100 device IDs per year (you cannot erase any IDs, until your next year begins -- only add them). The 100-ID limit will not be a hindrance for most developers, just keep in mind that you need to get the device ID ahead of time, before you create the Ad-Hoc Provisioning Profile to send to the person you want to install your app.