Releases: TelemetryDeck/SwiftSDK
Version 1.1.4
This bugfix release fixes a compile error on macOS < 11 discovered by @biocross. Thanks for reporting 🚀
Version 1.1.3
This release fixes an incompatibility with older WatchOS versions, thanks to @ddaddy, a better detection of iOS apps running on Mac thanks to @maxbaeumle, and better DEBUG detection in TestFlight builds thanks to @jazzychad.
It also switches all signals to our new ingestion URL, nom.telemetrydeck.com
. That's right, we have a new and even cooler name <3
This version replaces version 1.1.2 which had a typo in the URL.
Version 1.1.2
This release fixes an incompatibility with older WatchOS versions, thanks to @ddaddy, a better detection of iOS apps running on Mac thanks to @maxbaeumle, and better DEBUG detection in TestFlight builds thanks to @jazzychad.
It also switches all signals to our new ingestion URL, nom.telemetrydeck.com
. That's right, we have a new and even cooler name <3
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.