#72 new
MOApp

Mac App Store Apps rejected due to the use of BWToolkit

Reported by MOApp | December 27th, 2010 @ 06:21 AM

All my Apps for the upcoming Mac App Store have just been rejected :-(

Quote:

"We've reviewed your apps and are unable to post these versions to the App Store because they are using a private API. The use of non-public APIs is not permissible, as documented in section 2.5 of the App Store Review Guidelines https://developer.apple.com/appstore/mac/resources/approval/guidelines.html. We have included additional details below to help explain the issue, and hope you’ll consider revising and resubmitting your application.

Using private APIs can lead to a poor user experience should these APIs change in the future. The non-public API (NSTokenAttachmentCell._tacFlags) that is included in your application comes from the following private Apple frameworks - <AppKit.framework>."

I guess BWToolkit is used on 40/50% of all apps out there :-)

  1. Am I the only one?
  2. Are there more 'privat' things used in BWToolkit one has to take care about?

Thanks in advance.

Comments and changes to this ticket

  • Markus Müller

    Markus Müller December 27th, 2010 @ 03:05 PM

    I received the same email today. I looked into this and this doesn't seem to be the only use of private API. In the project there are currently four private Cocoa Header files:
    - NSTokenAttachment.h - NSTokenAttachmentCell.h - NSWindow-NSTimeMachineSupport.h - NSCustomView.h

    I'll try to remove them from my branch or remove the framework from my app before I resubmit.

  • MOApp

    MOApp December 27th, 2010 @ 03:59 PM

    What really sucks is the fact that two apps of mine have been already approved before without any problem :-(

    I've already removed the complete TokenField, maybe I've missed the others, thanks for pointing out them…

  • Stuart Hall

    Stuart Hall December 28th, 2010 @ 01:14 AM

    I got the same email today as well, would love to know if these are fixed in a future version.

    Cheers

  • Brandon Walkin

    Brandon Walkin December 29th, 2010 @ 02:51 AM

    I don't think there's any way to customize a token field like that without private API. I'd suggest replacing the token fields with standard ones.

    In terms of other private API in BWToolkit, most of it's used in the .ibplugin part of the project and doesn't get compiled into the binary. Some of it's used in the framework to make IB integration work better. For instance, NSCell's _textAttributes is overridden instead of using -setAttributedStringValue: so styles get updated live as you change cell titles in IB.

    Since the rejections here are only regarding modifying private ivars (which only BWTokenField does, as far as I recall), hopefully they're just looking for private ivar use and not private method use. Or maybe they've whitelisted _textAttributes as something that's permissible to override.

    In any case, Apple has deprecated IB plugins with Xcode 4, which is why I haven't been updating it and why it's probably not worth the time to rewrite the framework to not use private API. Please file bugs with Apple to add IB plugin support to Xcode 4. Once they do, I'll start working on v2.0.

  • Florian Zand

    Florian Zand December 29th, 2010 @ 06:55 AM

    So does my app gets rejected even if I only use the BWSplitView in InterfaceBuilder/ the .xib-file?

  • MOApp

    MOApp December 29th, 2010 @ 06:59 AM

    It doesn't matter what you use in IB as long as you use the unchanged framework you will get rejected.
    I've removed the private ivars from the framework and submitted again - so for the moment all we can do is to wait or completely remove the framework…

  • ppilone

    ppilone December 29th, 2010 @ 11:45 AM

    Does this mean compiling BWToolkit from source without the BWTokenField classes? If that's the case I can compile/reject/re-submit without the token field classes. What I'm concerned about is the existence of the private headers is enough to warrant a rejection. It seems like Apple has been pretty specific about naming the private API calls in their rejection notices. Since rejections related to BWToolkit only seem to mention the private ivars in the token field category, I guess we're safe to assume that's all we need to remove?

  • MOApp

    MOApp January 1st, 2011 @ 11:45 PM

    I've just received 'clearance' for all six apps using BWToolkit after removing the token field code :-)

  • Brandon Walkin

    Brandon Walkin January 9th, 2011 @ 06:30 PM

    Excellent. Thanks for the update.

  • Stuart Hall

    Stuart Hall January 9th, 2011 @ 06:34 PM

    Same here, approved after token code was removed.

  • pounder

    pounder January 12th, 2011 @ 01:10 AM

    What exactly are the steps in removing the BWTokenField code/classes? I'm just using a HUD with a few buttons and actions. Thanks

  • webmixer

    webmixer February 4th, 2011 @ 05:46 AM

    byteproject has released a new verson of BWToolkit without call to private APis

    it's available here: http://byteproject.net/post/3016833303/bwtoolkit-1-2-5-w-o-private-api

  • Shazron Abdullah

    Shazron Abdullah February 13th, 2011 @ 01:52 AM

    Probably essentially the same thing that byteproject did, but on github:
    It's on my master branch, here are the commits I made on top of 1.2.5 so you can see the diffs (click on the link on the commit hash):
    https://github.com/shazron/bwtoolkit/commits/master/

    The vendor branch is essentially the code from Brandon Walkin's mercurial repo.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

BWToolkit is an Interface Builder plugin that contains commonly used UI elements and other objects designed to simplify Mac development.

Shared Ticket Bins

Pages