1.3.0 beta release notes include:

Your network requests are automatically traced now 🚀

This is done via swizzling (at least it looks like it). Swizzling is very invasive and can cause issues down the road, so we would like to opt-out from it. Is there an option to do it? If so, including it in the changelog would be ideal. 🙏

The issue

I'm trying to use datadog in both the app bundle and the notification extension bundle. I've tried two and encountered two different errors:
1/ using spm. I had to manually embed the Datadog library for the notification extension code to compile. That worked just fine, however, doing that triggered a bug when submitting to apple :

• ERROR ITMS-90685: "CFBundleIdentifier Collision. There is more than one bundle with the CFBundleIdentifier value 'Datadog' under the iOS application
• ERROR ITMS-90205: "Invalid Bundle. The bundle at … /Plugins/NotificationServiceExt.appex' contains disallowed nested bundles.
• ERROR ITMS-90206: "Invalid Bundle. The bundle at '…/PlugIns/NotificationServiceExt.appex' contains disallowed file 'Frameworks'."

So, i tried using Cocoapods, and wrote "pod 'DatadogSDK' " in both the app and the extension targets.
This doesn't compile, because of a "UIApplication.shared" dependency in RUMDebugging.swift :

• 'shared' is unavailable in application extensions for iOS: Use view controller based solutions where appropriate instead.
  At this point i feel kind of stuck.. Did i miss something ?

Datadog SDK version:

1.4.0

Last working Datadog SDK version:

?

Dependency Manager:

CocoaPods & SwiftPM

Other toolset:

Xcode version:

12.2

Swift version:

5.x

Deployment Target:

ios 13.0

The issue

I'm using SwiftUI to build the UI part of the app. With SwiftUI there is no storyboard, instead the interface builder is replaced with the so called 'preview', which renders live your view. However after integrating this SDK the preview fails to build because of an error:

@objc attribute used without importing module 'Foundation'

I will attach the entire log generated from xCode about the problem.

Additional info:
This does not block the project from building on a device. Only the 'preview' generated from SwiftUI
The app is written purely in swift.

Datadog SDK version:

Integrated version 1.3.0 of dd-sdk-ios in a project using the swiftUI "preview" xCode.

Last working Datadog SDK version:

I don't know, never used it before. Probably never worked as swiftUI is relatively new.

Dependency Manager:

Used swift package manager to add the library

Other toolset:

No, nothing.

Xcode version:

xCode Version 11.6 (11E708)

Swift version:

Swift v. 5.2

Deployment Target:

iOS 13.0, iPhone

macOS version:

macOS Catalina 10.15.6

The issue

When I submit my app to the App Store I get the following errors:

• App Store Connect Operation Error
  ERROR ITMS-90685: "CFBundleIdentifier Collision. There is more than one bundle with the CFBundleIdentifier value 'com.datadogqh.Datadog' under the iOS application 'XXX.app'."
• App Store Connect Operation Error
  ERROR ITMS-90205: "Invalid Bundle. The bundle at 'XXX.app/Frameworks/DatadogObjc.framework' contains disallowed nested bundles."
• App Store Connect Operation Error
  ERROR ITMS-90206: "Invalid Bundle. The bundle at 'XXX.app/Frameworks/DatadogObjc.framework' contains disallowed file 'Frameworks'."

Datadog SDK version:

1.2.2

Last working Datadog SDK version:

NA

Dependency Manager:

Carthage

Other toolset:

NA

Xcode version:

11.3.0

Swift version:

5.0

Deployment Target:

iOS 11, iPhone

macOS version:

10.14.5

Logger is such a common name that almost every project I've worked with had a class with that name.

Now because both the SDK target and the class it bundles are called Datadog you can't get rid of ambiguous for type lookup in this context error to reference the Datadog Logger type since Datadog.Logger won't work as it will think it's looking for a subtype of Datadog class and not module.

This should be corrected, either by some renaming or scope changes.

PS. The workaround is to create a file that only imports Datadog module and create a typealias there typealias DatadogLogger = Logger but given how generic Logger name is I really think this should be corrected in the SDK itself.

Describe what happened
The SDK is crashing on initialisation in FileWriter.init

Steps to reproduce the issue:
We have not been able to reproduce this in a dev environment but we are getting reports from our production app. It's currently only happening to a limited amount of users but for them it looks like it crashes on each launch.

Here is the code for initialising:

Datadog.initialize(appContext: .init(),
    configuration: Datadog.Configuration
        .builderUsing(clientToken: <client-token>)
        .build())

And here is the top of the call stack:

Crashed: com.apple.main-thread
SIGABRT ABORT 0x000000010491a418

Crashed: com.apple.main-thread
0  ???                            0x10491a418 (Missing)
1  ???                            0x104919a58 (Missing)
2  ???                            0x104919a88 (Missing)
3  ???                            0x1048dc8f8 (Missing)
4  ???                            0x1048dca14 (Missing)
5  libdyld.dylib                  0x1c0b7c848 dyld_stub_binder + 60
6  Datadog                        0x106d286b0 specialized FileWriter.init(orchestrator:queue:maxWriteSize:) + 460 (<compiler-generated>:460)
7  Datadog                        0x106d4b1f8 specialized static LogsPersistenceStrategy.defalut(using:) + 1000 (FileWriter.swift:1000)
8  Datadog                        0x106d31a98 specialized Datadog.__allocating_init(appContext:logsUploadURLProvider:dateProvider:userInfoProvider:networkConnectionInfoProvider:carrierInfoProvider:) + 64 (<compiler-generated>:64)
9  Datadog                        0x106d31fcc specialized static Datadog.initializeOrThrow(appContext:configuration:) + 716 (<compiler-generated>:716)
10 Datadog                        0x106d31478 static Datadog.initialize(appContext:configuration:) + 32 (<compiler-generated>:32)
11 Qapital                        0x1044e4c04 DataDogDestination.init(runtime:dataModel:) + 4379347972 (<compiler-generated>:4379347972)
12 Qapital                        0x1044d6310 specialized static LogController.setupDataDogDestination(runtime:dataModel:) + 4379288336 (DataDogDestination.swift:4379288336)

