This document’s file has been changed by another application since you opened or saved it.
In my complex Core Data-based app, I get this behavior: 1. I launch the app with no prior state. It creates a .sqlite Core Data DB with some default data. 2. Quit and re-launch 3. App opens that default file. 4. I modify the file then save it. 5. I get the sheet that says, "This document’s file has been changed by another application since you opened or saved it." No other app has touched the file. Any ideas? Thanks, -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: This document’s file has been changed by another application since you opened or saved it.
On 14 Oct 2013, at 10:37, Rick Mann wrote: > In my complex Core Data-based app, I get this behavior: > > 1. I launch the app with no prior state. It creates a .sqlite Core Data DB > with some default data. > 2. Quit and re-launch > 3. App opens that default file. > 4. I modify the file then save it. > 5. I get the sheet that says, "This document’s file has been changed by > another application since you opened or saved it." > > No other app has touched the file. Any ideas? So you're using the document architecture? Are you modifying the document outside of the -writeToURL:… methods? If so, there's your problem. ___ 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
Re: collection of applications
On 13 Oct 2013, at 11:29 PM, Maxthon Chan 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
Re: collection of applications
On 13 Oct 2013, at 11:45 PM, Maxthon Chan wrote: > Maybe you have to tell your management that it is technically infeasible to > do so in iOS without jailbreaking. Either you bake them all in/use separate > SpringBoard icons or the dynamic libraries will not be loaded in vanilla iOS > device without black magic. Jailbreaking hasn't deterred some of our potential clients, who were determined to get what they wanted, jailbreaking be damned. Our network carries data the disclosure of which is a felony. I had to explain that we simply could not make a policy of bringing computers that had been rooted by God-knows-who inside our security wall. Management isn't 100% likely to shy away from security disasters, but it makes more weight than jailbreaking's being technically inadvisable. — 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
Re: This document’s file has been changed by another application since you opened or saved it.
On Oct 14, 2013, at 02:46 , Mike Abdullah wrote: > So you're using the document architecture? Are you modifying the document > outside of the -writeToURL:… methods? If so, there's your problem. It's Core Data, so I only ever modify the file via -[NSManagedObjectContext save:]. I don't even implement a writeToURL:… anywhere. -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Deferring creation of children when using bindings?
I'm having trouble searching for a solution to this need: I have a tree controller bound to an array in my window controller. I populate it with top-level items, and they show up, but I'd like to defer populating the children of each item until the user actually clicks the disclosure triangle. Getting the children is time-consuming and expensive. Is there a way I can get it to show the disclosure triangle and then call me back when it's clicked open? Thanks, -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: Deferring creation of children when using bindings?
On Oct 14, 2013, at 1:33 PM, Rick Mann wrote: > I have a tree controller bound to an array in my window controller. I > populate it with top-level items, and they show up, but I'd like to defer > populating the children of each item until the user actually clicks the > disclosure triangle. Getting the children is time-consuming and expensive. Is > there a way I can get it to show the disclosure triangle and then call me > back when it's clicked open? In your model class implement a boolean property that returns YES for a leaf, and set that as the NSTreeController’s leafKeyPath. Then the controller will just call that for closed items and draw the disclosure triangles for items where it returns NO. Then you’re free to make the children and (optionally) count properties compute the children lazily, because they won’t be called until the item is flipped open in the UI. —Jens ___ 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
Re: This document’s file has been changed by another application since you opened or saved it.
On 14 Oct 2013, at 19:27, Rick Mann wrote: > > On Oct 14, 2013, at 02:46 , Mike Abdullah wrote: > >> So you're using the document architecture? Are you modifying the document >> outside of the -writeToURL:… methods? If so, there's your problem. > > It's Core Data, so I only ever modify the file via -[NSManagedObjectContext > save:]. I don't even implement a writeToURL:… anywhere. Therein lies your problem. You are modifying the document behind NSDocument's back. Let the user/document system decide when to save, rather than saving the context yourself. If you do desperately need to force a save, do so through NSDocument, not the context. ___ 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
Re: This document’s file has been changed by another application since you opened or saved it.
On Oct 14, 2013, at 14:30 , Mike Abdullah wrote: > Therein lies your problem. You are modifying the document behind NSDocument's > back. Let the user/document system decide when to save, rather than saving > the context yourself. If you do desperately need to force a save, do so > through NSDocument, not the context. Ah. I think this is the result of my attempt to do something that's perhaps not supported, or maybe I'm just overriding the wrong things. The document that was giving me the trouble is a "Library" document my app implements. To edit an item in the library, I create a new document "ItemEditorDoc", and give it an NSManagedObjectContext that is a child of the LibraryDoc's MOC. (When the user saves the ItemEditorDoc, it should implicitly also save the LibraryDoc). Is this kosher? -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: Deferring creation of children when using bindings?
On Oct 14, 2013, at 14:12 , Jens Alfke wrote: > > On Oct 14, 2013, at 1:33 PM, Rick Mann wrote: > >> I have a tree controller bound to an array in my window controller. I >> populate it with top-level items, and they show up, but I'd like to defer >> populating the children of each item until the user actually clicks the >> disclosure triangle. Getting the children is time-consuming and expensive. >> Is there a way I can get it to show the disclosure triangle and then call me >> back when it's clicked open? > > In your model class implement a boolean property that returns YES for a leaf, > and set that as the NSTreeController’s leafKeyPath. Then the controller will > just call that for closed items and draw the disclosure triangles for items > where it returns NO. > > Then you’re free to make the children and (optionally) count properties > compute the children lazily, because they won’t be called until the item is > flipped open in the UI. Thanks, Jens, that seems to work well. -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
NSTreeController: how do I select a model object?
Hey, Rick’s tree controller question reminded me that I’ve got one I’ve been meaning to ask: With an NSOutlineView driven by an NSTreeController, I’m having trouble figuring out how to programmatically select an item: given one of my model objects, how do I tell the controller or view to select it? NSTreeController has a .selectedObjects property, which is great for _getting_ the selection, but for some reason it’s a read-only property (unlike in NSArrayController), so I can’t use it to _set_ the selection. But if I go through the outline view, its ‘item’ objects are the NSTreeNodes managed by the controller, not my model objects, and I don’t see any clean way to map from a model object to its tree node. It seems like I’d have to write a recursive function to search the entire NSTreeNode hierarchy for one whose representedObject is my model object. Surely that can’t be the only way to do this? —Jens ___ 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
Re: NSTreeController: how do I select a model object?
On 15 Oct 2013, at 8:18 AM, Jens Alfke wrote: > With an NSOutlineView driven by an NSTreeController, I’m having trouble > figuring out how to programmatically select an item: given one of my model > objects, how do I tell the controller or view to select it? I'm using datasources, but that shouldn't matter: [self.outlineView selectRowIndexes:[NSIndexSet indexSetWithIndex:[self.outlineView rowForItem:item]] byExtendingSelection:NO]; -- Shane Stanley 'AppleScriptObjC Explored' ___ 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
Re: This document’s file has been changed by another application since you opened or saved it.
On 2013 Oct 14, at 14:46, Rick Mann wrote: > The document that was giving me the trouble is a "Library" document my app > implements. To edit an item in the library, I create a new document > "ItemEditorDoc", and give it an NSManagedObjectContext that is a child of the > LibraryDoc's MOC. (When the user saves the ItemEditorDoc, it should > implicitly also save the LibraryDoc). > > Is this kosher? Creating a document to edit an item seems pretty weird. "Give it a child MOC" (setting its managed object context, I presume) from some other document seems even more weird. I would recommend a more conventional design. Or, maybe read Mike Abdullah's latest reply again. It depends not on what triggers the save operation but on what method is used. • -[NSDocument saveDocument:] is kosher. • -[NSManagedObjectContext save:] will cause the trouble you are seeing. ___ 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
Re: NSTreeController: how do I select a model object?
On Oct 14, 2013, at 4:18 PM, Jens Alfke wrote: > With an NSOutlineView driven by an NSTreeController, I’m having trouble > figuring out how to programmatically select an item: given one of my model > objects, how do I tell the controller or view to select it? > > NSTreeController has a .selectedObjects property, which is great for > _getting_ the selection, but for some reason it’s a read-only property > (unlike in NSArrayController), so I can’t use it to _set_ the selection. > > But if I go through the outline view, its ‘item’ objects are the NSTreeNodes > managed by the controller, not my model objects, and I don’t see any clean > way to map from a model object to its tree node. It seems like I’d have to > write a recursive function to search the entire NSTreeNode hierarchy for one > whose representedObject is my model object. Surely that can’t be the only way > to do this? I used the method described here on a project using NSTreeController and bindings to populate an outline view: http://blog.wilshipley.com/2006/04/pimp-my-code-part-10-whining-about.html I'm not aware of any changes to NSTreeController/bindings that would replace this approach, but I'm always ready to be pleasantly surprised. :-) ___ 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
Re: NSTreeController: how do I select a model object?
On 15 Oct 2013, at 9:30 AM, Shane Stanley wrote: > I'm using datasources, but that shouldn't matter: But first coffee of the day tells me that's precisely the point. Sorry for the noise. -- Shane Stanley 'AppleScriptObjC Explored' ___ 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
Re: This document’s file has been changed by another application since you opened or saved it.
On Oct 14, 2013, at 15:37 , Jerry Krinock wrote: > Creating a document to edit an item seems pretty weird. "Give it a child > MOC" (setting its managed object context, I presume) from some other document > seems even more weird. I would recommend a more conventional design. That's how I felt at first, but really, it should be fine. The user experience is that of editing an item (really, it's a part in a specialized CAD program, and the UI to edit it is virtually identical to that of editing a document that uses those parts). The UI includes a window with dirty status, undo stack, etc. It just doesn't save to a disk, but rather to the library's MOC. The new concurrency types encourage this use, I think. I have yet to adopt the new document convention of never having to save; I'm a bit old-school in this regard, and I find saving a copy a little cumbersome, etc, but the technique should lend itself to that, too. > Or, maybe read Mike Abdullah's latest reply again. It depends not on what > triggers the save operation but on what method is used. > > • -[NSDocument saveDocument:] is kosher. > • -[NSManagedObjectContext save:] will cause the trouble you are seeing. Yep, I'm now getting into a save loop; probably overloaded the wrong thing. When the user saves a new part, there's a specialized dialog for entering the save information (name, etc.), rather than a standard NSSavePanel. After that's done, I seem to be starting it all over again. I think I'm overriding at the wrong points. -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: This document’s file has been changed by another application since you opened or saved it.
On Mon, Oct 14, 2013, at 04:46 PM, Rick Mann wrote: > > On Oct 14, 2013, at 15:37 , Jerry Krinock wrote: > > > Creating a document to edit an item seems pretty weird. "Give it a child > > MOC" (setting its managed object context, I presume) from some other > > document seems even more weird. I would recommend a more conventional > > design. > > That's how I felt at first, but really, it should be fine. The user > experience is that of editing an item (really, it's a part in a > specialized CAD program, and the UI to edit it is virtually identical to > that of editing a document that uses those parts). The UI includes a > window with dirty status, undo stack, etc. It just doesn't save to a > disk, but rather to the library's MOC. The new concurrency types > encourage this use, I think. The new concurrency types are explicitly designed around _not_ accessing a persistent store via two different Core Data stacks. Your intended UI sounds fine, but you should create a child MOC and attach it to your document's main MOC. You should not be writing to the on-disk store behind the document's PSC's back and then trying to patch things up later. > > I have yet to adopt the new document convention of never having to save; You should really get on board with that. It's been three OSes now. Do not anticipate this option being available to you forever. --Kyle Sluder ___ 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
Re: This document’s file has been changed by another application since you opened or saved it.
On Mon, Oct 14, 2013, at 05:27 PM, Kyle Sluder wrote: > The new concurrency types are explicitly designed around _not_ accessing > a persistent store via two different Core Data stacks. And rereading your first post, I see "I modify the file and then save it" does not imply the behind-the-scenes trickery I thought it did. Never mind! --Kyle Sluder ___ 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
Re: This document’s file has been changed by another application since you opened or saved it.
On Oct 14, 2013, at 17:27 , Kyle Sluder wrote: > a persistent store via two different Core Data stacks. > > Your intended UI sounds fine, but you should create a child MOC and > attach it to your document's main MOC. You should not be writing to the > on-disk store behind the document's PSC's back and then trying to patch > things up later. I was trying to say, this is exactly what I'm trying to do. I didn't realize I was circumventing things by calling -save:, too much non-document iOS development. -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: This document’s file has been changed by another application since you opened or saved it.
On Oct 14, 2013, at 17:28 , Kyle Sluder wrote: > And rereading your first post, I see "I modify the file and then save > it" does not imply the behind-the-scenes trickery I thought it did. > Never mind! No worries ;-) It's sometimes hard to be both precise, and brief. -- Rick signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
Re: NSTreeController: how do I select a model object?
On Oct 14, 2013, at 3:49 PM, Michael Babin wrote: > I used the method described here on a project using NSTreeController and > bindings to populate an outline view: > http://blog.wilshipley.com/2006/04/pimp-my-code-part-10-whining-about.html > I'm not aware of any changes to NSTreeController/bindings that would replace > this approach, but I'm always ready to be pleasantly surprised. :-) Well, the big change is that what Wil in 2006 called the "strange little shadow objects that point to your REAL objects when you put real objects into an NSTreeController” are now public API, as NSTreeNode instances. This makes it feasible to navigate the controller’s tree without having to do a lot of NSIndexPath gunk the way his code does. These days, to get the index paths of model objects you “simply” have to recurse down the NSTreeNode hierarchy, which is still a mess but probably a lot more efficient than Wil’s 2006 code. So I guess it’s time for me to write that code... —Jens ___ 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
Re: collection of applications
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 wrote: > On 13 Oct 2013, at 11:29 PM, Maxthon Chan 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
Re: collection of applications
You can use a repo and package limiting tool on jailbroken devices, and make sure that only whitelisted packages/repos are accessible. Also, for those sensitive data, something like TLS/IPSec will help a lot. On Oct 14, 2013, at 22:59, Fritz Anderson wrote: > On 13 Oct 2013, at 11:45 PM, Maxthon Chan wrote: > >> Maybe you have to tell your management that it is technically infeasible to >> do so in iOS without jailbreaking. Either you bake them all in/use separate >> SpringBoard icons or the dynamic libraries will not be loaded in vanilla iOS >> device without black magic. > > Jailbreaking hasn't deterred some of our potential clients, who were > determined to get what they wanted, jailbreaking be damned. > > Our network carries data the disclosure of which is a felony. I had to > explain that we simply could not make a policy of bringing computers that had > been rooted by God-knows-who inside our security wall. Management isn't 100% > likely to shy away from security disasters, but it makes more weight than > jailbreaking's being technically inadvisable. > > — 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
