Heads up: Apple store rejection for apps using three20

[Pradeepta Dash]

Apologies if this has been reported earlier. 

An app of mine got rejected because three20 uses private API/ivars.

- UITouch._locationInWindow
- UITouch._phase
- UITouch._previousLocationInWindow
- UITouch._tapCount
- UITouch._timestamp
- UITouch._touchFlags
- UITouch._view
- UITouch._window

--pradeepta

[Mads Rasmussen]

That's bad !!

Any workarounds? are the use of these private APIs isolated or used in all classes?

Mads

--
Mads Rasmussen
Creative-Apps
Chief Technology Officer
------------------------------------------
mads.ra...@creative-apps.com
www.creative-apps.com
Mobile: 55 11 7533-6292
Mobile: 55 11 9407-4493
Skype: rasmussen.brazil2
@mazebr

[Pradeepta Dash]

To be fair the source code in three20 calls it out

"/**

 * WARNING: This depends on undocumented APIs and may be fragile.  For testing only.

 */

"

From UIViewAdditions, I am going to remove 

a) - (void)simulateTapAtPoint:(CGPoint)location

b) UITouch (TTCategory)

That *should* be enough.

I will let everyone know how that works out.

--pradeepta

[uprise78]

Ummmm....those arent private. They are listed right in the UITouch
docs:

http://developer.apple.com/iphone/library/documentation/UIKit/Reference/UITouch_Class/Reference/Reference.html

What you may be referring to is the simulateTapAtPoint: method and the
UITouch/UIEvent categories. Just remove the simulateTapAtPoint:
method and everything it references which is just the UITouch
(TTCategory) and UIEvent (TTCategory). You can get extra efficient and
remove the UIEventFake class.

[Pradeepta Dash]

Here is the code : http://github.com/joehewitt/three20/blob/master/src/UIViewAdditions.m

@implementation UITouch (TTCategory)
 

- (id)initInView:(UIView *)view location:(CGPoint)location {
  if (self = [super init]) {
    _tapCount = 1; <= BAD
    _locationInWindow = location; <= BAD
    _previousLocationInWindow = location; <= BAD
 

    UIView *target = [view.window hitTest:_locationInWindow withEvent:nil];
    _view = [target retain]; <= BAD
    _window = [view.window retain]; <= BAD
    _phase = UITouchPhaseBegan; <= BAD
    _touchFlags._firstTouchForView = 1; <= BAD
    _touchFlags._isTap = 1; <= BAD
    _timestamp = [NSDate timeIntervalSinceReferenceDate]; <= BAD
  }
  return self;
}
 

- (void)changeToPhase:(UITouchPhase)phase {
  _phase = phase; <= BAD
  _timestamp = [NSDate timeIntervalSinceReferenceDate]; <= BAD
}
 

@end

[Matt Vague]

So were supposed to remove this from three20??

On Oct 26, 3:47 pm, Pradeepta Dash <pradee...@gmail.com> wrote:
> Here is the code :http://github.com/joehewitt/three20/blob/master/src/UIViewAdditions.m
>
> @implementation UITouch (TTCategory)
>
> - (id)initInView:(UIView *)view location:(CGPoint)location {
>   if (self = [super init]) {
>     _tapCount = 1; <= BAD
>     _locationInWindow = location; <= BAD
>     _previousLocationInWindow = location; <= BAD
>
>     UIView *target = [view.window hitTest:_locationInWindow withEvent:nil];
>     _view = [target retain]; <= BAD
>     _window = [view.window retain]; <= BAD
>     _phase = UITouchPhaseBegan; <= BAD
>     _touchFlags._firstTouchForView = 1; <= BAD
>     _touchFlags._isTap = 1; <= BAD
>     _timestamp = [NSDate timeIntervalSinceReferenceDate]; <= BAD
>   }
>   return self;
>
> }
>
> - (void)changeToPhase:(UITouchPhase)phase {
>   _phase = phase; <= BAD
>   _timestamp = [NSDate timeIntervalSinceReferenceDate]; <= BAD
>
> }
>
> @end
>
>
>
> On Mon, Oct 26, 2009 at 3:38 PM, uprise78 <des...@gmail.com> wrote:
>
> > Ummmm....those arent private.  They are listed right in the UITouch
> > docs:
>

> >http://developer.apple.com/iphone/library/documentation/UIKit/Referen...

[uprise78]

To be safe, you probably should. That being said, I have a few apps
in the app store that have that code in them. It just depends on your
luck with the Apple employee who does your review.

[neptune2000]

Can anyone else confirm rejection?

[neptune2000]

Can anyone give a list of "safe" changes that are going to satisfy the
requirement and not break everything?

Notice that three20 is included in the Facebook app.

[Jonathan Saggau]

Is it perhaps time for a #define APP_STORE_SAFE ? :)