Expected behaviour:

Actual behaviour:

Additional context

• OS version and device model
  Does not seem to be limited to a specific device model or OS version.
• Datadog SDK version
  1.1.0
• an explanation of what might cause the bug and/or how it can be fixed

Hi there 🙂

Is it intentional that user info is being logged under usr vs. user?

P.S. we've began using the SDK in our project and can't wait to see the integration grow.

The thing

Hi there,

Is it possible to rename the Global struct to something else, like GlobalRum like in the Android library or DatadogGlobal etc. Global is apparently a common name and thus raises conflicts 😅

According to the documentation, assign DDURLSessionDelegate() as a delegate of the URLSession, for example:
let session = URLSession(
configuration: .default,
delegate: DDURLSessionDelegate(),
delegateQueue: nil
)

But in case of AFNetworking using AFHTTPSessionManager how would that translate?

I had implemented a custom datadog internal sdk for logging before this official SDK was available. I have both watchOS and iOS applications. However, I can't switch to using this SDK because it relies on certain UIKit components not in watchOS.

Could we get watchOS support?

Describe what happened

Thanks for developing an iOS first party SDK!
We've been successful integrating it and it has been super helpful.
Unfortunately I recently discovered that sub-second precision was missing from the log explorer, and that logs within a same second appear to be randomly ordered.

Steps to reproduce the issue:
Log multiple events within a second.

Expected behaviour:
Subsecond precision is reported to the log explorer.

Actual behaviour:
Subsecond precision is truncated, and it appears that the log sequence within a given second is random 🙀

Additional context

• OS version and device model: Confirmed on XS @ iOS 13.4.1
• Datadog SDK version: 1.0.2
• We are piping our logs to Datadog using SwiftyBeaver with an additional log destination. The sequence of logs is preserved in our other SwiftyBeaver destinations: console output, OSLog...

Some code in sequence:

You can see that the two logs in the 14:31:51 second are not in the right sequence.

RUM functionality is in beta, but it's only accessible using the Swift code. The Objective-C interop framework doesn't have anything relating to RUM in it.
I don't know if this is on the roadmap, but it would be great to have this added to the DatadogObjC framework, or otherwise have the Swift RUM code exposed to Objective-C.

Describe what happened

In some project and env configurations, compilation fails with Missing required module '_Datadog_Private'.

Steps to reproduce the issue:

So far we only know about CarthageCache use case reported in this comment.

This error message can be also reproduced by deleting Carthage/Checkouts/dd-sdk-ios/Datadog/DatadogPrivate folder manually from Carthage installation.

Expected behaviour:

SDK should link and compile in all environments with no error.

Additional context

• Datadog SDK version - all versions from 1.0.1

Feature request

Persist user info across sessions, set by Datadog.setUserInfo(id:name:email:)

Description

It appears that the user's info (id, name, email) is only stored in memory, and not persisted across sessions.

This is problematic when logging launch time sequence events: in my application, I am asynchronously loading user information from my Apollo SQL cache in order to speed up the time to first layout pass for a better experience.
That information is then set on Datadog for future logging, by that happens on another thread. See this sample code:

context.workspaceRepository.users
    .distinctUntilChanged(WorkspaceUserInfo.isMeEqual)
    .observeOn(ConcurrentDispatchQueueScheduler(qos: .background))
    .subscribe(onNext: { [weak self] result in
        switch result {
        case .success(let users):
            guard let me = users.me else {
                ...
                return
            }

            log.info("Setting up Datadog", .app)
            Datadog.setUserInfo(id: me.id, name: me.profile.displayName, email: me.profile.email)

        case .failure(let error):
            ...
        }
    })
    .disposed(by: bag)

The consequence is that the first milliseconds of my launch sequence logging are not attributed to any users.
This is especially confusing when filtering logs with email: [email protected] for instance, because it filters-out early launch!

☝️ In the log explorer, I am not seeing 📱 Will finishlaunching

👇 Which is present in my console output locally:

This has been problematic for me to debug my session tracking code for instance.

Possible solutions

I could persist it myself as a one-off, say in UserDefaults and set it synchronously, but I was expecting Datadog would do this for me and only clear user info when explicitly set back to nil.

Would you consider Datadog persisting this info directly?

Library such as AppCenter do this themselves for instance, see code here

Let me know if this makes sense!

Calling trackUIKitRUMViews() tracks the views and the actions except the errors, i.e. app crashes. Are the crashes supported by 1.4.0?

The issue

The latest package won't get compiled when the project target is set to macCatalyst or tvOS.

Detail

Since the CoreTelephony has not been supported for macCatalyst and tvOS. (Even the official documentation says the CoreTelephony can be used in macCatalyst 13.0+) So the compiler would generate complaints when build for mac and tv.

I know this SDK is targeted for iOS, however, after the release of macCatalyst, the same project could also be compiled to mac app. I tried to constrain the platforms to iOS only in project build settings. But the compiler is still building the Datadog module when targeting mac. Looks like this is a bug between Swift Package Manager & Xcode.

