On Mon, Jun 14, 2010 at 8:36 PM, John Engelhart <email@hidden>wrote:
> Bad News, Everyone! -- Professor Farnsworth
> I've received nearly half a dozen reports that iOS4 applications using
> RegexKitLite are now being rejected when they are submitted for AppStore
> approval due to violating section 3.3.1.
> I don't wish to speculate publicly as to why at this point due to the fact
> that iOS 4 is still under NDA. Needless to say, if you application uses
> RegexKitLite, you should prepare for the fact that it will likely be
> rejected at this point.
Since the documentation for iOS 4 is now publicly available at
http://developer.apple.com/iphone/library/ , I thought I'd give an update.
The reason why applications using RegexKitLite were being rejected were due
to violation section 3.3.1, the use of private and/or undocumented API's,
specifically the use of "uregex_clone()" in RegexKitLite 4.0, and ONLY in
Again, the only version of RegexKitLite that was causing rejections was
RegexKitLite 4.0. Versions of RegexKitLite < 4.0 would not cause your app
to be rejected.
To the best of my knowledge, uregex_clone() IS a "public" API and is
documented in the uregex.h headers. I believe that Apples tool that
automatically scans submitted applications for private and/or undocumented
API use was incorrectly flagging apps that made use of uregex_clone(), but
this is speculation on my part.
The boring details---
RegexKitLite 4.0 introduced support for Blocks. In order to get around some
tricking multithreading issues, RegexKitLite 4.0 needs to use the
uregex_clone() function to make a copy of the compiled regex that the Block
will be using. RegexKitLite 4.0 was the first version to use
uregex_clone(), and the code that calls uregex_clone() is only compiled if,
and only if, RegexKitLite automagically detects support for the new Blocks
feature / functionality.
iOS4 is the first iPhone / etc OS to support Blocks. This feature was, to
the best of my knowledge, still under NDA, which is why I was so vague in my
Although this part is speculation on my part, I believe this led to a series
of unfortunate coincidences that caused all the trouble. Reports of
applications being rejected only started very shortly after Apple announced
that they were now accepting applications for iOS 4. I suspect that
applications using RegexKitLite 4.0 and were targeting a SDK < iOS 4.0 were
not triggering the automagic Blocks detection logic, so the code that called
uregex_clone() was never compiled in to an application that was submitted up
till the point where iOS 4 applications were being accepted.
Shortly after I posted my original message to cocoa-dev, reports of
applications being rejected stopped coming in. At this point in time, I
don't have positive confirmation that this means that uregex_clone() is no
longer being flagged as a 3.3.1 violation, but that is a possibility.
If you want to use RegexKitLite, you have three options:
1) Use RegexKitLite 3.3, the last version before RegexKitLite 4.0. I have
had positive confirmation that this approach DOES work.
2) Use RegexKitLite 4.0 and compile with -DRKL_BLOCKS=0, which forcibly
disables the new Blocks functionality inside RegexKitLite, and therefore the
call to uregex_clone() will not appear in your binary. I have had positive
confirmation that this approach DOES work.
3) Use RegexKitLite 4.0 without -DRKL_BLOCKS=0 and hope that Apple has
resolved the problem on their end. Based on reports, your application
should be rejected "within minutes" if it is due to 3.3.1 / uregex_clone().
If anyone has submitted an app "sometime after June 14th, 2010" that used
RegexKitLite 4.0 and DID NOT disable Blocks functionality with
-DRKL_BLOCKS=0, and can verify that uregex_clone() exists in your submitted
application via something like "shell% nm -m
/path/to/ihpone/binary.App/YourApp | grep uregex_clone", could you please
let me know?
I have yet to dig in to the new iOS 4 NSRegularExpression functionality, or
its Blocks iteration technique. I can tell you that I designed
RegexKitLites Blocks enumeration functionality to use as little memory as
possible during enumeration. The details are spelled out in
In fact there is even an enumeration
option, RKLRegexEnumerationFastCapturedStringsXXX, which allows for both
extremely fast and "no memory usage" strings to be passed to the supplied
Block provided that certain caveats are observed (see the documentation for
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden