The recent requirement of "use_frameworks!"

[kristfal]

This is a continuation of the closed topic at #131, feel free to close this issue and reopen that if it makes more sense.

5.6.0 introduced a hard requirement for pod installation to enable use_frameworks!.

While this works well for this library in isolation, a fair share of other iOS libraries fails to compile with dynamic frameworks, including Firebase, Google Analytics++.

For any app with dependencies like the ones mentioned above, it seems like the only option is to drop the Mapbox pods and embed pre-downloaded binaries. This is a poor developer experience for many reasons.

For anyone maintaining downstream projects, this means having to pick between asking users to enable use_frameworks!, guide them through downloading and installing static frameworks or use Carthage. Neither options are good, and for those of us who are maintaining RN projects, Carthage is not really an option.

With this in mind, how do you recommend we handle this situation? Would you be able to reverse the use_frameworks requirement?

Some relevant downstream tickets:
mapbox/mapbox-navigation-ios#2309
https://github.com/react-native-mapbox-gl/maps/issues/635

[chrisballinger]

I came here to raise the same issue. Our app uses static linking for launch performance reasons, with use_modular_headers! in the Podfile instead of use_frameworks!.

Additionally CocoaPods 1.9 is introducing a static framework linking option use_frameworks! :linkage => :static, which will trigger the same issue. This feature will eventually allow individual pods to be marked as statically or dynamically linked, but in the meantime we will be forced to use a workaround.

Another solution is that Mapbox (or the community) could ship another podspec with a statically linked framework that uses spec.static_framework = true.

[julianrex]

Thanks both of you for the detailed comments - we are currently evaluating the most appropriate path forwards.

Would you be able to reverse the use_frameworks requirement?

This is part of our discussions; we also need to consider our other distribution methods and ensure that we're consistent across the board.

@chrisballinger thanks for the link about 1.9.

Providing another podspec is another thing we're considering. We will update this thread when there's more clarity.

[kristfal]

Thanks for the update. I know this is a complex topic, but any idea when you plan to make a decision?

If we are looking at several weeks until a solution can be made, we’ll apply a workaround in the react-native wrapper. If it is a matter of days, I’d be more comfortable deferring the solution to whatever you end up with.

[stonetip]

This is an important issue to us as well, for the reasons stated by @kristfal and @chrisballinger above.

[makozlo-airship]

Commenting to add that this is important to us as well, we have an impending product delivery we're trying to prepare for.

[julianrex]

If we are looking at several weeks until a solution can be made, we’ll apply a workaround in the react-native wrapper. If it is a matter of days, I’d be more comfortable deferring the solution to whatever you end up with.

@kristfal In the short-term, I would apply a work-around; I don't have a better timeline for you unfortunately.

/cc @knov

[olegdater]

Just to let you know, this is huge issue for us as well. Basically made the package unusable. Unable to use with such non-replaceable packages as firebase

[chrisballinger]

@julianrex It looks like your build instructions still reference a static framework option if you're manually building from source: https://github.com/mapbox/mapbox-gl-native-ios/blob/ios-v5.7.0-beta.1/platform/ios/INSTALL.md#static-framework

Do those instructions still work? If they do, would it be possible to tell the MapboxCI system to publish static frameworks as release assets? IIRC at some point Mapbox was publishing prebuilt static and dynamic frameworks. That way the community could provide a podspec that references these static frameworks as a workaround.

[yilakt]

This is a huge issue, and makes the package unusable / incompatible with too many packages.

Can you please remove useframeworks!

[allthetime]

What is the workaround? I just did a library upgrade and now I am blocked.

[yilakt]

@allthetime downgrade to version 7.0.9 I think

[parrots]

@allthetime I had my install pinned to 5.5 and that was working for me. I didn't want to fall too far behind though, and I wasn't sure this would be fixed in time for the Metal SDK (which I really really need), so I moved to Carthage for MapBox.

[Vednus]

I'm not having to deal with this anymore because the only conflict I was having was an issue with appcenter and they've since updated their packages. But, I did see this in react-native-permissions which might help you guys out: https://github.com/react-native-community/react-native-permissions#%EF%B8%8F-if-you-encounter-the-error-invalid-rnpermission-x-should-be-one-of-

[Alaa-Ben]

Any news on this ? I have the same issue with use_frameworks incompatibilities :'(

[stonetip]

We’re not using RN, so any downside to switching over to Carthage? The most important dependencies otherwise are GRDB and Apple’s Swift Protobuf. I’ve been wondering too about Metal? Is that one of the main reasons to migrate to the latest Mapbox SDK?

[mfazekas]

FWIW we're (react-native-mapbox-gl) working around the issue using this:

 s.dependency 'Mapbox-iOS-SDK', '~> 5.7'
 s.dependency '@react-native-mapbox-gl-mapbox-static', '~> 5.7'

'@react-native-mapbox-gl-mapbox-static' is a podspec created by me, it just links in "dynamic/MapboxMobileEvents.framework" from "https://mapbox.s3.amazonaws.com/mapbox-gl-native/ios/builds/mapbox-ios-sdk-5.7.0-dynamic-with-events.zip"

https://github.com/CocoaPods/Specs/blob/master/Specs/6/1/a/@react-native-mapbox-gl-mapbox-static/5.7.0/@react-native-mapbox-gl-mapbox-static.podspec.json

[stonetip]

Is the "use_frameworks!" issue ever going to be resolved, particularly in July when the new Mapbox GL Native renderer is introduced? (Kinda hoping to upgrade for that).

[allthetime]

There is a workaround now it is detailed in install instructions

…

On Tue, Jun 23, 2020 at 2:13 PM Jon Nehring ***@***.***> wrote: Is the "use_frameworks!" issue ever going to be resolved, particularly in July when the new Mapbox GL Native renderer is introduced? (Kinda hoping to upgrade for that). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#154 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQU4BJWFU6LS7JVP6UI6M3RYELH3ANCNFSM4KLQABOA> .

[ghost]

There is a workaround now it is detailed in install instructions

Could you please link to it as the "official" install instructions still says "use_frameworks!" must be included in the podfile?