[Mike D]

Safe changes are listed below in one of my previous replies.

[Nazar]

Thanks for the heads up, Pradeepta

[neptune2000]

What about the call to simulateTapAtPoint in UIWebViewAdditions.m ?

On Oct 26, 3:38 pm, uprise78 <des...@gmail.com> wrote:
> Ummmm....those arent private.  They are listed right in the UITouch
> docs:
>

> http://developer.apple.com/iphone/library/documentation/UIKit/Referen...

[Mike D]

you will need to remove that as well or your project wont compile.

[neptune2000]

I get that, but removing the call is going to pretty much break the
function that uses it.

[Mike D]

Nothing in three20 uses it. As long as you arent using it then it
won't hurt anything.

[neptune2000]

That's good. So if I remove

- (void) simulateTapAtPoint:(CGPoint_ location

- (id)initInView:(UIView *)view location:(CGPoint)location {

- (void)changeToPhase:(UITouchPhase)phase {

- (void)simulateTopElement:(NSString*) query {

I should not be getting any compilation errors, right?

I guess it is time to try.

[neptune2000]

That seems to do it. No compilation errors.

[Nick Partridge]

Related to this rejection, I just had an app rejected with the following feedback:

> The non-public APIs that are included in your applications are the
> following:
> - firstResponder
> - undocumented, Private UITouch instance variables

I'm going to assume that the UITouch instance variables is the same issue as Pradeepta's, however the firstResponder problem is troubling.

That selector is used whenever Three20 (or otherwise) needs to know if the keyboard is visible, or to scroll the first responder into the view. I'll have to strip all that functionality out of three20 to use it.

A greater concern though, is that Three20 is using private APIs without flagging it to the consumer of the library. As much as I find three20 to be a great productivity to boost to working with cocoa, we're going to be phasing it out of our applications.

-Nick

[taco]

Ouch.

I've just started adopting Three20. Abandon ship?

[Mike D]

I sure wouldn't abandon ship. TTStyle alone is more than enough
reason to keep using it let alone all the other built in goodies.

[Pradeepta Dash]

I got rejected for the 2nd reason, exact same verbage.

However, I took out the all calls to firstResponder as well and re-submitted the app just now (just to safe)

Thanks for the heads up.

--pradeepta

[Lyndsay Hackett]

Pradeepta & Nick, were the calls ones that you'd made inside your own
code or were they calls that are made in the Three20 libraries? In
other words, will just having the library in your app trigger a
possible rejection or do you need to make those calls yourself to
trigger the rejection?

Thanks

Lyndsay

[siong1987]

Hi Pradeepta,

Is it possible for you to fork a branch on github to share your SAFE
three20 library with us?

Thank you.

On Oct 28, 6:53 pm, Pradeepta Dash <pradee...@gmail.com> wrote:

[Nick Partridge]

For firstResponder, any TTViewController that has a keyboard displayed within it will call the private selector. Given this is the base for every view controller in three20... :-s . We are definitely calling this code.

However, I'm confident we're not using the code that accesses the UITouch private variables and yet they have included that in the rejection notice. I suspect they're using static analysis to find the usages and that just having the code within your project will be enough for a rejection.

-Nick

[David Morford]

The changes are straight forward. To get rid of firstResponder calls,
do the following:

1. Delete the TTIsKeyboardVisible function in TTGlobal.h/m. Nothing
calls it.

2. Delete TTMessageController. It accounts for the majority of the
calls and MFMailComposeViewController in MessageUI basically makes it
obsolete.

3. Replace scrollFirstResponderIntoView in UITableViewAdditions with
this (or something similar):

-(void) scrollFirstResponderIntoView {
NSIndexPath *selectedRowIndexPath = [self indexPathForSelectedRow];
if (![[self indexPathsForVisibleRows]
containsObject:selectedRowIndexPath]) {
[self
scrollToNearestSelectedRowAtScrollPosition:UITableViewScrollPositionMiddle
animated:YES];
}
}

This breaks the TTTableControlItem... but they are kind broken in the
present form anyway so just add UITextFields directly to a
TTTableViewItem or don't use TTableItem/TTTableViewController for
views that need interaction. I would guesstimate that anything that
wants to scroll to TTStyledNode might be affected as well but can not
fathom where they might be used realistically other than a
TTStyledTextTableItemCell that might want to scroll to a particular
TTStyledNode subclass instance in its TTStyledTextLabel.

4. In frameWithKeyboardSubtracted in UIViewAdditions.m, Comment out
the line below (302 in e8ecb80) and the matching bracket:

if ([self.window performSelector:@selector(firstResponder)]) {

I removed these and the UITouch code from my own branch as soon as I
saw them, ages ago it seems now. I maintain my own branch manually,
incorporating changes by hand so that I am always aware of what is
going on inside the code. I did test them with the latest master,
e8ecb80, using TTCatalog. I found nothing that seemed broken aside
from scrolling for TTTableControlItem instances. There are prolly some
other issues... make the changes and report them back here. This is
what open source libraries are all about...

Apple needs to add an open source libraries and frameworks category to
the design awards at WWDC next year and Joe should win on iPhone OS
for Three20. That having been said, Three20 encompasses a number of
advanced concepts and anyone contemplating using it for production
applications, your own or for your clients or company, should take the
time to fully understand it.

Cheers,
David

[Joe Hewitt]

I got a phone call from Apple today about this issue. They asked me
to remove simulateTapAtPoint and related code due to their static
analyzer automatically flagging it and rejecting apps. I just checked
in some changes which wrap this code in an #ifdef DEBUG so they can
still be used for their intended debugging purposes.

[Nick Partridge]

That having been said, Three20 encompasses a number of
advanced concepts and anyone contemplating using it for production
applications, your own or for your clients or company, should take the
time to fully understand it.

 

Indeed, the need to audit all your dependencies is a valuable lesson I've just learned! Hopefully other's can benefit from my experience.

The snapshot I've been using is a50859aa3, dated July 8. I assumed that this would have been through the App Store a number of times already, and was really relying on a crowd-sourced audit. I guess apple have a new tool for checking for this.

 

[Jonathan Saggau]

In case anybody ever wants to get first responder by searching the view
hierarchy:

//
// UIWindow+ttFirstResponder.h
// Three20
//
// Created by jonathan on 10/29/09.
// Copyright 2009 __MyCompanyName__. All rights reserved.
//

#import <UIKit/UIKit.h>

@interface UIWindow (ttFirstResponder)

-(UIView *)ttFirstResponder;

@end

// UIWindow+ttFirstResponder.m

#import "UIWindow+ttFirstResponder.h"

UIView * recursiveFirstResponderSearchInView(UIView *viewToSearch)
{
UIView *fResponder = nil;
if([viewToSearch isFirstResponder])
{
return viewToSearch;
}
for (UIView *view in [viewToSearch subviews]) {
if([view isFirstResponder])
{
fResponder = view;
break;
}
UIView *someOtherView = recursiveFirstResponderSearchInView(view);
if([someOtherView isFirstResponder])
{
fResponder = someOtherView;
break;
}
}
return fResponder;
}

@implementation UIWindow (ttFirstResponder)

-(UIView *)ttFirstResponder;
{
UIView *responder = recursiveFirstResponderSearchInView(self);
return responder;
}

@end

[Eelco Lempsink]

I got two apps accepted this week, both using the September 8 version
(969d6f6, extended with some bugfixes).

--
Regards,

Eelco Lempsink

[David Morford]

Good fix Jonathan. Much thanks for sharing.

[David Morford]

I should add that TTMessageController does not use firstResponder WRT
UIWindow. It just has text strings to store which text field was the
firstResponder during persist/restoreView calls. Should have looked
closer in Project Find but I never use the class and don't include in
my local project variant.

Cheers,
David

[neptune2000]

What changes did you do to eliminate the reliance on calls to
firstResponder? Would you mind being more specific?

On Oct 28, 6:53 pm, Pradeepta Dash <pradee...@gmail.com> wrote:

[Adam Jack]

First, David (Morford) thank you for your steps to removing the offending calls.

Second, Jonathan, this is very useful thanks. I'll be using it to update David's step #4. 

4. In frameWithKeyboardSubtracted in UIViewAdditions.m, Comment out  
the line below (302 in e8ecb80) and the matching bracket:

     if ([self.window performSelector:@selector(firstResponder)]) {

I found that ignoring detecting if a keyboard was raised meant things overlays (loading, error, etc.) fit into the space above a keyboard, and failed to cover the whole visible view. At first I opted to comment out the whole section this "if block" contained (since I don't have such cases w/ a keyboard) but I like the idea of fixing it properly with this.

regards,

Adam

--

Share Wildlife: http://wildobs.com

iPhone Application: http://wildobs.com/about/iphone

[wuf810]

I'm confused! Sorry but I am.

So a question: will Joe's latest commit take care of the issue of a
potential rejection or should I consider changing the firstResponder
code?

If the latter, can someone be a bit more specific....I can see
Jonathan's UIWindow Category fix but where am I suppose to implement
it.

Sorry still early days for me and I need a bit of hand holding :-)

TIA, Michael.

[Mike D]

Hi ifdefed only part of the code. The whole GSEvent and UITouch
category needs to get ifdefed as well.




On Fri, Oct 30, 2009 at 7:14 PM, Cory <cory.i...@gmail.com> wrote:
>
> I just had a few Apps that were using Three20 get rejected too. I
> think we need to get Joe to fix it up in the main development line for
> all future apps...

>
> On Oct 28, 8:25 pm, Nick Partridge <nkp...@gmail.com> wrote:
>> For firstResponder, any TTViewController that has a keyboard displayed
>> within it will call the private selector. Given this is the base for every
>> view controller in three20... :-s . We are definitely calling this code.
>>
>> However, I'm confident we're not using the code that accesses the UITouch
>> private variables and yet they have included that in the rejection notice. I
>> suspect they're using static analysis to find the usages and that just
>> having the code within your project will be enough for a rejection.
>>
>> -Nick

>> On Thu, Oct 29, 2009 at 12:13 PM, Lyndsay Hackett <lyndsay.hack...@gmail.com

[wuf810]

Is this something we can do ourselves? if yes anybody willing to share
advice/instructions?

TIA, Michael.

[Mike D]

Ifdef the GSEvent and UITouch category and if you want to go all the
way remove calls to window firstResponder. There are 3 of them. That
is all the privates in the source.

Mike

[wuf810]

Thanks Mike, much appreciated. Regards, M.

On Oct 31, 4:25 am, Mike D <des...@gmail.com> wrote:
> Ifdef the GSEvent and UITouch category and if you want to go all the
> way remove calls to window firstResponder. There are 3 of them. That
> is all the privates in the source.
>
> Mike
>

[Erotsppa]

I don't understand this, all you have added is #ifdef but it's not
removed from the code. If you do a simple grep off the binary, you can
still find references to things like UITouch._locationInWindow. Our
apps will still get rejected?

[Mike D]

The ifdef is a compiler directive that tells the compiler NOT to
include that portion of the code in the binary.

Mike

[Erotsppa]

Well I'm no expert with compilers but like I said, a simple grep -R
'UITouch._tapCount' MyApp/build/ and you will find it, pretty sure the
same goes for the script used by Apple team.

On Oct 31, 4:40 pm, Mike D <des...@gmail.com> wrote:
> The ifdef is a compiler directive that tells the compiler NOT to
> include that portion of the code in the binary.
>
> Mike
>

[Mike D]

If you properly ifdef any code section it will most definitely not be
in the compiled binary.

Mike

[Erotsppa]

well the method initInView is not even ifdef, only the method that
calls it is. maybe that's the reason. I don't know again, whatever the
cause might be, I just know that you will most probably get rejected
for using three20's HEAD as of today.

On Oct 31, 4:46 pm, Mike D <des...@gmail.com> wrote:
> If you properly ifdef any code section it will most definitely not be
> in the compiled binary.
>
> Mike
>

[Mike D]

There seems to be a lot of confusion about all this so I think I will
create an app store safe branch so that this thread can disappear and
everyone can get back to coding and stop worrying.

Mike

[wuf810]

:-) Yes much confusion! I have already made the changes but would
appreciate a safe branch so I can double check I've not missed
anything.

So, thanks in advance!

M

On Oct 31, 9:02 pm, Mike D <des...@gmail.com> wrote:
> There seems to be a lot of confusion about all this so I think I will
> create an app store safe branch so that this thread can disappear and
> everyone can get back to coding and stop worrying.
>
> Mike
>

[uprise78]

I forked the repo and modified all offending code so that it is App
Store safe. All the three20 classes should work as expected including
TTTableView with UITextView/Fields.


git://github.com/uprise78/three20-P31.git
http://github.com/uprise78/three20-P31

[wuf810]

Thanks, I for one appreciate this. Submitting a new app next week...I
will be sure to let everyone know if there are any three20 related
rejections.

Michael.

On Oct 31, 10:57 pm, uprise78 <des...@gmail.com> wrote:
> I forked the repo and modified all offending code so that it is App
> Store safe.  All the three20 classes should work as expected including
> TTTableView with UITextView/Fields.
>

> git://github.com/uprise78/three20-P31.githttp://github.com/uprise78/three20-P31

[Luca De Baptistis]

Thanks uprise78.

Is the last commit from Joe (it says 2 days ago) the same as yours? He added ifdef's too.

Thanks

--
Prima di stampare, pensa all'ambiente ** Think about the environment before printing
Charles de Gaulle  - "The better I get to know men, the more I find myself loving dogs."

[Mike D]

Joe missed a bunch of stuff and also left in calls to window firstResponder. 

Mike

[Luca De Baptistis]

Oh ok. Thanks

Ted Turner  - "Sports is like a war without the killing."

[Brenden]

We were just rejected for this. See their email message:

Upon review of your application, XXXXXX0.6: Application Submission
Feedback cannot be posted to the App Store due to the usage of private
APIs. Usage of such non-public API, as outlined in the iPhone
Developer Program License Agreement section 3.3.1, is prohibited:

"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 non-public APIs that are included in your application are the
following undocumented private UITouch instance variables:
UITouch._locationInWindow
UITouch._phase
UITouch._previousLocationInWindow
UITouch._tapCount
UITouch._timestamp
UITouch._touchFlags
UITouch._view
UITouch._window


I have no idea what to do. I see the UIVIewAdditions.m, but if we
remove this, won't it affect the library code? We are only using
three20 for the photo library, so maybe we can skid on by without it.

On Oct 27, 7:58 am, neptune2000 <papa.ma...@gmail.com> wrote:
> Can anyone else confirm rejection?
>
> On Oct 26, 3:20 pm, Pradeepta Dash <pradee...@gmail.com> wrote:
>
> > Apologies if this has been reported earlier.
>
> > An app of mine got rejected because three20 uses private API/ivars.
>
> > - UITouch._locationInWindow
> > - UITouch._phase
> > - UITouch._previousLocationInWindow
> > - UITouch._tapCount
> > - UITouch._timestamp
> > - UITouch._touchFlags
> > - UITouch._view
> > - UITouch._window
>
> > --pradeepta

[Adam Jack]

Please review the recent archive for this mailing list, you will find multiple messages on how to fix this (and I think one cloned branch w/ fixes.)

regards

Adam

[Mike D]

Look about 3 messages back. I forked the repo and made it 'App Store
safe'. The fork is a drop in replacement with 100% of the
functionality of the normal three20 project.

[Brenden]

I've just compiled with Joe's Oct 28 commit that includes the #ifdef
DEBUG. I checked to make sure I didn't have it defined anywhere and
then I uploaded the binary. It is in review again. Hopefully that
pragma change will do it. I'll let you know if it gets rejected again.

Just to make sure, is there any reason that it wouldn't work? Should I
use the forked repo?

Thanks for the quick replies.

[Lyndsay Hackett]

Joe's changes does not address firstResponder, which others have been
rejected for.

Lyndsay

Sent from my iPhone

[Brenden]

Ok, I've resubmitted again today due to claims that Joe missed some
private calls. I've used uprise78's P31 version. I'll follow up with
any rejections and I look forward to Joe integrating all the needed
fixes to remove private API calls.

Thanks.

On Oct 31, 2:57 pm, uprise78 <des...@gmail.com> wrote:
> I forked the repo and modified all offending code so that it is App
> Store safe.  All the three20 classes should work as expected including
> TTTableView with UITextView/Fields.
>

> git://github.com/uprise78/three20-P31.githttp://github.com/uprise78/three20-P31

[ciukes]

Mine was just rejected:

"... Unfortunately it cannot be added to the App Store because it is
using a private API. Use of non-public APIs, which as outlined in the
iPhone Developer Program License Agreement section 3.3.1 is
prohibited:.

"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 non-public APIs that are included in your application are the

following undocumented, private UITouch instance variables:

UITouch._locationInWindow
UITouch._phase
UITouch._previousLocationInWindow
UITouch._tapCount
UITouch._timestamp
UITouch._touchFlags
UITouch._view
UITouch._window

Regards,

iPhone Developer Program
****************************

[ciukes]

Skimming the sources and checking what's new in the git repo I don't
see any committed change related to the issue above.
The lines 45-58 from the UIViewAdditions.m ring the bell to me:
43 @implementation UITouch (TTCategory)
44
45 - (id)initInView:(UIView *)view location:(CGPoint)location {
46 if (self = [super init]) {
47 _tapCount = 1;
48 _locationInWindow = location;
49 _previousLocationInWindow = location;
50
51 UIView *target = [view.window hitTest:_locationInWindow
withEvent:nil];
52 _view = [target retain];
53 _window = [view.window retain];
54 _phase = UITouchPhaseBegan;
55 _touchFlags._firstTouchForView = 1;
56 _touchFlags._isTap = 1;
57 _timestamp = [NSDate timeIntervalSinceReferenceDate];
(http://github.com/joehewitt/three20/blob/
8183ae25528bbc575ab41a41227756f06c166240/src/UIViewAdditions.m)

I'm not familiar with Three20 internals. Can someone more experienced
comment on this issue, please?

Regards

[Mike D]

See a few posts down. I forked a three20 branch that is app store
safe. It's a drop in replacement with all functionality. Use it and
you have no worries about private api's.

[ciukes]

> See a few posts down.  I forked a three20 branch that is app store
> safe.  It's a drop in replacement with all functionality.  Use it and
> you have no worries about private api's.

Thanks for the great job! I'm going to use it right now.

[Mads Rasmussen]

Thanks Mike !!

Appreciate your help on resolving this

Mads

--
Mads Rasmussen
Creative-Apps
Chief Technology Officer
------------------------------------------
mads.ra...@creative-apps.com
www.creative-apps.com
Mobile: 55 11 7533-6292
Mobile: 55 11 9407-4493
Skype: rasmussen.brazil2
@mazebr

[neptune2000]

I see uprise78 fork but not yours. What's the URL of your fork?

[Mike D]

uprise78 fork is mine.

[VMSpot]

I just got rejected for the exact same thing grrrrr. So what do we
do????

[VMSpot]

Nevermind.

[Marcin Maciukiewicz]

On 4 Nov 2009, at 18:31, VMSpot wrote:

>
> I just got rejected for the exact same thing grrrrr. So what do we
> do????

Did you use the altered Three20 fork from Mike D?

Regards,
Marcin.

[wuf810]

Never mind what? Never mind 'I've just noticed the rest of the thread
and didn't use the fork' or something else.

Helps us all here and let's us know if you got rejected with the old
commit, Joe's commit or uprise78/Mike's commit.

Thanks, Michael.

[neptune2000]

It would be nice to know when we get the first non-rejection using
Mike D's fork.

> > > > > > --pradeepta- Hide quoted text -
>
> - Show quoted text -

[Pradeepta Dash]

Still waiting after resubmission with fixes. 

9 days and counting....

--pradeepta

[Mike D]

As long as you don't try to submit a debug build there is nothing
private in there. I have 2 apps in review using the fork now. As
soon as Apple gets them through the review process ill post an update.

On Wed, Nov 4, 2009 at 11:47 AM, neptune2000 <papa....@gmail.com> wrote:
>

[Adam Jack]

Yeah, I was unlucky enough to have 4 apps (two new, two updates) in queue at that time and any I did not pull/re-build/re-submit have been rejected. Unfortunately none have yet made it out safely again, and I am waiting w/ bated breath. Frustrating...

I'd also like to see this mailing list return to normal business, and this thread to die. ;-)

That all said ... this is a minor blip of a hiccup (somehow I blame Apple's optimizer for not removing private calls that weren't even being called! ;-) and has not detracted from what I think about Three20, and all it does for the developer (both in class libraries and app design.) It feels a good time to repeat how much I appreciate all the help Joe has given developers through this framework. Thanks Joe.

regards,

Adam

--

Share Wildlife: http://wildobs.com

Wildlife iPhone/iPod Touch Applications: http://wildobs.com/about/iphone

[Todd]

When I exchange my old 320/src folder for the uprise78/three20-P31 at:

http://github.com/uprise78/three20-P31/blob/03ac3948c59f0adaec71b32c22fd0ea6198bb9d6/index.html

I get 93 errors when I compile. There must be a step I'm missing.
Any help please?

Thanks!

[Mike D]

Follow the directions on the three20 page EXACTLY. Be 100% certain
your header search paths are setup properly. Be 100% certain the
external project is linked and set as a dependency.

[Marcin Maciukiewicz]

On 5 Nov 2009, at 18:39, Mike D wrote:

>
> Follow the directions on the three20 page EXACTLY. Be 100% certain
> your header search paths are setup properly. Be 100% certain the
> external project is linked and set as a dependency.
>

Confirmed. In a properly configured project I replaced regular with
forked version and had no errors at all.

>>
>> When I exchange my old 320/src folder for the uprise78/three20-P31
>> at:
>>
>> http://github.com/uprise78/three20-P31/blob/03ac3948c59f0adaec71b32c22fd0ea6198bb9d6/index.html
>>
>> I get 93 errors when I compile. There must be a step I'm missing.
>> Any help please?

My blind guess is you've replaced regular 'src' content with full
blown forked project content thus the header files are located in a
wrong place.
Double check what you have done.

Regards,
Marcin.

[caseysackett]

I was also bit by this and had an app rejected. I've resubmitted with
the three20-P31 fork, but is there a utility that will scan the
compiled app for use of private APIs? Maybe something that lists a
symbol table of all methods called? What does Apple use in their
review process?

On Nov 5, 1:03 pm, Marcin Maciukiewicz <ciu...@gmail.com> wrote:
> On 5 Nov 2009, at 18:39, Mike D wrote:
>
>
>
> > Follow the directions on the three20 page EXACTLY.  Be 100% certain
> > your header search paths are setup properly.  Be 100% certain the
> > external project is linked and set as a dependency.
>
> Confirmed. In a properly configured project I replaced regular with  
> forked version and had no errors at all.
>
>
>
> >> When I exchange my old 320/src folder for the uprise78/three20-P31  
> >> at:
>

> >>http://github.com/uprise78/three20-P31/blob/03ac3948c59f0adaec71b32c2...

[Mike D]

Probably a static scanner of some sort. Nothing they have made public.

Mike

[Marcin Maciukiewicz]

On 6 Nov 2009, at 14:51, caseysackett wrote:

>
> I was also bit by this and had an app rejected. I've resubmitted with
> the three20-P31 fork, but is there a utility that will scan the
> compiled app for use of private APIs? Maybe something that lists a
> symbol table of all methods called? What does Apple use in their
> review process?

I wish they have shared the tool, at least as a part of the submission
process. This would be a great help for everyone.
On the other hand I can imagine this will never happen as this would
raise many issues
beggining with "why have you rejected my app? it was fine with the
tool".

Regards,
Marcin.

[Neil Inglis]

They could perhaps integrate it so that your binary is scanned at
Upload time, much as they validate the version number and bundle id in
Info.plist. Though I wouldn't want to see iTunes Connect shakier than
it already is.

[Marcin Maciukiewicz]

On 6 Nov 2009, at 17:08, Neil Inglis wrote:

>
> They could perhaps integrate it so that your binary is scanned at
> Upload time, much as they validate the version number and bundle id in
> Info.plist.

Just another reason to give you an ambigous rejection message and
leave without a clue.
I think I rather like the tension growing for weeks and then a sudden
hit with the rejection bat:)

Regards,
Marcin.

[Gavin Heer]

Just use 'nm' from the terminal, works great.

-Gavin.

[Marcin Maciukiewicz]

On 6 Nov 2009, at 18:52, Gavin Heer wrote:

>
> Just use 'nm' from the terminal, works great.
>
> -Gavin.

... matching the output against a list of symbols gathered from all
the frameworks withing the SDK.
That will do the job.

Thanks for the push Gavin:)

Regards,
Marcin.

[Gabor]

It looks like Joe Hewitt's checkin from Oct 28, 2009 fixes these
problems:

commit: 8183ae25528bbc575ab41a41227756f06c166240
"Disable code that uses private APIs except in debug builds"

Thus you won't need to use a special build or fork of the code
anymore. Just git pull to get the latest source.

Gabor

[Mike D]

Read the rest of this GIGANTIC stream of posts and take a look at the
commit. Joe did NOT fix the issues.

[fab]

We had our app rejected due to UITouch private variables. We didn't
use one of the updated repositories, but just completely removed
UITouch as well as replaced calls to firstResponder with
findFirstResponder (even though they didn't mention it in the
rejection email) and got approved tonight.
Many thanks to all who contributed.
fabio

On Nov 1, 3:41 am, Mike D <des...@gmail.com> wrote:
> Joe missed a bunch of stuff and also left in calls to window
> firstResponder.
>
> Mike
>
> On Oct 31, 2009, at 7:39 PM, Luca De Baptistis <luca.de...@gmail.com> wrote:
>
> Thanks uprise78.
> Is the last commit from Joe (it says 2 days ago) the same as yours? He added
> ifdef's too.
> Thanks
>
>
>
>
>
> On Sun, Nov 1, 2009 at 02:33, wuf810 <michaelk...@mac.com> wrote:
>
> > Thanks, I for one appreciate this. Submitting a new app next week...I
> > will be sure to let everyone know if there are any three20 related
> > rejections.
>
> > Michael.
>
> > On Oct 31, 10:57 pm, uprise78 <des...@gmail.com> wrote:
> > > I forked the repo and modified all offending code so that it is App
> > > Store safe.  All the three20 classes should work as expected including
> > > TTTableView with UITextView/Fields.
>
> > > git://
> > github.com/uprise78/three20-P31.githttp://github.com/uprise78/three20-P31
>
> > > On Oct 31, 2:24 pm, wuf810 <michaelk...@mac.com> wrote:
>
> > > > :-) Yes much confusion! I have already made the changes but would
> > > > appreciate a safe branch so I can double check I've not missed
> > > > anything.
>
> > > > So, thanks in advance!
>
> > > > M
>
> > > > On Oct 31, 9:02 pm, Mike D <des...@gmail.com> wrote:
>
> > > > > There seems to be a lot of confusion about all this so I think I will
> > > > > create an app store safe branch so that this thread can disappear and
> > > > > everyone can get back to coding and stop worrying.
>
> > > > > Mike
>
> --
> Prima di stampare, pensa all'ambiente ** Think about the environment before
> printing
> Charles de Gaulle<http://www.brainyquote.com/quotes/authors/c/charles_de_gaulle.html>
> - "The better I get to know men, the more I find myself loving dogs."

[Akshay Shah]

Can you give some more details about this thing...
I want to use it in my next project,
i guess this may help me a lot then..

Regards,
Akshay.

On Oct 29, 9:55 am, Joe Hewitt <joehew...@gmail.com> wrote:
> I got a phone call from Apple today about this issue.  They asked me
> to remove simulateTapAtPoint and related code due to their static
> analyzer automatically flagging it and rejecting apps.  I just checked
> in some changes which wrap this code in an #ifdef DEBUG so they can
> still be used for their intended debugging purposes.

[Adam Jack]

Read back over this list's archives, you'll get more than enough details to help you a *lot* . :)

regards,

Adam

[spork3000]

Anyone here have an app using the uprise78/three20-P31 fork that's
been approved yet? I'd be nice to close this rejection thread off with
a few affirmative "approvals".


Thanks...

[PRADEEPTA dash]

I never thought that this thread would be the straw that broke the
camel's back.
Thanks for three20, Joe.

Sent from my iPhone

[Aaron Berk]

I have submitted an app with the P31 fork and hope it is approved
soon. I will keep you posted on its progress.

[cheolho]

just wanted to second the request for a branch. If someone has
already done the work to make it apple safe.
Now I understand why he left. This is bs overall.

On Oct 28, 6:24 pm, siong1987 <siong1...@gmail.com> wrote:
> Hi Pradeepta,
>
> Is it possible for you to fork a branch on github to share your SAFE
> three20 library with us?
>
> Thank you.
>
> On Oct 28, 6:53 pm, Pradeepta Dash <pradee...@gmail.com> wrote:
>
>
>
> > I got rejected for the 2nd reason, exact same verbage.
>
> > However, I took out the all calls to firstResponder as well and re-submitted
> > the app just now (just to safe)
>
> > Thanks for the heads up.
> > --pradeepta
>
> > On Wed, Oct 28, 2009 at 6:02 PM, Nick Partridge <nkp...@gmail.com> wrote:
> > > Related to this rejection, I just had an app rejected with the following
> > > feedback:
>
> > > > The non-public APIs that are included in your applications are the
> > > > following:
> > > > - firstResponder
> > > > - undocumented, Private UITouch instance variables
>
> > > I'm going to assume that the UITouch instance variables is the same issue
> > > as Pradeepta's, however the firstResponder problem is troubling.
>
> > > That selector is used whenever Three20 (or otherwise) needs to know if the
> > > keyboard is visible, or to scroll the first responder into the view. I'll
> > > have to strip all that functionality out of three20 to use it.
>
> > > A greater concern though, is that Three20 is using private APIs without
> > > flagging it to the consumer of the library. As much as I find three20 to be
> > > a great productivity to boost to working with cocoa, we're going to be
> > > phasing it out of our applications.
>
> > > -Nick

[Ricky Cheng]

This one is suppose to be safe.

http://github.com/uprise78/three20-P31/commit/3a1f0a9bea92aed27f12a513e1e70c5412ba0f91

[winter]

Here are what happened to us:

- Got the rejection letter from Apple on Nov 5 with the following
reason:

The non-public APIs that are included in your application are the
following undocumented, private UITouch instance variables:

UITouch._locationInWindow
UITouch._phase
UITouch._previousLocationInWindow
UITouch._tapCount
UITouch._timestamp
UITouch._touchFlags
UITouch._view
UITouch._window

We were using a fair old three30 code in 2.2.1 OS. So we updated the
code to latest Joe's code the day after (Nov 6) after we notice Joe's
had put in a fix. (i.e not using any folk/branch by other fellows).

Today we received another rejection from Apple, with the following
reason:

The non-public API that is included in your application comes from the
following private Apple frameworks - App is using
UITouch._locationInWindow, UITouch._phase,
UITouch._previousLocationInWindow, UITouch._tapCount,
UITouch._timestamp, UITouch._touchFlags, UITouch._view and
UITouch._window undocumented UITouch instance variables. .

Can someone help to interpret what's Apple is thinking as two similar
but different rejection message?

So now we just submitted a new one with the P31 folk and hope it goes.

Thanks for all the hard work Joe's and rest of you guys!

On Nov 13, 11:25 am, Ricky Cheng <soul...@gmail.com> wrote:
> This one is suppose to be safe.
>

> http://github.com/uprise78/three20-P31/commit/3a1f0a9bea92aed27f12a51...

[Tollhouse Studio]

So I built an app with the first three20, it got rejected just like
the rest of you.

I downloaded the p31 and in the samples folder and TTCatalog I started
building with the xcode.project in there.

Is this the right thing to do or do I have to edit the codes supplied
in the P31 build?

Please help because I built an app that I was proud of and I can't do
it any other way without Three20

Thanks folks.

[chiappone]

I really thing these changes need to go into the master revision so
that we can put this to rest and continue to build of the master. Who
is now in charge of doing this since Joe has left the project?

~chris

On Nov 13, 5:08 am, Tollhouse Studio <tollhousestu...@googlemail.com>
wrote:

[Tollhouse Studio]

I agree with you, this is getting complicated when three20 was so
straight forward and easy to use.

A master build using public API's to sort everyones problems would be
amazing.

Chris.

[Mike D]

The master has had one update in the last few months. Consider it
dead until someone else from Facebook takes over. Until that time
just make any changes you need. Use the magic of version control to
do whatever you want to your local branch and then if and when the
master is updated merge in the changes.

[Erotsppa]

Anyone have any success past the review team with p13? It's been two
weeks now since p13 was released so some people must be getting
feedback?