We have an application which will be used only by customers nationwide and for this reason we do not want to put the application on appstore. Shortly we want to publish it on one of our servers like a zip file then the customers will connect to that server and download the application. Yesterday when I called to apple support, one of the customer represantatives said to me that this is not possible even if we choose the enterprise license. But today I found a link which it says it can be possible. http://developer.apple.com/library/ios/#featuredarticles/FA_Wireless_Enterprise_App_Distribution/Introduction/Introduction.html
Now, I want to know that is there anybody had same problem in here? What are the differences between enterprise license and company license? And the most important is that how can we do what we want to do if it is possible?
It's not officially possible.
You could try Enterprise distribution as others have mention, though it's not designed for distribution outside your company. I'm not saying it will happen, but if Apple find you're doing it they might close your developer account. I've never heard of that happening; only you can decide whether it's an acceptible risk.
Apple would say that you should put the app in the App Store. Unless Apple would reject your app I don't see why this wouldn't work. You don't have to make it easy to find and you don't have to make it cheap.
You can limit it to your customers by requiring a log in. Many, many apps do this, from Salesforce to Skype to Twitter.
Your options are:
Use solutions like TestFlight (free AFAIK) and HockeyApp (paid
service / 1 month free trial) which use UDIDs for app distribution - they
allow seamless ad-hoc distributions.
Use Apple's corporate license ($99/yr) + enterprise license
($299/yr) at the same time and use the latter to distribute your
betas/products without managing UDIDs (i.e. anyone with a link to
your server can install the app, but you can introduce serial numbers etc.).
NOTE: using enterprise license obliges user to not share the app
outside the company, but most companies breach the license agreement
(sharing the apps outside company is not traceable AFAIK).
If you plan to distribute your app outside App Store, option 2 with enterprise license is a way to go, but mind the license agreement on other hand.
The Apple representitive was wrong.
With an enterprise account you can sign an application using an enterprise distribution certificate and provisioning profile, which lets the app run on any device with no restrictions.
You can also use Over-The-Air distribution which lets people install the app through a simple http link in Safari (for example).
We use this a lot at my workplace. We have hundreds of people around the world using our (private) apps, all installed via safari.
The standard Corporate license only lets you manage a maximum of 100 devices on your developer account, but if you take this route you can still use Over-The-Air distribution with an ad-hoc distribution certificate/profile. But you have to manage each device id yourself.
If the cost of the enterprise account is not too much for you, that is definitely the route to take.
It's like Apple said, not possible.
You can add device to the ad-hoc profile, this will allow your app to run on 100 device maximum.
You can use the Enterprise license but you will still need to register the device before the app can be installed and there is still a a maximum.
See the comment of Mike Weller.
Mustafa
you can generate your OTA(Over-The-Air) file in which you set your appropriate profile(with client`s UDID) and send that link to your client and easily provide your update.with using little bit help of your web-developer.check here.
hope this is helpful to you mate...
Related
Just curious, from an API point of view and in general, besides not having to go through iTunes app approval process is there any other advantages (or even disadvantages) over a regular app for the normal app store?
The public apis exposed to standard license holders are exactly the same as those available for enterprise license holders. In my opinion the advantages of enterprise license would be:
You are free to use even the undocumented apis if you want. Since the apps never go through iTunes store, there is no way Apple can interfere in their distribution.
No need to adhere to HIG guidelines for the same reason as above (although we always try to follow them for apparent reasons).
Since enterprise in-house distribution allows deployment on any iDevice, the testing of apps is also not limited to 100 devices registered on the provisioning portal.
Disadvantages would be:
You can't use features like in-app purchase, iAds etc.(although there is no requirement of such features in enterprise apps).
The enterprise in-house distribution certificate expires in one year. That means rebuilding and redeployment of all the apps again with a new certificate(every year again and again).
To summarize, I would say that I definitely don't agree with MDT's comment. Enterprise apps are not meant for general public, so there is no need of market visibility for them. Consider an enterprise app which shows dashboard of sales data. The use would be relevant to internal users of the enterprise only and imagine what would happen if it is available on the app store.
Marco Arment seems to think so; http://www.marco.org/2012/01/06/autorenewable-subscription-restrictions
To summarize the article, he spent some time trying to make instapaper paid for by an auto renewable subscription, but then was turned down from the app store because that wasn't the intended use (even though it makes perfect sense for his business model).
We are developing an enterprise application and I looked at the following options:
1. Putting on itunes.
Cannot do this since our application is to be used only by our clients with a login and passwrod.
You cannot have login based app in itunes:
http://appreview.tumblr.com/post/952395621/cannot-be-intended-for-a-limited-audience
2. Using iOS Developer Enterprise
Cannot do this as :
The iOS Developer Enterprise Program should be used to develop and distribute proprietary in-house applications to your own employees within your own company. As such, your company would not qualify for direct Program enrollment in this situation. We would suggest that your client apply for enrollment in the Program, and, once enrolled in the Program, your client may add the appropriate developers from your company to their iOS Development Team.
Our client cannot add us.
3. Adhoc distribution.
This is only for 100 beta testers.
So are there any other options if I want our client to donwload our app.
Provide some minimal functionality to all users that does not require any proprietary data, but have the app download all proprietary data and enable proprietary features only after your enterprise customer logs in. Then submit it to the App store.
There are plenty of examples in the app store. Banking apps: they might advertise the bank, have maps to the nearest branch, perhaps include a calculator of some sort, but of course don't allow any actual banking features or download any account information until after a customer logs in. Security apps: provide a public weather web cam view to everybody, but a security cam view only to people who buy their expensive $100K security camera system.
The example private golf course app could have included public information on the club, the current weather, map info on local restaurants, and maybe who to contact to apply for the $10M membership, but then added private club info (calendar, roster) only to paid members after log in.
Make sure to create a test account with dummy (non-proprietary) data and give it to Apple.
You can absolutely have a login based app. I have helped someone submit one that got approved that sounds very similar to the one you are describing. Also, think about the Netflix app for example, login based, limited to Netflix users (although this is probably not as limited as you are talking about).
Your solution is clearly "Using iOS Developer Enterprise"...
Can you be more explicit about the "Our client cannot add us." ?
You can get your client to sign up to the iOS enterprise agreement so that they can install it on their phones, and you are simply a team member for them. That also shifts the liability for the app onto them, should anything go wrong.
Lets say I have a client that wishes me to build a business app for the iphone. I would still need to enroll to the standard developer program so that the app can be installed on real devices and the only way for my client to install the app is through the app store? I cannot just distribute it to my client directly?
I'm just reading about how to start developing for iphone, so i'm a total noob. Any information is appreciated.
Thanks,
Yes you do need a developer license. No you can distribute it directly if you have each device setup on your account to do so. I am also pretty sure apple has a special license that makes it easier for handling enterprise applications you might want to send them an email to ask about it.
EDIT
Ok I found a link. It is more expensive the normal but this is definitely what you want for your company. It lets you do adhoc distribution across your company.
http://developer.apple.com/programs/ios/enterprise/
You need a developer certificate to put an app on any iOS device with a stock OS.
What kind of certificate and how many you need depends on the type and amount of distribution you require, and the size of your client's company.
You most likely will need to join the iOS developer program ($99/annum) yourself to install and test your apps as you develop them. In addition you can deploy Ad Hoc installations for up to 100 devices (including your own, your testers, your clients, plus, very importantly, including all repair replacements and upgrade devices).
Your client may not need any license if they only want a few copies and are willing to have you renew your Ad Hoc installs a few times per year.
If your client wishes to deploy an app in their own name outside their company or through the iTunes App store, then they need to apply to the iOS developer program themselves.
If your client is large enough to have a published Dunn & Bradstreet rating, and wishes to deploy only to their employees, then they can apply to the more expensive Enterprise iOS Developer program, and run their own internal app store.
A client has asked us to develop a proprietary in-house app for managing their back-end systems. However, we are a small development company and I'm certain that their company does not have >500 employees.
Are there any alternative, yet similar, solutions to distributing this app to their company without going through the iPhone enterprise program?
(just to clarify: obviously, we would like to go through the official enterprise program but seeing how the company doesn't have >500 employees, this isn't possible).
UPDATE (27/09): It appears Apple have removed the 500 employee limit for the enterprise distribution See here. So this will probably be our route now (which is helpful because the app is approaching completion). I'll update this as we go through the process if anyone would like me to, so that others may get an idea of what the actual process is like.
You can submit the app as a completely free app on the AppStore but require that the user log in and authenticate to use it. That way anyone can download it but you control who can actually use it. Apple does all the distribution for you for and you don't have to worry about Ad-Hoc deployments or IT departments.
You then build a really simple configuration management system on a web host (or platform like Google AppEngine) that manages the authentication of apps.
When a user launches the free app they are asked for a username/password/whatever. That information is sent to the web-based configuration management system and confirmed. If the app receives an acceptable confirmation from the configuration management system it unlocks itself for use by that user.
The app can either re-authenticate every time it launches (useful if you want lots of control) or it can store a key file locally indicating that it has been authenticated. If it sees the local key file when the app launches it considers itself authenticated and never checks again.
Whether you use one user account per person or one for the whole company is up to you.
This style of distribution is very useful if you want to have control of who can use the app but want the ease of deployment that the AppStore provides.
Apple has accepted many apps onto the AppStore that use this method of authenticating against a remote server (Skype is a perfect example).
If you keep track of device UDID on the configuration server you can also pre-load it to allow a certain set of devices to work.
Further, nothing I have described is iPhone specific so you can use the same configuration management system and concepts on other platforms like Android (or even desktops) if you ever port the app or build other apps needing this in the future.
Also, since the action of authenticating devices is not processor or data intensive you will likely never incur a cost if you build this on Google AppEngine as you will never go over the free quotas and you will gain the stability and scalability of Google's backend architecture.
As this particular deployment is for managing an in-house back-end system deploying it through the AppStore can seem insecure because there is proprietary information embedded in the app, in particular the information that allows it to connect to and authenticate against the back-end systems.
The solution to that is to not include this information within the app and simply have that information be part of the response that the app receives from the configuration management server. Basically the app contains the logic necessary to perform its function but without the connection information it has no ability to manage any back-end system.
If you make the app authenticate every time it launches you can change the connection information on the configuration server and the app will update to the new information without any new deployment being necessary. The user just needs to restart the app. This gives your client the flexibility to change their internal network configuration without invalidating your application code. You could also make this information manually configurable within the application but then you incur an IT cost when setting up the application on each device and if you already are going to set up a configuration management system you might as well use it.
To further secure the above solution you may want to have the configuration management system be in-house and behind the company's firewall so that regardless of who gets a hold of the app they cannot connect to the config system unless they are within the company's network.
I was researching this yesterday and today, and it appears that Apple has just (within the past week) removed the >500 employee requirement for enterprise development. However, I believe you will need to develop/deploy for a particular client using a development toolkit registered by the client.
So if you do work for client A and client B, both client A and B will need to sign up with Apple as business developers, at which point you can develop apps for them (as a contractor) and use their tools to build and deploy within their enterprises. I would think it would be a good idea for your company to also be registered as a business developer.
Apple does still require you to have a Dun & Bradstreet DUNS number to sign up as a Business Developer.
About the only real choices you have are...
Up to 100 devices as ad-hoc distribution.
Enterprize distribution (requires > 500 employees)
Everyone has to march their device down to some IT-central and get built as a "developer" device. (yikes!)
Jail-broken.
Jail-broken may sound scary, but it's actually pretty advanced, now-a-days, and can be managed quite easily. Still, it voids your warrantee (unless you're willing to restore-to-factory and be not-honest about it ;)
Still, technically, it's an available option and can be made to work, if you're willing to plan it out.
Let us know what you decide, and the pros & cons of that method.
Another obvious although not neccesarily pleasant is to submit your app to the app store as an app but can only be accessed with a client password. Assuming you can get past the aapp store process this might work for you.
Olie said:
About the only real choices you have are...
Up to 100 devices as ad-hoc distribution.
Enterprize distribution (requires > 500 employees)
Everyone has to march their device down to some IT-central and get built as a "developer" device. (yikes!)
Jail-broken.
But to be clear (correct me if I'm wrong):
if you use the "Ad-hoc" distribution method, your costumers will see the app vanish after exactly 3 months.
only up to 100 devices can be used for testing (i.e. used in "developer mode") and moreover, the app will vanish after 3 months.
So, Apple doesn't give us any choice, are you really big (>500 employes)?? ok so you can do what you want etc otherwise... "byebye"
Moreover, forget about what "Bryce" said before, an app like the one he described would be rejected with the "limeted audience" motivation.
iOS is not for enterprise app....if you don't want to rely on some clever hackers (i.e. jailbreak)
Ad-hoc distribution is limited to 100 devices per app, that's true, but you can add the project n times to the apple developer center, so you can deploy it to n * 100 devices
How does apple ensure that your enterprise has greater than 500 people? I'd give it a go through the enterprise program anyway...
I would not jailbreak, I would not do ad-hoc because it is limited to 100, and I wouldn't make everyone put their phones in developer mode.
For future maintainability, enterprise mode is the way to go, so see if you can navigate your way through the process without mentioning that you might not be quite 500 users.
Also, I saw your comment about developing using MonoTouch. I would talk to Apple about this before you do anything else, because given their recent policy changes I am pretty sure this will get your app denied from the App Store and the Enterprise program.
Edit: I checked the Mono web page. It seems like Apple may still be letting mono apps in, and the Mono creators insist that it is kosher, but you might be running the risk of having your future app pulled from phones at any time.
A better edit: Straight from the mono website: Enterprise MonoTouch
It is important to point out that the new iPhone Developer Agreement terms are for AppStore deployment and not the Enterprise program that allows deployment of in-house application to users in the enterprise (using the Enterprise Deployment program).
So you might be good there as long as you can get into the enterprise program.
You can completely bypass the App-Store or Enterprise Developer Program approval process, if you develop your app as pure HTML5 solution.
This technology is called webapps. And they can be pretty advanced in functionality. You automatically have cross platform readiness and very easy deployment options (as webclip this can be distributed via .mobileconfig configuration files)
See http://www.apple.com/webapps/whatarewebapps.html
There is another solution: an own app store:
http://rhomobile.com/products/rhogallery/
unfortunately only in combination with RhoHub.
Or:
http://www.appcentral.com/
More info:
http://www.apple.com/iphone/business/integration/mdm/
http://www.cio.com/article/638175/Emerging_Tech_Alternatives_to_Apple_App_Store_For_Enterprises?page=2&taxonomyId=3002
In theory the proposed solution of publishing a free app meant for one company is not valid, since published apps in the app store should not be intended for a "limited audience" (whatever that means), according to:
http://appreview.tumblr.com/post/952395621/cannot-be-intended-for-a-limited-audience
Has anyone tried this with success? Any other ideas?
I am writing an iPhone apps for in-house use. There is 4 of us in the project team. We need to deploy the application to around 20 iTouch devices via ad-hoc distribution mode and there is no intention to put the application in the App store.
The question is, should I go for the Standard Individual Program or the Standard Company Program?
Note: I am not asking to choose between Standard and Enterprise. Since I only need ad-hoc distribution and the application is running on only 20 devices, I believe the standard program should be good enough for this purpose. However, for the standard program, there is option for Standard Individual Program or the Standard Company Program.
revised response:
This info is readily available on the iphone developer application page. Both accounts allow ad-hoc distribution. The enterprise program allows in-house distribution or proprietary apps for companies with 500 or more employees.
original response:
You have to go for the corporate program. It's the only one that allows you to distribute apps within an organization as far as I know. The individual account is only for apps that you intend to sell in the app store.
Review the licenses for each program with your legal team if you have one. I believe you will need the corporate one.
If the company has less than 500 people, you don't mind a slightly more difficult distribution system, and the $200 difference is really important, than register with the standard program as a company. Otherwise, sign up for the enterprise program.
You should only register as an individual if the company does not own the software being distributed and doesn't want to own the software. Which I doubt is the case.
For any business with multiple users I would recommend getting a Corporate account. That way you can have a team leader, and separate account logins for each member of the team.
For a Corporate account you will need to provide a legal contact at your company who has authority to bind your company to the terms and conditions of the Apple agreement.
Check out my post here for a bit more detail about what you have to do, and how long it takes:
https://stackoverflow.com/questions/1876333/how-long-does-it-take-to-get-an-iphone-app-into-the-app-store-closed
To clarify: the iOS Developer Enterprise Program does not require that your company has 500 employees or more. This restriction was lifted in September 2010.
To learn more check out the article "Apple iOS Enterprise Developer Program Summary" at http://www.apperian.com/technote/Apple_iOS_Enterprise_Developer_Program
Please note that access to the actual "license agreement" requires that you agree to the SDK License first (it is not shown to the public).
Here's the main differences if you get the Standard Company program (and not plain old standard program):
You get to run a team in the provisioning portal, i.e. you can invite other iOS developers to be in your team, and they can download provisioning profiles for your app, etc.
You need info like your DUNS company number and a company address
Your organization's legal entity name would be listed as the seller of your apps on the App Store (if you published there)
The first item is the most pertinent. Without a dev team, only the person signing up will have access the provisioning portal.