30 Replies
      Latest reply: May 5, 2017 4:14 PM by literal RSS
      assdass Level 1 Level 1 (0 points)

        Just got this message for a few of my apps that are live in the app store (and have been for years).

         

        "Your app, extension, and/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 section 3.3.2 of the Apple Developer Program License Agreement and App Store Review Guideline 2.5.2. 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 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.

        Please perform an in-depth review of your app and remove any code, frameworks, or SDKs that fall in line with the functionality described above before submitting the next update for your app for review."

         

        I'm not sure what they are referring to, or how to resolve this issue.  I am guessing there will be a swarm of these posts coming from affected developers.  Does anyone have ideas what would cause this & how to resolve?  I dont even know where to start...

        • Re: Message from Apple Review...
          vinny1575 Level 1 Level 1 (0 points)

          Are you using Rollout.io? I'm getting the same message. Trying to figure out what it is. Rollout.io is the closest thing.

          • Re: Message from Apple Review...
            wjacker3 Level 1 Level 1 (0 points)

            we got this message too, please advice us how to fix this

            • Re: Message from Apple Review...
              abecedarian Level 1 Level 1 (0 points)

              We got this message too, and we also have Rollout SDK in our project, though we are not using it. And do you guys see para 2?

               

              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 or call SPI, based on the contents of the downloaded script.

               

              Does it means we can't use these methods anymore? Especially respondsToSelector and performSelector, they are quite useful. 

                • Re: Message from Apple Review...
                  orion_ggl Level 1 Level 1 (0 points)

                  No, the key is "passes arbitrary parameters".

                   

                  Calling performSelector() with a valid selector to your own code which is known at compile-time by Xcode is part of ordinary Objective-C programming and I don't think Apple would have any intent to remove it.

                   

                  Calling performSelector with a selector you construct at runtime could be used to call private framework methods or other things that Apple don't like (and which have always been against the app review rules).

                  I'm guessing this restriction is to stop you bypassing a static scan for private framework selectors and suchlike.

                  • Re: Message from Apple Review...
                    racecarr Level 1 Level 1 (0 points)

                    I'm pretty confident Apple is not going to outright ban method calls such as

                    respondsToSelector:

                    or

                    performSelector:

                    . The important part is "passes arbitrary parameters to dynamic methods". Don't do that with code downloaded dynamically (i.e. via Javascript from the internet) and you'll be fine.

                  • Re: Message from Apple Review...
                    mstearne Level 1 Level 1 (0 points)

                    I wonder if this is targeted also at frameworks like MeteorJS and Ionic that allow for your WebView based apps to be updated without review. That always seemed like a pretty pourus (but convienent) solution for app updates.

                    • Re: Message from Apple Review...
                      shujucn Level 1 Level 1 (0 points)

                      I also receive this message from apple. And just use framwork of  mixpannel to collect app log, I am not sure is this the same issure

                      • Re: Message from Apple Review...
                        aperiz Level 1 Level 1 (0 points)

                        What about React Native apps? 

                        • Re: Message from Apple Review...
                          Nick Moore Level 1 Level 1 (0 points)

                          Not sure what Rollout can do to "fix" this. It seem pretty clear that Rollout's functionality is explicitly not allowed by Apple.

                          • Re: Message from Apple Review...
                            DavidDB Level 1 Level 1 (0 points)

                            This message worries me slightly, as all our applications make use of a library that relies on method_exchangeImplementations(), however merely for extending the functionality of some classes, nothing like injecting code from a remote resource as rollout.io is doing.

                             

                            App Store Review Guideline 2.5.2 states the following:

                            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 iOS, watchOS, macOS, or tvOS apps.

                             

                            So applications that have a valid use for dlopen(), dlsym(), respondsToSelector:, performSelector:, method_exchangeImplementations() should not be affected by this I hope?

                              • Re: Message from Apple Review...
                                dickey Level 1 Level 1 (0 points)

                                method_exchangeImplementations() is the basis of method swizzling.  It is used by every major library (AFNetworking, analytics, growth marketing, crash management sdks, growth automation) and many apps.  Apps that have a valid use of method_exchangeImplementations() aren't affected.

                                 

                                I don't thing Apple is going to break this.  Changing behavior of app using JavaScriptCore and executing javascript that is downloaded and executed is at risk of man in the middle attack.

                                 

                                If you look at the timing of this change, it points to CIA Wikileaks earlier that day... I believe on March 7

                                 

                                I am not a security expert, but I think Apple should allow javascript downloads over TLS / HTTPS, require Strict-Transport-Security header,  use certificates to establish trust, and establish explicit trust between the app and the javascript source.

                                 

                                We have seen improvements when we moved "Beyond Deep Linking" to iOS Universal Links (and Android App Links), where, the website uses apple-app-site-association in the .well-known subfolder of website and the app has to add the applinks in the app capabilities section in Xcode.

                              • Re: Message from Apple Review...
                                KoCMoHaBTa Level 1 Level 1 (0 points)

                                You can start by figuring out which functionality or behaviour of your app and/or the frameworks your are using could cause this.

                                You are the person who knows your product and code.

                                You did not even posted minimum information about your product behaviour and libraries you've used.

                                This is like asking random persons "why my car engine is not starting" and you'de expect the solution right away.

                                Apparantly the obvious cause would be rollout.io and they noticed that they are working on a fix for this, so until then you are probably stuck.

                                • Re: Message from Apple Review...
                                  graham-snapkitchen Level 1 Level 1 (0 points)

                                  Rollout is one thing; performSelector is another. I wish Apple's description of the issue were a little clearer about this. If we can't use performSelector that's going to be a challenge. What could be meant by "arbitrary parameters"? Is the "and" in

                                   

                                  "... includes any code which passes arbitrary parameters to dynamic methods ..., *and* running remote scripts"

                                   

                                  just a continuation of banned things, or is it a boolean and, so you can do all the former as long as you're not running remote scripts?

                                  • Re: Message from Apple Review...
                                    mhteas Level 1 Level 1 (0 points)

                                    So as useful as Rollout.io is for those using it, it's a violation of the app review guidelines.  I looked at it when it came out and decided not to get involved partly to avoid buying myself what I thought of as future trouble.

                                     

                                    App review guidelines:

                                     

                                    • 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 iOS, watchOS, macOS, or tvOS apps.

                                     

                                    The "download" part if that is what Rollout.io does.

                                    • Re: Message from Apple Review...
                                      vimipatel Level 2 Level 2 (30 points)

                                      Hello everyone,

                                       

                                      I think you should know about this : https://9to5mac.com/2017/03/07/apple-cracks-down-on-hot-push-code-sdks/ 

                                      So, If your app is live on store then you should contact to your SDK provider and ask for solution. They might contact to Apple Inc. and find some better support.

                                      • Re: Message from Apple Review...
                                        jonnolen Level 1 Level 1 (0 points)

                                        Have there been any reports of this affecting reactnative apps?

                                          • Re: Message from Apple Review...
                                            zingmagic Level 1 Level 1 (0 points)

                                            we think we might have just been hit by this - we use a 3rd party lib that has react native in it + as far as we can tell is the most likely source of the issue

                                              • Re: Message from Apple Review...
                                                dickey Level 1 Level 1 (0 points)

                                                Which SDK? Could you specify.

                                                  • Re: Message from Apple Review...
                                                    zingmagic Level 1 Level 1 (0 points)

                                                    Skillz eSports SDK.

                                                     

                                                    Outside of std ios frameworks we have a couple of ad providers (AdMob, Applovin) and facebook analytics. None of these seem very likely candidates. We definately dont do any of the 'failure' things in our main app code.

                                                     

                                                    The frustrating part is there does not seem to be any way or any tools to actually determine which frameworks might be causing the issue - as far as we can tell the only way to find out is to build apps with each of the frameworks removed one at a time and see if Apple accept/reject whcih hardly seems intelligent..

                                                      • Re: Message from Apple Review...
                                                        KMT Level 8 Level 8 (9,290 points)

                                                        >and see if Apple accept/reject whcih hardly seems intelligent..

                                                         

                                                        This isn't a new situation. Apple tends to keep things vague so they can define/apply on the fly, without being boxed in/dragged into debate ("You didn't explicitly write that I couldn't do this, so get out of my way"), so I don't think there is a solution that favors everyone.


                                                        Of course, it leaves devs to poke around in the dark, at least until the dust settles, and some will find it more of a burden than others - welcome to the app store.

                                                  • Re: Message from Apple Review...
                                                    dovidfekkeatswyft Level 1 Level 1 (0 points)

                                                    From the React Native github issues;

                                                    3.3.2 of Apple Developer Program License:

                                                    An Application may not download or install executable code. Interpreted
                                                    code may only be used in an Application if all scripts, code and interpreters are
                                                    packaged in the Application and not downloaded. The only exception to the
                                                    foregoing is scripts and code downloaded and run by Apple's built-in WebKit
                                                    framework or JavascriptCore, provided that such scripts and code do not change
                                                    the primary purpose of the Application by providing features or functionality that are
                                                    inconsistent with the intended and advertised purpose of the Application as
                                                    submitted to the App Store.

                                                    explicitly mentions that:

                                                    An Application may not download or install executable code

                                                    React Native does none of these. And so, using React Native doesn't expose you to the aforementioned issue.

                                                      • Re: Message from Apple Review...
                                                        Samfrompluto Level 1 Level 1 (0 points)

                                                        What about react native apps that use a service like code push. With a service like that in theory you could completely change the app functionally. We use apps that use code push and while we don't ever change app functionality using code push, we have fixed a few critical bugs and pushed it immediately to clients. It's very concerning as to what exactly this could apply to.

                                                        • Re: Message from Apple Review...
                                                          CausticMango Level 1 Level 1 (0 points)

                                                          I don't know, that response sounds a little like whistling past the graveyard. While React Native may not have been intended for the same purpose as Rollout.io, it is certainly possible to use it that way.

                                                           

                                                          In fact, it is one of the touted "benefits" of RN, as explicitly called out by some users. Note the quote from this blog post https://www.aerofs.com/blog/reactnativeautoupdater-dynamic-updates-to-react-native-apps/

                                                           

                                                          "Technically, we can ship a React Native app with no Javascript code, and point it to a URL on the server on the internet. That would be just like how the dev environment works. The problem with that is that JS-bundles tend to be very big. A simple app can easily run into a couple of megabytes. Wasting the time and bandwidth to download them every time the app runs is clearly not an ideal way of doing things.

                                                           

                                                          "Luckily, this is super easy to solve. We can ship the app with an initial JS-bundle, and check for updates in the background after the app starts."

                                                           

                                                          I wouldn't be shocked to see RN come under scrutiny in the future (in fact, I'd go so far as to say is *should* come under scrutiny).

                                                          • Re: Message from Apple Review...
                                                            zingmagic Level 1 Level 1 (0 points)

                                                            As far as we can tell React Native is the issue for us.

                                                             

                                                            What is entirely possible is that the 'forbidden' methods exist within the RN library regardless of whether they get used or not (dont know how intelligent the linkers are for different langs these days). Simply by virtue of the methds existing in the library the app fails whatever testing tool is being used.

                                                             

                                                            So the key is that 'its certainly possible to use it that way' even if no one ever does/did knowingly or otherwise.

                                                             

                                                            Any one any clue as to who/what determines exactly what is considered as "significant changes to your app’s behavior".

                                                            As far as we can tell any change at all is considered "signficant".