Describe the bug A clear and concise description of what the bug is.

Coming across a very weird debug message lately since the last update. The message appears around 20 secs post starting the app. The message says:

[Segment ERROR - finish(file:):320] Unable to rename to temp: file:///Users/chetanmalhotra/Library/Developer/CoreSimulator/Devices/094C9BEE-0AB5-4345-AB1D-2CA907B66033/data/Containers/Data/Application/1688B1EE-1CCC-44B7-AA72-FB7A9A272B3E/Documents/segment/XVFH4DGT0ufXKfxlMQzNMQDosdD9eKLW/7-segment-events, Error: Error Domain=NSCocoaErrorDomain Code=4 "“7-segment-events” couldn’t be moved to “XVFH4DGT0ufXKfxlMQzNMQDosdD9eKLW” because either the former doesn’t exist, or the folder containing the latter doesn’t exist." UserInfo={NSSourceFilePathErrorKey=/Users/chetanmalhotra/Library/Developer/CoreSimulator/Devices/094C9BEE-0AB5-4345-AB1D-2CA907B66033/data/Containers/Data/Application/1688B1EE-1CCC-44B7-AA72-FB7A9A272B3E/Documents/segment/XVFH4DGT0ufXKfxlMQzNMQDosdD9eKLW/7-segment-events, NSUserStringVariant=( Move ), NSDestinationFilePath=/Users/chetanmalhotra/Library/Developer/CoreSimulator/Devices/094C9BEE-0AB5-4345-AB1D-2CA907B66033/data/Containers/Data/Application/1688B1EE-1CCC-44B7-AA72-FB7A9A272B3E/Documents/segment/XVFH4DGT0ufXKfxlMQzNMQDosdD9eKLW/7-segment-events.temp, NSFilePath=/Users/chetanmalhotra/Library/Developer/CoreSimulator/Devices/094C9BEE-0AB5-4345-AB1D-2CA907B66033/data/Containers/Data/Application/1688B1EE-1CCC-44B7-AA72-FB7A9A272B3E/Documents/segment/XVFH4DGT0ufXKfxlMQzNMQDosdD9eKLW/7-segment-events, NSUnderlyingError=0x600001e34e40 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}}

To Reproduce Steps to reproduce the behavior:

1. Just run any project that uses identify() and track()
2. Wait for ~20 secs
3. See error

Expected behavior There should be no warnings/werrors

Screenshots If applicable, add screenshots to help explain your problem.

Platform (please complete the following information):

• Library Version in use: 1.3.1
• Platform being tested: Ios 15
• Integrations in use: Firebase and Amplitude

Additional context Kinda urgent. Pls help saviours

Describe the bug Setting the apiHost in the configuration has no effect, events are still sent to api.segment.io/v1 regardless of the configuration values for apiHost.

let configuration = Configuration(writeKey: writeKey)
   .trackApplicationLifecycleEvents(true)
   .apiHost("analytics-ingestion.kraftful.com")
   .flushInterval(10)

Analytics.debugLogsEnabled = true
analytics = Analytics(configuration: configuration)

Steps for repro:

I have created an example app with repro in a fork: https://github.com/kraftful/analytics-swift/tree/jgable/api-host-repro (specific commit is ce5331dfd60ca82870c27a1a38268d8e9d6c4577)

• Clone the above branch/commit
• Load the ExampleApp project in XCode (in the Examples/APIHostConfigurationRepro folder)
• Put breakpoints in the HTTPClient file in Segment package where the batch uploads happen
• Run the app on simulator (I have tried iPhone 12 Pro)
• Login using creds: [email protected], test1234
• Observe the value of uploadURL in the debugger when the batch is uploaded

Expected:

• Should be analytics-ingestion.kraftful.com since that is passed in the configuration in the SegmentAnalytlics.swift file

Actual:

• api.segment.io/v1 is used instead.

Expected behavior

Event batches should be sent to the configured apiHost.

Screenshots

Platform (please complete the following information):

• Library Version in use: latest
• Platform being tested: iOS (latest)
• Integrations in use: none

Describe the bug After migrating from analytics-ios v1.1.2 to v1.2.0, the integrations field did not contain any information. When this happens events are shown in the live debugger for a source but do not reach the source destinations.

