Re: Mountain Lion changes
Re: Mountain Lion changes
- Subject: Re: Mountain Lion changes
- From: Zav - public <email@hidden>
- Date: Wed, 25 Jul 2012 11:51:37 -0400
OK. I'm reserving my natural feelings on this topic for the sake of decorum since I am a genteel and refined gentleman.
Sandboxing sucks, and it's the mark of people who do not know how to do security.
Now, I do not know the correct way to do this, but I do know that this is not it and it places unfortunate burdens on the developers.
If I am writing code that is not for release to the app store, I want nothing to do with sandboxing, yet Apple's docs all point you to a sandboxing model of writing files to the OS.
As it is on iOS, directly because of sandboxing, we are forced to co-opt other directories to SIMPLY STORE APP PREFERENCES OUTSIDE OF THE APP.
When our app gets updated, BECAUSE OF SANDBOXING, we had to rebuild the app and redistribute on each device just so we could have a certain unique ID for each app. This simply blows.
Why? Because our app in question is serialized with a unique ID. When a new build gets installed, the previously saved ID is wiped, because the preference pList is IN the app, not saved where they are expected to be, in a prefs folder outside the app, just like Jesus intended.
Why couldn't Apple sandbox each preference to be app specific, with a non mutate-able name in a preference folder that is OUTSIDE THE APP?
They could have. Files and folders are just items and containers with relations to each other. Apple's sandboxing could have extended support for preferences outside the app, even scratch files that exist in a non-mutable container that is tied to the name of the app.
Developers are expensive. This is a massive waste of time and money and inconvenience to developers who are not using the App Store and are developing private applications or applications that are internal to their enterprise/company.
Also, it is against corporate policy of many companies to store ANY corporate info outside the corporate net, so storing data in iCloud is not acceptable. Also, if you look at the sandboxing premise, using iCloud for storage is also a sandboxing violation.
Apple's change means that we looked into storing unique app info in address books entries, in image files in the supported directories, even in MP3 file metadata. Remember, I'm reading and writing dicts, that end up as pLists, which are simply XML files, which is simply an ASCII string stream.
It's inane. Also restricting the coders from writing anywhere on the disk aside from the user's Documents, Music and Photos folders? OK. I'll give you one dictionary pList file. Every developer, write all your data to that.
This approach simply shows that Apple's people do not properly know how to apply security and offer a development system that is not overly restrictive for developers.
Forcing devs to use a subset of folders will cost them more time and will end up with people co-opting what is there to handle simple tasks as reading and writing shareable data to the drives.
It's simply bad and ill thought out.
And that's my reserved opinion. Now back to dealing with the stupidity of Xcode which added all the launch screens into the icon section of the app bundle.
On Jul 25, 2012, at 11:11 AM, John C. Welch <email@hidden> wrote:
> On 7/25/12 11:04 AM, "Zav - public" <email@hidden> wrote:
>
>> What I'm really worried about are the implications of sandboxing and the
>> idiotic "every app is an island" approach. Often, I'll want to save a
>> preference outside the app, or use AppleScript to write a file to my
>> desktop that tracks the iTunes song I am playing in case I mistakenly
>> quit and it forgets the song.
>
> Actually, sandboxing is a pretty intelligent security issue, and only a
> requirement for the MAS. Also, you might want to read up on the docs on
> sandboxing in ML. It's a bit better than lion. Much actually. And a lot of
> application sandboxing doesn't really apply to scripts. User-written
> scripts are treated as you'd expect.
>
>>
>> The sandboxing API only allows a few supported folders to write to file
>> saving outside of the app and these places (preferences too) all require
>> user interaction to confirm the action.
>
> you really, REALLY want to look at the changes to sandboxing in 10.8
>
>>
>> I've also got some patent pending material written in AppleScript and
>> Xcode that I'm sure will end up breaking, yet, I really hope not.
>
> --
> --
> Politics:
>
> A strife of interests masquerading as a contest of principles. The conduct
> of public affairs for private advantage.
>
> Ambrose Bierce
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> applescriptobjc-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
applescriptobjc-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden