Apple rejected build because it links against MapKit and not uses it

[iby]

Your app links against the MapKit framework but does not appear to include Maps functionality. If your app does include Maps functionality, please respond to this message in Resolution Center with steps on how to locate it within your app.

If you do not intend to use Maps, please unlink the MapKit framework. If you would like to use Maps, please add the "com.apple.developer.maps" entitlement and submit an updated binary for review.

If you are using a third-party framework that links against the MapKit framework, you may want to contact the third-party framework provider for help on unlinking from it.

Turns out the lucky framework is ReactiveCocoa with MapKit extensions, which are available since 2016… ☹️

otool -L ReactiveCocoa.framework/ReactiveCocoa; 
ReactiveCocoa.framework/ReactiveCocoa:
	@rpath/ReactiveCocoa.framework/ReactiveCocoa (compatibility version 1.0.0, current version 1.0.0)
	@rpath/ReactiveSwift.framework/ReactiveSwift (compatibility version 1.0.0, current version 1.0.0)
	@rpath/Result.framework/Versions/A/Result (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1349.63.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1504.82.104)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1349.64.0)
	@rpath/libswiftAppKit.dylib (compatibility version 1.0.0, current version 802.0.53)
	@rpath/libswiftCore.dylib (compatibility version 1.0.0, current version 802.0.53)
	@rpath/libswiftCoreData.dylib (compatibility version 1.0.0, current version 802.0.53)
	@rpath/libswiftCoreGraphics.dylib (compatibility version 1.0.0, current version 802.0.53)
	@rpath/libswiftCoreImage.dylib (compatibility version 1.0.0, current version 802.0.53)
	@rpath/libswiftCoreLocation.dylib (compatibility version 1.0.0, current version 802.0.53)
	@rpath/libswiftDarwin.dylib (compatibility version 1.0.0, current version 802.0.53)
	@rpath/libswiftDispatch.dylib (compatibility version 1.0.0, current version 802.0.53)
	@rpath/libswiftFoundation.dylib (compatibility version 1.0.0, current version 802.0.53)
	@rpath/libswiftIOKit.dylib (compatibility version 1.0.0, current version 802.0.53)
	@rpath/libswiftMapKit.dylib (compatibility version 1.0.0, current version 802.0.53)
	@rpath/libswiftObjectiveC.dylib (compatibility version 1.0.0, current version 802.0.53)
	@rpath/libswiftQuartzCore.dylib (compatibility version 1.0.0, current version 802.0.53)
	@rpath/libswiftXPC.dylib (compatibility version 1.0.0, current version 802.0.53)

For some reason this issue wasn't flagged before. I explained the situation and waiting for response, but it seems like a legit case – the app doesn't need MapKit and it doesn't need entitlements without users actually needing this functionality. Any easy workarounds?

[andersio]

Any easy workarounds?

You can build RAC without the MapKit bindings, which is all covered by MKMapView.swift AFAICR. We do not have other build settings or places that link against MapKit.

If you use CocoaPods, you may clone the podspec to exclude the said file, while still pointing to this repo.

Apparently we would have to offer these bindings separately if Apple tightens the rules. We cannot workaround it without a new framework target or subspec given how Swift module import works.

[iby]

Yep, MKMapView.swift appears to be the root of this dependency. It certainly is a workaround, but would involve doing it every time dependencies are updated with Carthage, which takes the problem on whole new level. Anyway, I'm gonna see what Apple review team thinks about this situation.

Regarding the solution, separating MapKit into ReactiveMapKit is definitely a neat approach. Alternatively we could use MAPKIT compiler flag pulled from environment and wrap the whole extension in a conditional compile statement. Just tried this with Carthage and it worked, but aesthetics of this raise questions:

ianbytchek@ibmbp:dependency$ carthage build reactivecocoa --platform mac
ianbytchek@ibmbp:Mac$ otool -L ReactiveCocoa.framework/ReactiveCocoa 
ReactiveCocoa.framework/ReactiveCocoa:
	…
	@rpath/libswiftIOKit.dylib (compatibility version 1.0.0, current version 802.0.53)
	@rpath/libswiftObjectiveC.dylib (compatibility version 1.0.0, current version 802.0.53)
	…
ianbytchek@ibmbp:dependency$ RC_SWIFT_FLAGS="-DMAPKIT" carthage build reactivecocoa --platform mac
ianbytchek@ibmbp:Mac$ otool -L ReactiveCocoa.framework/ReactiveCocoa 
ReactiveCocoa.framework/ReactiveCocoa:
	…
	@rpath/libswiftIOKit.dylib (compatibility version 1.0.0, current version 802.0.53)
	@rpath/libswiftMapKit.dylib (compatibility version 1.0.0, current version 802.0.53)
	@rpath/libswiftObjectiveC.dylib (compatibility version 1.0.0, current version 802.0.53)
	…

[andersio]

Regarding the solution, separating MapKit into ReactiveMapKit is definitely a neat approach.

I think we would go after this path. Probably subspecs for CocoaPods users.

[iby]

It would be appropriate to resolve this issue in a future update, however, we will now proceed with your review.

Apple spared me, but said punishment is inevitable next time.

[andersio]

Glad to know. Will push this forward ASAP.