AppStore rejections for NSLocationWhenInUseUsageDescription

[peterpaulis]

Description:
I cannot upload my app to appstore as i get

Missing Info.plist key - This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSLocationAlwaysUsageDescription key with a string value explaining to the user how the app uses this data.

The app was previously working and approved, this was an minor minor update

My app doesnt use location!

Environment
Latest XCode 9.3

Steps to Reproduce Issue:

1. submit app using onesignal to appstore
2. you ge immidietly rejected

Anything else:

(crash stacktraces, as well as any other information here)

[LKaemmerling]

See OneSignal/OneSignal-Cordova-SDK#363 for this.

[gdeglin]

Thanks for reporting this. Our team is investigating.

[uncleho]

It's an issue happening to a lot of people on the developer forums, not sure if it's OneSignal related: https://forums.developer.apple.com/thread/101367

[Nightsd01]

@peterpaulis Can you try something as a debugging step? Can you try removing the OneSignal SDK from your project and see if that resolves the issue?

You don't actually have to submit for App Store review, we just want to see if you can upload a build.

We're trying to reproduce this issue on our side, we've got some test apps, but our apps are not getting denied.

[Nightsd01]

@peterpaulis We suspect Apple may have fixed this in the past hour or two, can you try uploading another build?

[habovh]

Can confirm this just happened to me as well.

I do not need the "Always" access to location, but it seems like the NSLocationAlwaysUsageDescription is now mandatory when using OneSignal SDK, and the location prompt will now ask for either "While using" or "Always" option regarding location access.
I very much do not like it, since asking for an "intrusive" permission that I do not even need doesn't seem appropriate.

Any way to configure the SDK so it does not try to ask for "Always" location permissions?

[Nightsd01]

@habovh This seems to be happening to a lot of people, many of them don't use the OneSignal SDK in their app, so we don't think this issue is related to OneSignal.

NSLocationAlwaysUsageDescription is not mandatory with the OneSignal SDK. It will work just fine if you only use NSLocationWhenInUsageDescription. The problem seems to have been an issue with Apple's review system, and it seems they are rolling out a fix. We will continue to keep investigating the problem.

In the mean time, can you try completely removing the OneSignal SDK from your project and see if Apple will accept a new build? You don't need to submit it for review, we just want to isolate the issue.

[Nightsd01]

Ok, I can confirm that Apple is aware of this issue and their engineers are looking into it.

[Nightsd01]

It appears that Apple has resolved this issue. I will be closing the issue soon. If you are still encountering this problem uploading binaries, please reply

[OmarShoaib]

Hi,

I've just uploaded the newer version of the app to the App Store and I got below email from Apple. I am not using any sort of location service in the app although previous versions was uploaded perfectly.

-- 
Dear Developer,

We identified one or more issues with a recent delivery for your app, "<app_name>". Your delivery was successful, but you may wish to correct the following issues in your next delivery:"Missing Purpose String in Info.plist File. Your app's code references one or more APIs that access sensitive user data. The app's Info.plist file should contain a NSLocationAlwaysUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. Starting spring 2019, all apps submitted to the App Store that access user data will be required to include a purpose string.If you're using external libraries or SDKs, they may reference APIs that require a purpose string. While your app might not use these APIs, a purpose string is still required. You can contact the developer of the library or SDK and request they release a version of their code that doesn't contain the APIs. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy)."

"Missing Purpose String in Info.plist File. Your app's code references one or more APIs that access sensitive user data. The app's Info.plist file should contain a NSLocationWhenInUseUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. Starting spring 2019, all apps submitted to the App Store that access user data will be required to include a purpose string.If you're using external libraries or SDKs, they may reference APIs that require a purpose string. While your app might not use these APIs, a purpose string is still required. You can contact the developer of the library or SDK and request they release a version of their code that doesn't contain the APIs. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy)."

After you’ve corrected the issues, you can use Xcode or Application Loader to upload a new binary to iTunes Connect.

Best regards,

The App Store Team

Anything from you guys will be a great help.

Thanks

[Nightsd01]

Hi @OmarShoaib

