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.
Related
I've recently had some involvement with a group with an organizational account for iOS development.
They have multiple teams all developing separate iOS applications. I was somewhat surprised to learn that there is no coordination at all of use of the organization's "iOS distribution" certificates. Instead whichever developer needs to submit a build just creates a new one, revoking one or more existing ones if necessary (Apple appears to allow a limited supply of three of these to be "live" simultaneously). Justification for this practice seems to be a combination of the observations that:
distribution certificates created by one developer aren't (easily) usable by another (you can find quite a few questions around SO on this topic; the solution appears to be to make sure the private key element of the certificate is also shared, but this organization has yet to take that on board. Example, another example; there are many more).
xcode7 makes it easier than ever to churn distribution certificates, so it's clearly Apple's intended way (xcode6 would have needed a trip to the developer center).
distribution certificates are only needed for the fairly small window of appstore submission; once the app is in the appstore it makes no difference whether the distribution certificate is revoked.
Apple seem to have some slightly odd last-in-first-out rules around distribution certificate renewal (if you have "old", "newer" and "newest" and you revoke "newer" or "newest"... you'll find you still can't create a new one until you've revoked "old"). Or at least those rules appear odd to an organization which would have liked to divide up the limited stock of distribution certificates between various teams/projects, but found that didn't fit what Apple actually provide.
However, I observe a very serious negative consequence of this policy of rapid distribution certificate churn is that testflight builds don't stay valid for very long at all and tesflight users find themselves getting dialogs about invalid certificates or having apps they're supposed to be testflight testers of disappearing from testflight all too soon. (In fact see also this question along the same lines).
Given that Apple clearly see testflight as an important piece of the appstore infrastructure, I find it hard to believe this organization is going about things in the way Apple actually intend things to be done. Can someone with some insight into the Right Way of doing things please enlighten me?
Apologies if my terminology is off in some of the above... I just dabble in this stuff.
The right way is to have one distribution certificate and share the private key. We share a small keychain that contains just the private keys and certs needed for development/distribution among our org. You can add this 'stub' keychain to all your development machines, and if it's checked into version control, you can push out updates to everyone easily. You can also password protect it, in which case Xcode will ask you to unlock it when using to codesign.
The fact that it's "easy" to churn the certs is actually a bad thing, IMO. As you've observed, it's easy for other developers on the team to screw things up, particularly regarding TestFlight, although I heard from another developer recently that Apple might have fixed that. (I haven't confirmed it myself.)
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 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.
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...
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).