Proposed solution

Add macro in files who are using CoreTelephony

Hengyu@c51a24f

Datadog SDK version:

1.3.1

Last working Datadog SDK version:

N.A.

Dependency Manager:

Swift Package Manager

Other toolset:

N.A.

Xcode version:

Xcode 12.0 (12A7209)

Swift version:

Swift 5.1

Deployment Target:

macCatalyst 13.0+ & tvOS 11.0+

macOS version:

macOS Catalina 10.15.7 (19H2)

Add support for ApolloClient

Similar to the support for AlamoFire (as mentioned in #357) can you add support for ApolloClient.

My suspicion is that working with the NetworkTransport would be pretty similar to what was done to support AlamoFire https://www.apollographql.com/docs/ios/initialization/#advanced-client-creation

Does the SDK also save logs on the local device? If so is it possible to set limits such as only the last 7 days or only 50 MB of logs.

Hi, first off thanks to you all for creating this sdk. While it's not in our production app yet, it's working great for us in testing.

One thing I'm trying to figure out: We have a broadcast extension which has a short lifecycle. Is there a way to configure the datadog sdk to send logs immediately? Our extension can be killed at any time and I want to make sure all of our logs make it to datadog. I was poking through the code but it wasn't obvious if this was possible.

Thanks!

The problem

As I was testing out various Datadog features, I noticed that baggage items set in a span are not propagated to its descendants.

It seems that the OTSpan.baggageItem(withKey:) only returns the baggage item if it was set directly on the span, and does not query the span's parent.

This is also evident from the implementation of DDSpan and BaggageItems:

internal class DDSpan: OTSpan {
    //...
    func baggageItem(withKey key: String) -> String? {
        if warnIfFinished("baggageItem(withKey:)") {
            return nil
        }
        return ddContext.baggageItems.get(key: key)
    }
    //...
}

internal class BaggageItems {
    //...
    /// Baggage items of the parent `DDSpan` or`nil` for items of the root span.
    private let parent: BaggageItems?

    /// Unsynchronized baggage items dictionary. Use `queue` to synchronize the access.
    private var unsafeItems: [String: String] = [:]
	//...
    func get(key: String) -> String? {
        queue.sync { self.unsafeItems[key] }
    }
    //...
    /// Returns all baggage items for the span, including its parent items.
    /// This property is unsafe and should be accessed using `queue`.
    private var unsafeAll: [String: String] {
        let parentItems = parent?.unsafeAll ?? [:]
        let selfItems = unsafeItems

        let allItems = parentItems.merging(selfItems) { _, selfItem -> String in
            return selfItem
        }

        return allItems
    }
}

The only way to access the parent span's baggage items is to iterate through all of then in DDSpanContext:

internal class DDSpanContext: OTSpanContext {
    //...
    func forEachBaggageItem(callback: (String, String) -> Bool) {
        for (itemKey, itemValue) in baggageItems.all {
            if callback(itemKey, itemValue) {
                break
            }
        }
    }
    //...
}

The documentation for OTSpan.baggageItem(forKey:) does not specify whether this is expected behavior.

Suggestions

If this is expected behavior, adding a note in the OTSpan.baggageItem(forKey:) would be very useful.

If OTSpan.baggageItem(forKey:) is expected to return ancestor baggage items, then BaggaggeItems could be modified in the following way:

internal class BaggageItems {
    //...
    func get(key: String) -> String? {
        queue.sync { self.unsafeItems[key] } ?? parent?.get(key: key)
    }
    //...

With our own Logger class in Logger.swift, we can't access Datadog's Logger class with Datadog.Logger.

Already tried building a logger by doing the following:

import Datadog
import Datadog.Logger
import Datadog.Datadog
...

Datadog.Logger.builder... // still doesn't work

When Datadog RUM is configured using a custom service name which contains characters not permitted in URL query strings (such as a space), the library will crash.

I'm using version 1.4.0-beta1.

Steps to reproduce:

1. Configure Datadog for RUM and set a custom service name:

Datadog.initialize(
    appContext: .init(),
    configuration:
        Datadog.Configuration
            .builderUsing(
                rumApplicationID: "<RUM Application ID>",
                clientToken: "<Client Token>",
                environment: "sandbox"
            )
            .set(serviceName: "My App")
            .build()
)
Global.rum = RUMMonitor.initialize()

2. Run the app and Datadog should crash with the following error:

*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff2041daf2 __exceptionPreprocess + 242
	1   libobjc.A.dylib                     0x00007fff20177e78 objc_exception_throw + 48
	2   Foundation                          0x00007fff2085cb21 __57-[__NSConcreteURLComponents setPercentEncodedQueryItems:]_block_invoke + 0
	3   libswiftFoundation.dylib            0x0000000106eaf947 $s10Foundation13URLComponentsV10queryItemsSayAA12URLQueryItemVGSgvsTf4gn_nTm + 311
	4   libswiftFoundation.dylib            0x0000000106eaadb5 $s10Foundation13URLComponentsV24percentEncodedQueryItemsSayAA12URLQueryItemVGSgvs + 21
	5   Datadog                             0x0000000105b51b42 $s7Datadog17UploadURLProviderC3url10Foundation3URLVvg + 946
	6   Datadog                             0x0000000105b52d18 $s7Datadog12DataUploaderC17createRequestWith33_B0B50AAFF8A14F152AB4165520ED0E9ALL4data10Foundation10URLRequestVAG0B0V_tF + 248
	7   Datadog                             0x0000000105b52a0e $s7Datadog12DataUploaderC6upload4dataAA0B12UploadStatusO10Foundation0B0V_tF + 270
	8   Datadog                             0x0000000105b4ee66 $s7Datadog16DataUploadWorkerC012scheduleNextC004_2E3G27D1790FB5C692514696637CC9BCBLL5afterySd_tFyycfU_ + 3078
	9   Datadog                             0x0000000105b18120 $sIeg_IeyB_TR + 48
	10  libdispatch.dylib                   0x00000001073389c8 _dispatch_client_callout + 8
	11  libdispatch.dylib                   0x000000010733b316 _dispatch_continuation_pop + 557
	12  libdispatch.dylib                   0x000000010734ee8b _dispatch_source_invoke + 2205
	13  libdispatch.dylib                   0x000000010733f0ad _dispatch_lane_serial_drain + 307
	14  libdispatch.dylib                   0x000000010733ff67 _dispatch_lane_invoke + 439
	15  libdispatch.dylib                   0x000000010734bde2 _dispatch_workloop_worker_thread + 882
	16  libsystem_pthread.dylib             0x00007fff5e73d499 _pthread_wqthread + 314
	17  libsystem_pthread.dylib             0x00007fff5e73c467 start_wqthread + 15
)
libc++abi.dylib: terminating with uncaught exception of type NSException
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** +[NSURLComponents setPercentEncodedQueryItems:]: invalid characters in percentEncodedQueryItems'
terminating with uncaught exception of type NSException

cinterop fails for DatadogSDKObjc pod

Using the following in my kotlin multiplatform project (Kotlin 1.4.21):

pod(name = "DatadogSDKObjc", moduleName = "DatadogObjc", version = "~>1.5.0-alpha2")

cinterop is failing with the following:

Exception in thread "main" java.lang.Error: /.../common/build/cocoapods/synthetic/IOS/common/build/Release-iphonesimulator/DatadogSDKObjc/DatadogObjc.framework/Headers/DatadogObjc-Swift.h:965:37: error: cannot find interface declaration for 'DDURLSessionDelegate', superclass of 'DDNSURLSessionDelegate'
	at org.jetbrains.kotlin.native.interop.indexer.UtilsKt.ensureNoCompileErrors(Utils.kt:152)
	at org.jetbrains.kotlin.native.interop.indexer.IndexerKt.indexDeclarations(Indexer.kt:1003)
	at org.jetbrains.kotlin.native.interop.indexer.IndexerKt.buildNativeIndexImpl(Indexer.kt:992)
	at org.jetbrains.kotlin.native.interop.indexer.NativeIndexKt.buildNativeIndex(NativeIndex.kt:91)
	at org.jetbrains.kotlin.native.interop.gen.jvm.MainKt.processCLib(main.kt:267)
	at org.jetbrains.kotlin.native.interop.gen.jvm.MainKt.interop(main.kt:73)
	at org.jetbrains.kotlin.cli.utilities.InteropCompilerKt.invokeInterop(InteropCompiler.kt:45)
	at org.jetbrains.kotlin.cli.utilities.MainKt.mainImpl(main.kt:19)
	at org.jetbrains.kotlin.cli.utilities.MainKt.main(main.kt:41)

I realized this might be a cinterop issue but it is actually not very clear. I created a YouTrack ticket as well here in case: https://youtrack.jetbrains.com/issue/KT-44724

The issue

I imported datadog using:#import <Datadog/Datadog.h>
but Xcode still couldn't find the DataDog classes like DDDataDog or DDAppContext. It looks DatadogSDK/Datadog.h might be incomplete?

Datadog SDK version:

1.1.0

Last working Datadog SDK version:

First time using Datadog

Dependency Manager:

Cocoapods

Other toolset:

None

Xcode version:

11.3

Swift version:

NA, Objective-C project

Deployment Target:

13.2

macOS version:

10.14.5

The thing

Currently, our backend services and android use "-" character (for example "t-prod") as part of the env name but the iOS library is giving me an error saying: "Datadog SDK usage error: environment contains illegal characters (only alphanumerics and _ are allowed)".

Any reason why on iOS this is different?

Is your feature request related to a problem? Please describe:
📝 Integrate datadog with 2 different API keys, one which is used by iOS SDK and one which is used by the iOS app itself using the same SDK to trace logs. Will this cause any conflicts like other logging frameworks ?

Describe the solution you'd like:
📝 Integrate datadog with 2 different API keys, one which is used by iOS SDK and one which is used by the iOS app itself using the same SDK to trace logs.

The issue

Hey all, first thanks so much working on this, I'm excited to give it a whirl in our app. When trying to install with cocoapods, I get the following error: Using Swift static libraries with custom module maps is currently not supported. Please build DatadogSDK as a framework or remove the custom module map. Unfortunately for my team, we can't move to use_frameworks and need to keep modules. When looking at your custom Datadog module map, I see it is eerily similar to an autogenerated one with the exception of the sudo private module you have set exposing _Datadog_Private

framework module _Datadog_Private {
  export *
  header "ObjcExceptionHandler.h"
}

Any reason this can't just be exposed in DatadogObjc and let the autogenerated module map be used (other than the fact you want to discourage 3d party devs from consuming ObjcExceptionHandler.m)? Or any easy workarounds short of manually integrating into our project? Thank you for your time.

• Alex

Datadog SDK version:

DatadogSDK (1.2.1)

Last working Datadog SDK version:

First time using

Dependency Manager:

Cocoapods 1.9.1

Other toolset:

N / A

Xcode version:

Version 11.5 (11E608c)

Swift version:

Swift 5

Deployment Target:

iOS 11

macOS version:

Mac OS Catalina v 10.15.2

RUM implementation in SwiftUI

I have gone through the documentation doesn't mention anything regarding SwiftUI, natively. Is there a way to implement RUM in a native SwiftUI and not UIViewControllerRepresentable?

The issue

Compilation fails with 5 issues in a new Xcode 11.3.1 project with DataDog SDK 1.3.0:

1. Value of type 'FileHandle' has no member 'seekToEnd' in File.swift line 62
2. Extraneous argument label 'contentsOf:' in call in File.swift line 63
3. Compiler-suggested fix: Replace 'contentsOf: ' with ''
4. Value of type 'FileHandle' has no member 'readToEnd' in File.swift line 94
5. Ambiguous reference to member 'swizzle(using:)' in URLSessionSwizzler.swift line 68
6. Ambiguous reference to member 'swizzle(using:)' in URLSessionSwizzler.swift line 109

Datadog SDK version: 1.3.0

Last working Datadog SDK version: 1.2.4

Dependency Manager: Cocoapods 1.9.3

Other toolset: n/a

Xcode version: Xcode 11.3.1 (11C505)

Swift version: 5.1.3 (swiftlang-1100.0.282.1 clang-1100.0.33.15)

Deployment Target: iOS 13.2, iPhone + iPad

macOS version: macOS Catalina 10.15.5 (19F101)

I'm a huge fan of datadog and my team uses it for our backend services. I am currently in the process of implementing it on iOS so that we can have a unified logging service across all platforms. An issue though has been the lack of macOS support. We have an iOS and a macOS app which share a lot of code. Because of this I have to reside to #if os checks to make sure the shared code can compile on both iOS and macOS. It would be great if we could use this SDK to log to datadog from our macOS app as well.

I found PR #55 where macOS support was removed. It mentioned that macOS support might be added back if requested. Is this a possibility?

We use Xamarin.iOS for our app therefore, we need to use DatadogSDKObjc to generate bindings, and when we were trying to integrate now Datadog RUM we noticed that there are no objects exposed for datadog RUM. Not sure if objc C headers in this release (1.4.1) for RUM are missing or there is no plan to add them as there are for Trace and Logging

The issue

Apple introduced a new Logger class in iOS 14, and most project have some kind of Logger class as a layer of abstraction.

import Datadog

let logger: Logger // ❗ ambiguous class name

import Datadog

let logger: Datadog.Logger // ❗ the compile thinks we're talking about the class, which doesn't have a nested class named `Logger` therefore cannot find class `Datadog.Logger`

import class Datadog.Logger 

let logger: Datadog.Logger // ✅
let config: Datadog.Configuration // ❗ import statement only imports the Logger class, unknown `Datadog.Configuration` class
let context: Datadog.AppContext // ❗ import statement only imports the Logger class, unknown `Datadog.Configuration` class

This is just an annoying import dance cause solely by the fact that the module contains a class of the same name.

Datadog SDK version:

_Which version of the Datadog SDK causes this problem?
1.3.1

Last working Datadog SDK version:

_What is the last Datadog SDK version where this problem didn't occur?
n/a

Dependency Manager:

_Which dependency manager do you use?
Cocoapods

Xcode version:

Xcode 11.7 (11E801a)

Swift version:

5.2.4

The Solution

Rename the module to DatadogSDK or any other name than the Datadog class.
Or rename the Datadog class to something like DatadogClient.

Our app supports both iOS and tvOS. Is it possible to add support for tvOS?

The crash

The crash is happening at launch on this line

The crash only happens with iOS 11.1 and below. No issue with iOS 11.2 and above.

Fatal Exception: NSInternalInconsistencyException
Invalid parameter not satisfying: formatOptions == 0 || !(formatOptions & ~(NSISO8601DateFormatWithYear | NSISO8601DateFormatWithMonth | NSISO8601DateFormatWithWeekOfYear | NSISO8601DateFormatWithDay | NSISO8601DateFormatWithTime | NSISO8601DateFormatWithTimeZone | NSISO8601DateFormatWithSpaceBetweenDateAndTime | NSISO8601DateFormatWithDashSeparatorInDate | NSISO8601DateFormatWithColonSeparatorInTime | NSISO8601DateFormatWithColonSeparatorInTimeZone | NSISO8601DateFormatWithFullDate | NSISO8601DateFormatWithFullTime | NSISO8601DateFormatWithInternetDateTime))

Datadog SDK versions:

1.2.0

Last stable Datadog SDK version:

1.2.0

Volume:

Low

OS version:

iOS 11.1 and below

Deployment Target:

iOS 11, iPhone

Device version:

iPhone X, iPhone 8, iPhone 8 Plus

Environment:

No correlation

More of a question than an issue:

My team uses Datadog for all of our services, and I am looking to use it for iOS as well instead of needing to find another logging app. I realize this is still in Alpha, but is this project in a place where it is safe/ready to be used in a production app?

Thanks!

I noticed that the documentation for traces has information on offline behavior (https://docs.datadoghq.com/tracing/setup/ios/?tab=us#batch-collection). Notably that they are batched and sent at a suitable time later.

I don't see any similar notes for logs (https://docs.datadoghq.com/logs/log_collection/ios/?tab=us) and I was wondering if someone could explain the offline behavior and/or add that information to the documentation.

Thanks,
Sebastian

Describe what happened
We have a series of crashes in Firebase that point to different lines in NWPathMonitor.current.

Steps to reproduce the issue:
Have not reproduced locally, based only on crash reports.

Expected behaviour:
Does not crash.

Actual behaviour:
Crashes.

Additional context

• Affecting iOS13 and iOS12 devices (we do support iOS 11, but not seeing crashes for devices on that OS)
• Datadog SDK version 1.1.0 (cocoapods installation)
• Built with Xcode 11.4.1
• Not a huge number of crashes, but it's at ~500 crashes in the last 7 days compared to about 2.8M users in the same period.

Stack Traces

Crashed: com.datadoghq.ios-sdk-logs-upload
0  libswiftCore.dylib             0x195690314 _swift_release_dealloc + 16
1  libswiftNetwork.dylib          0x1bd5d4d88 destroy for NWPath + 44
2  libswiftNetwork.dylib          0x1bd5d4d88 destroy for NWPath + 44
3  Datadog                        0x1052e79fc NWPathMonitor.current.getter + 22 (NetworkPathMonitor.swift:22)
4  Datadog                        0x1052c2234 DataUploadConditions.canPerformUpload() + 48 (NetworkConnectionInfoProvider.swift:48)
5  Datadog                        0x1052c3f5c closure #1 in DataUploadWorker.scheduleNextUpload(after:) + 51 (DataUploadWorker.swift:51)
6  Datadog                        0x1052dae14 thunk for @escaping @callee_guaranteed () -> () + 28 (<compiler-generated>:28)
7  libdispatch.dylib              0x187c0d524 _dispatch_client_callout + 16
8  libdispatch.dylib              0x187bb5e98 _dispatch_continuation_pop$VARIANT$mp + 412
9  libdispatch.dylib              0x187bc6430 _dispatch_source_invoke$VARIANT$mp + 1276
10 libdispatch.dylib              0x187bb9770 _dispatch_lane_serial_drain$VARIANT$mp + 300
11 libdispatch.dylib              0x187bba294 _dispatch_lane_invoke$VARIANT$mp + 416
12 libdispatch.dylib              0x187bc378c _dispatch_workloop_worker_thread + 588
13 libsystem_pthread.dylib        0x187c5eb74 _pthread_wqthread + 272
14 libsystem_pthread.dylib        0x187c61740 start_wqthread + 8

Crashed: com.datadoghq.ios-sdk-logs-upload
0  libswiftCore.dylib             0x1a2a6b94c swift_unknownObjectRetain + 16
1  libswiftNetwork.dylib          0x1cb9b0044 outlined init with copy of NWPath + 1232
2  Datadog                        0x10218bbb0 NWPathMonitor.current.getter + 15 (NetworkPathMonitor.swift:15)
3  Datadog                        0x102167358 DataUploadConditions.canPerformUpload() + 48 (NetworkConnectionInfoProvider.swift:48)
4  Datadog                        0x102168c80 closure #1 in DataUploadWorker.scheduleNextUpload(after:) + 51 (DataUploadWorker.swift:51)
5  Datadog                        0x10217f358 thunk for @escaping @callee_guaranteed () -> () + 28 (<compiler-generated>:28)
6  libdispatch.dylib              0x194bac33c _dispatch_client_callout + 20
7  libdispatch.dylib              0x194baeaf8 _dispatch_continuation_pop + 408
8  libdispatch.dylib              0x194bbf624 _dispatch_source_invoke + 1224
9  libdispatch.dylib              0x194bb272c _dispatch_lane_serial_drain + 264
10 libdispatch.dylib              0x194bb3290 _dispatch_lane_invoke + 400
11 libdispatch.dylib              0x194bbc928 _dispatch_workloop_worker_thread + 584
12 libsystem_pthread.dylib        0x194c13714 _pthread_wqthread + 276
13 libsystem_pthread.dylib        0x194c199c8 start_wqthread + 8

There are 4 or 5 other identical crashes that point to different line numbers in NWPathMonitor.swift:<Line>. Lines include 22, 15, 24, and 16 (in order of crash frequency).

This is our most prominent crash currently and we'd love to have it resolved soon. Cheers.

The crash

Although this ISO8601DateFormatter crash on iOS 11.0.x - 11.1.x was fixed in #126:

Fatal Exception: NSInternalInconsistencyException
Invalid parameter not satisfying: formatOptions == 0 || !(formatOptions & ~(NSISO8601DateFormatWithYear | NSISO8601DateFormatWithMonth | NSISO8601DateFormatWithWeekOfYear | NSISO8601DateFormatWithDay | NSISO8601DateFormatWithTime | NSISO8601DateFormatWithTimeZone | NSISO8601DateFormatWithSpaceBetweenDateAndTime | NSISO8601DateFormatWithDashSeparatorInDate | NSISO8601DateFormatWithColonSeparatorInTime | NSISO8601DateFormatWithColonSeparatorInTimeZone | NSISO8601DateFormatWithFullDate | NSISO8601DateFormatWithFullTime | NSISO8601DateFormatWithInternetDateTime))

we still get reports (1, 2) on its occurrences on iOS 11.0.3 iPhone 6/6s and iOS 11.1.2 iPhone 6s.

This was originally fixed in #129 by opting-out from using .withFractionalSeconds below iOS 11.2:

let formatter = ISO8601DateFormatter()
- formatter.formatOptions.insert(.withFractionalSeconds)
+ if #available(iOS 11.2, *) {
+   formatter.formatOptions.insert(.withFractionalSeconds)
+ }

It seems to not work on iPhone 6 and 6s.

Datadog SDK versions:

1.2.2

OS version + device version:

• iOS 11.0.3 iPhone 6
• iOS 11.0.3 iPhone 6s
• iOS 11.1.2 iPhone 6s

Describe what happened
Include any error message or stack trace if available.

The FileWriter class implemented in this SDK crashes if the device is out of memory. I have attached the stacktrace and some details below.

Additional context
Device Info

# Platform: ios
# OS Version: 12.3.1 (16F203)
# Device: iPhone 6s Plus
# RAM Free: 1.4%
# Disk Free: < 1%

Stacktrace

Fatal Exception: NSFileHandleOperationException
0  CoreFoundation                 0x18773527c __exceptionPreprocess
1  libobjc.A.dylib                0x18690f9f8 objc_exception_throw
2  CoreFoundation                 0x18763f4b0 -[NSCache init]
3  Foundation                     0x18815fb24 _NSFileHandleRaiseOperationException
4  Foundation                     0x1880f0784 -[NSConcreteFileHandle writeData:]
5  Datadog                        0x102ed0e5c specialized FileWriter.synchronizedWrite<A>(value:) (FileWriter.swift)
6  Datadog                        0x102ed1720 partial apply for specialized  + 38 (FileWriter.swift:38)
7  Datadog                        0x102ec38d4 thunk for @escaping @callee_guaranteed () -> () (<compiler-generated>)
8  libdispatch.dylib              0x187174a38 _dispatch_call_block_and_release
9  libdispatch.dylib              0x1871757d4 _dispatch_client_callout
10 libdispatch.dylib              0x18711e320 _dispatch_lane_serial_drain$VARIANT$mp
11 libdispatch.dylib              0x18711ee3c _dispatch_lane_invoke$VARIANT$mp
12 libdispatch.dylib              0x1871274a8 _dispatch_workloop_worker_thread
13 libsystem_pthread.dylib        0x187355114 _pthread_wqthread
14 libsystem_pthread.dylib        0x187357cd4 start_wqthread

Is your feature request related to a problem? Please describe:
We are planning on using this SDK going forward to support logging via Datadog. However, at the moment, we won't be able to add that support via SPM. Additionally, we do not use Cocoapods as dependency manager anymore.

Describe the solution you'd like:
We would like to add Carthage support.

Describe alternatives you've considered:
SPM was considered but due to internal structure of out project, we are unable to do so at this time.

Additional context:
n/a

It appears that in all cases, this occurs shortly after launch / after Logger is created.

Crash details:

Thread 7 Crashed:
0   libswiftCore.dylib            	0x000000020b96f7ec swift_isUniquelyReferenced_nonNull_native + 0
1   Datadog                       	0x000000010969d7d0 specialized Dictionary.merging(_:uniquingKeysWith:) + 64 (<compiler-generated>:0)
2   Datadog                       	0x000000010969a024 Logger.debug(_:attributes:) + 152
3   InstaShopper                  	0x0000000103cc40c8 DatadogWriter.writeMessage(_:logLevel:) + 992

Redacted crash report included in zip file:

2020-03-11_21-34-05.9183_-0400-d9f8257d00b30d86bce2bfac00812dcd649fff30.crash.zip

Last commit in version we are currently using is 5eb1ecc

Describe what happened

Hi, I'm trying to install the latest release dd-sdk-ios 1.0.1 using Carthage 0.34.0 and Xcode 11.3.1 but this dependency fails to compile with this error:

$ /usr/bin/xcrun xcodebuild -workspace /Carthage/Checkouts/dd-sdk-ios/instrumented-tests/Integration/Integration.xcworkspace CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES -list
Build settings from command line:
    CARTHAGE = YES
    CODE_SIGN_IDENTITY =
    CODE_SIGNING_REQUIRED = NO

Resolve Package Graph

Resolved source packages:
  dd-sdk-ios: /Carthage/Checkouts/dd-sdk-ios
  HTTPServerMock: /Carthage/Checkouts/dd-sdk-ios/instrumented-tests/http-server-mock

xcodebuild: error: Could not resolve package dependencies:
  package has unsupported layout; modulemap '/Carthage/Checkouts/dd-sdk-ios/Datadog/DatadogPrivate/module.modulemap' should be inside the 'include' directory

I got this xcrun command from the failed Carthage output:

A shell task (/usr/bin/xcrun xcodebuild -workspace /Carthage/Checkouts/dd-sdk-ios/instrumented-tests/Integration/Integration.xcworkspace CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES -list) failed with exit code 74:
xcodebuild: error: Could not resolve package dependencies:
  package has unsupported layout; modulemap '/Carthage/Checkouts/dd-sdk-ios/Datadog/DatadogPrivate/module.modulemap' should be inside the 'include' directory

Any ideas?

Steps to reproduce the issue:

Looks like I can reproduce this in Xcode 11.3.1 by:

1. Clone this repo
2. Open /dd-sdk-ios/examples/iOS-app-example-spm/iOS-app-example-spm.xcodeproj
3. Cmd + B

The compilation works fine in Xcode 11.4.0, somewhat surprisingly, but 🤷‍♂ :

Expected behaviour:
📝

Actual behaviour:
📝

Additional context

• OS version and device model
• Datadog SDK version

An explanation of what might cause the bug and/or how it can be fixed:

Removing the empty /Datadog/DatadogPrivate/module.modulemap file seems to satisfy the compiler and fixes the build. Not sure what the implications of this are, though, perhaps an undesirable one is auto-generated.

Hello everyone, we're interested in using DataDog's logging for our mobile apps as we're already using other DataDog services.

We tested out the integration and it's working well. We're curious about the security measures we have to take when using the client token. The documentation mentions the following:

For security reasons, you must use a client token: you cannot use Datadog API keys to configure the dd-sdk-ios library as they would be exposed client-side in the iOS application IPA byte code.

From this I understand the client token is considered safe even if disclosed (as they will be exposed in the byte code). If we are working on an app that is open source, is it still safe to publicly commit the token in the source code?

How is the client token verified under the hood to ensure only logs coming from the production release are coming through in our logs? In other words, what prevents someone from using our client token and eventually send logs into our service?

Is the SDK validating the Bundle Identifier on a signed app? I wasn't able to find any documentation to make sure something like this would prevent bad actors from spamming our logs.

Thanks!

The thing

Any value we set Datadog.verbosityLevel to has no effect on the logs we print out to console using printLogsToConsole(true) and on the logs we send to Datadog using .sendLogsToDatadog(true)

Tell us the thing 🙂

Datadog is working well and sending logs like we want! We can even print them to the console. However, when we try to change verbosity via that variable, it does not seem to affect anything (ie all levels of logs are still being sent).

Any help would be appreciated!

The crash

Writing lots of logs causes memory usage to spike. On the first wave the memory usage reached 1.2GB. On the 2nd wave memory usage reached 1.8 GB then iOS terminated process due to memory issue. Would it be possible to process the logs in smaller sets and/or using @autoreleasepool?

With Datadog OFF:

Datadog ON:
first wave reaches 1.2GB

then releases memory

2nd wave : It reached 1.8GB of memory usage then iOS terminated process due to memory issue

Datadog SDK versions:

1.2.2

Last stable Datadog SDK version:

NA

Volume:

NA not in production

OS version:

13.3.1

Deployment Target:

iOS 11, iPhone

Device version:

iPhone XR

Environment:

Memory pressure

The thing

I'm integrating Datadog SDK for Logs in both Android and iOS and I came with an issue that for android I'm able to do
Log.E(msg, throwable) but I don't see any overload method to add neither an NSError nor Error.

Is there a way to achieve send an exception? I tried to add the attribute "error.message" or "error.stack" but those are reserved.

Describe what happened

Crashed: com.datadoghq.ios-sdk-logs-upload
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000020

We are seeing two separate but likely related crashes. Limited stack traces included below.

1
Datadog
$s7Datadog29NetworkConnectionInfoProviderC7currentAA0bcD0Vvg + 152
2
Datadog
$s7Datadog20DataUploadConditionsV010canPerformC0SbyF + 180
3
Datadog
$s7Datadog16DataUploadWorkerC012scheduleNextC004_2E3G27D1790FB5C692514696637CC9BCBLL5afterySd_tFyycfU_ + 600

and

2
Datadog
$s7Network13NWPathMonitorC7DatadogE15currentPathInfoAD09NWCurrentfG0VyF + 132
3
Datadog
$s7Datadog29NetworkConnectionInfoProviderC7currentAA0bcD0Vvg + 152
4
Datadog
$s7Datadog20DataUploadConditionsV010canPerformC0SbyF + 180
5
Datadog
$s7Datadog16DataUploadWorkerC012scheduleNextC004_2E3G27D1790FB5C692514696637CC9BCBLL5afterySd_tFyycfU_ + 600

Will try to provide more detailed stack traces if available.

Steps to reproduce the issue:
Unknown

Expected behaviour:
No crash

Actual behaviour:
Crash; numbers till limited, but not negligible

Additional context

• OS version and device model: across various models os versions
• Datadog SDK version: latest beta
• an explanation of what might cause the bug and/or how it can be fixed: unknown, but about 40-45% of crashes are in background

The thing

We have noticed that the SDK stops randomly sending logs.
We discovered the issue by comparing our analytics events with DataDog logs (tracked at the same time).
And we find out that there are no "missing" logs but the SDK really stops to send logs until the next launch (all logs "in queue" are sent).

Describe what happened
Occasional crash when initializing

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x158)
    frame #0: 0x00000001123db95d libswiftCore.dylib`swift_retain + 45
    frame #1: 0x000000011242c0ac libswiftCore.dylib`swift_bridgeObjectRetain + 60
    frame #2: 0x00000001101803f8 Datadog`specialized static Datadog.initializeOrThrow(appContext:configuration:) [inlined] Datadog.Datadog.Configuration.LogsEndpoint.url.getter : Swift.String(self=<unavailable>) at <compiler-generated>:0 [opt]
  * frame #3: 0x00000001101803e9 Datadog`specialized static Datadog.initializeOrThrow(appContext=<unavailable>, configuration=Datadog.Datadog.Configuration @ 0x00007f9be7490330) at Datadog.swift:92 [opt]
    frame #4: 0x000000011017f6e0 Datadog`static Datadog.initialize(appContext:configuration:) [inlined] static Datadog.Datadog.(initializeOrThrow in _464DF524A29BD84B41553F4E387AFB56)(appContext: Datadog.Datadog.AppContext, configuration: Datadog.Datadog.Configuration) throws -> () at <compiler-generated>:0 [opt]
    frame #5: 0x000000011017f6d8 Datadog`static Datadog.initialize(appContext=<unavailable>, configuration=<unavailable>) at Datadog.swift:55 [opt]

Steps to reproduce the issue:
Not easy to repro

Additional context

• OS version and device model: Occurring on simulator for now; change not in production yet
• Datadog SDK version: 1.1.0

There's a possibility that the issue was only present in times around DD outage, but has not been confirmed.

Is there an option to capture NSLogs emitted from frameworks I'm using? Something similar to redirecting std error to a file but to Datadog instead? https://stackoverflow.com/questions/7271528/how-to-nslog-into-a-file