I am saying in-house apps deployed in an ad-hoc fashion. (also, you can use exit(3) which is a public POSIX API but it is less elegant)
If the apps have the same developer ID, you can also use a shared keychain. I did that for a few App Store apps that shares a login. On Oct 14, 2013, at 22:49, Fritz Anderson <fri...@manoverboard.org> wrote: > On 13 Oct 2013, at 11:29 PM, Maxthon Chan <xcvi...@me.com> wrote: > >> method call -[UIApplication _terminate], it is private but since your apps >> are in-house you are not bind to the rules > > Strictly speaking, this is not so. The Enterprise license (when I last looked > at it about a year ago) requires that in-house applications conform to the > criteria for App Store review. What you're referring to is not a total > exemption from the rules, but the unlikelihood you will be caught, or that > Apple will take much trouble if you are. > > Many of the rules reflect Apple's need to have its products make a good > impression on the people who paid extra money for a good experience. If you > run the battery life of an Apple customer's iPhone down to two hours, that > damages the iPhone's reputation with the user and his friends, regardless of > whether the user is part of a captive audience. > > We had a project in the acquisition stage that would have synthesized all of > a device's sensor data into a conjecture of the mental state of the user. (It > was a professor's research project, what do I know.) We knew it was creepy. > > Our Apple field engineer has his ear to the ground. I got an email from him > saying that while every technique we were considering, separately, was > technically feasible, the privacy implications were such that if we went > ahead, Apple could shut us down, and would. I was relieved. > > It was not relevant that the application was to be distributed in-house, nor > that all users would have signed iron-clad consent agreements, nor that > they'd be completely free not to install it. The concern, as I understood it, > was that people would hear that iPhones could spy on them. > > Quite aside from its being wrong, which I think was the main thing on the > engineer's mind. One of the nice things about writing software for Apple > devices is that what you can do is also — usually and broadly speaking — the > right thing to do. > > > As for private API: It's not smart. Apple's engineers know what the > interactions and prerequisites of its private API are. If the prerequisites > change, they can adjust to them and not worry about being out of step with > the OS — their code _is_ the OS. As with being caught on your in-house > applications, you're relying on luck. > > And you're not supposed to kill an application out from under the user. > That's why there is no API for it. > > [Please don't protest that this isn't reasonable or fair (which usually boils > down to feeling entitled to do what you want without interference from The > Man), or that you haven't had any trouble yet, or that you don't believe you > ever will; and therefore it shouldn't apply to you. It just is. It's not that > it's immoral, it's just that to a nonzero degree, it's unwise.] > > — F > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