To Reproduce

1. Add an integration like AppsFlyer to the segment client.
2. On v1.1.2 trigger a track event and notice how the integrations object has a list of integrations.
3. Update the SDK to v.1.2.0
4. Trigger the same event. <--- Issue here
5. The integrations object is empty

Event v1.1.2

{
  "context": {
    "library": {
      "name": "analytics-swift",
      "version": "1.1.2"
    },
    "locale": "en-US",
    "network": {
      "bluetooth": false,
      "cellular": true,
      "wifi": false
    }
  },
  "event": "Application Foregrounded",
  "integrations": {
    "AppsFlyer": false,
    "Segment.io": false
  },
  "receivedAt": "2022-04-11T23:21:53.134Z",
  "sentAt": "2022-04-11T23:21:52.706Z",
  "timestamp": "2022-04-11T23:21:44.226Z",
  "type": "track",
}

Event v1.2.0

{
  "context": {
		"library": {
      "name": "analytics-swift",
      "version": "1.2.0"
    },
    "locale": "en-US",
    "network": {
      "bluetooth": false,
      "cellular": true,
      "wifi": false
    }
	},
  "event": "Application Foregrounded",
  "integrations": {},
  "receivedAt": "2022-04-11T23:20:33.204Z",
  "sentAt": "2022-04-11T23:20:32.773Z",
  "timestamp": "2022-04-11T23:20:32.281Z",
  "type": "track",
}

Expected behavior The integrations object should remain the same after upgrading from v1.1.X to v1.2.X

Platform (please complete the following information):

• Library Version in use: v.1.2.0
• Platform being tested: iOS
• Integrations in use: AppsFlyer

Additional context This regression issue was introduced on v1.2.0.

Describe the bug As mentioned on our call, here's the warning that I'm regularly getting from the system.

[BackgroundTask] Background task still not ended after expiration handlers were called: <_UIBackgroundTaskInfo: 0x2835fdd40>: taskID = 4, taskName = Called by <AppName>, from $s7Segment0A11DestinationC14UploadTaskInfoV3url4taskAE10Foundation3URLV_So016NSURLSessionDataD0CtcfC, creationTime = 1095354 (elapsed = 27). This app will likely be terminated by the system. Call UIApplication.endBackgroundTask(_:) to avoid this.

I assume this means the app will have to launch cold each time this occurs.

To Reproduce It seems to happen intermittently.

I believe it usually occurs if I run a build on device, and that put aside the phone with the debugger still running. That message appeared almost 12 mins after the app was launched via a build and run in Xcode.

As mentioned, my current network is a little flakey so it could be related to a low/no network situation, too.

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Platform (please complete the following information):

• Library Version in use: [e.g. 0.0.5]
• Platform being tested: [e.g. iOS]
• Integrations in use: [e.g. Firebase, Amplitude]

Additional context Add any other context about the problem here.

Is your feature request related to a problem? Please describe. Currently, on iOS, the only way to run an upload as a well behaved background task seems to be to opt-in to lifecycle events. That's because the current implementation seems to rely on an internal UploadTaskInfo in the SegmentDestination which is only accessible to internal clients.

AFAICT this means there is no simple way to create your own background task to upload any outstanding events.

This would be especially useful in low/no network situations. Currently, even if opted-in to iOS lifecycle events, the background task that is created will fail if the network is unavailable.

Describe the solution you'd like An ideal solution would be one with flexibility and adherence to platform recommendations.

For example, on iOS it is possible to opt-in to 'background modes' one of which is called 'background processing'. This mode allows a developer to use he system's Background Task Scheduler to do additional processing at some point when the battery and network conditions are favourable. The system scheduler enforces adherence to platform recommendations (i.e cancelling when asked, and letting the system know when it's complete) by docking an app's time on the scheduler for non-compliance.

With that in mind, I suggest a task API similar to the one for URLSession but with an additional callback for completion with some kind of TaskState to inform of success, cancellation or failure:

struct SegmentUploadTask {
    func start(_ completion: @escaping (TaskState) -> Void)
    func cancel()
}

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

