My app was rejected due to this ,Please help me to resolve this .This issue is new to me .
Guideline 2.5.1 - Performance - Software Requirements
Your app uses or references the following non-public APIs:
"_IOObjectRelease, IOServiceGetMatchingService, IOServiceMatching
The use of non-public APIs is not permitted on the App Store because it can lead to a poor user experience should these APIs change. Continuing to use or conceal non-public APIs in future submissions of this app may result in the termination of your Apple Developer account, as well as removal of all associated apps from the App Store.
Next Steps
If you are using third-party libraries, please update to the most recent version of those libraries. If you do not have access to the libraries' source, you may be able to search the compiled binary using the "strings" or "otool" command line tools. The "strings" tool can output a list of the methods that the library calls and "otool -ov" will output the Objective-C class structures and their defined methods. These tools can help you narrow down where the problematic code resides. You could also use the "nm" tool to verify if any third-party libraries are calling these APIs.
Resources
For information on the "nm" tool, please review the "nm tool" Xcode manual page. If there are no alternatives for providing the functionality your app requires, you can file an enhancement request.
Thanks in Advance !!!
Related
My searches have turned up nothing concrete. My extension uses Google's file picker to allow the user to browse their sheets and choose a desired file to write some data to, which manifest v3 breaks because of some GAPI limitations. Unless I've missed something obvious, there does not seem to be a simple workaround or method for this to migrate to v3 -- it just seems to be disallowed.
I'm not asking if there's a way to do something that they intend to not be possible (even though I doubt such a thing would exist with Google) but I'm optimistically hoping that maybe there is some hacky/annoying workaround that still fits within their rules. If I absolutely have to just allow them to set a sheet URL manually I will...I'm just trying to avoid it.
Any tips or suggestions would be appreciated.
You may have to test it yourself to make sure there are no weird behaviors, but Google has some recommendations regarding this in their migration guide:
In Manifest V3, all of your extension's logic must be included in the extension. You can no longer load and execute a remotely hosted file. A number of alternative approaches are available, depending on your use case and the reason for remote hosting. Here are approaches to consider:
Configuration-driven features and logic
In this approach, your extension loads a remote configuration (for example a JSON file) at runtime and caches the configuration locally. The extension then uses this cached configuration to decide which features to enable.
Externalize logic with a remote service
Consider migrating application logic from the extension to a remote web service that your extension can call. (Essentially a form of message passing.) This provides you the ability to keep code private and change the code on demand while avoiding the extra overhead of resubmitting to the Chrome Web Store.
Bundle third-party libraries
If you are using a popular framework like React or Bootstrap, you can download the minified files, add them to your project and import them locally.
For your case, option #3 seems like the easiest. Looking at the Google Picker API documentation it only uses two relatively small script files, https://apis.google.com/js/api.js and https://accounts.google.com/gsi/client. You could try to bundle these in your Chrome extension and call the methods locally.
I read about Worklight's Direct Update feature already. However, I still have some questions that would like to clarify:
Q1: Is it true that Apple allows Worklight Apps to be published to APP
Store even there is a direct update feature?
Q2: How will Apple review and monitor the Worklight Apps' content if
there is a huge change after the direct update? Or, Apple does not
worry about the cached web resource in the application, does it?
Q3: Is there any limitation or pre-condition about the direct update
for the web resource? For example, the major entries of html and js
script files must be existed... etc.
Q1: Is it true that Apple allows Worklight Apps to be published to APP Store even there is a direct update feature?
A1: There are existing Worklight customers that have submitted an application to the App Store and passed Apple's app submission process. For best results, make sure you use Worklight v5.0.6.1 or later.
Q2: How will Apple review and monitor the Worklight Apps' content if there is a huge change after the direct update? Or, Apple does not worry about the cached web resource in the application, does it?
A2: Apple only reviews app submissions to the App Store and whether or not they follow their guidelines. They do not review future updates to the application (as long as it was not re-submitted), for example in the form of a Direct Update unless there are some extra-ordinary circumstances (like inappropriate content that was discovered afterwards, for example...)
Q3: Is there any limitation or pre-condition about the direct update for the web resource? For example, the major entries of html and js script files must be existed... etc.
A3: I am not entirely sure I understand the question. There is no limitation in Direct Update - this feature replaces the existing web resources of an application with new ones. The only thing I can think of is that both the Worklight Studio (that the app was created on) and Worklight Server (that the app lives on) must be of the same version number.
An update.
Apple now allows code updates if you use a webview
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts,
code and interpreters are packaged in the Application and not
downloaded. The only exception to the foregoing is scripts and code
downloaded and run by Apple's built- in WebKit framework, provided
that such scripts and code do not change the primary purpose of the
Application by providing features or functionality that are
inconsistent with the intended and advertised purpose of the
Application as submitted to the App Store.
I'm developing an application that uses an API key, and I am considering making it open source (probably under the GPLv3).
I've seen How to open-source an application that uses API keys, and am considering designing so that if the API key is provided during compilation (using an included C++ header file), it will be used by the application. Otherwise it will have a first-run wizard and settings panel to set the API key at runtime.
I am planning on distributing my application in the Ubuntu Software Center. Is it possible to distribute binaries of the application with my own API key compiled into it, or would this break the GPL?
I wrote to the FSF, and here is their response:
Given the API key and the source code, people who receive the source
code of your software should be able to compile the same binary they got
from you and use it in the same way. From your description this seems to
be the case.
They should also be free not to use your API key or web service, but to
modify the software and connect it to a web service of their own choice
or design with their own API keys. I'm unfamiliar with the web service/s
in question and therefore I don't know if this is relevant to your
specific situation.
I hope this answer is of help. Please feel free to write back if you
have any further questions.
--
I am not a lawyer, the above is not legal advice
Regards, Yoni Rabkin
So I have this bit of a project planned for Windows Store and Android. Basically, a networking multi-tool coupled with a scripting engine to implement protocols and behavior. Ideal uses being things like "my embedded device uses this simplistic network protocol. I'd like to quickly prototype a way to control it from my tablet".
It's my understanding that the Android market should have no problem with this. However, the Windows Store policy includes a vague clause concerning remote code execution
3.9 All app logic must originate from, and reside in, your app package Your app must not attempt to change or extend the packaged content
through any form of dynamic inclusion of code or data that changes how
the application interacts with the Windows Runtime, or behaves with
regard to Store policy. It is not permissible, for example, to
download a remote script and subsequently execute that script in the
local context of your app package.
Of course, the scripting engine will be sandboxed and such and should be "safe"(completely intepreted, no reflection), but does it violate this policy?
If you build in your scripting engine, and only run local scripts, you will be good. However, if you were thinking to have a repository of scripts that could be downloaded and subsequently run, that would be in violation of the policy as we understand it.
Unfortunately I don't think anyone but someone on that team can answer that (or someone with direct experience in that) because of the closeness to the legal language. Have you tried the Windows Store Appl Publishing forum at: http://social.msdn.microsoft.com/Forums/en-US/windowsstore/threads
In the context of scripting engine example given, unless the app modifies the scripting engine after deployment on user's system such that the representation of protocol/behavior (the script artifact's format) is made to change then it'll be policy violation. Its as if you submit Python interpreter, and at some point in time it abruptly moves onto interpreting ecmascript.
Even though the API has been open since Mac OS X Leopard, there's surprisingly, and unfortunately, very little documentation on how to correctly use SMJobBless() for creating privileged helper tools. There are a lot of gotchas, even when copying code directly from Apple's sample project. Luckily, I've found my way around this, and have gotten the basis for my helper tool working.
However, it would seem that SMJobBless() only blesses the tool and copies it over, but doesn't run it. I've included code in my helper tool's main() function that should run, but doesn't (since NSLog() inexplicably doesn't work–according to the tiny bit of information I have found–I've tried syslog()ing some "Hello world" type strings, but nothing appears on the system console). There's no indication that the helper tool is launched at all.
The documentation is mostly useless. It simply says that after SMJobBless() is called, the helper tool is 'ready', with no indication of what 'ready' even means.
Furthermore, Apple's sample doesn't include any interprocess communication code, and doesn't explain how one is supposed to interact with the helper tool. Do you use Distributed Objects? Mach ports? Who knows? There's no official word on how to do it.
So, does anyone have any information on how to get this done? I've confirmed that the helper tool is installed, and authentication works, but I simply can't figure out how to launch the helper tool and communicate with it - there's simply such a gap in the documentation that this is a mystery for now. It's very frustrating; I can't be the only one with this problem (but there's little mention of it anywhere), and SMJobBless() obviously works somehow, since it's what Apple uses.
(Please don't mention AuthorizationExecuteWithPrivileges(). I'm not using it: it's deprecated, sure to go away, and is a major security hole. No thanks.)
XPC isn't an option if you're trying to elevate privileges (from https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html):
By default, XPC services are run in the most restricted environment
possible—sandboxed with minimal filesystem access, network access, and
so on. Elevating a service’s privileges to root is not supported.
SMJobBless will install a helper tool and register it with Launchd, as in the SMJobBless example provided by Apple. The trick to getting your helper tool to actually launch is to simply attempt to connect to your helper tool's advertised services.
There was a WWDC2010 example called ssd that demonstrated a simple launchd client/server model via sockets. It's not available from Apple any longer, but I've found a link here: https://lists.apple.com/archives/macnetworkprog/2011/Jul/msg00005.html
I've incorporated the dispatch queue handling in the server code from the ssd example into the helper tool in the SMJobBless example and can confirm that my helper tool is indeed running (as root) when my main app attempts a connection on the appropriate port. See the WWDC2010 video on Launchd to understand the other mechanisms with which you can communicate with your helper tool (other than sockets).
I'm not sure I can legally redistribute the modified sources I have, but it should be fairly straightforward to merge the two projects and get your helper tool running.
Edit: Here is an example project I wrote that uses a distributed object for communication between the app and helper: https://www.dropbox.com/s/5kjl8koyqzvszrl/Elevator.zip
In fact #KurtRevis's comment is right, you can use XPC APIs without using XPC services, and it is ideally suited to the job since.
Nathan de Vries has an excellent writeup of using XPC APIs with SMJobBless and has even modified the SMJobBless sample app to use mach XPC to both activate the job and for bidirectional communications:
http://atnan.com/blog/2012/02/29/modern-privileged-helper-tools-using-smjobbless-plus-xpc/
https://github.com/atnan/SMJobBlessXPC
Somewhat related to all this is avoiding unnecessary admin password prompts. See the following email list thread for ideas on how to check if the bundle version and code signature of an already installed helper match (which also allows you to remove a higher versioned helper in the case of a user downgrading):
http://www.cocoabuilder.com/archive/cocoa/309298-question-about-smjobbless.html
If you don't want to wade through the thread, here is a link to the modified SMJobBless sample project provided by Eric Gorr:
http://ericgorr.net/cocoadev/SMJobBless.zip
Also note that the ssd example mentioned in other answers here is still available online from Apple as part of the WWDC 2010 download bundle:
http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?code=y&source=x&bundleID=20645
Apple now (2015) has an "EvenBetterAuthorizationSample" that demonstrates installing a privileged helper tool and using the NSXPCConnection API to communicate between the app and the helper tool:
https://developer.apple.com/library/mac/samplecode/EvenBetterAuthorizationSample/Listings/Read_Me_About_EvenBetterAuthorizationSample_txt.html
The README is some of the best (only?) documentation of SMJobBless() available.
I feel your pain and am in the same boat. I'm in charge of the Mac version of an app that needs to perform various system configuration tasks. Of course some of these task need to be done with administrative rights. I started by using the sample code from BetterAuthorizationSample. It was a major pain to implement but it seemed to work. But then ran into cases where it would crash on some systems. I didn't understand everything that the BAS code did and my own lack of coding experience probably contributed to the problems. So I had to remove these privileged functions from my app.
Apple doesn't seem to care about the lack of documentation. See this message from the creator of the ServiceManagement framework. From his comments, I assume that XPC is the "intuitive replacement" he is referring to, but since it is only available on Lion, you'll still have to find another solution for Snow Leopard or earlier clients. It's also not clear to me if XPC can be used for privileged helpers (system level tasks that require admin or root access) or is just intended for privilege separation within your own app to make it more secure.
The BAS documentation is in desperate need of an update, but it also doesn't appear to be a top priority.
Now I'm attempting to rewrite my app from the ground up. Professional Cocoa Application Security by Graham Lee gives some insight on how to do use privileged helpers with SMJobBless, but doesn't go into much detail about on-demand access to launchd jobs.
So here's what I've been able to find:
If you want to launch your privileged helper on demand, you'll have to use an IPC socket. You should add a Sockets entry to your helper's launchd.plist. After you install the app with SMJobBless, the helper will need to "check-in" with launchd (via LAUNCH_KEY_CHECKIN) to get the socket file descriptors.
Sadly, the only mentions of LAUNCH_KEY_CHECKIN seem to be in the SampleD and BAS sample code.
I don't have any experience with sockets, so that's my roadblock at the moment. I'd like to use the highest level API I can, so I'm trying to find out if I can use any Objective-C classes for this (like NSStream).
You might find the launchd developers mailing list helpful. Another XPC option I just found out about is XPCKit. It's worth a look.
HTH
I wrote a blog post on this a few months ago, which included a cleaned up version of Apple's SMJobBless sample. Might help...
http://www.bornsleepy.com/bornsleepy/os-x-helper-applications
Itai have you looked at the SMJobBless sample code from WWDC 2010? It includes a helper tool and app to bless it.
https://developer.apple.com/library/mac/#samplecode/SMJobBless/Listings/ReadMe_txt.html#//apple_ref/doc/uid/DTS40010071-ReadMe_txt-DontLinkElementID_3
Its README file says:
This sample as it stands does not actually run the helper tool. The following samples show how to [sic] a launchd job and set up interprocess communication:
ssd (Doesn't seem to be online anymore. Was part of the WWDC 2010 sample code.)
BetterAuthorizationSample