I am researching to find the different ways an in-house app can be distributed with Apple. Just to be clear what we need is to distribute a private app that can only be used by the members of our organization.
I know the App Store rejects this kind of apps, so my question is, what is the official way that Apple gives us to do this?
I've been searching and I've found the Apple business manager, but reading the documentation I don't know if it is what I'm looking for. Has somebody used it before? How does it work? Does it need an external MDM to work or apple gives us one?
Note: I know this has been asked before, I've gone through all the questions and I've posted this one because the others are outdated.
So after some more deeper research I have found that the Custom Apps are the best solution.
To clarify for those as confused as me, there are two methods: in House and Custom Apps.
In House is described by Apple as "no longer the standard" but still working. It apparently needs an MDM to work, also an Apple Enterprise developer Program membership. The apps expire every year so you have to keep an eye on it.
Custom App (the new way of doing it). It doesn't need an MDM to work (but can be used with it), the other option is to provide redemption codes that an user can use to download the app in the App Store (or with a direct link also provided by Apple). You won't need an Apple Enterprise developer Program membership but a normal Apple Developer Program membership (an the organization will have to be registered in the Apple Business Manager).
Here you have a step by step guide to do the complete process.
Related
A couple of days ago I was asked whether it is possible to record a conversation using an iPhone. Having heard of Apple’s disapproval of that given function, I have confirmed it was not possible. However, out of curiosity, I have googled the info on this issue. Surprisingly, it led me to a website offering a variety of dubious shady activities (wiretapping related).
I will leave all the details behind, just to tell you in a few words that out of desire to understand how it was even possible, using that site I easily managed to install an unauthorized third-party application onto my iPhone with iOS 8.0 bypassing the legal distribution channels and without me providing them the UDID of my phone so they could add it to their distribute certificate (eventually substituting the original messenger app (WhatsApp, Skype, etc.) with their almost identical clone that is collecting and submitting personal info).
As far as i understood the clean/not jailbreaked iOS has no distribution channels other than AppStore, Ad Hoc or Enterprise channels (with providing UDID in the latter two).
I don’t know if this is a system flaw or vulnerability, but this is supposed to not be possible. Maybe, though, my logic is missing something. That is why I am trying to address this issue here.
The aim of this post is to bring up your expertise and to find out collectively the mechanics of these activities to ultimately prompt Apple to eliminate the related shortcomings.
Again, I have the details and can provide them in case needed, but for the sake of not being deleted or, God forbid, banned I am keeping those to myself for the moment.
Thank you.
One can buy an enterprise account for 299$ per year to build in-house Apps, which can be distributed without knowing or adding any UDID.
These Apps should normally only be distributed to employees, but this restriction is often ignored and Apple bans those accounts then.
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.
I'm looking for the optimal way to distribute prototype/pilot apps to K-12 institutions and I can't quite seem to figure it out.
It doesn't seem like using either the regular App Store or the Volume Purchase Program stores is ideal, as the app will only work for our pilot classrooms where the teachers have been given login credentials. Everybody else will not be able to use the app in any way, and so we'll likely get the lowest rating, if the app even makes it past review.
The two options that seem viable-ish are:
Enterprise Distribution: it's technically not really meant for this scenario, but I've heard people use it successfully. Build the app and distribute it through the enterprise distribution flow. The problem is that technically, since we're not affiliated with the institutions we're piloting in, we'd have to have them pay $300/year and add us as contractor developers for them, something I don't envision happening. The approach I heard of was that of developers signing up for an enterprise account and using institutional devices as if they were part of that company.
Custom B2B app: seems like one could use this route as well, even though custom B2B apps still go through an Apple review process, so I'm not clear if a prototype would get too far through the process. Also updating the app will most likely be a pain, as you have to wait for the review process to complete. It's also not clear if educational institutions are allowed to use this route.
I'm really curious to hear what your experience with either one of those has been and if you think they fit the scenario well. Is there another options I'm missing? It's especially important that the distribution flow is simple for multiple devices and allow for painless update of the apps, as we'd like to iterate as fast as possible.
Thanks!
Another option that might fit your needs is using TestFlight http://www.testflightapp.com. It allows you to send beta or prototype versions of your app to individual devices over the web. However, you're still limited to using Apple's provisioning and can only distribute up to 100 devices in a given year. Users will also need to provide you with their device UDID. It might be a good solution if you're only looking to have a few beta testers.
I would like to distribute an App preview to a musician that I am working with. He is not an employee of my company but offered me to do the game sountrack for free.
I have checked on the iOS Provisioning Portal and found the following dislcaimer:
"Important: Your iOS Developer Program membership can be terminated if you provide pre-release Apple Software to anyone other than employees, contractors, and members of your organization who are registered as Apple Developers and have a demonstrable need to know or use Apple Software in order to develop and test applications on your behalf. Unauthorized distribution of Apple Confidential Information (including pre-release Apple Software) is prohibited and may subject you to both civil and criminal liability."
According to this I can only distribuite preview apps to test developer that I somehow employ. This excludes the case of friends working for free on non coding matters (e.g. musician).
Does anyone of you had a similar concern?
Thank you very much!
EDIT2:
I posted again this question on new post with additional details as Apple replied to me on this matter and did provide a different answer than the ones below. I have tried to add comments to those answers but this question doesn't seem to have any more visibility and need to solve this quickly, so thought that that was the way to go.. let me know if this is not correct. Thanks!
That's for pre-release Apple Software such as the beta a new version of iOS. You can send your own app to your friend so that he can test it, but you can't give him access to pre-release Apple Software and other confidential information.
Here is a guide that shows how you can send the app to beta testers, and here is a web application that makes the process easier.
Also Apple's Tools Workflow Guide says:
it’s always a good idea to perform wider testing with a representative sample of your app’s potential users. Such testing may reveal issues that surface only with particular usage patterns. An app tester is a potential user of your app who is not part of your development team but is willing to test it before it’s released through the App Store.) Adding app testers to your group of testers exposes your app to a variety of usage styles. You can collect and analyze crash reports (also known as crash logs) from these testers to resolve execution problems.
Nope, I think you misunderstood. You can distribute your own app as an Ad-Hoc to your friends whoever is a developer or not. However, there's a 100 devices limitation. And Apple is encourage you to do so before submit your app to App Store.
You cannot test your app the same way the users of your app will use it. They have different data and different usage patterns. Before publishing your app on the App Store, put it through real-world testing to find and solve as many problems as possible.
You can refer to THIS DOC to find out how to publish your App for user testing.
This question already has an answer here:
Closed 11 years ago.
Possible Duplicate:
How does enterprise distribution of iOS apps restrict distribution outside of one company?
How does enterprise distribution of iOS apps restrict distribution outside of one company?
This is almost the exact same question as above, but I feel it wasn't answered in layman's terms. I'm still confused after looking at Apples manual.
We are constrained by these factors:
We are in Canada so we can't get B2B
Our corporate client does not want to sign up for Apple's Enterprise
Our app holds confidential information (no itunes)
100 employees are expected to use the app
Our client expects to be able to download the app without shipping their hardware to us
So then, has anyone done this? The Enterprise SDK is for in-house only (as per terms of the legal agreement), but how would anyone know the difference? If we post our .ipa and manifest file and help our client with the provisioning, what are some "got-chaya" we should watch for? It sounds like Apple just wants to squeeze into corporations and they are forcing this on them, which then makes it harder for developers to sway clients to use Apple!
The correct solution is for your client to sign up for Apple Enterprise. The fact that they 'don't want to' is unacceptable. That is the only way this is going to work out without one or both of you breaking a license agreement.
Even if Apple has no way to know if you're distributing outside of your company, you have a responsibility to uphold the license you agreed to.
It's hard to tell whether or not they enforce the restrictions to the Enterprise Developer Program. So far, I've not heard of any such case.
But getting hints would be easy for them, since Enterprise apps need to authenticate frequently with an Apple server to make sure the distribution certificate is still valid. So technically they may come to know who installs those apps and may come to the conclusion that in a specific case the terms of use for the Enterprise Developer Program have been violated.
If I were you I'd stick to those terms - even if you don't care about laws and morality and stuff just consider this: What if you provide your client with your app using the EDP and Apple shuts it down? I can't think of a more embarrassing situation.
That being said I do sympathize with your situation, because I was facing it too, just two months ago. So I know how painful it is to explain to your client that you can't do what they want because Apple does not allow it in their terms of use. I lost that job in the end because I couldn't talk them into enrolling themselves.
So if your client is as stubborn as mine has been, there's no solution for you I'm afraid. It won't help you right away, but I'd strongly suggest contacting Apple about it. Maybe they'll do something about it if enough people start complaining...