Describe the bug The included AppsFlyer example currently results in the plugin reaching an indeterminate state.

I'm not sure whether this is because the example needs to be re-architected, or because the plugin architecture is not behaving as it was designed.

My expectation is that the set-up for AppsFlyer should always be done prior to AppsFlyerLib.shared().start() being called.

However, with the current example this isn't guaranteed.

From my observations on an iPhone X and iPhone 7 Plus, I can see that update(settings:) is often called twice. This is the method that contains the AppsFlyer set-up code.

The first time it is called is prior to the plugin's applicationDidBecomeActive(application:) method being called. This would be what I expect, but at this point Segment doesn't appear to have loaded the AppsFlyer specific settings and so the majority of this method's execution, and therefore the AppsFlyer set-up, is skipped.

Shortly after, applicationDidBecomeActive(application:) is then called. This invokes AppsFlyerLib.shared().start(), but as the settings were missing previously, AppsFlyer is started without necessary setup having taken place.

So when update(settings:) is called a second time, this time with the associated AppsFlyer settings, the plug-in doesn't behave as expected. For example, the AppsFlyerLibDelegate method onConversionDataSuccess(_:) may not get called at all.

Is your feature request related to a problem? Please describe. We're trying to migrate away from CocoaPods towards Swift Package Manager for our dependency management and the lack of SPM support of FacebookAppEvents is blocking us from completing that goal.

Describe the solution you'd like We'd like to migrate all of our dependency management to Swift Package Manager, including Segment FacebookAppEvents

Describe alternatives you've considered Our only option is to continue using CocoaPods for all our Segment, Facebook, and GoogleAnalytics/Firebase needs because Segment FacebookAppEvents pulls all the others in via CocoaPods and trying to import them both via CocoaPods and SPM creates build issues.

Describe the bug The following compile-time errors occur in Segment 1.0.4 when archiving a Release configuration app:

…/SourcePackages/checkouts/analytics-swift/Sources/Segment/Utilities/JSON.swift:305:19: error: thrown expression type 'String' does not conform to 'Error'
            throw "This JSON object is not an array type."
                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
…/SourcePackages/checkouts/analytics-swift/Sources/Segment/Utilities/JSON.swift:328:19: error: thrown expression type 'String' does not conform to 'Error'
            throw "This JSON object is not an array type."
                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
…/SourcePackages/checkouts/analytics-swift/Sources/Segment/Utilities/JSON.swift:350:19: error: thrown expression type 'String' does not conform to 'Error'
            throw "This JSON object is not an array type."
                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I'm not sure why it works in Debug configuration builds, but it seems odd to be throwing a String. I tried searching but couldn't find an Error conformance for String in the package.

Describe the bug When you add analytics-swift to an Xcode project, the default is to have it fetch "up to next major from ". Unfortunately, tag 1.0.0's Package.swift contains a reference to Sovran [email protected]:segmentio/Sovran-Swift.git, which Xcode fails to pull, getting

x-swift-package-repository-authentication://?scm=com.apple.dt.Xcode.sourcecontrol.Git&[email protected]:segmentio/Sovran-Swift.git#error=-1005 Authentication failed because the credentials were missing

Your main branch has an updated Package.swift. You should probably make a new tag in git with that change.

To Reproduce Steps to reproduce the behavior:

1. Add analytics-swift using default Xcode version selection
2. Be sad

Recently we've noticed crashes coming from the new OutputFileStream code. An example stack trace is included at the end of this issue.