Our SDK doesn’t access location directly, it uses reflection at runtime to see if your app has location enabled. Even then it will only access location unless you call setLocationShared(false)

Can you give a list of the dependencies in your app in addition to our SDK’s?

[OmarShoaib]

Thanks for quick reply @Nightsd01

BTW I forgot to tell you that I am using UnitySDK of OneSignal and the dependencies/plugins besides OneSignal that I am using are listed below

Vuforia
Sqlite3
NativeGallery
UnityOBBDownloader (Uses PlayServices)

They all are working fine until the last update.

[keithdmoore]

I just started getting this message as well.

[Nightsd01]

@OmarShoaib that is interesting, this issue used to be extremely rare, Apple may have changed things. We will look into this issue.

[tahasabih]

Happening to me now as well.
My iOS target is iOS 10 where this string was compulsory for applications needed this whenever accessing location apis.
When I had me iOS target as iOS11, apple did not give me any errors before.

[EthanCG]

Hi, just happening to me.
I'm using ionic, below version info
`cli packages: (/usr/local/lib/node_modules)

@ionic/cli-utils  : 1.19.2
ionic (Ionic CLI) : 3.20.0

global packages:

cordova (Cordova CLI) : 8.0.0 

local packages:

@ionic/app-scripts : 3.1.11
Cordova Platforms  : ios 4.5.5
Ionic Framework    : ionic-angular 3.9.2

System:

Node  : v6.11.2
npm   : 3.10.10 
OS    : macOS High Sierra
Xcode : Xcode 9.4.1 Build version 9F2000 

`
Plugin depencies
cordova-plugin-device 2.0.2 "Device"
cordova-plugin-document-viewer 0.9.10 "SitewaertsDocumentViewer"
cordova-plugin-file 6.0.1 "File"
cordova-plugin-file-transfer 1.7.1 "File Transfer"
cordova-plugin-inappbrowser 3.0.0 "InAppBrowser"
cordova-plugin-ionic-keyboard 2.1.2 "cordova-plugin-ionic-keyboard"
cordova-plugin-ionic-webview 2.0.2 "cordova-plugin-ionic-webview"
cordova-plugin-splashscreen 5.0.2 "Splashscreen"
cordova-plugin-whitelist 1.3.3 "Whitelist"
cordova-plugin-youtube-video-player 1.0.6 "CordovaYoutubeVideoPlayer"
onesignal-cordova-plugin 2.4.3 "OneSignal Push Notifications"

I have other apps with same depencies except OneSignal and I haven't store rejection.

[EthanCG]

I just tried again, I sent few build, switching iOS version 10.4 (issue detected) > 11.3 (issue detected) and back to 10.4 (no issue detected).
Maybe an Apple automatic code review system error?

[EthanCG]

Then after many tests, I removed OneSignal for compatibility issue with YouTubePlayer plugin and replace it by another notification plugin. Same issue with this second notification provider. The only way to solve the Apple mail issu is to add key to the info.plist like this :
<key>NSLocationAlwaysUsageDescription</key> <string>Send Geolocated notifications</string> <key>NSLocationWhenInUseUsageDescription</key> <string>Send Geolocated notifications</string>
Adding entry in the config.xml doesn't make required update to the info.plist file.

[kaasasolut]

I think it's because of Unity itself. We do not use this SDK but got the same message from App Store Connect just moments ago.
Unity includes a file called iPhone_Sensors.mm. In that, there's the following code:

void LocationService::StartUpdatingLocation()
{
    if (gLocationServiceStatus.locationStatus != kLocationServiceRunning)
    {
        CLLocationManager* locationManager = gLocationServiceStatus.GetLocationManager();

        // request authorization on ios8
        if ([locationManager respondsToSelector: @selector(requestWhenInUseAuthorization)])
            [locationManager performSelector: @selector(requestWhenInUseAuthorization)];

        locationManager.desiredAccuracy = gLocationServiceStatus.desiredAccuracy;
        // Set a movement threshold for new events
        locationManager.distanceFilter = gLocationServiceStatus.distanceFilter;

#if PLATFORM_IOS
        [locationManager startUpdatingLocation];
#else
        [locationManager requestLocation];
#endif

        gLocationServiceStatus.locationStatus = kLocationServiceInitializing;
    }
}

