Releases: TelemetryDeck/SwiftSDK
Version 1.1.1
This point release includes some awesome PRs from users, specifically #35 #36 #37 and #38. Thanks a lot @Clafou and @jazzychad! And thanks to @ddaddy for the implementation of caching!
New API Endpoint
This version of the TelemetryClient sends its signals to the new dedicated ingestion API, nom.apptelemetry.io
. It provides better availability, and it accepts signals bundled in bulk instead of one by one. Which is important for...
Signal Caching
Signals are now only sent every 10 seconds. If the time hasn't elapsed yet, there is no internet connectivity, or an error occurs on the server side, the signals are locally cached (in the user's cachesDirectory
in a file called telemetrysignalcache
) until they can be delivered to the server. Not only does this mean signals now survive if your users are out and about beyond the reach of cell reception, it also means even less impact on battery, because we're operating the radio way fewer.
Session Management
A session ID automatically gets generated when the TelemetryClient
is initialized. On iOS, watchOS and tvOS, a new session identifier gets generated whenever your app returns from background (this will also send a sessionUpdated
signal). To manually set a new session call TelemetryManager.generateNewSession()
.
Default User
You can now call the TelemetryManager.updateDefaultUser(...)
method to set the default user for all signals created after the default user has been set (e.g. when your user has logged in). This way you don't have to supply a user identifier every time you send a signal, just set it once and all your signals belong to that user.
(User identifiers are hashed on device, and then hashed again on the server before storage, so you can use email addresses or other sensible information as user identifier without breaking any privacy law: the actual identifier never leaves the device)
Version 1.1
New API Endpoint
This version of the TelemetryClient sends its signals to the new dedicated ingestion API, nom.apptelemetry.io
. It provides better availability, and it accepts signals bundled in bulk instead of one by one. Which is important for...
Signal Caching
Signals are now only sent every 10 seconds. If the time hasn't elapsed yet, there is no internet connectivity, or an error occurs on the server side, the signals are locally cached (in the user's cachesDirectory
in a file called telemetrysignalcache
) until they can be delivered to the server. Not only does this mean signals now survive if your users are out and about beyond the reach of cell reception, it also means even less impact on battery, because we're operating the radio way fewer.
Session Management
A session ID automatically gets generated when the TelemetryClient
is initialized. On iOS, watchOS and tvOS, a new session identifier gets generated whenever your app returns from background (this will also send a sessionUpdated
signal). To manually set a new session call TelemetryManager.generateNewSession()
.
Default User
You can now call the TelemetryManager.updateDefaultUser(...)
method to set the default user for all signals created after the default user has been set (e.g. when your user has logged in). This way you don't have to supply a user identifier every time you send a signal, just set it once and all your signals belong to that user.
(User identifiers are hashed on device, and then hashed again on the server before storage, so you can use email addresses or other sensible information as user identifier without breaking any privacy law: the actual identifier never leaves the device)
1.0.13
1.0.12
1.0.11
1.0.10
1.0.9
This update fixes various issues that prevented the client from being compiled for watchOS and tvOS. Additionally, devices that don't supply the identifierForVendor
property, such as the Mac, now report their platform and the system version number as identifier.
1.0.8
Adds these values to the default signal payload:
architecture
: The build architecture, such as x86_64 or arm64operatingSystem
: The operating system as reported by Swift. Note that this will report catalyst apps and iOS apps running on macOS as "iOS".targetEnvironment
: The target environment as reported by swift. Either "simulator", "macCatalyst" or "native"
Also updates this value in the default payload:
platform
: Based on the operating version reported by swift, but adding some smartness to better detect the actual platform. Should correctly identify catalyst apps on macOS. Will probably not detect iOS apps running on ARM based Macs.