After wrapping my Mac App with App Wrapper, the app runs, but I still see the following message in Console;
04-02-16 23:06:54,233 sandboxd[145]: ([21861]) MyApp(21861) deny system-socket
I’ve added the temporary entitlement; com.apple.airportd to enable querying the AirPort,
but still get the above sandbox message; does anyone know how to fix this or should I just ignore it and submit the App to the MAS for review?
Thanks in advance for your reply.
Are you actually querying the AirPort or are you trying to use a network connection?
If you’re trying to do something with a HTTPSocket you need Network Access entitlements (usually only Client)
@Tim Parnell
Thanks Tim, I’m just querying, not sending or receiving anything. Adding Client (or also Server) Network access does not help.
[quote=245225:@Boudewijn Krijger]@Tim Parnell
Thanks Tim, I’m just querying, not sending or receiving anything. Adding Client (or also Server) Network access does not help.[/quote]
Querying the AirPort is for changing the device and it’s settings.
If you’re just trying to determine connection, you still need Network Access, not AirPort access.
@Tim Parnell
I’m using an MBS plugin; CWInterfaceMBS.scanForNetworksWithParameters which does not function unless I add com.apple.airportd as a Global Mach Services temporary entitlement.
I’m not changing anything, merely querying and using that information to provide feedback to the user.
I do have Client Network Access, but this has nothing to do with the CWInterfaceMBS.scanForNetworksWithParameters being blocked unless I add the com.apple.airportd entitlement.
Apple Rejected my App because of the com.apple.airport entitlement.
Any Suggestions anyone?
[quote=246913:@Boudewijn Krijger]I do have Client Network Access, but this has nothing to do with the CWInterfaceMBS.scanForNetworksWithParameters being blocked unless I add the com.apple.airportd entitlement.
Apple Rejected my App because of the com.apple.airport entitlement.
Any Suggestions anyone?[/quote]
Join the club of developers who’s apps are not welcome on the App Store, it’s a growing club!
3 Choices I see:
#1 Fight it, respond to the reviewer that your application absolutely needs this entitlement or it’s a waste of investment. If they continue to reject, appeal and appeal until you run out of patience/hair or they cave.
#2 Find other ways of solving this task, which don’t require temporary entitlements, maybe there’s a terminal command or a more modern API, or maybe look at Apple’s API docs yourself and see if there’s a better function.
#3 Fuck 'em, Host it on your own site, distribute it via all other download sites, ramp up efforts to sell it elsewhere. There’s a great deal of developers who are have been pushed out the App Store by Apple’s rules who continue to do well. After all the App Store is such a flooded marketplace, that it’s just another sales channel with largest percentage cut of them all!
We have Apps on and off the App Store, several of the functions required for code signing an application are barred on the App Store, hence why there’s not even an App Wrapper Mini anymore. Yet App Wrapper is one of our best selling products.
It is always good to have another way to sell than the MAS anyway.
For an upcoming app, I am seriously considering two different versions : one, kind of neutered, for the MAS because of current limitations, and another one off MAS with all bells and whistles.
MacPhun, our greatest competitor in the App Store (for Photo) apps, does this, they sell a cut down version on the App Store (which Apple promote) and then they sell a full version on their site. They even promote their ‘Pro’ version in their cut down apps; which is frowned upon, but hey they’re a promoted partner so they can do pretty much whatever they want.
I intend to do just that. After all, promoting is not selling. If I mention the bells and whistle of the pro version in the built-in manual, it is information, not in app purchase 
@Michel Bujardet In such case, do the two apps share the same bundle-signature? Because, if they need different signatures, how will the user purchasing the PRO version access settings and data stored in a different container?
Interesting question and actually the answer is rather simple.
#1 If you use NSUserDefaults to store the settings they’re automatically transferrable, so is using the OWRecentItems from the Sandbox Kit.
#2 The App Sandbox is not as restrictive as you might think, it’s the App Store that adds another layer of complication on top of the App Sandbox. For most cases (being a bit too general here), Michel’s app should run fine Sandboxed (may need some additional entitlements for the non app store version). That way the data is synced regardless.
#3 Don’t care; MacPhun’s Pro apps are not sandboxed (and I’m pretty sure not coded following Apple’s guidelines or use a different bundle ID). Basically they’re Pro version didn’t retain any of my settings from the cheap ■■■ version.
I use NSUserDefaults only to get/set nap; but for other items such as a window.position, checkbox.values etc I use a file in the sandboxed app’s container.
As a consequence, to access that file from a non-sandboxed app, a call to specialfolder.applicationData.child(“my app”) will return the file stored in Library > Application Support, not the one stored in Containers.
And if both apps are sandboxed and consequently have different signatures, then app1 cannot access the data of app2.
These are the things that are on my mind at present.
As for OWRecentItems: with the right UTIs, I’d not foresee problems accessing external files via getOpenFolderitem.
Am I not reading you all right? Meanwhile, thanks for the suggestions.
There’s a bunch of APIs for storing Windows positions and such in NSUserDefaults. Although for large amounts of data, you should really be storing that in a file and not NSUserDefaults.
[quote=247503:@Carlo Rubini]And if both apps are sandboxed and consequently have different signatures, then app1 cannot access the data of app2.
These are the things that are on my mind at present.[/quote]
You can create a Shared Group Container, that the non-Sandboxed app and the Sandboxed application can access. You need to specify the correct entitlement when Sandboxing (which can be done in recent versions of App Wrapper). I share the code here if you’d like (I have to go to a different computer and dig it out).
With OWRecentItems, it uses the OS APIs for storing and maintaining a recent file list, which works across both Sandboxed and un-sandboxed. It also holds onto the File access through out restarts, which can save a bundle of trouble with Sandboxed applications and avoids those nasty Security Scoped Bookmarkses…
It doesn’t matter about the UTI, as long as your application was granted access to the file, it will retain it.
I’d appreciate it. When you have time.
Thanks.
I started to write out how to do and realized that it pretty much needs a whole tutorial…
Then I got distracted and ended up losing it (due to session timeout)… Bah!
Sorry for that. When you get time…
Thanks.
Here’s an update; After 3 attempts of submitting an App for review with extensive motivation, I received Apples confirmation that my App will always be rejected because it tries to access the airport( I do this with an MBS plugin that uses the official Apple API).
Although App-Wrapper allows me to correctly request an exception, Apple simply decided they will not grant it.
This means I have to re-write my App to do EXACTLY the same using a terminal command (that accesses the exact same API) and use the returned data from it.
Sometimes Apple makes no sense…