The documentation for requestWhenInUseAuthorization says:

When the current authorization status is kCLAuthorizationStatusNotDetermined, this method runs asynchronously and prompts the user to grant permission to the app to use location services. The user prompt contains the text from the NSLocationWhenInUseUsageDescription key in your app’s Info.plist file, and the presence of that key is required when calling this method.

It seems that Apple changed something in their processing, so that triggers the message now.

[Nightsd01]

Thanks for the helpful info. It looks like Apple is simply scanning the bitcode for any usage of location services. Our SDK accesses location services indirectly to avoid a crash if an app doesn’t use location services, so they must be scanning strings too....

It’s a bit ridiculous considering how many dependencies/frameworks use location services but only under certain conditions that may not be applicable to some apps.

I’ll keep this issue open until we’ve found a solution.

As a temporary workaround, if you don’t use location-based push notifications, you can call OneSignal.setLocationShared(false). That will turn off location access from our SDK. If you add the location permissions to your info.plist, Apple will stop sending you those warnings, but as long as your app never requests location permission, the plist strings will go unused.

[OmarShoaib]

Thumbs up! @EthanCG and @Nightsd01

For now, I've just added both OneSignal.SetLocationShared(false) and NSLocation permission strings and uploaded the binary. Voila! No error emails. And there's no popup of location permission in the app as well. So, that might be a possible workaround at the time.

Thanks all

[keithdmoore]

Without making any changes, I did not get any emails from Apple today after pushing a build to the App Store.

[Nightsd01]

We have heard that this was a bug with Apple's static analysis for new build uploads and was fixed - we have not heard any additional complaints so I'll be closing this issue.

If anyone sees an email like this in the future please post here.

[VitorGit]

Just received this exact same email. No new plugins were added and the previous builds were accepted just fine.

[gnoph]

We got the same email today too. Not sure if it's another one-time deal or Apple really believes that we are using location APIs. I searched the xcode project generated by Unity's iOS build for "NSLocation" and I found only libOneSignal.a having a match.

UPDATE: CLLocationManager is found in both Unity's iPhone_Sensors.mm and libOneSignal.a. OneSignal uses it indirectly through NSClassFromString. iPhone_Sensors.mm uses it explicitly.

UPDATE2: Unity has a LocationService API built-in which uses iPhone_Sensors.mm. Even though we don't use LocationService in our app, CLLocationManager does seem to be linked in the final output of our iOS app because of it. I'm not sure whether libOneSignal.a's implicit use is also considered by Apple. But as long as we are using Unity, it doesn't seem like we can get away with it without providing NSLocationAlwaysUsageDescription. This seems to be Apple's new policy for "spring 2019".

[jkasten2]

@VitorGit Can you check if you have the Core Location library in your Xcode project. If so can your remove it?

@gnoph Thanks for all the details. If you remove the Core Location library from the generated project do you get compile errors with iPhone_Sensors.mm? I would assume so but it is possible there are preprocessors handling this.

[gnoph]

Hi, @jkasten2.

Thanks for the hint. I just realized that the CoreLocation usages from iPhone_Sensors.mm are conditional on UNITY_USES_LOCATION preprocessor macro, which is currently defined to 0 in our project. That is, our app does not depend on CoreLocation framework. The framework is included in the project but not tagged with any targets. Removing it from the project does not affect the build. I haven't tried App Store submission yet.

Now I think our app does not have explicit references of CoreLocation APIs in the binary at all. I guess Apple somehow detected it in OneSignal library, even though it's used indirectly.

@VitorGit Can you check if you have the Core Location library in your Xcode project. If so can your remove it?

@gnoph Thanks for all the details. If you remove the Core Location library from the generated project do you get compile errors with iPhone_Sensors.mm? I would assume so but it is possible there are preprocessors handling this.

[Nightsd01]

@bolino add the strings to your Info.plist. It’s a silly situation thanks to Apple but unfortunately that’s the current solution. Fortunately none of this will be visible to your users.

[vitovalov]

Same!

Please split the pod ASAP. Meanwhile I'm gonna be using Firebase Notifications. 🤷‍♂️

