Recently I've heard that Apple is using tools to search for references to undocumented APIs and are rejecting iPhone apps from the App Store because of it.
The popular Three20 framework is causing people to get rejected.
I also just saw that the KissXML library has also caused rejection.
I'm looking for an Objective C DOM-based XML parser and am now considering TouchXML.
Can anyone confirm that TouchXML does not reference any undocumented APIs? I don't want to risk an app rejection based on this.
I can confirm that I've included no private frameworks in several projects that use TouchXML that have all become apps in the App Store. I would ask the question at the google code site to make sure, but John Wight who wrote the library writes very clean and tight code. It would surprise me if he used any undocumented APIs.
Also, I wouldn't worry about it too much. Build your app and submit it and if it gets rejected, fix it then. Apple will even tell you what API you're referencing that you're not supposed to if that is the case. If you have to go through their bureaucracy anyhow, you might as well benefit from it by making them tell you what's wrong. Also, keep in mind that probably everyone gets rejected at least once--especially if it's your first app. ;-)
Tidy does. My app was just rejected from the app store on that basis.
"3.3.1 Applications may only use Documented APIs in the manner prescribed
by Apple and must not use or call any private APIs."
The following non-public APIs are included in your application:
tidyBufAlloc
tidyBufFree
tidyBufInit
tidyCleanAndRepair
tidyCreate
tidyOptSetBool
tidyParseBuffer
tidyParseString
tidyRelease
tidySaveBuffer
tidySaveString
tidySetCharEncoding
tidySetErrorBuffer
tidySetOutCharEncoding"
I know that there is at least one app on appstore which uses TouchXML. But during development process I found some bugs there, so I try to find some alternative now.
Consider using libxml2. It has a steeper learning curve, but the speed and flexibility are worth it.
I've just had an app rejected precisely because it uses touchXML
Related
I got following message from app review team, now i am confused how to fix it and what is the problem exectly any help would be appreciated.
2.5
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:
currentHost
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.
We appreciate that you may have made the precautions in your code for
using non-public APIs, however, there is no way to accurately or
completely predict how an API may be modified and what effects those
modifications may have. For this reason, we do not permit the use of
non-public APIs in App Store apps.
If there are no alternatives for providing the functionality your app
requires, we encourage you to file an enhancement request. Or, try
working with the Apple Developer Technical Support team to explore
alternative solutions.
On occasion, there may be apps on the App Store that don't appear to
be in compliance with the App Store Review Guidelines. We work hard to
ensure that the apps on the App Store are in compliance and we try to
identify any apps currently on the App Store that may not be. It takes
time to identify these occurrences but another app being out of
compliance is not a reason for your app to be. For discrete code-level
questions, you may wish to consult with Apple Developer Technical
Support. Please be sure to:
include the complete details of your rejection issues
prepare any symbolicated crash logs, screenshots, and steps to reproduce the issues for when the DTS engineer follows up.
For information on how to symbolicate and read a crash log, please see
Tech Note TN2151 Understanding and Analyzing iPhone OS Application
Crash Reports.
If you have difficulty reproducing this issue, please try testing the
workflow as described in
https://developer.apple.com/library/ios/qa/qa1764/Testing Workflow
with Xcode's Archive feature".
any help would be appreciated.
It looks like you are using this method to get your current ip in your application. You can use other alternatives like in the link mentioned:
https://stackoverflow.com/a/6535436/1111384
You can use this to get current ip.
Hope this resolves your issue.
A client do not want to consider MonoTouch for a new project.
MonoTouch.info has a long list of apps, but I have not found any on the caliber that can convince a client too choose a technology. The client has seen the list, and actually use the bland screenshots as an argument against MonoTouch.
Where can I find examples of applications useful as motivation. High profile apps created using MonoTouch, the apps you call home about. The apps that made it to the top 25 lists in their category.?
I responded on Twitter but thought I'd reply properly here;
The first app I will mention is iCircuit - http://icircuitapp.com/ - this application is featured on the Apple website here - http://www.apple.com/ipad/business/apps/index.html#workflow-icircuit - and is a pretty good seller.
Diggify is a Digg application which hit the top #8 sold application in Canada apparently - http://www.intomobile.com/apps/diggify/359756952/
An application that I built myself (it's a little old now admittedly) but I do think that it looks rather nice - http://bit.ly/gfxmasappstore :)
London Bike App is another nice looking application - http://www.londonbikeapp.com/
Update: Wow, this is an old question, there's a whole bunch of great apps using MonoTouch at http://xamarin.com/apps
Hope this helps,
ChrisNTR
I know of a couple apps that were built using Monotouch and sold very well but due to the uncertainly surrounding the terms when MT first came out and later the 3.3.1 mess the devs didn't make a big fuss out of it. I suspect they aren't the only ones not publicizing what technology they used to make their app.
If your client is using a handful of screenshots on a website as the reason to rule out using Monotouch then you might want to rethink your pitch. Whether or not an app has been developed in native Objective-C or C# via Monotouch makes no difference on the overall design or appearance because both rely on the CocoaTouch framework for UI. Being able to deliver an app that meets your client's idea of what makes a great app has nothing to do with the language you use and has everything to do with your ability to translate the essence of their ideas into a solid design and UX. Sell that, not the framework.
I found this article to be helpful when I'm trying to explain to others why I use Monotouch over native objective-c.
"Why we chose MonoTouch to write the Diggify iPhone app"
Apple doesn't want anyone to create iPhone apps outside of the Xcode/Objective-C environment. How can they actually enforce this?
If the non Xcode IDE, for example Unity, compiles to an iPhone executable, how will Apple know which dev environment you used to create the app? Can they have Xcode compile some sort of signature into the executable that no one knows about?
For tools such as unity, corona, flash, and other platforms used to 'generate' iphone apps, Apple may be able to 'decompile' and examine your app (look at patterns of generated functions, etc). From this, they might be able to guess that your app was generated with such a tool.
In the limit, this is impossible. Consider the following: I write some script code to generate a bunch of objective-c code. Then I manually import the objective-c files into xcode and build the app. How would apple be able to distinguish the script-generated code from human-written code? Maybe I just tend to write code that happens to look machine-generated. There's no way for apple to determine whether the code was "originally written in objective-c, c, c++ or javascript" or not, yet this would still, technically, violate the agreement. That's why the 3.3.1 part of the agreement is nonsense.
Most automated systems do things a particular way, which isn't hard to detect. If you've ever looked at the PHP or JavaScript code Adobe Dreamweaver generates, for example, you know how easy it is to find stuff like this.
Apple is doing this to prevent people from using Adobe's Flash development framework. It should also be noted that Apple's decision to limit Application Frameworks like this is causing the DOJ/FTC or some government agency to start an informal inquiry into monopolistic practices.
From this article:
"According to the Post's Hollywood source, Apple's ban of Adobe's Flash technology on the iPhone and iPad is what prompted the government to poke around. "
They really don't have an issue up until now with other frameworks because Adobe didn't have one based with the Flash environment. Now that there is one, Apple is going to restrict anything that talks/looks/smells/acts like an Adobe Flash app on the iPhone. In my opinion, they won't do anything to other frameworks, but they'll enforce the rule just for Adobe. Which brings up the whole monopolistic practices thing.
I believe that many of these translator tools have some kind of common runtime function library which take care of the portions that could not be translated 1:1. Those function could then be pretty constant regardless of your application. That way there would be no real need to decompile the app. but instead just look for usage of those function signatures.
FWIW I find the whole idea of limiting user's choice of tools is a bad move.
I'm not all that familiar with Apple's iPhone development system, but I'm trying to figure out if theres a way for developers who create custom iPhone apps to update their apps on a mass scale. For example, would a company who publishes hundreds of apps have to resubmit every app they've made manually if they find a minor bug that affects all their apps (assuming they have used a template)? Or is it possible to somehow use or build a custom program that can make this process easier, by automatically generating or updating apps? I don't believe Apple has an API or anything, but it just seems like it would be a nightmare for these developers to fix bugs, and thought maybe I was missing something.
Thanks in advance for your help!
Apple provides no way to automate this. In theory you could write a program to simulate a browser to login and upload new binaries for you, but I'm not sure Apple would like that very much, and it would be a lot of work.
In addition, one might argue that if the apps are similar enough to warrant this automation, it should probably be one app instead of many. But that may be an over generalization without knowing your use case.
There's the Application Loader
http://itunesconnect.apple.com/apploader/ApplicationLoader_1.2.dmg
(requires login)
It doesn't do bulk uploads, but it does provide a maybe more accessible interface.
Isn't there that separate application that you can use to talk to iTunesConnect? (Though I still don't think it's possible to do mass updates.)
I know it's been asked before (like here), but is there way to natively use XSLT on the iPhone? If not, and I need to use libxslt, is there any documentation/tutorial of how to use it on the iPhone?
EDIT:
I've decided to use libxslt. What files are necessary to include? I haven't found any tutorials of examples of use on the iPhone, and I'm unsure of how to approach it. Any help would be appreciated.
Thanks in advance.
Cannot use libXSLT on iPhone. Not as of today. App will be rejected. libXSLT is built into the iOS andd COULD be called - but this is a private API of the iPhone and will cause rejection. If you compile the libxslt library yourself and statically link it to your app, you will still get rejected. Many people have reported this bug in the app review process but nothing has yet changed.
It depends how you want to use XSLT; not sure what you mean by "natively". If you're just embedding a browser, MobileSafari will interpret XSLT for you.
If you're just converting one XML document into another for processing, libxslt is not a bad choice. There's no difference using libxslt on the iPhone from any other platform. Given Apple doesn't include headers for it, it is likely they don't want you using the bundled copy. You are better off compiling a copy into your application instead, against the provided libxml2 library.
If you want a more specific answer you may wish to pose a more specific question. :-)