New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

App rejected because AMBlurView #25

Closed
orsharir opened this Issue Jan 18, 2014 · 32 comments

Comments

Projects
None yet
@orsharir

orsharir commented Jan 18, 2014

Hey,

My app was just rejected because I used AMBlurView in it:

2.5

We also found that your app interacts with the organization and layout of a provided view's internal hierarchy, which is a private entity. Interacting with private entities is not in compliance with the App Store Review Guidelines.

Specifically, your app uses classes like AMBlurView or MDBlurView, which take layers from UIToolbar and UINavigationBar view hierarchies.

Selecting specific layers or subviews in our provided views makes assumptions about the organization and layout of the view hierarchy. However, this hierarchy could change without notice, affecting the behavior of your app.

@johnuphoff

This comment has been minimized.

Show comment
Hide comment
@johnuphoff

johnuphoff Jan 18, 2014

ModMusic A made it through review twice with the AMBlur view class implemented.
Both submissions were in October, separated by about 15 days.
Your response suggests that there were other issues with the app as well that may have contributed to the investigation into the “misappropriated" UIToolbar class.
Good to know though - maybe they changed their policy…

Anyone with other recent submissions?

On Jan 18, 2014, at 12:46 AM, Or Sharir notifications@github.com wrote:

Hey,

My app was just rejected because I used AMBlurView in it:

2.5

We also found that your app interacts with the organization and layout of a provided view's internal hierarchy, which is a private entity. Interacting with private entities is not in compliance with the App Store Review Guidelines.

Specifically, your app uses classes like AMBlurView or MDBlurView, which take layers from UIToolbar and UINavigationBar view hierarchies.

Selecting specific layers or subviews in our provided views makes assumptions about the organization and layout of the view hierarchy. However, this hierarchy could change without notice, affecting the behavior of your app.


Reply to this email directly or view it on GitHub.

johnuphoff commented Jan 18, 2014

ModMusic A made it through review twice with the AMBlur view class implemented.
Both submissions were in October, separated by about 15 days.
Your response suggests that there were other issues with the app as well that may have contributed to the investigation into the “misappropriated" UIToolbar class.
Good to know though - maybe they changed their policy…

Anyone with other recent submissions?

On Jan 18, 2014, at 12:46 AM, Or Sharir notifications@github.com wrote:

Hey,

My app was just rejected because I used AMBlurView in it:

2.5

We also found that your app interacts with the organization and layout of a provided view's internal hierarchy, which is a private entity. Interacting with private entities is not in compliance with the App Store Review Guidelines.

Specifically, your app uses classes like AMBlurView or MDBlurView, which take layers from UIToolbar and UINavigationBar view hierarchies.

Selecting specific layers or subviews in our provided views makes assumptions about the organization and layout of the view hierarchy. However, this hierarchy could change without notice, affecting the behavior of your app.


Reply to this email directly or view it on GitHub.

@orsharir

This comment has been minimized.

Show comment
Hide comment
@orsharir

orsharir Jan 18, 2014

You're correct that there was another reason for the rejection (unrelated to live blurring), but I just wanted to share that Apple apparently doesn't like the use of AMBlurView's solution to live blurring.

orsharir commented Jan 18, 2014

You're correct that there was another reason for the rejection (unrelated to live blurring), but I just wanted to share that Apple apparently doesn't like the use of AMBlurView's solution to live blurring.

@BlackLee

This comment has been minimized.

Show comment
Hide comment
@BlackLee

BlackLee Jan 21, 2014

em, I didn't use this library, but I saw it uses UIToolbar inside a UIView, which is exactly the same as my current usage, it's been rejected today. (2014.01.21)

BlackLee commented Jan 21, 2014

em, I didn't use this library, but I saw it uses UIToolbar inside a UIView, which is exactly the same as my current usage, it's been rejected today. (2014.01.21)

@JagCesar

This comment has been minimized.

Show comment
Hide comment
@JagCesar

JagCesar Jan 21, 2014

Owner

Ok, this is bad news… But hopefully this means that they have a better solution in the works :)

I'll update the readme. Thanks for informing me with this info!

Owner

JagCesar commented Jan 21, 2014

Ok, this is bad news… But hopefully this means that they have a better solution in the works :)

I'll update the readme. Thanks for informing me with this info!

@akac

This comment has been minimized.

Show comment
Hide comment
@akac

akac Jan 21, 2014

They changed their policy. We've been using it since September without issues including a release in December. But yesterday was rejected for using AMBlurView. They explicitly said its not allowed anymore.