Had to fill this question to find out the answer that pointed me here.
https://stackoverflow.com/q/56777940/860311

[stsier]

Just use

NSLocationAlwaysAndWhenInUseUsageDescription

instead of NSLocationAlwaysUsageDescription + NSLocationWhenInUseUsageDescription

Apple is so stupidly secrete about their tweeks..

[skibitsky]

Same in v2.13.

ITMS-90683: Missing Purpose String in Info.plist - Your app's code references one or more APIs that access sensitive user data. The app's Info.plist file should contain a NSLocationAlwaysUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. Starting Spring 2019, all apps submitted to the App Store that access user data are required to include a purpose string. If you're using external libraries or SDKs, they may reference APIs that require a purpose string. While your app might not use these APIs, a purpose string is still required. You can contact the developer of the library or SDK and request they release a version of their code that doesn't contain the APIs. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy).

ITMS-90683: Missing Purpose String in Info.plist - Your app's code references one or more APIs that access sensitive user data. The app's Info.plist file should contain a NSLocationWhenInUseUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. Starting Spring 2019, all apps submitted to the App Store that access user data are required to include a purpose string. If you're using external libraries or SDKs, they may reference APIs that require a purpose string. While your app might not use these APIs, a purpose string is still required. You can contact the developer of the library or SDK and request they release a version of their code that doesn't contain the APIs. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy).

[DanielZ15]

Thanks for the helpful info. It looks like Apple is simply scanning the bitcode for any usage of location services. Our SDK accesses location services indirectly to avoid a crash if an app doesn’t use location services, so they must be scanning strings too....

It’s a bit ridiculous considering how many dependencies/frameworks use location services but only under certain conditions that may not be applicable to some apps.

I’ll keep this issue open until we’ve found a solution.

As a temporary workaround, if you don’t use location-based push notifications, you can call OneSignal.setLocationShared(false). That will turn off location access from our SDK. If you add the location permissions to your info.plist, Apple will stop sending you those warnings, but as long as your app never requests location permission, the plist strings will go unused.

hi @Nightsd01 . I realize your replies here are couple years back now. But I'm experiencing this now as a warning (testflight only, I don't have a production build yet). And I was wondering if you know if we do use this workaround (thank you for that btw), do you know by any chance if "Location" will appear under "Information" on the app page in the app store? That's my concern as it might deter downloads since people may think we use the location when we actually don't. Thanks!

[JetForMe]

I just integrated OneSignal into my iOS app and got this warning tonight, after having submitted earlier builds that didn't.

[GeylanKalafMohe]

Still getting this E-Mail:

ITMS-90683: Missing Purpose String in Info.plist - Your app's code references one or more APIs that access sensitive user data. The app's Info.plist file should contain a NSLocationAlwaysUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. Starting Spring 2019, all apps submitted to the App Store that access user data are required to include a purpose string. If you're using external libraries or SDKs, they may reference APIs that require a purpose string. While your app might not use these APIs, a purpose string is still required. You can contact the developer of the library or SDK and request they release a version of their code that doesn't contain the APIs. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy).ITMS-90683: Missing Purpose String in Info.plist - Your app's code references one or more APIs that access sensitive user data. The app's Info.plist file should contain a NSLocationWhenInUseUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. Starting Spring 2019, all apps submitted to the App Store that access user data are required to include a purpose string. If you're using external libraries or SDKs, they may reference APIs that require a purpose string. While your app might not use these APIs, a purpose string is still required. You can contact the developer of the library or SDK and request they release a version of their code that doesn't contain the APIs. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy).After you’ve corrected the issues, you can upload a new binary to App Store Connect.Best regards,The App Store Team

ITMS-90683: Missing Purpose String in Info.plist - Your app's code references one or more APIs that access sensitive user data. The app's Info.plist file should contain a NSLocationAlwaysUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. Starting Spring 2019, all apps submitted to the App Store that access user data are required to include a purpose string. If you're using external libraries or SDKs, they may reference APIs that require a purpose string. While your app might not use these APIs, a purpose string is still required. You can contact the developer of the library or SDK and request they release a version of their code that doesn't contain the APIs. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy).ITMS-90683: Missing Purpose String in Info.plist - Your app's code references one or more APIs that access sensitive user data. The app's Info.plist file should contain a NSLocationWhenInUseUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. Starting Spring 2019, all apps submitted to the App Store that access user data are required to include a purpose string. If you're using external libraries or SDKs, they may reference APIs that require a purpose string. While your app might not use these APIs, a purpose string is still required. You can contact the developer of the library or SDK and request they release a version of their code that doesn't contain the APIs. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy).After you’ve corrected the issues, you can upload a new binary to App Store Connect.Best regards,The App Store Team

ITMS-90683: Missing Purpose String in Info.plist - Your app's code references one or more APIs that access sensitive user data. The app's Info.plist file should contain a NSLocationAlwaysUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. Starting Spring 2019, all apps submitted to the App Store that access user data are required to include a purpose string. If you're using external libraries or SDKs, they may reference APIs that require a purpose string. While your app might not use these APIs, a purpose string is still required. You can contact the developer of the library or SDK and request they release a version of their code that doesn't contain the APIs. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy).ITMS-90683: Missing Purpose String in Info.plist - Your app's code references one or more APIs that access sensitive user data. The app's Info.plist file should contain a NSLocationWhenInUseUsageDescription key with a user-facing purpose string explaining clearly and completely why your app needs the data. Starting Spring 2019, all apps submitted to the App Store that access user data are required to include a purpose string. If you're using external libraries or SDKs, they may reference APIs that require a purpose string. While your app might not use these APIs, a purpose string is still required. You can contact the developer of the library or SDK and request they release a version of their code that doesn't contain the APIs. Learn more (https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy).After you’ve corrected the issues, you can upload a new binary to App Store Connect.Best regards,The App Store Team

[JetForMe]

I sometimes get the warning, sometimes don't.

[MihaMarkic]

Silly question, but what would somebody put into NSLocationAlwaysAndWhenInUseUsageDescription (or NSLocation***)? I mean, afterall the app isn't using it...

[GeylanKalafMohe]

@MihaMarkic 'We need to access your Location to send you proper notifications' for example

[Pedro-vzla]

Nov 24, 2022. still happening. The first time I had my app uploaded to testflight then approved in app store I did not get this email but now that I change literally one line of code ( updating a URL in the code ) I get the email. I set the NSLocationAlwaysAndWhenInUseUsageDescription string and hope this is going to help me in the approval

[donmb1]

I also receive this when uploading my build to Appstore Connect

[mariomka]

I also receive this after updating from 3.11.2 to 3.11.4.
Maybe these changes have something to do with it? 0102f9a

[donmb1]

This is still an issue

[nan-li]

Hi all, it looks like Apple may be getting more vigorous in their warnings for detecting location code.

These still appear to be warnings and not app store rejections? Please confirm if that is still the case?

Apple may have updated their logic for detecting location code so even if you are not using it it is included in the OneSignal library. In order to resolve this fully, we will need to provide an SDK version that does not include the location module.

In the meantime you might need to provide a description indicating that you will never prompt or collect this information.

Our workaround still applies from comments above if you are seeing a rejection:

Parts of the OneSignal iOS SDK allow apps to use location targeting for push notifications (geofence notifications). Apple appears to be scanning apps for any code that uses location services, even if the app doesn’t actually use it.

I would recommend putting an NSLocationWhenInUseUsageDescription string in your Info.plist even if your app doesn’t actually use it. If your app calls setLocationShared(false) our SDK will not prompt the user for location permission.

[donmb1]

@nan-li I can confirm that my app still got approved despite the warning message
however I would not give much on that because the Apple approval process is pretty random

[Aulig]

Happening to me too - can you reopen the issue please @Nightsd01

[bitjunk]

Same started happening again! Really hope we get a new SDK without the location thing given that it's been going on for years!!

[khushalkhan83]

reopen it, its still an issue

[RMatushkin]

I came across this topic while developing an application on Flutter, but this problem concerns the iOS platform specifically, so I will describe the solution here, I am sure that anyone can apply it in their iOS application:

1. You have to fork this repository to make your own version of OneSignal dependency.
2. Edit "ios/onesignal_flutter.podspec" file to have something like that:

Pod::Spec.new do |s|
  s.name             = 'onesignal_flutter'
  s.version          = '5.0.0'
  s.summary          = 'The OneSignal Flutter SDK'
  s.description      = 'Allows you to easily add OneSignal to your flutter projects, to make sending and handling push notifications easy'
  s.homepage         = 'https://www.onesignal.com'
  s.license          = { :file => '../LICENSE' }
  s.author           = { 'Brad Hesse' => 'brad@onesignal.com', 'Josh Kasten' => 'josh@onesignal.com' }
  s.source           = { :path => '.' }
  s.source_files = 'Classes/**/*'
  s.public_header_files = 'Classes/**/*.h'
  s.dependency 'Flutter'
  # s.dependency 'OneSignalXCFramework', '5.0.1'
  s.dependency 'OneSignalXCFramework/OneSignal', '5.0.1'
  s.dependency 'OneSignalXCFramework/OneSignalCore', '5.0.1'
  s.dependency 'OneSignalXCFramework/OneSignalExtension', '5.0.1'
  s.dependency 'OneSignalXCFramework/OneSignalInAppMessages', '5.0.1'
  # s.dependency 'OneSignalXCFramework/OneSignalLocation', '5.0.1'
  s.dependency 'OneSignalXCFramework/OneSignalNotifications', '5.0.1'
  s.dependency 'OneSignalXCFramework/OneSignalOSCore', '5.0.1'
  s.dependency 'OneSignalXCFramework/OneSignalOutcomes', '5.0.1'
  s.dependency 'OneSignalXCFramework/OneSignalUser', '5.0.1'
  s.ios.deployment_target = '11.0'
  s.static_framework = true
end

Please note that I commented "OneSignalXCFramework" to exclude the whole dependency and then I define all necessary submodules, and you can comment "OneSignalLocation" or don't add it indeed.

3. Use this version of the dependency in your project, add such lines in "pubspec.yaml":

onesignal_flutter:
  path: '<PATH>'

4. Update "Podfile":

target 'OneSignalNotificationServiceExtension' do
  use_frameworks!
  pod 'OneSignalXCFramework/OneSignal', '>= 5.0.0', '< 6.0'
  pod 'OneSignalXCFramework/OneSignalCore', '>= 5.0.0', '< 6.0'
  pod 'OneSignalXCFramework/OneSignalExtension', '>= 5.0.0', '< 6.0'
  pod 'OneSignalXCFramework/OneSignalInAppMessages', '>= 5.0.0', '< 6.0'
  pod 'OneSignalXCFramework/OneSignalNotifications', '>= 5.0.0', '< 6.0'
  pod 'OneSignalXCFramework/OneSignalOSCore', '>= 5.0.0', '< 6.0'
  pod 'OneSignalXCFramework/OneSignalOutcomes', '>= 5.0.0', '< 6.0'
  pod 'OneSignalXCFramework/OneSignalUser', '>= 5.0.0', '< 6.0'
end

Please note that I didn't add "OneSignalXCFramework" and defined all submodules instead.

Today I built a new version of my application and the AppStore no longer sends a notification about "NSLocationWhenInUseUsageDescription". Try it, gentlemen! 🤓

[bitjunk]

@RMatushkin Thanks for sharing! I wouldn't mind forking and doing all that work if it was free software but it's not. I do pay for it and it's cumbersome to do that patch work for all the future version upgrades.

[RMatushkin]

@RMatushkin Thanks for sharing! I wouldn't mind forking and doing all that work if it was free software but it's not. I do pay for it and it's cumbersome to do that patch work for all the future version upgrades.

You are correct; developers should offer the ability to exclude modules without requiring manual manipulation. However, since this issue has remained unresolved for many years, it might be quicker to take matters into your own hands. I can't afford to wait indefinitely and delay the release of new apps.

[ashleydee1999]

I can confirm that this is still an ongoing issue, I'll try the workaround

[khushalkhan83]

One signal sdk caused cyclic dependency in xcode build i have to remove one signal from ios