My company has an Apple Enterprise Account, which we have used to deploy apps to employees using an MDM. Works fine.
We are developing an app with an outside developer. This app probably will be put in the App Store.
I generally understand the difference between Enterprise and Developer Accounts.
What I don't understand is the need to have 2 separate accounts? I cannot link my Ent to a Dev account? I have to maintain two separate accounts?
Our outside developer wants to use Test Flight for testing, which is fine by me, but we are just starting internal employee testing, so I want them just to send me the archive and I will distribute it internally using our MDM, until I can figure out if we can just "extend" our Enterprise account, and or we want to use Test Flight.
What is best practice regarding this?
The best practice is to decide as early as possible how the distribution of the app will work. If it is truly an internal app not intended for the App Store, then use your Enterprise account. If it is likely to be put into the App Store at some point, then use the normal non-enterprise account and TestFlight for pre-release builds.
It can be an involved process to later transfer the app from one account to the other and may involve intervention by Apple, or changing of the bundle ID. It's best to figure this out ahead of time and put the project into the proper account.
If using your MDM is an absolute requirement, you may be able to create an additional target within the project to use the enterprise account, while the main target uses the non-enterprise account.
Another advantage to using a non-enterprise account and external TestFlight builds is that your app will go though quick, periodic reviews by Apple which can catch many errors before submitting the App Store release candidate.
Related
i have some doubt to how distributing for clients that have an Enterprise Developer account works.
Here is the situation:
-My company have its own developer account (normal one not enterprise).
-My client wants to distribute an app using their own account.
-My company have to develop this app.
Now, how do i setup my xcode for this? Which solution is the best? Should i use directly the clients account or there is a way in which they add my account as developer in their team?
I'm concerned about this because i'm going to use my company account to test this app on devices during the development and xcode , to me, is pretty hard to understand when it comes to change certificates and accounts.
Thanks a lot.
As Alessia already wrote the easiest way is to build the app with the enterprise certificate of your customer. For that your customer has to provide you the private/public key pair or give you access to their enterprise program so you can create and download it.
If your customer do not want to provide it to you (maybe for security reasons) there is another way. It's more complicated especially if your customer has no experience with iOS development. In that case you have to develop and test your app with your own developer program. If your release version successfully passes your quality tests you deliver it to your customer and they need to resign your app. see: example for resign
i think the easiest thing is to make the build with the certificates in enterprise.
So you should ask identity and mobile provisioning created from enterprise account of your client, and then build your app with this certificates.
Your client can also enable (in developer mode) your apple account so you can create yourself certificates (in enterprise).
You can also create multiple target for this management.
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.
There has been a lot of questions on this already that answer some of my questions. I am looking for someone who has direct experience with setting up and managing both accounts.
I have a situation where I need to send a private Beta test to more than 100 people (the ad-hoc device limit for iOS), but I still want to be able to publish publicly to the app store.
My solution is to obtain both an enterprise account and a regular developer account. The enterprise account allows me to distribute to anyone within my company, privately with no limit. The regular account gives me the ability to publish to the app store. Unfortunately this means I have two create two different apple developer accounts.
I am worried about the hidden caveats that are involved with this process.
Is there any caveats with managing two separate apple developer accounts for the same application?
Any problem with packaging names for applications? I'm assuming the identifier needs to be different.
I hear that you cannot test the storekit with the enterprise program. Any other problems similiar to that?
I have experience with managing both Developer and Enterprise a/c. We have multiple applications in appstore. We mainly use the enterprise a/c for testing and developer's a/c for publishing the application to app store. This has worked fine for us for more than a year now.
That being said, managing two accounts is cumbersome. I have no idea why Apple won't allow us to create App Store distribution profile using the Enterprise a/c! Here are few recommendations:
Choose the names of the accounts so that you could easily distinguish them e.g. "xxx developer" and "xxx enterprise".
It is possible to create the developer and ad-hoc distribution profiles in both the accounts. Overtime it can become messy especially if you have multiple developers and applications. So I would recommend forming some guidelines for the accounts usage beforehand.
You can use the Wildcard App Id when creating the distribution profile. So you can avoid changing the Apple Id for the same application in these accounts. However, if you use Push Notifications and/or In App Purchase then you will have to use explicit App Id, and App Id needs to be different in each account.
We are developing an app specifically to a single customer's requirements and want to put it in the hands of their evaluation team (3 people) as we go along. Before we release the product, we'll be going with enterprise distro but we need to figure out this interim step.
Get an iOS developer account for $99 and register the devices of those three people to your account.
I use a company called testflight, they are at testflightapp.com They make it pretty easy to distribute an application to testers when you have an ios developer account.
At my company, we have the customer sign up for the $99 developer program and manage their own devices, then have them add our developers as developers (surprise), and make special builds for their devices.*
We also recently had a (larger) client sign up for an enterprise account so they could distribute our builds to their employees for testing w/o having to manage UDIDs.
Takes the ball out of your court, but it does seem to adhere to the Apple standards.
*: We frequently end up releasing these custom builds to the app store via the customer's developer account, which (IIRC) is also in line with Apple standards. If the app is branded by/exclusively for a given company, it makes sense.