We are already signed up with an iOS Developer Program. Now is it possible for us to sign up for an iOS Enterprise Program?
I am asking this because when we develop apps we need to install the app to multiple iPhones/iPads for testing purposes. Since the developer program has a limitation of 100 UDIDs, we are thinking of using an enterprise program to distribute the test builds.
Any advice is appreciated. Thanks in advance.
Yes, you can have both.
We are in the verification process of an Enterprise account currently - the main registration difference is that your company will need to have a DUNS number. (Dun & Bradstreet)
Our application has been in limbo with Apple now, as the DUNS we supplied was not listed on their database - Apple use a particular dataset which only lists organisations that have published financials, so if your company has not done this then you should inform Apple of this during the application process, so that they look you up in the correct database.
Good luck!
i dont know how big of a company we are talking about, but are you sure 100 devices that can be tested on arent enough?
the eneterprise programm is normally for apps that are just developed for the company itself and that will never go onto the app store..
but otherwise if there is a need for a lot of testers it should be possible
i myself never was part of the enterprise programm so you should probaly wait for some more opinions anyhow^^
I'm thinking to do the something, and just get done talking to apple support yesterday. If you want to join both program, you will need difference Apple ID, which is easy to do, just sign up with another email address.
And the enterprise program is used for in-house app only which means you are not supposed to test the app on devices not belong to the company or employees of company.
The enterprise account is definitely not suitable for this.
The enterprise account is only for companies distributing apps within their own company. The account terms say that you are not allowed to distribute outside your company at all, and you are responsible for this. Within your company, you can do what you want.
I'd also check if the testing terms have changed during WWDC.
Related
We're developing an app for an enterprise customer (approx. 1500 of its users are going to use it). At the moment the most likely way we're going to charge them is on a per-usage basis (every time an employee uses the app, we get a small amount), so it's important that the app is distributed only among employees. I'm considering using iOS Developer Enterprise Program ( https://developer.apple.com/programs/ios/enterprise/ ) or releasing an app via a regular iTunes Store with some basic marketing functionality and then letting users to log in and use the real functionality the customer is paying for.
Edit: perhaps the B2B Volume Purchase Program ( https://developer.apple.com/programs/volume/b2b/ ) is the answer?
Are there any other possibilities?
What's the most convenient way of distributing such app?
If I go with iOS Dev Enterprise Program, who should create the account? Us or them? (I'm betting the latter).
I'm pretty sure your per-usage model is against Apple's Ts&Cs in any deployment space (B2B, App Store, etc). I'm also fairly confident that deploying through the App Store will get you flagged eventually when they dive into your code. Either of those deployment models is going to get you shut down and your Enterprise Cert revoked if they ever catch on. Either way you likely want to have someone fluent with legalese look at what you're attempting to do.
The point of using B2B to circumvent the App Store is to allow you to provide a private deployment of an app at a minimal cost without supplying source code. To that point the customer should be the one maintaining the Enterprise account. You would join their account as a Member, compile the code using one of their dev certs and dev provisioning profiles, supply the customer with the .XCArchive file and they can re-sign it with their Enterprise Cert. It's a pretty streamlined process.
The Enterprise Developer program is convenient because you don't need to go through the store review process. Just put up new builds for installation from your own www site. The enterprise whose employees will be using the app needs to get the license. They will need a DUNS number and the application process may take a week or so. They may get a phone call from Apple to verify their intentions and eligibility.
I was asked to do a recruitment app that will recruit people for the company, so of course it will be free. When I released it, it got rejected for being very basic.
Now the client want to just release it through their site if apple don't want to accept it.
I know how to create the .ipa file through adhoc disribution which is what I use to give them copy and test it by putting it on a test site so that they can download it on their iphones.
But this is only for testing purposes, only the phones registered as devices on the dev account can download the file successfully.
So is it possible to release an app that will be used by users successfully without submitting it to apple?
With an Enterprise account you can more or less host your own private app store for an unlimited amount of devices and distribute in-house without Apple.
With a Developer account you can run ad-hoc installs via TestFlight or comparable services for up to 100 devices.
The new iTunes TestFlight integration announed at WWDC14 allows for 1000 devices.
The only solution that will look truly professional is the Enterprise App Store and it requires you to have a DUNS and an approval from Apple, but generally with a DUNS you're set. It's $299 instead of $99, but that's not so much money for most companies that have a DUNS. Also you can't use that account for publishing apps to the public App Store.
In general, yes it is possible: you can release an enterprise app outside the app store, provided that your company has the requisite enterprise agreement.
However, this is intended for internal use, and while I haven't read the agreement myself, I believe that distribution to the public at large would likely be in breach. (EDIT: As Zaph points out, this is in fact explicitly disallowed.)
The situation you're describing would fall outside this.
Moreover, from a user experience standpoint, it's unreasonable to expect prospective employees to download an application from outside the app store.
This is not only technically difficult for a lot of people, but it would look incredibly unprofessional, which is the opposite of what you're after in a recruitment app.
No. Apple restricts the apps available to users only to those on App Store.
(Actually, not 100% true - you could release the app on Cydia and target only jailbroken phones, but I suspect this is not what you mean to do.)
Alternately, make a web application, using JavaScript/HTML/CSS. Anyone can use a web application, it can be installed on the launcher screen, and it does not require App Store, just a web server somewhere. If you need persistence, you might also want to look into manifest files and offline apps. Especially if your app is basic, you can make it look and feel almost as a native app using one of the very nice web frameworks such as jQuery Touch.
However, you might just leave it as a webpage - why would you restrict your recruitment pool only to people willing to install your app?
tl;dr: You can't release an ObjC app except on AppStore.
There are already multiple answers to this question, probably because it is not specific enough.
Let's gather all the information that's necessary here:
If you want an app for a company (given that you recruited people through the app, i.e. people who used the app would join the company), you should use the Enterprise Program.
If the app is meant for the general public (in this case, possibly, you would like the app as a branding, promoting app for the company), you cannot use the Enterprise account, since it violates Apple's terms. As an example, see this funny case: http://www.imore.com/how-gameboy-emulator-finding-its-way-non-jailbroken-devices
AdHoc and TestFlight should not be used for a release app. AdHoc only is meant to be used for testing purposes. Introducing non-developer related devices into your AdHoc profile would mean termination of your dev account (e.g. this aggressive and also funny case: http://www.intomobile.com/2012/07/09/apple-goes-after-sites-selling-activations-ios-6-beta/).
Finally, two interesting notes:
There is no limit to the number of devices in an Enterprise Program app. It's not 1K, at least the information out there says the opposite (e.g. the case with the link in 1). The 1k device limit will be for beta testers with TestFlight (according to http://www.neglectedpotential.com/2014/06/testflight/).
An Enterprise account cannot publish apps to the public on the AppStore (see this FAQ: https://developer.apple.com/support/ios/enterprise.html -if it doesn't work, you can load the cached version from Google, etc.). Thanks to Departamento B for this information I didn't know about.
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
I've built an application that my company owns the code to.
One company wants a slightly modified version of this app (branding mostly) to distribute internally (using https://developer.apple.com/programs/ios/enterprise/).
I'm also going to sell it thru the ordinary App Store.
Would I run into any issues here? I can't find any information regarding that this somehow wouldn't be allowed, but I don't want to shoot myself in the foot here either...
Any insight out there?
Thanks!
/J
Simple answer NO.
As far as Apple would see it - they would be two completely different applications. Each one would have a different App ID and a different provisioning profile.
You will however have to purchase an Apple Enterprise Developer license if you want to distribute through the Enterprise program.
Here is a link to some commonly asked questions about the Enterprise Program
If you have anymore questions just ask.
There's no conflict here. The only thing is that you'll need different provisioning profiles for each build and you'll need an enterprise developer account to create the enterprise build. Other than that, there aren't any issues.
A Mobile Operator needs to distribute an app which is using private APIs onto non-jailbroken devices.
From what I've read everywhere so far, this is not possible.
Just out of curiosity: Enterprise Developer Program is reserved for apps that are distributed within the company only and is used by employees or contractors, but how would Apple find out if the user is an employee or just some random iPhone user?
Of course, if the number of customers grows big enough, Apple will notice that some day, get suspicious and shut down the enterprise developer account.
But, suppose, the app is used locally (only in a few countries) and on not that many customers (say, in order of tens of thousands or hundreds of thousands), is there a way Apple could find that out? So, what I am wondering is if there is anything measurable on the device or in the app that signifies the user as the employee of the app developer. I doubt that.
Thanks!
Technically I don't think Apple has any way of knowing on which device an enterprise app was deployed and what it actually does. Also I don't think Apple would be a lot concerned if you deploy an enterprise app in a few non-employee devices. They only want to ensure that you don't use the Enterprise license as an alternative distribution mechanism for iOS apps.
According to me the following would be the drawbacks of attempting such a thing:
1) If the distribution to non-employees reaches high levels and this
comes to Apple's knowledge(through a disgruntled employee maybe), it
is more likely that they would take legal action against the
enterprise(apart from shutting down the account), causing loss of
money and loss of face.
2) Enterprise distribution certificates expire in 1 year(even the
in-house ones), so if your really start an alternate distribution
mecahnism using an enterprise license, you can imagine how difficult
would the after sales support be.
3) Of course ethics is a matter, if you take that into account :)
You are correct that the Enterprise Developer Program allows to deploy apps within a company and its employees only.
However, Apple is not (yet) intervening if you offer your Enterprise signed app to the public although it technically able to (see the "kill switch" comment above).
One example is the app provided for download at http://www.featurepoints.com. The app installs a provisioning profile named "TapGen InHouse" expiring 2014-06-30, effectively skirting the App Store and Apple's approval process.
So either Apple can not tell random customers from employees or they just don't care (at least as long if you are below a certain threshold).