flurry / flurryswiftpackage Goto Github PK

Hello there, I've just noticed that something's different in Xcode 13.3 when uploading an .ipa that uses Flurry as a dependency.

In my case, I'm using it with Swift Package Manager, I'm on the latest version (12.4.0 as of today).
Important things:

• Xcode 13.2 works fine
• Xcode 13.3 does NOT work fine

These are the related errors I get when uploading the app to AppStore Connect:

$ xcrun "altool" "--upload-app" "-f" "/Users/vagrant/deploy/[REDACTED].ipa" "--type" "ios" "--username" "[REDACTED]" "--password" "[REDACTED]"
*** Error: ERROR: [ContentDelivery.Uploader] Asset validation failed (90208) Invalid Bundle. The bundle [REDACTED].app/Frameworks/CrashReporter.framework does not support the minimum OS Version specified in the Info.plist. (ID: 3751efe2-5b41-4772-b253-a6a7ab9454da)
*** Error: ERROR: [ContentDelivery.Uploader] Asset validation failed (90208) Invalid Bundle. The bundle [REDACTED].app/Frameworks/Flurry_iOS_SDK.framework does not support the minimum OS Version specified in the Info.plist. (ID: 91c0d8aa-1028-4002-b5b3-5a788ee8b80d)

It looks that Flurry's not setting the minimum OS version in the Info.plist file correctly.

Is there any chance to correct this so we can use the latest Xcode version?
Thank you!

Sento.

swift-tools-version from Package.swift has been upgraded from 5.3 to 5.6 with this commit.
Swift 5.6 is available from Xcode 13.3 so after that update the SDK cannot be used with Xcode versions below 13.3 - I get the following error on Xcode 13.2.1:

We can fix that by downgrading swift-tools-version. This PR fixes the issue: #14
With this update the SDK can be used in both Xcode 13.2.1 and Xcode > 13.3

Hi,
I am using SPM for Flurry for just analytics, and don't want to include the crash reporting functionality, since I already have that through a different package (AppCenter). That package has a dependency on PLCrashReporter, which has an internal framework called "CrashReporter". And Flurry also seems to produce a package called "CrashReporter", which also seems to depend upon "CrashReporter" framework. The problem is that the name seems to clash, and I'm getting an error in Xcode when I try to add Flurry:

multiple targets named 'CrashReporter' in: 'flurryswiftpackage', 'plcrashreporter'

Is there a way to fix this? I wish I could just exclude the Crash Reporting dependency in the Flurry library.

Flurry cannot be linked into Xcode 13.3 through the Swift Package. It always returns this error:

I have tried removing flurry from the project and readding it, as well as removing the package and linking it in locally. I have also reset package caches, cleaned the project, and removed all derived data, but this error always happens when I try to use Flurry.

When I try to 'Add Package Dependency' with Xcode 14.2 in a MacBookPro M1Pro, entering GitHub with my authentication token the system replies:
The remote repository could not be accessed.
Make sure a valid repository exists at the specified location and that the correct credentials have been supplied.
Address: https://github.com/flurrydev/FlurrySwiftPackage/

Any hints ?

Apple required App Privacy manifests until 2025. So Flurry SDK that contains an app privacy manifest must be signed.
I would like to know when you adopt this change.

References
https://developer.apple.com/videos/play/wwdc2023/10060/
https://developer.apple.com/news/?id=av1nevon
https://developer.apple.com/app-store/user-privacy-and-data-use/

Please check it out. Thanks!

When using both the FlurryAnalyticsSPM and FlurryMessagingSPM packages we always get the following error:
error: “Flurry.h” couldn’t be copied to “include” because an item with the same name already exists. (in target 'FlurryMessagingSPM' from project 'Flurry')
The error ONLY happens the first time trying to build from a clean project. Building twice or more will succeed.

Are we doing something wrong or is there an actual issue?

Steps to reproduce:

• Add the repository to swift packages in the project.
• Select the FlurryAnalyticsSPM and FlurryMessagingSPM
• Add #import "Flurry.h" to the bridging header.
• Build the project.

Technical setup:
XCode: Version 12.4 (12D4e)
MacOS: 11.2.3 (20D91)
Reproduced on both Intel and M1.