akac commented Jan 21, 2014

They changed their policy. We've been using it since September without issues including a release in December. But yesterday was rejected for using AMBlurView. They explicitly said its not allowed anymore.

@ddaddy

This comment has been minimized.

Show comment
Hide comment
@ddaddy

ddaddy Jan 21, 2014

Is this just for new apps, or is anyone seeing it with app updates?

ddaddy commented Jan 21, 2014

Is this just for new apps, or is anyone seeing it with app updates?

@akac

This comment has been minimized.

Show comment
Hide comment
@akac

akac Jan 21, 2014

Ours was an app update. Read the full text from Apple above.

akac commented Jan 21, 2014

Ours was an app update. Read the full text from Apple above.

@JagCesar JagCesar closed this in ec93a0d Jan 21, 2014

@JagCesar JagCesar reopened this Jan 21, 2014

@JagCesar

This comment has been minimized.

Show comment
Hide comment
@JagCesar

JagCesar Jan 21, 2014

Owner

I didn't want to close this issue, as my fix only 'might' be a fix. Feel free to use this code instead and see if they still don't like it :) It shouldn't be a problem anymore.

Owner

JagCesar commented Jan 21, 2014

I didn't want to close this issue, as my fix only 'might' be a fix. Feel free to use this code instead and see if they still don't like it :) It shouldn't be a problem anymore.

@JonChristensen

This comment has been minimized.

Show comment
Hide comment
@JonChristensen

JonChristensen Jan 29, 2014

It's been 8 days since the proposed fix. Has anyone made it through review with it? My concern would be that apple is blanket rejecting apps that use this even though it has been fixed. Looking forward to hearing people are making it through because I'm planning to use this.

JonChristensen commented Jan 29, 2014

It's been 8 days since the proposed fix. Has anyone made it through review with it? My concern would be that apple is blanket rejecting apps that use this even though it has been fixed. Looking forward to hearing people are making it through because I'm planning to use this.

@Julioacarrettoni

This comment has been minimized.

Show comment
Hide comment
@Julioacarrettoni

Julioacarrettoni commented Jan 29, 2014

👍 to @JonChristensen request.

@stevekohls

This comment has been minimized.

Show comment
Hide comment
@stevekohls

stevekohls Feb 1, 2014

Will you be tagging this change and updating the podspec? I realize you might be waiting until someone confirms the new code will get past Apple's review.
For now I'll do a local CocoaPods reference with this latest code.

stevekohls commented Feb 1, 2014

Will you be tagging this change and updating the podspec? I realize you might be waiting until someone confirms the new code will get past Apple's review.
For now I'll do a local CocoaPods reference with this latest code.

@JagCesar

This comment has been minimized.

Show comment
Hide comment
@JagCesar

JagCesar Feb 2, 2014

Owner

@stevekohls, I'll send a PR to cocoa pods within a few hours :)

Owner

JagCesar commented Feb 2, 2014

@stevekohls, I'll send a PR to cocoa pods within a few hours :)

@JagCesar

This comment has been minimized.

Show comment
Hide comment
@JagCesar

JagCesar Feb 12, 2014

Owner

It's tagged as v.0.0.4 and it's merged to the Specs repo now. I'm keeping this ticket open for now, if I don't hear anything within the coming weeks I'll close it. :)

Owner

JagCesar commented Feb 12, 2014

It's tagged as v.0.0.4 and it's merged to the Specs repo now. I'm keeping this ticket open for now, if I don't hear anything within the coming weeks I'll close it. :)

@wwzhy

This comment has been minimized.

Show comment
Hide comment
@wwzhy

wwzhy Feb 20, 2014

I use the latest version and My app was just rejected today.

2.5: Apps that use non-public APIs will be rejected
2.5

We found that your app interacts with the organization and layout of a provided view's internal hierarchy, which is a private entity. Interacting with private entities is not in compliance with the App Store Review Guidelines.

Specifically, your app uses classes like AMBlurView or MDBlurView, which take layers from UIToolbar and UINavigationBar view hierarchies.

Selecting specific layers or subviews in our provided views makes assumptions about the organization and layout of the view hierarchy. However, this hierarchy could change without notice, affecting the behavior of your app.

Please revise your app to remove this functionality.

wwzhy commented Feb 20, 2014

I use the latest version and My app was just rejected today.

2.5: Apps that use non-public APIs will be rejected
2.5

We found that your app interacts with the organization and layout of a provided view's internal hierarchy, which is a private entity. Interacting with private entities is not in compliance with the App Store Review Guidelines.

