Re: collection of applications
Re: collection of applications
- Subject: Re: collection of applications
- From: Maxthon Chan <email@hidden>
- Date: Tue, 15 Oct 2013 12:10:31 +0800
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 <email@hidden> wrote:
> On 13 Oct 2013, at 11:29 PM, Maxthon Chan <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden