App rejected because AMBlurView

[orsharir]

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]

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]

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]

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]

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]

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]

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

[akac]

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

[JagCesar]

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]

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]

:+1: to @JonChristensen request.

[stevekohls]

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]

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

[JagCesar]

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]

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]

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.. :-1:

[wwzhy]

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

[JagCesar]

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]

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]

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]

@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]

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

[ivfuricks]

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

[sdjuarez]

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

[rrrus]

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]

@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]

@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]

@rrrus awesome, thanks for the response.

[neywen]

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]

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]

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

[Goles]

@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]

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