Specifically, your app uses classes like AMBlurView or MDBlurView, which take layers from UIToolbar and UINavigationBar view hierarchies.

Selecting specific layers or subviews in our provided views makes assumptions about the organization and layout of the view hierarchy. However, this hierarchy could change without notice, affecting the behavior of your app.

Please revise your app to remove this functionality.

@JagCesar

This comment has been minimized.

Show comment
Hide comment
@JagCesar

JagCesar Feb 20, 2014

Owner

Ouch. And you're sure you used v.0.0.4? This is very bad news.. We're not even allowed to use the UIToolbar as a subview and stretch it.. 👎

Owner

JagCesar commented Feb 20, 2014

Ouch. And you're sure you used v.0.0.4? This is very bad news.. We're not even allowed to use the UIToolbar as a subview and stretch it.. 👎

@wwzhy

This comment has been minimized.

Show comment
Hide comment
@wwzhy

wwzhy Feb 20, 2014

Yes,it was rejeced a week ago,then I used v.0.0.4 and it was rejected again today.

wwzhy commented Feb 20, 2014

Yes,it was rejeced a week ago,then I used v.0.0.4 and it was rejected again today.

@JagCesar

This comment has been minimized.

Show comment
Hide comment
@JagCesar

JagCesar Feb 20, 2014

Owner

Have you talked to them and said that we're in fact not playing around with subviews in the view hierarchies anymore? We're using a standard view, specifically UIToolbar, and are no longer touching the private entities in this object.

Owner

JagCesar commented Feb 20, 2014

Have you talked to them and said that we're in fact not playing around with subviews in the view hierarchies anymore? We're using a standard view, specifically UIToolbar, and are no longer touching the private entities in this object.

@vendruscolo

This comment has been minimized.

Show comment
Hide comment
@vendruscolo

vendruscolo Feb 24, 2014

That's curious, because Apple approved three releases of my app which is using this project.

To be precise, Apple approved it in these days:

  • January 10, 2014
  • January 23, 2014
  • February 20, 2014

vendruscolo commented Feb 24, 2014

That's curious, because Apple approved three releases of my app which is using this project.

To be precise, Apple approved it in these days:

  • January 10, 2014
  • January 23, 2014
  • February 20, 2014
@rrrus

This comment has been minimized.

Show comment
Hide comment
@rrrus

rrrus Mar 12, 2014

our app was just rejected with the same message that includes "Specifically, your app uses classes like AMBlurView..." despite using the latest AMBlurView which does not mess with the internal layers. Seems they're just searching for the AMBlurView symbol. I attempted to explain that while AMBlurView used to mess with the internals, it no longer does, but they simply referred me to DTS to resolve my issue. I didn't bother filing an appeal on the issue, instead I moved all of the code into a subclass we made of AMBlurView and removed the original entirely. If this succeeds, then I suggest you change the name of the project or class.

rrrus commented Mar 12, 2014

our app was just rejected with the same message that includes "Specifically, your app uses classes like AMBlurView..." despite using the latest AMBlurView which does not mess with the internal layers. Seems they're just searching for the AMBlurView symbol. I attempted to explain that while AMBlurView used to mess with the internals, it no longer does, but they simply referred me to DTS to resolve my issue. I didn't bother filing an appeal on the issue, instead I moved all of the code into a subclass we made of AMBlurView and removed the original entirely. If this succeeds, then I suggest you change the name of the project or class.

@JagCesar

This comment has been minimized.

Show comment
Hide comment
@JagCesar

JagCesar Mar 12, 2014

Owner

@rrrus, It's worth a try! I'll rename the class to something else and send in a new pull request to cocoa pods :)

Owner

JagCesar commented Mar 12, 2014

@rrrus, It's worth a try! I'll rename the class to something else and send in a new pull request to cocoa pods :)

@JagCesar

This comment has been minimized.

Show comment
Hide comment
@JagCesar

JagCesar Mar 13, 2014

Owner

I've updated the Podspec and now renamed the class, let's see if it works better :)

Owner

JagCesar commented Mar 13, 2014

I've updated the Podspec and now renamed the class, let's see if it works better :)

@ivfuricks

This comment has been minimized.

Show comment
Hide comment
@ivfuricks

ivfuricks Mar 16, 2014

Actually,it really depends on reviewer.Apple approved my app which uses this project.

ivfuricks commented Mar 16, 2014

Actually,it really depends on reviewer.Apple approved my app which uses this project.