Additional info:

• Selecting only FlurryAnalyticsSPM works fine. It is only the combination of two packages that triggers the problem (i.e. FlurryAnalyticsSPM combined with FlurryConfigSPM also triggers it).

This package appears to be fairly stable (no changes since Dec 2021) but is still described as beta, which is slowing adoption within my organisation (and presumably others).

Is it still considered to be beta software? And is it just the SPM packaging that is considered beta, or the actual SDKs within?

Hi,

Very similar to my old issue from earlier in the year: #11

It looks like arm64 is missing for the watchOS device binary in Flurry.xcframework. This causes Xcode to skip linking when building for Watch, and build fails with symbols not defined. Caused by: https://developer.apple.com/documentation/Xcode-Release-Notes/xcode-14-release-notes#:~:text=Xcode%20builds%20for%20watchOS%20devices%20now%20include%20the%20arm64%20architecture%20by%20default.%20(83319300)

I'm using the 12.0.1-lite release and building an iPhone app with Watch extension on Xcode 14.

The workaround is to remove arm64 from architectures on your watch target/s. But it's unclear if this will affect series 8 watches.

Thanks

Hi,

It looks like arm64 is missing for the watchOS simulator binary in Flurry.xcframework. This causes Xcode to skip linking when building for Watch simulator, and build fails with symbols not defined.

I'm using the 12.0.0 release and building an iPhone app with Watch extension on Xcode 13.3.

The workaround for now is to wrap calls to FlurryWatch in #if !targetEnvironment(simulator). But it would be great not to need to do this, and to be able to test our Flurry tracking in simulator.

Thanks

Edit: This PR originally added arm64 support to the xcframeworks: #6

Hello,
I’ve just updated an iOS app with the Flurry Swift package for iOS and it works fine.
The issue comes when I compile for Mac Catalyst: it shows the following two error messages:

"/Users/#username#/Library/Developer/Xcode/DerivedData/#nameOfBundle#-apiatgkmqztjuzeqnljjtkrytyhr/SourcePackages/checkouts/FlurrySwiftPackage/artifacts/FlurryConfig.xcframework
/Users/#username#/Library/Developer/Xcode/DerivedData/#nameOfBundle#-apiatgkmqztjuzeqnljjtkrytyhr/SourcePackages/checkouts/FlurrySwiftPackage/artifacts/FlurryConfig.xcframework:1:1 While building for Mac Catalyst, no library for this platform was found in '/Users/#username#/Library/Developer/Xcode/DerivedData/#nameOfBundle#-apiatgkmqztjuzeqnljjtkrytyhr/SourcePackages/checkouts/FlurrySwiftPackage/artifacts/FlurryConfig.xcframework'.

/Users/#username#/Library/Developer/Xcode/DerivedData/#nameOfBundle#-apiatgkmqztjuzeqnljjtkrytyhr/SourcePackages/checkouts/FlurrySwiftPackage/artifacts/FlurryMessaging.xcframework
/Users/#username#/Library/Developer/Xcode/DerivedData/#nameOfBundle#-apiatgkmqztjuzeqnljjtkrytyhr/SourcePackages/checkouts/FlurrySwiftPackage/artifacts/FlurryMessaging.xcframework:1:1 While building for Mac Catalyst, no library for this platform was found in '/Users/#username#/Library/Developer/Xcode/DerivedData/#nameOfBundle#-apiatgkmqztjuzeqnljjtkrytyhr/SourcePackages/checkouts/FlurrySwiftPackage/artifacts/FlurryMessaging.xcframework'.
"
BTW: in Mac Catalyst only I’m no longer interested in Flurry tracking. Just for iOS I use Flurry, and my code is always:
#if !targetEnvironment(macCatalyst)
… do stuff Flurry-related
#endif

The weird thing is that the compiler seems not looking for the Flurry.xcframework but just for the FlurryConfig.xcframework and FlurryMessaging.xcframework.
All three are present in the Build Phases tab in section 'Link Binary with Libraries’ and ALL three are marked ‘optional’, and for iOS only.

My hw/św pattern is:

MacBook Pro M1Pro 2021
macOS Ventura 13.1
Xcode 14.2

