I have posted this question on SO since I think it is the most logical place to find people with a lot of experience with the iOS Enterprise program.
For my company, we are developing an in-house app. We would like to deploy this app with the minimum effort required on the user's side <1>, as it should be possible to quickly install it for incoming colleagues. Additionally, we can't always guarantee an up and running internet connection at install time <2>. The in-house app is to be downloaded on our premises from a webserver through wifi.
We are currently not enrolled in the enterprise program, as we're investigating whether or not our goals can be realized.
As for <1>, what we've found is that UDIDs are not necessary to include in the provisioning profile for enterprise deployment. What is needed, is a provisioning profile. Now, here are my first concrete questions:
are any additional steps necessary before a provisioning profile can be installed?
can the provisioning profile be embedded within the app as can be done for OTA betas? This would save a user the step of installing the profile.
For <2>, the following issues come to mind:
here it states that access is needed to ax.init.itunes.apple.com and ocsp.apple.com. The former for querying the max allowable GPRS app file size. It doesn't sound relevant when your goal is to distribute over wifi, but the page says "If this site isn’t reachable, installation may fail." so it does concern me a bit. The latter one seems less severe as it is stated that "Inability to contact or get a response from the OCSP server isn’t interpreted as a revocation", which means that it should be possible to not contact this server right away.
I'm assuming that I can use any URL scheme to point to a local server that provides the app bundle and that there are no restrictions on server configuration.
Summarizing the two: is it possible to install an in-house app from a local server without a functioning internet connection?
Thanks for the help; it's greatly appreciated. As I have no prior experience with Enterprise deployment, it is tough to be confident that I'm not missing out on the nitty gritty details in Apple's documentation.
Provisioning profile can be embedded.
Your employee's devices requires internet connection when they are downloading the app, so that the device can contact Apple servers you mentioned.
Related
EDIT: see conclusion at the end of this post.
First off, let me clarify I've found a few similar questions/answers on SO, but none that apply to my particular situation. The one that came closest is this one but it doesn't address the AirWatch aspect.
So I'll try to be very specific.
Background
I have an iOS application that's free. I also have the same app for Android and Windows 10 but those are not my concern.
The iOS app is available to anyone from the App store. But I have a few large corporate customers who use AirWatch to manage the installation/update cycle of their devices. They either have Enterprise or VPP Apple accounts. They want me to provide them with the IPA file so they can distribute it themselves through AirWatch.
In my mind, that's a perfectly legitimate request: they just want to have better control over what gets installed on their devices.
Problem
From what I understand, an Enterprise account requires that the application be signed with the customer's certificate. But if I have several such customers, that means I have to re-sign each application for each customer, every time I have a new update available. And those customers that have VPP accounts cannot use them because the VPP program only applies to paid apps, not to free ones.
Note: keep in mind that at that stage when I'm ready to provide the app to these customers, the app has already been reviewed and accepted by the App Store. So it's deemed legit.
After googling this matter for a while, I know it's possible for someone else to resign an app or to sign it for the first time if it is provided in unsigned form to start with. However, resigned apps are apparently not supported by AirWatch (and, I assume, other MDM's as well).
If that information is incorrect, then I guess all I would need to know is the recipe that I, as a coder, have to follow before providing the app to my customers and what kind of steps they have to take in order to deploy using AirWatch.
Question
So how do I get my free app to my customers so they can manage the distribution themselves, without me having to go through yet another set of hassles every time I change something.
Remember: if I only had a single corporate customer I wouldn't give it a second thought and I would just use their own certificates but I have several potential customers with the same requirements, so the point is to make it easy for all of them and for myself.
I hope my question was clear enough, thanks in advance for any help.
EDIT - Conclusion: I was able to validate that an unsigned IPA file can be signed with the customer's certificate and uploaded to their AirWatch distribution app. Which means I simply have to provide the unsigned version to any customer with the same issue and they will be able to distribute the app themselves with their MDM. Hope this information helps others.
If your customers really can't re-sign your IPA, I believe the best solution for you to do would be to sign up yourself for an enterprise account, then use your own enterprise provisioning profile to sign a single ipa for distribution to the companies that need the app. Their MDM platforms should be able to handle the "trusting" of your enterprise signing identity, so the experience for the end users would be no different than if they were installing and running one signed by their own enterprise account.
The downside of this is that you will then be on the hook for providing your customers new versions when your cert of profile is about to expire. If you have them re-sign your IPA, it would be their responsibility to keep track of that and resign / redistribute a new provisioning profile when they expire.
Also, I have never heard of any restrictions on MDM's distributing re-signed IPAs. I don't even understand how they could prevent it, as a properly re-signed IPA should look no different than an IPA that was build and signed using the new signing identity and profile. I would challenge that, as many MAM (Mobile App Management) vendors offer wrapping of apps that do re-sign the binaries and allow you to distribute those resigned IPAs through MDM systems. I would really expect any corporation with Airwatch to know how to resign an IPA using something like iReSign. That really is your easiest option. Build an IPA for each release, send it out to all your clients, and each can re-sign it with their own signing identity. That way if you stop doing development, they aren't reliant on your signing identity and profile to keep the application running.
because the VPP program only applies to paid apps, not to free ones.
You can manage free apps with VPP. It's maybe free but it's still a license. VPP manages licenses for an organization and allows admins to give and tack back these licenses.
I have right now free Apps in my AirWatch Console, in the tab "Purchased". This tab is only available if VPP is configured and displays only apps from the VPP. I can't go check in the VPP myself because I don't have any access but theses free apps wouldn't be in the tab "Purchased" if they weren't bought with the VPP.
They want me to provide them with the IPA file so they can distribute it themselves through AirWatch.
If you are ready to do that, your customers can upload the ipa file as an internal application and then deploy it to their iOS devices. As AirWatch customers, they should have access to the document VMware AirWatch Mobile Application Management (MAM) Guide with the Chatper 4 "Internal Applications". There is a particular process for iOS apps described.
Multiple websites offer the possibility of downloading app(s) directly from their site, without the use of the App Store (emu4ios.net, iemulators.com, gba4iosapp.com).
By following the guidelines provided on these sites, the app will be downloaded and installed on my device.
My question is, how is this achieved, and how may I accomplish this with my own app/website?
You need an enterprise certificate. And as soon as you do this, your certificate will be revoked. However if the user sets their day back before the certificate was revoked the app will install properly.
Please note, enterprise certificates are expensive, and its probably better you buy the normal developer package.
I know questions like this one have been asked over and over again but I couldn't find an answer that goes straight to the point.
I have seen guides that seems to allow you to distribute your app OTA without having to be part of the Enterprise program.
I also have seen some tricks where, if you don't have a SSL certificate in your hosting, you still can use dropbox to configure your "links". (Enterprise app deployment doesn't work on iOS 7.1)
In summary I have used dropbox as it was indicated in one of the answers I found before and it totally worked. The problem is that I tried to test it in a different device and it didn't work (typical message
Unable to Download App. xxxx could not be installed at this time.
I'm signing the app using a distribution certificate and I'm using a provisioning profile for distribution:
I know it can sound pretty obvious that all that is meant to work only for the AppStore or ad-hoc distribution (this last one requires to collect all devices UDID and it's not what i'm looking for).
I would like to know if it is definitely possible or not to distribute my apps "in-house" without having to be part of the Enterprise program. If true... what I'm doing wrong?
Note: the guide you link to is not for in-house app distribution. That blog post is about ad-hoc distribution without using iTunes. It's not about not having to provision your devices or getting around paying for the Enterprise program.
It is possible, but it still requires the business to spend some money.
If the business is enrolled in the Volume Purchase Program then you can identify them as the authorized purchaser of your Business 2 Business app when you submit it to the App Store. Regular customers won't see it.
Unfortunately, Apple does not say up front how much it costs a business to enroll in the Volume Purchase Program (I'm guessing that it varies) so I don't know if it's cheaper than the Enterprise Program.
I'm in charge of developing an application for my company. It'll only be used by my company. I found the Enterprise Program.
I read
iOS Developer Enterprise Program
but I also read something about MDM iOS that I need to implement.
Is MDM needed to distribute my app? Also, how will my coworkers be able to download the app? How does Apple know they are authorized, and not some random guy who found the link on Google?
You don’t need to do MDM for the enterprise program as far as I know. As for preventing people from downloading the app, I think you just have to keep the link private, or put it behind a URL that can only be accessed on your company network or VPN. And of course, require login, so someone can’t access your internal information just by downloading the app! Presumably, Apple will revoke your enterprise privileges if they find you are abusing them.
Source: I worked at a company that used enterprise distribution for internal beta distribution, among other things.
One of my clients has 30 iPads that are used with an in-house developed app. The "Ad Hoc" distribution model is easy to implement if the number of deployed devices is less than 100. This approach is sometimes described as a "Beta test" approach, but that's just one common use for it.
See these pages:
https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/TestingYouriOSApp/TestingYouriOSApp.html
Ad-hoc Deployment
All:
My employer believes they have a legal loophole to distribute Enterprise signed apps to our customers, but I'm uncertain it will be technically feasable. ( We are in the infancy of IOS in our enviroment)
"Internal Use Applications developed under [the Apple Enterprise Agreement] may be deployed on Deployment Devices in two ways: (1) deployment for internal use by Employees, and (2) deployment for use by Customers either on Your physical premises or under the direct supervision and physical control of Your Employees in other locations, subject to Apple’s right to review and approve such deployment as set forth herein. The App Store approval process is not required."
In our case, it is true -- customers will be on our remote physical site. (Personally, I believe clause 2 is really intended for corporate-provided devices to a customer -- think museums, etc, or contractors, and that even if this is a loophole, is one that is likely to be locked down. But that is moot for now.)
Our location are without cellular service is not available, AND where we provide the only available Wifi which is restricted to our intranet-- we do not allow not customers free internet access, except at very expensive cost to the customer which we do not wish to do here). So, the idea was to locally host the app (IPA) and profile in our local LAN, have the customer install a Enterprise provisioning profile, and then install our apps from a local source.
So my question is if this TECHNICALLY feasable --- Is is possible to install a povisioning profile over the air (Wifi) WITHOUT calling back to Apple?. And if so, can a Enterprise signed app also be installed, again without calling back to Apple. Does an end user get anything more scary than a "Do you want to install MegaCorps Enterprise Provisoning Profile on your device"?
You can allow for installing apps from a secure web page. Just follow the directions here:
https://developer.apple.com/library/ios/#featuredarticles/FA_Wireless_Enterprise_App_Distribution/Introduction/Introduction.html
It's in the section In-house apps > Deploying apps > Installing apps wirelessly. Apple doesn't say anything about needing to add individual UDIDs to the provisioning profile. I think they don't want to make a big deal of it lest misuse becoming rampant.
I don't have any legal advice, though.