While digging into this, we noticed the switch from the foundation FileHandle API to the older POSIX API. The rationale presumably is the deprecation of the write(data: Data) function. This left us perplexed and we believe this to be a misunderstanding. The specific write(data: Data) function was deprecated, yes, but it was replaced with the generic write<T>(contentsOf: T) throws where T : DataProtocol function. As well as being more flexible in its input parameter, the new function also properly communicates errors via throws (related: unhandled exceptions at the write(data: Data) call site was previously an issue we saw coming from your code). It is a welcome replacement (:

If I may, it seems the best course of action would be to remove the OutputFileStream addition, specifically, and simply update the code as it was previously so that it uses the non-deprecated write function from FileHandle. And, the new API forces you to handle the errors I mentioned we had also been encountering, 2 birds...

But, if you must stick with the POSIX API, which, while fun to use at times, I would strongly discourage, then the implementation needs some work. There are numerous issues (lack of handling for short writes, unnecessary string conversions, generally thread safety, dubious pointer handling, etc.) which I'm happy to help you through if you decide to stick with this route. But, it's super tricky to get all this right when using the POSIX API hence why the first class Apple-supported Foundation APIs are preferred over the POSIX ones.

Hardware Model:     iPhone14,3
Process:            Uno
Identifier:         app.Uno
Version:            1.0
Role:               Background
OS Version:         iOS 16.0
Exception Type:     EXC_BAD_ACCESS 
Exception Subtype:  KERN_INVALID_ADDRESS


EXC_BAD_ACCESS: Attempted to dereference garbage pointer 0x68.

0  libsystem_c.dylib _flockfile
1  libsystem_c.dylib _fwrite
2  Uno               closure #1 in OutputFileStream.write(_:) (OutputFileStream.swift:69:17)
3  Uno               specialized String.UTF8View.withContiguousStorageIfAvailable<A>(_:) (<compiler-generated>)
4  Uno               OutputFileStream.write(_:) (OutputFileStream.swift:67:29)
5  Uno               closure #1 in Storage.write<A>(_:value:) (Storage.swift:42:26)
6  Uno               thunk for @callee_guaranteed () -> () (<compiler-generated>)
7  Uno               thunk for @escaping @callee_guaranteed () -> () (<compiler-generated>)
8  libdispatch.dylib __dispatch_client_callout
9  libdispatch.dylib __dispatch_lane_barrier_sync_invoke_and_complete
10 Uno               Storage.write<A>(_:value:) (Storage.swift:37:19)
11 Uno               SegmentDestination.queueEvent<A>(event:) (SegmentDestination.swift:126:17)
12 Uno               SegmentDestination.execute<A>(event:) (SegmentDestination.swift:106:13)
13 Uno               specialized closure #1 in Mediator.execute<A>(event:) (Timeline.swift:78:32)
14 Uno               specialized Timeline.process<A>(incomingEvent:) (Timeline.swift:37:13)
15 Uno               closure #1 in StartupQueue.replayEvents() (StartupQueue.swift:60:28)
16 Uno               thunk for @callee_guaranteed () -> () (<compiler-generated>)
17 Uno               thunk for @escaping @callee_guaranteed () -> () (<compiler-generated>)
18 libdispatch.dylib __dispatch_client_callout
19 libdispatch.dylib __dispatch_lane_barrier_sync_invoke_and_complete
20 Uno               StartupQueue.replayEvents() (StartupQueue.swift:58:19)
21 Uno               closure #1 in StartupQueue.analytics.didset (StartupQueue.swift:21:23)
22 Uno               thunk for @escaping @callee_guaranteed (@in_guaranteed A) -> () (<compiler-generated>)
23 Uno               thunk for @escaping @callee_guaranteed (@in_guaranteed A) -> (@out ()) (<compiler-generated>)
24 Uno               closure #1 in Store.notify<A>(subscribers:state:) (Store.swift:250:21)
25 Uno               thunk for @escaping @callee_guaranteed () -> () (<compiler-generated>)
26 libdispatch.dylib __dispatch_call_block_and_release
27 libdispatch.dylib __dispatch_client_callout
28 libdispatch.dylib __dispatch_main_queue_drain
29 libdispatch.dylib __dispatch_main_queue_callback_4CF
30 CoreFoundation    ___CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
31 CoreFoundation    ___CFRunLoopRun
32 CoreFoundation    _CFRunLoopRunSpecific
33 GraphicsServices  _GSEventRunModal
34 UIKitCore         -[UIApplication _run]
35 UIKitCore         _UIApplicationMain
36 SwiftUI           0x18a82fce4 (0x18a82fc40 + 164)
37 SwiftUI           0x18a78cc20 (0x18a78cb8c + 148)
38 SwiftUI           0x18a775b40 (0x18a775ac4 + 124)
39 Uno               static App.$main() (App.swift:74:1)
40 dyld              start

Describe the bug I am calling the identify method with a hashed copy of the user's email address. This never appears in the web debugger, but when I change the userId to something short, such as my first name or "test", it works without issue. Is there a character limit applied? The segment debugger doesn't show any signs of errors.

To Reproduce Steps to reproduce the behavior:

1. Do identify(userId: "ee1d83696ded26626ad9fd3f9ad4a28f207cab5a")
2. Notice no debugging errors in Xcode, but web debugger doesn't receive event.3.
3. Do identify(userId: "test")
4. Notice that the event appears in web debugger.

Expected behavior The event should be sent to Segment, and shown in the web debugger.

Platform (please complete the following information):

• Library Version in use: 1.3.1
• Platform being tested: iOS
• Integrations in use: Amplitude

This PR adds an "Application Foreground" event to the iOS and macOS lifecycle handlers which is tracked on every call of applicationDidBecomeActive. This is equivalent to the "Application Backgrounded" event which is tracked on every call of applicationDidResignActive.

Closes #172.

The SDK automatically tracks lifecycle events, including an "Application Backgrounded" event in the applicationDidResignActive hook. In the corresponding applicationDidBecomeActive hook, the current implementation uses a flag to track an "Application Opened" event the first time it is called (which makes sense) but there is no event tracked on every call of applicationDidBecomeActive.

I am proposing there should be an equivalent "Application Foregrounded" event that is tracked every time applicationDidBecomeActive is called.

The pair of these two events would provide accurate "bookends" for session time tracking in various analytics platforms. I am using Mixpanel and from their documentation you can see we need to supply a "Session Start Event" and a "Session End Event".

https://help.mixpanel.com/hc/en-us/articles/115004695223

There are other ways to track session time (at least in Mixpanel) using a timeout but this approach is less accurate and event then, without an "Application Foregrounded" event there isn't a guaranteed accurate way to signal the beginning of a session.

We need this on macOS and iOS which both seem to have a similar implementation in the applicationDidBecomeActive and appears to be a trivial addition. I can't speak for Linux or watchOS.

Fixes issue #152

It was observed that when network traffic is blocked that outbound requests are timing out after 60 seconds, however the flush interval has a default of 30 seconds. This would result in a cascading set of outbound network requests that would all fail.

This change makes it such that in the case where connectivity is unavailable, we pause the flush timer for 5 minutes before attempting again.

Describe the bug When using LittleSnitch to block traffic to Segement.io from our application, we are getting huge CPU Spikes really often, and when entering foreground/background - basically every time the flush is called.

I think there are several problems in SegmentDestination:

1. Storage can grow without limits - old events that are not sent are never removed.
2. Storage is keeping files infinitely - which is causing a snowball effect for every sync.
3. Flush logic is not well prepared for having a lot of data to work with. First of all, it read all the data from the filesystem every time it's called. Then for each of the files, it creates a network request straight away iterating over all of them - which in my case ends up being over 1500 requests created and failing in milliseconds. This is when CPU spikes are kicking in. The whole process is repeated every time the flush() is called and things are getting worse and worse over time when more un-send events are piling up in the storage.

To Reproduce Steps to reproduce the behavior:

1. Install LittleSnitch
2. Block segment.io traffic in LittleSnitch
3. Create around 100.000 tracked events in Segment
4. Observe the CPUSpikes when flush logic is called.
5. Log an enormous amount of network connections created during the flush() call.

Expected behavior

1. If the user decides to block segment.io coming from our application using external software there should be no performance drop or CPU spikes coming out of this library.

2. Storage should not grow infinitely - at some point, older events should be removed when newer events are added - there should be the maximum amount of files that are allowed to be cached for sending.

3. flush() method should not go so aggressive with creating network events for all un-send files - instead it should either go one by one and read the next files only when the previous one succeeded or it should pre-check if segment batch API is reachable before trying to create a massive amount of requests.

Platform (please complete the following information):

• Library Version in use: 1.2.2
• Platform being tested: macOS
• Integrations in use: Amplitude

Workaround As for now, I am using an ugly workaround from this fork that simply deleted all failed events if the error is URLError.networkConnectionLost - which is the case for LittleSnitch.