CocoaPods, Reachability, and use_frameworks! #95

g0ld2k opened this Issue Mar 19, 2015 · 19 comments


None yet
g0ld2k commented Mar 19, 2015

With CocoaPods 0.36, they added the capability to generate frameworks for pods. For Swift projects, using frameworks eliminates the need for a Objective-C bridge.


    # Uncomment this line to define a global platform for your project
    platform :ios, "8.0"

    target "VB ParkFinder" do
    pod 'ArcGIS-Runtime-SDK-iOS', '~> 10.2'
    pod 'Reachability', '~> 3.2'
    pod 'TUSafariActivity', '~> 1.0.3'
    pod 'NHCalendarActivity', '~> 0.0.1'

    target "VB ParkFinderTests" do


Reachability works great as a Framework, however when submitting the app to Apple, Apple incorrectly identifies Reachability as being a private API (it looks like there is a private API class called Reachability), which causes the app to be rejected.

Dear developer,

We have discovered one or more issues with your recent delivery for "VB ParkFinder". To process your delivery, the following issues must be corrected:

Non-public API usage:

The app contains or inherits from non-public classes in VB ParkFinder: Reachability

If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed.

If you think this message was sent in error and that you have only used Apple-published APIs in accordance with the guidelines, send the app's nine-digit Apple ID, along with detailed information about why you believe the above APIs were incorrectly flagged, to For further information, visit the Technical Support Information page.

Once these issues have been corrected, you can then redeliver the corrected binary.


The App Store team

None of the other Pods in my project caused this issue.

I was able to work around the issue by removing the use_frameworks! line from my Podfile and creating a Objective-C bridging file, no other code was changed. My submission without use_frameworks! passed Apple's initial checks without a problem.

I'm not sure what the solution would be, but it sounds like there is a collision occurring with Apple's private frameworks due to the naming of your project.


Thats a new one! The solution, I suppose, would be to rename the framework as something else while keeping the name for compiled projects?



Got rejected for the same reason. I'd rather not remove use_frameworks!. Is there another quick solution for this?

@g0ld2k g0ld2k referenced this issue Apr 1, 2015

App rejection #96



Our's got rejected due to this, too.


time for a rename it seems.


I agree - I have a lot of work right now, but I'd like to look into if you can detect when being compiled as a framework and change the class name dynamically.


Why not just TMReachability? We'll know it's still Reachability under the
hood. :)

On Mon, Apr 20, 2015 at 11:09 AM, Tony Million

I agree - I have a lot of work right now, but I'd like to look into if you
can detect when being compiled as a framework and change the class name

Reply to this email directly or view it on GitHub
#95 (comment)


Faced the same problem today. Renaming should fix it.

@seanoshea seanoshea referenced this issue in seanoshea/BluePlaquesLondon May 1, 2015

Reachability class can be replaced with a pod. #41

allaire commented May 8, 2015



I'm also facing this problem. Can't remove use_frameworks! because we're using some Swift pods.
None of the forks I've looked at seem to rename everything properly for CocoaPods.


@cpatterson I forked and use this regularly to get my app into the app-store. It might be a few fixes behind. I was planning on bringing it up-to-date soon™ (if needed):

@tonymillion I recommend renaming the items in question to TMReachability instead of chasing the golden helicopter solution. Especially since this issue is a) a blocking issue, and b) over two months old.


@tonymillion: you added the big warning in the README for this issue; but if you don't mind me saying, that's not really a solution that helps a CocoaPods user, which is where this issue was discovered. 😉


warpling commented Jul 9, 2015

I'm struggling a bit with this. I renamed Reachability's files and classes and successfully submitted to Apple but after a pod install I am getting linker errors with TMReachability. Is there a correct way to fix this via the pod or should I just ditch the pod in favor of my own fork or copying in the files manually?


@warpling: as per @albertbori suggestion, that's what I'm currently doing:

pod 'TMReachability', :git => '', :commit => 'e34782b386307e386348b481c02c176d58ba45e6'

Thanks @Cinamonas, I missed that! I ended up just pulling in the two files and renaming them.


@albertbori thanks for sharing your fork. fixed this issue for me!






@Cinamonas solution somehow works for me when I run it on the phone, but fails when I attempt an App Store archive. Anyone else run into this?


@DaveCole different target for release/debug perhaps? Can you run it on your phone in release mode? (You can change the mode in Product > Edit Scheme)

@aaronschachter aaronschachter referenced this issue in DoSomething/LetsDoThis-iOS Oct 5, 2015

Handle offline connection #91

0 of 1 task complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment