Hello everyone we faced an issue with your last version 7.12.0 that contains a dependency which his name is malformatted and cause a block from Apple when we upload to iTunes Connect.
this is the error
`Asset validation failed This bundle is invalid. The bundle at path Payload/******/Frameworks/third_party-IsAppEncrypted.framework has an invalid CFBundleIdentifier 'third_party-IsAppEncrypted' There are invalid characters(characters that are not dots, hyphen and alphanumerics) that have been replaced with their code point 'third\u005fparty-IsAppEncrypted' CFBundleIdentifier must be present, must contain only alphanumerics, dots, hyphens and must not end with a dot. [see the Core Foundation Keys at https://developer.apple.com/library/content/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/TP40009249-102070-TPXREF105] (ID: 7bf7a09b-a8e9-438e-8591-442cd9f73f7e) (90049)
{
NSLocalizedDescription = "Asset validation failed";
NSLocalizedFailureReason = "This bundle is invalid. The bundle at path Payload/AppOfCards.app/Frameworks/third_party-IsAppEncrypted.framework has an invalid CFBundleIdentifier 'third_party-IsAppEncrypted' There are invalid characters(characters that are not dots, hyphen and alphanumerics) that have been replaced with their code point 'third\u005fparty-IsAppEncrypted' CFBundleIdentifier must be present, must contain only alphanumerics, dots, hyphens and must not end with a dot. [see the Core Foundation Keys at https://developer.apple.com/library/content/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/TP40009249-102070-TPXREF105] (ID: 7bf7a09b-a8e9-438e-8591-442cd9f73f7e)";
NSUnderlyingError = "Error Domain=IrisAPI Code=-19241 "Asset validation failed" UserInfo={status=409, detail=This bundle is invalid. The bundle at path Payload/AppOfCards.app/Frameworks/third_party-IsAppEncrypted.framework has an invalid
}
I resolved the issue by rollback to the 7.11.5 I think that you should update your third_party-IsAppEncrypted.framework CFBundleIdentifier to respect Apple recommendation

regards

While publishing the 7.11.0 pod, the podspec failed to validate. Further investigation showed that something about the GULNetworkTests is causing flakes. They flakes seem to emerge depending on the Xcode version. Flakes were reproducible on Xcode 14.2.

Steps to reproduce:

1. pod gen GoogleUtilities.podspec --platforms=macos
2. Navigate to GULNetworkTests.m
3. Right-click the testing icon on GULNetworkTests and run the test repeatedly (~100 times should be fine)

Below is a. list of open API availability questions for the visionOS platform.

1. See the disabled - [GULAppDelegateSwizzlerTest testApplicationDidReceiveRemoteNotificationIsInvokedOnInterceptors] test for additional context. (See discussion thread in #108)
2. ...

build Xcode 13.2

Version:             1.0.380 (77)
Code Type:           ARM-64 (Native)
Role:                Foreground
Parent Process:      launchd [1]
Coalition:           com.fourxfun.ios.cyber [12505]

Date/Time:           2021-12-17 13:49:19.1418 +0800
Launch Time:         2021-12-17 13:49:16.2291 +0800
OS Version:          iPhone OS 15.1 (19B74)
Release Type:        User
Baseband Version:    7.02.00
Report Version:      104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000010
Exception Codes: 0x0000000000000001, 0x0000000000000010
VM Region Info: 0x10 is not in any region.  Bytes before following region: 4362944496
      REGION TYPE                 START - END      [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->  
      __TEXT                   1040d4000-1040dc000 [   32K] r-x/r-x SM=COW  ...berpunkMobile
Exception Note:  EXC_CORPSE_NOTIFY
Termination Reason: SIGNAL; [11]
Terminating Process: exc handler [65269]

Terminating Process: exc handler [65269]
Triggered by Thread:  0

Thread 0 name:   Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   UnityFramework                	       0x10c4a38d4 0x10c21c000 + 2652372
1   UnityFramework                	       0x10c4a38cc 0x10c21c000 + 2652364
2   CoreFoundation                	       0x1851c0c4c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 20
3   CoreFoundation                	       0x185255554 ___CFXRegistrationPost_block_invoke + 48
4   CoreFoundation                	       0x18522ab34 _CFXRegistrationPost + 416
5   CoreFoundation                	       0x1851d5754 _CFXNotificationPost + 696
6   Foundation                    	       0x1868f0138 -[NSNotificationCenter postNotificationName:object:userInfo:] + 92
7   UnityFramework                	       0x10c230cd0 0x10c21c000 + 85200
8   UnityFramework                	       0x10c230dac 0x10c21c000 + 85420
9   UnityFramework                	       0x10dad507c 0x10c21c000 + 25923708
10  GoogleUtilities               	       0x1068ebb68 -[GULAppDelegateSwizzler application:donor_didRegisterForRemoteNotificationsWithDeviceToken:] + 264
11  UIKitCore                     	       0x18839c43c __63-[UIApplication pushRegistry:didUpdatePushCredentials:forType:]_block_invoke + 108
12  libdispatch.dylib             	       0x184ef5194 _dispatch_call_block_and_release + 24
13  libdispatch.dylib             	       0x184ef6198 _dispatch_client_callout + 16
14  libdispatch.dylib             	       0x184ed74a8 _dispatch_main_queue_callback_4CF$VARIANT$armv81 + 908
15  CoreFoundation                	       0x1851e57e8 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
16  CoreFoundation                	       0x1851a30e8 __CFRunLoopRun + 2528
17  CoreFoundation                	       0x1851b5d7c CFRunLoopRunSpecific + 572
18  GraphicsServices              	       0x19f42a9a0 GSEventRunModal + 160
19  UIKitCore                     	       0x1879e805c -[UIApplication _run] + 1080
20  UIKitCore                     	       0x18777dce0 UIApplicationMain + 2028
21  UnityFramework                	       0x10c235c34 0x10c21c000 + 105524
22  CyberpunkMobile               	       0x1040dbe00 0x1040d4000 + 32256
23  dyld                          	       0x1043b4190 start + 444

ref:
https://giters.com/Unity-Technologies/com.unity.mobile.notifications/issues/121

Hello I think that the 7.13 version has an issue with the Privacy dependency

error: module name "GoogleUtilities-Privacy" is not a valid identifier

which block the upload symbols on Apple platform. Can you please resolve this issue of naming.

regards

The line above should use TARGET_OS_IOS instead TARGET_OS_IPHONE. Using TARGET_OS_IPHONE makes this section valid in the Vision simulator. The definition of target defs are as follows in TargetConditionals.h on Xcode 15.1 beta 1 for the vision sim:

 #if (__is_target_arch(x86_64) || __is_target_arch(arm64) || __is_target_arch(arm64e)) && __is_target_vendor(apple) && __is_target_os(xros) && __is_target_environment(simulator)
        #define TARGET_OS_MAC               1
        #define TARGET_OS_OSX               0
        #define TARGET_OS_IPHONE            1

        #define TARGET_OS_IOS               0

        #define TARGET_OS_WATCH             0
        
        #define TARGET_OS_TV                0
        #define TARGET_OS_SIMULATOR         1
        #define TARGET_OS_EMBEDDED          0
        #define TARGET_OS_RTKIT             0
        #define TARGET_OS_MACCATALYST       0
        #define TARGET_OS_MACCATALYST            0

        #define TARGET_OS_VISION            1
        
        
        #ifndef TARGET_OS_UIKITFORMAC
         #define TARGET_OS_UIKITFORMAC      0
        #endif
        #define TARGET_OS_DRIVERKIT         0
        #define DYNAMIC_TARGETS_ENABLED     1
    #endif

Ensure GULNetwork.h and all other header files have nullability annotations.

GoogleUtilities/AppDelegateSwizzler (7.2.2)

When I tried to wake up the App using scheme, if the App was running in the background, I found that the method in AppDelegate was not called. Through Debug, it is found that the hook in Google Utilities did not call the original method. Please see the screenshot. I hope it can be resolved as soon as possible. This is a very serious online problem.

The minimum supported iOS version is great than 7.0 so the + [GULAppEnvironmentUtil isIOS7OrHigher] API can be removed.

The following APIs should be removed in the next major version:

• GoogleUtilities/Environment/Public/GoogleUtilities/GULHeartbeatDateStorable.h
• GoogleUtilities/Environment/Public/GoogleUtilities/GULHeartbeatDateStorage.h
• GoogleUtilities/Environment/Public/GoogleUtilities/GULHeartbeatDateStorageUserDefaults.h

Reported:

• Internally b/187440915
• Externally #8047

PR with some context about the issue. #37

From Apple's newly published document "Describing use of required reason API":

Your app or third-party SDK must declare one or more approved reasons that accurately reflect your use of each of these APIs and the data derived from their use. You may use these APIs and the data derived from their use for the declared reasons only. These declared reasons must be consistent with your app’s functionality as presented to users, and you may not use the APIs or derived data for tracking.

Will GoogleUtilities sdk be either removing the use of these APIs or providing a privacy manifest file for the iOS SDK? Or perhaps are you in contact with Apple about this issue?

Environment

• Xcode version: 12.4 (12D4e)
• Firebase SDK version: 7.9.0
• Installation method: CocoaPods
• Firebase Component: Analytics, Crashlytics, RemoteConfig

Steps to reproduce

pod update

or

pod install

Console warning:

[!] Unable to read the license file `LICENSE` for the spec `Firebase (7.9.0)`

[!] Unable to read the license file `LICENSE` for the spec `GoogleUtilities (7.3.1)`

[!] Unable to read the license file `LICENSE` for the spec `Firebase (7.9.0)`

[!] Unable to read the license file `LICENSE` for the spec `GoogleUtilities (7.3.1)`

[!] [Xcodeproj] Generated duplicate UUIDs:

...

hasSwiftRuntime always returns true starting with Xcode 13. Firebase stops using this API in firebase/firebase-ios-sdk#8215

Hey Googlers!

Any chance you'd be down to release the Blaze/Bazel (Blazel!) BUILD files for this code? Would be handy to those of us building with Bazel, and I assume you've got them internally already. I think the only external dep, PromisesObjC, already has released theirs, which should keep things pretty easy.

If useful, here's the start of one I spun up for the subspecs I needed:

# Created referencing https://github.com/google/GoogleUtilities/blob/406c461ae85acbc2da327f13619ffa187f7b729e/GoogleUtilities.podspec

objc_library(
    name = "Environment",
    hdrs = glob(["GoogleUtilities/Environment/Public/GoogleUtilities/*.h"]),
    includes = ["GoogleUtilities/Environment/Public"],
    visibility = ["//visibility:public"],

    srcs = glob(["GoogleUtilities/Environment/**/*.m", "GoogleUtilities/Environment/**/*.h"]),
    deps = ["@GooglePromises//:FBLPromises", ":IsAppEncrypted"],
    sdk_frameworks = ["Security"],
)

objc_library(
    name = "Logger",
    hdrs = glob(["GoogleUtilities/Logger/Public/GoogleUtilities/*.h"]),
    includes = ["GoogleUtilities/Logger/Public"],
    visibility = ["//visibility:public"],

    srcs = glob(["GoogleUtilities/Logger/**/*.m", "GoogleUtilities/Logger/**/*.h"]),
    deps = [":Environment"],
)

objc_library(
    name = "IsAppEncrypted",
    hdrs = ["third_party/IsAppEncrypted/Public/IsAppEncrypted.h"],
    srcs = ["third_party/IsAppEncrypted/IsAppEncrypted.m"],
)

Thanks for your consideration!
Chris
(ex-Googler)

Upgraded GoogleUtilities from 7.9.0 to 7.10.0 and I'm now seeing these warnings in Xcode:

'subscriberCellularProvider' is deprecated: first deprecated in iOS 12.0

The Promises dependency is currently broken on macOS because it hasn't yet updated from a 10.10 minimum version.

On closer look, the dependency seems heavyweight for a single public API that is used in just one place in Firebase.

In Firebase:

$ git grep gul_dataTaskPromiseWithRequest
FirebaseAppCheck/Sources/Core/APIService/FIRAppCheckAPIService.m:  return [self.URLSession gul_dataTaskPromiseWithRequest:request]
FirebaseAppCheck/Tests/Unit/Core/FIRAppCheckAPIServiceTests.m:  OCMExpect([URLSessionMock gul_dataTaskPromiseWithRequest:URLRequestValidationArg])

The module KochavaCore (used by the KochavaTracker SDK) was reported to be experiencing a crash by the clients of Kochava. These clients happened to be using the Firebase Performance SDK. Some of them had recently upgraded to a newer version of the Firebase SDK while others only installed it recently. We tracked down the problem down to the Swizzling of our KVANetTransaction class, which was being selected by the Firebase Performance SDK to be Swizzled on the basis that it conformed to protocols NSURLSessionDataDelegate and NSURLSessionTaskDelegate. The actual cause of the crash is code located within the GoogleUtilities class GULObjectSwizzler.

To preface this, this swizzling is first creating two problematic or otherwise dangerous situations within the Kochava SDK:

1. The Kochava SDK retrieves the names of its classes through NSStringFromClass(), and it embeds these names within persisted objects stored within NSUserDefaults. Later these objects may be restored using these persisted class names. While the SDK does exert some control (type checking) over the target class on restore, it is expected that these class names would be the same as they started with. Class KVANetTransaction through the swizzling process was being turned into values in the form of fir_{someUUID}_KVANetTransaction. Since this UUID is not consistent across launch, and since that new class will not exist on a subsequent launch, it creates the possibility that persistently stored objects will be irrecoverable. Although we code for this possibility, this is unexpected and could also lead to another future crash.

2. The Kochava SDK uses the names of classes through NSStringFromClass() to display log messages. It uses the format: {Org} {Class Name} {Headline} on the main line. In this process it looks for prefixes such as Kochava or KVA and removes them prior to printing. When functioning properly this results in log messages such as:

Kochava NetTransaction - InstallNetTransaction - Request

However, with the Firebase Performance SDK running, the KVANetTransaction class is swizzled and its class is replaced. The new resulting class is fir_{someUUID}_KVANetTransaction. This results in unexpected log messages such as:

Kochava fir_UUID_KVANetTransaction - InstallNetTransaction - Request

While this behavior is not serious, it is improper for the functioning of the Kochava SDK. When our clients look for specific log messages they cannot be located as expected. Kochava also has automated systems which scan logs for certain log messages and these also would not function properly.

Most importantly, however, the swizzling is leading to a fairly reproducible crash. We tracked the crash down to the following file:

https://github.com/google/GoogleUtilities/blob/main/GoogleUtilities/ISASwizzler/GULObjectSwizzler.m

And to these lines of code in the dealloc method:

if (_swizzledObject == nil) {
      // The swizzled object has been deallocated already, so the generated class can be disposed
      // now.
      objc_disposeClassPair(_generatedClass);
      return;
}

Following the execution of this code on our KVANetTransaction class, specifically it does go into this if condition and calls objc_disposeClassPair(), and an unstable state is effected which ultimately leads to a crash with the associated label .cxx_destruct. The crash occurs shortly there after within the Kochava SDK, and usually on the deallocation of an instance of class KVALogMessage. A log message is probably involved here because when a trace log level is active there is a log message generated when instances of class KVANetTransaction are completing and will deallocate. We've also seen a crash on an object not our own, perhaps within the Firebase SDK, and will attach that screen shot as well.

From this we believe that the line if (_swizzledObject == nil) { may be occurring at an unsafe time. We're uncertain of the exact nature of the crash at the time of this writing. We've speculated this could be a problem related to the weak reference which you take on _swizzledObject and when that weak reference becomes nil during the dealloc process. Ref here:

__weak id _swizzledObject;

We have identified a workaround for the problem. We have modified module KochavaCore class KVANetTransaction beginning in version 4.5.0 to no longer conform to protocols NSURLSessionDataDelegate and NSURLSessionTaskDelegate, and we are instead using functions to create a data task which take a completion handler as a parameter. Having made this change in development, we can observe that the Firebase Performance SDK no longer swizzles class KVANetTransaction and the problem goes away.

Nevertheless, we want to express some concerns about the existing architecture within class GULObjectSwizzler.

First, we have clients which are using older versions of our SDK, and some will continue to use these versions for years into the future. If they install the Firebase Performance SDK, or perhaps some other SDK which uses GULObjectSwizzler on objects within our SDK, these mutual clients are likely to experience crashes.

Second, we have seen errors similar to these a couple years ago. They were deallocation errors on class KVALogMessage. At that time we thought we had tracked the problem down to the inclusion of the Firebase SDK, and we appeared to have compensated for the problem by prefixing our category extension methods on Apple foundation classes with the prefix kva_. We believed at that time that something within the Firebase SDK was colliding with our SDK, and we assumed that perhaps we had a common name collision on a category extension method on an Apple foundation class. This determination was made in collaboration between Kochava and Apple, and the prefixing of our category extension methods appeared to fix that problem at that time. We're now wondering, however, if the source of the problem actually had something to do with swizzling in some Firebase SDK, and that the method names might have been involved in the selection of what was being swizzled. We are speculating this based on how the Firebase Performance selects objects to swizzle based on protocol conformance (or the existence of methods named within protocols).

If the Firebase SDK goes on to swizzle Kochava classes in the future, these classes should be expected to function unexpectedly, as they rely on their class names for certain purposes such as 1) persistent storage identification. 2) the identification of the source of activity within log messages. 3) the identification of objects being sent to third party systems, wrappers, and the host. These objects are identified in JSON by their class names.

While we recognize that the performance monitoring feature of your SDK may require the use of swizzling, perhaps this could be engineered to be safer. And if not, there could be some way that developers could identify classes which are unsafe to swizzle. None of this however should detract from the central focus of this issue, which is that something is currently unsafe about the use of objc_disposeClassPair(_generatedClass); as demonstrated with the use of class KVANetTransaction, and this sometimes leads to a crash.

We will attach some screen shots for your reference. We will also provide a sample project which crashes most of the time for us. You should just need to pod update and add your own GoogleService-info.plist. Then you can run it in the simulator.

Thank you in advance for your assistance.

2021-03-22 14:39:04.626572-0700 PerformanceExample[97420:1216555] debug
Kochava fir_E3135118-8898-42C6-9A37-848F4747030C_KVANetTransaction - InstallNetTransaction - Request (7FC322F9-65E1172C-B136-412D-A0E1-416521B8E2CD)
{

Screen shot of later crash:

Screen shot of later crash not in Kochava, presumed to possibly be a Firebase class:

Sample App:
performance.zip