@sdjuarez

This comment has been minimized.

Show comment
Hide comment
@sdjuarez

sdjuarez Mar 19, 2014

Hello, anyone has succeeded lately on being approved with this latest Podspec and class rename?. Thanks!

sdjuarez commented Mar 19, 2014

Hello, anyone has succeeded lately on being approved with this latest Podspec and class rename?. Thanks!

@rrrus

This comment has been minimized.

Show comment
Hide comment
@rrrus

rrrus Mar 20, 2014

Our app that was rejected for using AMBlurView was just approved after we simply moved the code from AMBlurView into one of our own classes. shakes head oh apple.

rrrus commented Mar 20, 2014

Our app that was rejected for using AMBlurView was just approved after we simply moved the code from AMBlurView into one of our own classes. shakes head oh apple.

@iJustinCabral

This comment has been minimized.

Show comment
Hide comment
@iJustinCabral

iJustinCabral Apr 13, 2014

@rrrus We don't use AMBlurView in our app but we use one called ILTranslucentView which uses the same technique of using the UIToolBar blur layer.

Should we also hide it directly in the classes that use the blur to be on the safe side?

iJustinCabral commented Apr 13, 2014

@rrrus We don't use AMBlurView in our app but we use one called ILTranslucentView which uses the same technique of using the UIToolBar blur layer.

Should we also hide it directly in the classes that use the blur to be on the safe side?

@rrrus

This comment has been minimized.

Show comment
Hide comment
@rrrus

rrrus Apr 13, 2014

@iJustinCabral, you should be fine as it seems apple was simply searching the binary for the symbol names AMBlurView and MDBlurView, not what the code is actually doing.

rrrus commented Apr 13, 2014

@iJustinCabral, you should be fine as it seems apple was simply searching the binary for the symbol names AMBlurView and MDBlurView, not what the code is actually doing.

@iJustinCabral

This comment has been minimized.

Show comment
Hide comment
@iJustinCabral

iJustinCabral Apr 13, 2014

@rrrus awesome, thanks for the response.

iJustinCabral commented Apr 13, 2014

@rrrus awesome, thanks for the response.

@neywen

This comment has been minimized.

Show comment
Hide comment
@neywen

neywen Apr 24, 2014

hmmm, I'm not sure I get it right : is it really sufficient to change the class name ? Don't you think there's a chance for Apple to update the validation process with a new name to look for ?

neywen commented Apr 24, 2014

hmmm, I'm not sure I get it right : is it really sufficient to change the class name ? Don't you think there's a chance for Apple to update the validation process with a new name to look for ?

@JagCesar

This comment has been minimized.

Show comment
Hide comment
@JagCesar

JagCesar Apr 24, 2014

Owner

Yeah they could start looking for the new class name, but they don't have a reason to do that.The former implementation copied the UIToolBar layer and added it to an own, which can be interpreted as messing with views in objects that Apple provides us. To verify that we're not doing that anymore they banned AMBlurView.

The new implementation doesn't do anything wrong, and is open sourced so Apple shouldn't reject Apps using this class now or in the future.

/C

Owner

JagCesar commented Apr 24, 2014

Yeah they could start looking for the new class name, but they don't have a reason to do that.The former implementation copied the UIToolBar layer and added it to an own, which can be interpreted as messing with views in objects that Apple provides us. To verify that we're not doing that anymore they banned AMBlurView.

The new implementation doesn't do anything wrong, and is open sourced so Apple shouldn't reject Apps using this class now or in the future.

/C

@neywen

This comment has been minimized.

Show comment
Hide comment
@neywen

neywen Apr 24, 2014

ok, so it's not just a change of class name then :) I'll give it a try, thanks !
n.

neywen commented Apr 24, 2014

ok, so it's not just a change of class name then :) I'll give it a try, thanks !
n.

@Goles

This comment has been minimized.

Show comment
Hide comment
@Goles

Goles Apr 27, 2014

@JagCesar Just to be sure, you're saying that there shouldn't be more rejection issues? If so, you should remove the warning in README.md

Goles commented Apr 27, 2014

@JagCesar Just to be sure, you're saying that there shouldn't be more rejection issues? If so, you should remove the warning in README.md

@JagCesar

This comment has been minimized.

Show comment
Hide comment
@JagCesar

JagCesar Apr 27, 2014

Owner

@Goles That is correct. I am closing this issue and updating the README.md.

Owner

JagCesar commented Apr 27, 2014

@Goles That is correct. I am closing this issue and updating the README.md.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment