I update my application from version 1.0 to version 1.1 and I submit my iPhone App to Apple a week ago .Few minutes ago I got this Report from Apple that
We found that your app uses one or more non-public APIs, which is not in compliance with the App Store Review Guidelines. The use of non-public APIs is not permissible because it can lead to a poor user experience should these APIs change.
We found the following non-public API/s in your app: setContentToHTMLString.
If you have defined methods in your source code with the same names as the above-mentioned APIs, we suggest altering your method names so that they no longer collide with Apple's private APIs to avoid your application being flagged in future submissions.
Additionally, one or more of the above-mentioned APIs may reside in a static library included with your application. If you do not have access to the library's source, you may be able to search the compiled binary using "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 techniques can help you narrow down where the problematic code resides.
Please tell me, What to do to resolve it?
If you are using:
setContentToHTMLString
Don't use it anymore, if its a private API method and Apple doesn't want you to use it
If you are using a method in the private API, then you will have to find an alternative function. Either from a library or write your own.
If you have written a function named setContentToHTMLString then rename the function (you might like to prefix it- perhaps mySetContentToHTMLString) and change all of the usages over to your new name.
Then you'll be able to resubmit.
setContentToHTMLString is an undocumented method of UITextView. You may need to remove it. You are NOT allowed to access the private API.
Related
I'm trying to build some features using function builders (#_functionBuilder included in Swift 5.1).
I know using private framework APIs is disallowed, but does the same apply for private language features?
I have tried looking this up but couldn't find any relevant information on the topic specifically addressing this. Grateful if anyone can help me with this.
In order to build a Google Assistant app, Google provides two different APIs as part of their node.js actions-on-google library :
ActionsSdkApp
DialogflowApp
There have a common interface, but I don't understand what the difference is between the two and why I would use one or the other.
In short, these two objects provide similar (although not identical) methods to handle requests and provide results for two default ways Google allows you to build an Action for the Assistant.
The DialogflowApp object is the one you will likely use for most purposes. It is meant to work with the Dialogflow tool, letting it handle the Natural Language Processing (NLP) components and passing the results, where appropriate, to your webhook. It provides a few methods that are specific to Dialogflow features, such as Contexts, and maps other things to the response format that Dialogflow expects.
The ActionsSdkApp is meant to be used if you are using your own NLP and your webhook is getting things directly from Google (without using Dialogflow). If you need to build an actions.json file, you're using the Actions SDK.
Both have common methods and idioms, such as app.ask() and app.tell() and mapping app.data to session storage and so forth, even if the details of implementing these are different for each type.
You should be using the one that matches the tool that you're using. For most new users - that will likely be Dialogflow and the DialogflowApp object.
Update
Note that the API in the question, the specific objects asked about, and the specific methods talked about in my answer are for the previous version of the library.
The concept of when to use the ActionSDK vs Dialogflow objects in the current library still hold, so the concept behind this question and answer are still valid, but the technical details have changed.
Update - Jun 2020
The library in question is now deprecated, since it no longer works with the current version of Actions on Google (Actions Builder/SDK AoG v3). It still works with Dialogflow (which uses AoG v2) and if you're still using the AoG v2 Actions SDK.
IN SIMPLE TERMS
Use the Actions SDK for one-shot apps. These are apps that provide the required answer directly after being invoked and then stop. They give you just this one result. A typical example would be setting a timer to ten minutes.
Use the Dialogflow for all other apps, for those that are really conversational, where there are multiple paths to follow and where you want your user to provide more information during the conversation.
I see KissXML and Googles GData are both deprecated.
Can/should we still use them ?
What are the alternatives?
I want to be able to read and write xml with an XSD schema on iOS.
Any suggestions?
The gdata-objectivec-client project is not deprecated, though Google is generally using JSON for newer APIs.
The library's support for XML is wrapped up essentially in one class file, GDataXMLNode, which simulates Apple's tree-style NSXML API and builds on libxml2. While GDataXML is tailored to the needs of the library, it's usable outside of the library as well.
For your own app, it does not really matter if any particular XML library continues to be supported, so long as the library suits the needs of your app, and you have the source code to do any necessary maintenance.
I don't know if Google's GData is deprecated. As long as it parse XML correctly, I don't see why you can't/shouldn't use it. I'm using it.
I recently read about Dynamic Creation as one of the design pattern in Cocoa. However, I don't really understand how it works. So I need clarification from you who have implemented in your design.
What is it? Why and when would you use this design pattern?
I have read that you use NSClassFromString() to access the class. I assume that I use this when I want to use class that doesn't exist within the project I'm working on. Usually when I want to use certain class, I imported them in header. Does using this approach skip the #import process?
Class JavaArrayList = NSClassFromString(#"java.util.ArrayList");
I quote the code above as example. If do according to the code above, that means I can create a new JavaArrayList class and use the methods in it right?
JavaArrayList *foo = [[JavaArrayList alloc] init];
[foo useMethodBelongJava:doWhateverTask];
What are the benefits of using this design pattern? Especially in iPhone Development.
Your example appears to be using that pattern to instantiate a Java class. In the old days (up to about MacOS 10.4 I think), Apple had some technology called the Cocoa-Java Bridge, which let you use Java classes within Objective-C code. You had to instantiate them in the manner specified, because they didn't have Objective-C header files to import.
However, as of Snow Leopard, the Java Bridge no longer exists, so the code in your question won't work any more.
The recommended solution for calling a Java class from Objective-C is now JNI. Take a look at this question if that is what you're trying to do.
What is it? Why and when would you use this design pattern?
Coming back to NSClassFromString, it has other uses besides instantiating Java classes (which, as I mentioned, it doesn't do any more!). For an example, recently I wrote a library for parsing the response from a web service. In order to make it work with different web services, I had it read in a configuration file that described the data format it was expecting. For each field in the web service, my configuration file specified which Cocoa class to instantiate. Thus, in my code, I had a Cocoa class name as a string. To instantiate the object I wanted, I used NSClassFromString to turn it into a Class object.
Usually when I want to use certain class, I imported them in header. Does using this approach skip the #import process?
It can do. NSClassFromString will instantiate any class that is present at run time, so you don't need the header to be able to use it. If you don't have the header, you'll get a bunch of warnings of "may not respond to selector" whenever you try and use your newly instantiated class, as the compiler doesn't have enough information to be helpful. However, in many circumstances where NSClassFromString is useful, the header files aren't available.
See this link:
need advise about NSClassFromString
The only real benefit for iPhone was being able to reference classes from newer APIs and still target the old APIs. Since 4.0 you can do this anyway by setting the deployment target of your project. I can't really see any reason you would use it for iPhone programming any more.
This would only work for objective-C classes. You can't import java objects into your iphone app.
I'm pretty new to static libraries. I recently created one library because I have a lot of source code, and the updates of my projects ended as a nightmare.
So, this is a static library for iPhone.
My question is quite simple : I use this library for me and my company. But, how can I use a portion of it to make projects for my clients ? For example, I have a class which reads PDF or Photos, depending of the initialization parameters.
I don't want my client able to use the photo part, just by seeing the headers. How can i achieve that ? I thought to remove some parts of the headers i will give to my client, but i'm pretty sure there are better options.
Thanks
Presuming you are using objective C code, it will not be enough to just remove the headers since a smart client will be able to "ask" the code about its interface by using class-dump.
So if you want to be certain that the code is not available to your clients, you need to remove it completely from your static library.
Update:
CocoaReverseEngineering provides information about how to access the hidden information in frameworks and libraries. But you can also use it so you know what's possible and thus preventing it happening.