Any clue ?
How can I manage that ?

Thank you for any hint on this.

Hey there,

May I ask you if you can release the Lite version (without the CrashReporter) for the latest versions, please? As far as I can see that the latest version is 12.0.1 and available via the br_12.0.1-lite branch.

Thanks in advance,

Peter

As you know, the M1 SoC is based on arm64, so its iOS Simulator is also arm64. However, the included simulator build is for i386 and x86_64.

When I try to build for iOS Simulator on my M1 Mac using the included arm64 binary, I get this error:

Building for iOS Simulator, but the linked library 'libFlurry.a' was built for iOS.

When I try the x86_64 binary instead, I get this error:

The linked library 'libFlurry.a' is missing one or more architectures required by this target: arm64.

It took me a while to figure out why I couldn't update past 11.2.0, and it's because the URL in the readme is out of date.

When I enabled
.build(logLevel: FlurryLogLevel.all)

Now I see base64 encoded text logs of events names and params, what's the point?
Xcode logs should not be encoded, so I can read debug information right from the log.

Hi, I am trying to integrate the Flurry SDK and it crashes several seconds after my app starts. I was able to reproduce the crash with a basic test project with Flurry as the only dependency. It appears there is an address sanitization issue that Xcode catches. One can work around this issue by turning off Runtime Sanitization but I have needed to use that to debug a few issues in some C code bundled with our app. In the interim I will probably just comment out the Flurry init code if I need to debug something with address sanitization turned on. If there's any other info you need, let me know. Below are the steps to reproduce.

Versions
Flurry 12.1.3
Swift 5
Targeting iOS 16.0
Running on real device running 16.1.1
MacOS 12.6
Xcode 14.0.1

• Create a new SwiftUI project
• Add the Flurry dependency per the README instructions (using the Swift package)
• Edit the scheme used to run it, and enable Runtime Sanitization and the Detect use of stack after return option within the Diagnostics tab for that scheme
• Insert the following in the main App file and run it:

import SwiftUI
import UIKit
import Flurry_Config
import Flurry_iOS_SDK

class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool {
        let sb = FlurrySessionBuilder()
                  .build(logLevel: FlurryLogLevel.all)
                  .build(crashReportingEnabled: true)
                  .build(appVersion: Bundle.main.appVersion)
              
        Flurry.startSession(apiKey: "API_KEY_GOES_HERE", sessionBuilder: sb)
        
        return true
    }
}

@main
struct flurrytestApp: App {
    
    // inject ApplicationDelegate into the SwiftUI lifecycle
    @UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate

    var body: some Scene {
        WindowGroup {
            VStack {
                Text("Hello, world!")
            }
            .padding()
        }
    }
}

Crash output is:

[3A1F73BF-5C70-4AF7-BE8E-5CC46922BAE6]
2022-11-22 07:16:24.113528-0600 flurrytest[68232:4139969] -[FlurryStreamCoreBuffer streamMessage:]: msg = <FlurryStreamPreviousReport: 0x10b0007a0, type = 166, json = {   "fl.frame.version" : 1,   "fl.report.previous.success" : true }>
2022-11-22 07:16:24.117458-0600 flurrytest[68232:4139977] FlurryDataSender: Not sent blocks count [0]
2022-11-22 07:16:24.117665-0600 flurrytest[68232:4139977] -[FlurryBackgroundTaskTracker stopBackgroundTasksTracking]: stop background task
2022-11-22 07:16:24.133335-0600 flurrytest[68232:4139977] [tcp] tcp_input [C2.1.1.1:3] flags=[R] seq=1245760913, ack=0, win=0 state=CLOSED rcv_nxt=1245760913, snd_una=3560979046
==68232==ERROR: AddressSanitizer failed to deallocate 0x10000 (65536) bytes at address 0x000105914800
AddressSanitizer: CHECK failed: sanitizer_posix.cpp:61 "(("unable to unmap" && 0)) != (0)" (0x0, 0x0) (tid=4139970)
    <empty stack>

warning: hit breakpoint while running function, skipping commands and conditions to prevent recursion
AddressSanitizer report breakpoint hit. Use 'thread info -s' to get extended information about the report.