Skip to content

Releases: TelemetryDeck/SwiftSDK

Version 1.1.4

12 Sep 10:51
Compare
Choose a tag to compare

This bugfix release fixes a compile error on macOS < 11 discovered by @biocross. Thanks for reporting 🚀

Version 1.1.3

08 Sep 09:06
Compare
Choose a tag to compare

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

07 Sep 18:56
Compare
Choose a tag to compare

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

13 Aug 15:32
d4e89df
Compare
Choose a tag to compare

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

12 Aug 18:22
Compare
Choose a tag to compare

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

13 May 18:41
0d980cf
Compare
Choose a tag to compare

This update adds the system locale to the the default Signal payload. Thanks to @Rubenfer for adding this PR.

1.0.12

23 Apr 19:16
Compare
Choose a tag to compare

Introduce sessions. Signals now include an automatically generated session identifier. If you change nothing, a session lasts until your app is restarted from cold storage. If you want to start a new session, call TelemetryManager.generateNewSession().

1.0.11

30 Jan 15:10
Compare
Choose a tag to compare

Show logs when a signal is not being sent in DEBUG mode, and when a unique user identifier could not be created.

1.0.10

12 Jan 18:30
3c5f211
Compare
Choose a tag to compare

Telemetry Manager can now optionally configured to actually send Signals in DEBUG mode. It still won't by default, however.

Thanks to @ddaddy for this PR.

1.0.9

05 Jan 17:08
Compare
Choose a tag to compare

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.