i have enterprise developer account.
Now i m having 2 queries
1. I m getting code sign error while i use this profile and requested certificate.
2. How to distribute app with this account - enterprise account
Reply asap
Thanks
There are two ways to distribute your app. One is to deliver the files (users will need both the app and a provision profile) to your users' computers by whatever means you like (e-mail, web server, thumb drive, etc.) and have your users install the app by dragging those files into their iTunes library. The other way is to host your app on a web server and distribute it directly to users' devices. Apple's instructions for both methods are here.
It's hard to say what's causing your code signing error. What's helped me in the past is to read the error carefully for clues, and sometimes Google the exact error message. Make sure you've got your Entitlements file set correctly -- requirements for this seem to have changed at some point.
An alternative way of deploying apps wirelessly which requires almost zero setup on your end (in case you don't want to spend the time needed for that) is to use something like TestFlight.
Related
I just started creating custom client application for IOS, Which i have already developed for PC and Android clients. Idea of these apps is to use SQLite database file, which is created in PC admin app and is actualized by Internet. Development of this application is payed from one company and shoud be distributed to selected group of people.
What i want to ask is how to distribute this IOS application to certain audience of people (who has right to use it)? Should I put it on app store as free app without database file which should be downloaded to iphone from secret site?
The best way to do it is via the iOS Developer Enterprise Program.
As for the data, you could link it to a web API if the data is growing or changing regularly. But for static data, you could distribute it by including it in the application itself. See CoreData and other tools for more information.
You can also release it for free on App Store and provide a custom login. However, this is not recommended as this application is useless for the rest of the world. The only reason you would want to do this is if your custom clients can register on your website or some place else and you want to allow them to access the app. This is generally done for subscription based applications. But I presume yours is not such a case.
There is also Ad Hoc distribution, but with that you are limited to 100 devices.
You can read more about distribution.
Note: this may not be the bust way but here is my solution for it
I established a server and set user credentials on the server before, i share credentials with the client and he/she logs in with them.. Later they can edit their credentials, my app is on the store for any body but someone who doesnt have those credentials can't log in..
What you're trying to do is this:
https://developer.apple.com/programs/ios/enterprise/
An ad-hoc distribution is your solution.
https://developer.apple.com/programs/ios/distribute.html
If you're planning to distribute the app to more than 100 people, go for their Enterprise program:
https://developer.apple.com/programs/ios/enterprise/
Grepping around, I see that I'm not AT ALL alone in being... challenged... by the process of setting up an iPhone app, getting it to run, giving it my testers, and so on.
I've gotten it to work. Somehow I emailed a copy or two to testers, and eventually got my li'l app into the store, and that was fine.
But I can't say a really, deeply understand it! (And I don't do iOS dev every day. Even now my recollection of what I did is kind-of hazy.)
I'm moderately capable of understanding things, if presented, well, you know, in a way I can understand.
Can anyone point me to a crystal clear explanation of what provisioning actually is?
I feel that if I understood it, the recipes to do it would be obvious.
Thanks!
Development provisioning profiles sign your application, and allow the phone to know it's OK to run. These days, XCode automatically makes a Development Profile for you (the "Team Profile").
The other kind of profile, when you are talking about other people running you app, is a Distribution Profile. You need a Distribution profile for either giving your app to the store, or for giving to beta-testers.
The profile is what allows other people's phones to know it's OK to run your app, basically it includes a list of device ID's approved to run that application on the phone in question, along with being signed so that the phone knows the whole thing is valid.
If you read advice around the web concerning distribution, it's easy to get confused because things used to be a lot harder. You used to have to send Distribution certificates separately from your app to beta testers. These days the certificates are included in your app bundle so you don't have to worry about that.
Furthermore, sending an AdHoc build can be all kinds of unpleasant - for testers using Windows. These days, the absolute best way to do beta testing is have a link on the web that uses the Enterprise ad-hoc deployment feature, to let a user with iOS4 or higher automatically download and install your application with no iTunes or copying work at all. In fact I would at this point refuse to use beta testers running windows who were not on iOS4 or higher.
The guide link posted should have a section about the enterprise ad-hoc, but basically the way it works is there's a small plist file the phone downloads, that has a link to the IPA file containing your app. You point the phone to a specially formatted link to the plist file and the phone fetches the application directly.
All of this is predicated on using the "Build and Archive" option for building any ad-hoc distribution build. You should do that anyway because it also saves out a symbol file for you to use in debugging crash reports.
EDIT:
Here's a little more detail on enterprise deployment (which works for any registered developer, not just Enterprise registered developers):
http://jeffreysambells.com/posts/2010/06/22/ios-wireless-app-distribution/
The Developer Program User Guide should be helpful.
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?
The background story:
I work for a company that develops and manufactures a commercial product which can have up to 100+ dedicated PC's in a farm.
We only get a handful of new customers per year.
We developed an iPod/iPhone app that lets us send commands to the farm and pull data. Our parent company has major concerns about putting this app on the AppStore. (I really dont know the details of the paranoia, but I know its probably not a winnable battle).
We planned to distribute the App via Ad Hoc using ONE or TWO new iPods each time we sell a "farm". I have just learned that the Ad Hoc distribution expires after 90 days.
The Question:
Are there any alternatives for permanently loading our app onto an iPod Touch or iPhone without going through the App Store?
Our app has absolutely no use to anyone without our other product. We only plan to load this app on a handful of iPods a year. I doubt this matters, but maybe somebody has another solution?
Apple has an an enterprise distribution program, which might allow what you're trying to do. There's also jailbreaking the iPods. That would let you run unsigned code, so you could build your apps without ad-hoc certs.
I know this post has been marked as answered but i am in the same situation so i though i should share what i have experienced.
There is NO legal solution for this. You can't have an app distributed with out the annoying expiry dates.
I have been onto the ADC support and you can't get an extension on the certificates, you can renew for more than 1 year at a time and they have no interest in helping you.
I have clients who will not let the content of their apps hit the app store. There for they are stuck with sending all the devices back to renew certificates (i know you don't need to xcode etc.. to install the certs but try getting end users to do it...).
I am in the luck situation that i can try send the shell of an app to the appstore and then once verified (i.e. once off login - ssl to our server with the device id and a guid password) the app will download all the sensitive content to the phone.
I don't know if this will work for all apps - i.e. loading classes or libraries dynamically but for me it is only the content that is sensitive.
if anyone would like more info i am happy to talk it over, but i haven't tried getting the app through the store yet. I will try soon, so i can keep you posted if you are interested.
cheers
kle
As of September 2010, Apple has removed the 500-employee requirement. Go nuts!
See my post about setting up an Enterprise Program account (which moderators keep trying to close!):
https://stackoverflow.com/questions/1876333/how-long-does-it-take-to-get-an-iphone-app-into-the-app-store-closed
Issues with getting an Enterprise Program account:
-You need 500 employees.
-You can only provide the app to employees.
Make sure you check the detailed terms and conditions of using Ad Hoc distributions to be sure you are allowed to distribute them as you are doing. On the face of it you are probably okay (Apple link here), but worth checking the fine print. I know the Enterprise Program had a lot of fussy fine print, e.g. needing procedures to recover apps from employees when they leave the company, etc.
If you jailbreak the iTouch/iPhone then you can easily disable Apple's code signing checks. You can then build your app and load it onto the device as normal without worrying about expiry or anything else.
The only problem is that jailbreaking on newer batches of the 3GS is not particularly end-user friendly. For something to give to a client I think you would need to stick with the iTouch.
I'm a first time iPhone application developer and I'm developing application for my client who wish to distribute this application to a group of people related to his business only, and as FREE application only. This is such an application which is not meant for general users so we definitely don't want this application is publicly listed in Apple AppStore, rather we want to distribute application to group of people privately. Just like sending them a link to download application via email or something. They click on it and application get downloaded. But in Apple I read that two programs are available like Standard Program and Enterprise Program. The standard one will list application publicly which we do not want, and enterprise programs looks compelling for enterprise users connected to MS Exchange server which we do not posses and not even wish to setup because its not needed.
Can any one help me answer following?
1. If we go with Standard program, how can we restrict application to be visible via some AppStore link ONLY and we will send that link to our users via email.
2. If we go with Enterprise Program, can we do a simple setup over our Apache+PHP+Linux environment i.e. without involving MS Exchange server.
Thanks,
Sameer.
One way around this is to submit your application to the App Store, but put it's availability date in the future.
Then, you can create promo codes and send them to the people you'd like to be able to download your application, but it won't show up in the store.
If you do it this way, you don't need to know anybody's UDID, but you're limited to 50 people per version of your application.
If we go with Standard program, how can we restrict application to be
visible via some AppStore link ONLY
and we will send that link to our
users via email.
It is very simple: You can not. You can either manually distribute the App through AdHoc distribution (for this you will need the UDID of every single iPhone the app will be installed and afaik the the license runs out every year and needs to be renewed) or post it to the AppStore publicly but restrict access to your application by using an authentication within the App itself.
If we go with Enterprise Program, can we do a simple setup over our
Apache+PHP+Linux environment i.e.
without involving MS Exchange server.
Afaik I think this should be possible as you basically are just doing a huge AdHoc distribution, but without Exchange Server it might get a pain as you will probably also need the UDID. Yet honestly I never took any closer look at this program.
You can setup the app to require a password or hot corner when first run.
The Enterprise Program is your only viable option for a native iPhone App. Re-read the program details. It's exactly what you want.
If you deploy your App as a Web-App, you can skip this and simply deploy on the company website, so if you don't need native iPhone options, this might also be a viable way to deploy your program.
-t
You will need to qualify for the Enterprise Program: you'll need a minimum number of employees and a DUNS number. Read the Enrollment document for more information. Your situation (as described) does not sound like it qualifies.