blurAmount uses private API and likely to cause App Store rejection

[brentvatne]

This was flagged by @terribleben when discussing adding this same feature to Exponent, so I thought I would bring it to your attention!

[jamealg]

Ahh what's the likelihood of this causing a rejection? I'm working on an app for a client that we're planning to publish in a couple of weeks and I'm trying to decide if it's worth it to try to include this library. I wish I could contribute a fix but I know no Objective C.

[brentvatne]

the chances are.. not low. it uses a private api that apple can determine through static analysis of code. you could check out how we implemented this in exponent, using alpha: https://github.com/exponentjs/exponent/blob/master/ios/Exponent/Versioned/Modules/Api/Components/EXBlurView.m / https://github.com/exponentjs/exponent/blob/master/ios/Exponent/Versioned/Modules/Api/Components/EXBlurViewManager.m (the intensity prop)

[Kureev]

I'm curious to hear @jakehasler feedback about it

[bennygenel]

Hey @brentvatne; I don't want to start using Exponent just for blur effect -not because its not a great project- also I'm not good with native code. Do you have any easy solution? Can I just import BlurView from Exponent or is it possible to make some minor changes to this repo to get it not rejected?

[Kureev]

As an option you can use previous version (before blurAmount has been introduced) to be safe. If at least one person will confirm that app has been rejected because of using undocumented features, I'll revert this feature.

[jakehasler]

This sounds like a good plan. When I originally built out this feature, I figured that this would arise soon enough. We could even keep a branch with blurAmount still available so that if some want to develop without future app store submission, then they can still use the feature.

I am interested to see though if it truly causes rejection.

[terribleben]

Fair point-- it may not guarantee rejection. But it's good to let people know about it as a matter of caution, and awareness, since Apple is known to be arbitrary and inconsistent about enforcing this type of thing. So people who choose to use this can make their own judgment. e.g. this thread and this thread both mention that the solution is most ideal for people who don't use the app store.

[jakehasler]

Yeah that's a good point as well. I am aiming to finish up my app here in the next few weeks, and will be attempting submission, so I will gladly volunteer as the guinea pig to see if it gets through or not. If anyone else discovers any results sooner, then that's awesome.

[Kureev]

Awesome! Thanks for your feedback, guys! I'll keep an eye on this one.

[brentvatne]

Why not update to use the code I linked to above that does something very similar using opacity instead?

[Kureev]

Because opacity is not the same as blur radius.

Side note: One month passed since we added it and nobody complained so far.

[brentvatne]

@Kureev - I can't tell the difference

[Kureev]

This doesn't look like constant blur + opacity

[Kureev]

@brentvatne https://github.com/react-native-community/react-native-blur/issues/126 check how it looks with this component here

[Kureev]

Seems we have no related issues since November. Either nobody publish an app with this plugin since November, or everything is fine. I'll close it for now and re-open if somebody complain.

[jakehasler]

I know this issue is closed, but above, I mentioned that I would report back if I had any findings about this issue. My app, Date Hatcher, has been in the app store for about a month now, and utilizes heavily the blurAmount functionality from this library. The conclusion being: Even though it does use the private API, it did not cause App store rejection.

Thanks!

[terribleben]

I think this comment I made earlier is still relevant:

it's good to let people know about it as a matter of caution, and awareness, since Apple is known to be arbitrary and inconsistent about enforcing this type of thing. So people who choose to use this can make their own judgment.

So rather than judging the code by a story of one app getting approved once, or waiting around for another person to show up with a rejection story, it seems prudent to just mention somewhere if your library uses a private API.

[braco]

@terribleben is right: private APIs are fine until Apple decides they aren't anymore. You can get removed from the app store without warning.

[just4fun]

So, I'm using 3.1.3 and my app has been rejected several days ago, I was noticed that I violated 2.3.1 and 2.5.2 in App review guidelines.

From last summit to App Store, I have only introduced three libraries: react-native-blur, react-native-gifted-chat, react-native-search-bar to my codebase, and I didn't find any issues related from another two repos.

Just wanna know whether react-native-blur is using private API now.

Thanks in advance.

[just4fun]

If it DID use private API, could anyone tell me which version has no private API?

[Kureev]

@just4fun:

2.3.1 Don’t include any hidden or undocumented features in your app; your app’s functionality should be clear to end-users and App Review

This point is not about private API usage.

2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code, including other apps.

Also nothing about private APIs.

I believe there is something related to your app itself.

[just4fun]

@Kureev - yes, seems like you are right.

I'd like to attach the rejection reason Apple sent to me.

---

Guideline 2.3.1 - Performance

We discovered that your app contains hidden features.

You will experience a delayed review process if you deliberately disregard the App Store Review Guidelines, ignore previous rejection feedback in future app submissions, or use your app to mislead or deceive users.

Important Information

As a result of violating this guideline, your app’s review has been delayed. Future submissions of this app, and other apps associated with your Apple Developer account, will also experience a delayed review. Deliberate disregard of the App Store Review Guidelines and attempts to deceive users or undermine the review process are unacceptable and is a direct violation Section 3.2(f) of the Apple Developer Program License Agreement. Continuing to violate the Terms & Conditions of the Apple Developer Program will result in the termination of your account, as well as any related or linked accounts, and the removal of all your associated apps from the App Store.

We want to provide a safe experience for users to get apps and a fair environment for all developers to be successful. If you believe we have misunderstood or misinterpreted the intent of your app, you may submit an appeal for consideration or provide additional clarification by responding directly to this message in Resolution Center in iTunes Connect.

Guideline 2.5.2 - Performance - Software Requirements

Your app, extension, or linked framework appears to contain code designed explicitly with the capability to change your app’s behavior or functionality after App Review approval, which is not in compliance with App Store Review Guideline 2.5.2 and section 3.3.2 of the Apple Developer Program License Agreement.

This code, combined with a remote resource, can facilitate significant changes to your app’s behavior compared to when it was initially reviewed for the App Store. While you may not be using this functionality currently, it has the potential to load private frameworks, private methods, and enable future feature changes. This includes any code which passes arbitrary parameters to dynamic methods such as dlopen(), dlsym(), respondsToSelector:, performSelector:, method_exchangeImplementations(), and running remote scripts in order to change app behavior and/or call SPI, based on the contents of the downloaded script. Even if the remote resource is not intentionally malicious, it could easily be hijacked via a Man In The Middle (MiTM) attack, which can pose a serious security vulnerability to users of your app.

Important Information

As a result of violating this guideline, your app’s review has been delayed. Future submissions of this app, and other apps associated with your Apple Developer account, will also experience a delayed review. Deliberate disregard of the App Store Review Guidelines and attempts to deceive users or undermine the review process are unacceptable and is a direct violation Section 3.2(f) of the Apple Developer Program License Agreement. Continuing to violate the Terms & Conditions of the Apple Developer Program will result in the termination of your account, as well as any related or linked accounts, and the removal of all your associated apps from the App Store.

We want to provide a safe experience for users to get apps and a fair environment for all developers to be successful. If you believe we have misunderstood or misinterpreted the intent of your app, you may submit an appeal for consideration or provide additional clarification by responding directly to this message in Resolution Center in iTunes Connect.

---

Regarding 2.3.1, it seems that App Review team didn't use my app in right way, since I didn't provide same account and password as same as the one in the 5 screenshots I provided for submit. I have already sent email to App Review team for more explanation.

Regarding 2.5.2, seems like hot push is not allowed (I used react-native-code-push for hot push, and I also open an issue in https://github.com/Microsoft/react-native-code-push/issues/982), but I also found some API method names have been mentioned, not sure whether they're private API since I have no native knowledge.