Log to SwiftyBeaver Platform
The SwiftyBeaver Platform is the world’s first logging platform for Swift. It enables the very convenient automatic, highly-secured receiving & analyzing of logs, analytical user and device data an app creates at release.
The platform consists of the following components:
- SwiftyBeaver Framework to create logs in your app during development and release
- SwiftyBeaver Crypto Cloud to store & sync encrypted logs
- SwiftyBeaver Mac App to download, search & analyze the logs sent from you app
To start logging to the platform you just need to instantiate
SBPlatformDestination() with your credentials, optionally adjust the properties and then add the instance to SwiftyBeaver itself.
let platform = SBPlatformDestination(appID: "YourAppID", appSecret: "YourAppSecret", encryptionKey: "Your32CharKey") log.addDestination(platform)
You can adjust the logging behavior with the following properties of
||Empty String|| The identifier of your app's user. For example an email, name or unique ID. It can be changed during runtime and should be set as early as possible in the lifetime of your app.
||String|| A read-only UUID which uniquely represents the app on the device. Can be used to identify a user without account.
||10||Sets when log entries are sent to SwiftyBeaver Crypto Cloud. Needs to be within range of 1 - 1000.|
||false||Enable debug output to Xcode Console about the destination’s activity|
|.minLevel||.Verbose||Any level with a priority lower than that level is not logged. Possible values are SwiftyBeaver.Level.verbose, .debug, .info .warning, .error.|
~ TIPS & TRICKS ~
Where to get the credentials?
You need a SwiftyBeaver Logging Platform account which you can create for free in the SwiftyBeaver Mac App. That Mac App can also be used to generate new credentials for your apps.
What is ID, Secret & Encryption Key?
When you generate your credentials you will receive a server-generated ID and secret. the ID and the secret are used to identify your app with the platform. The encryption key is used to encrypt your logging data on a user's device inside the SwiftyBeaver Framework and is NEVER sent to the platform. In that way we can guarantee that even man-in-the-middle attacks do not expose your logging data. The encryption key must be 32 characters long and should be as random as possible. The Mac App can generate a valid random encryption key for you.
What is encrypted?
All logging and analytics data is encrypted on a user's device before being sent to the SwiftyBeaver Crypto Cloud.
What encryption is used?
Industry-standard AES-256 CBC encryption is used. SwiftyBeaver Framework has its own AES256CBC encryption framework included which was built in cooperation with crypto experts.
Can I get that kind of encryption for my own apps?
Absolutely! Just check our very convenient open-source AES256CBC encryption framework.
Where is it decrypted?
The decryption happens in the secure environment of your computer inside the SwiftyBeaver Mac App after it downloaded the encrypted data from SwiftyBeaver Crypto Cloud. The encryption key and your user credentials stay encrypted on your computer either inside your Mac OS X Keychain or inside an encrypted data container.
What part of the credentials can I share with you at a support request?
The ID you can share with us but nothing else. We will never ask you for your secret or your encryption key and you should never share them with anyone outside your team.
What device, user and app details are collected?
Additionally to the logging data the platform destination automatically collects valuable analytics data of the installed app, the user and the user’s device.
Collected device details:
- operating system platform ("OSX", "iOS", "watchOS", "tvOS")
- OS version (for example "10.11.2" for Mac OS X El Capitan)
- host name ("steves-iphone.local")
- device name ("Steve's iPhone")
- device model ("iPhone 6", "iPad 3", "27 inch iMac Late 2015")
Collected user & app details:
- user name, an important custom identifier set by you during runtime to improve search & filtering
- UUID, internally used to identify the device
- first start, to identify when the app was used the first time
- last start, to identify for how long the app was used
- starts, how often the app was started
- first app version, the version of the app when it was installed
- app version, the current app version
- first app build, the build number of the app when it was installed
- app build, the current app build
Where can I mine and analyze the data?
The SwiftyBeaver Mac App is made for convenient and powerful searching, filtering and analyzing of your app’s logging and analytics data.
When is the data sent to Crypto Cloud?
To avoid a drain on the device’s network and computing power the logging and analytics data is sent as bundle. The data bundle is sent either if the sending threshold is reached or the app was started and there are still unsent bundles existing (for example due to a formerly bad network). The sending threshold itself is the sum of a numeric value of log level’s sending points.
Default sending points per log level:
- Verbose: 0
- Debug: 1
- Info: 5
- Warning: 8
- Error: 10
For example if a user logged an info and a warning log entry then the sum of all sending points would be 5 + 8 = 13. That 13 is above the default sending threshold of 10 and the platform destination would send the logs. After the successful sending the sent logs are removed from the sending queue and the counter is reset to 0.
That point-based system prioritizes the sending of logs if an error or warning occurs without constantly sending less important logs.
How can I change when data is sent?
You can change the sending threshold to be slightly higher (for less often sending) or lower (for more often sending). But please keep in mind that frequent sending can negatively impact an app’s performance and the device's network and should be avoided.
What about log levels which are below the minimum level?
If you for example did set your minimum log level to info then all debug and verbose log entries are not processed by the platform destination. That also means that they are not added to the sending points calculation.
How can I learn what is going on under-the-hood?
During development you can set the showNSLog property to true to get debug output of the platform destination's sending logic to your console.
Should I tune it?
In general you should leave everything as it is because the sending points and the threshold defaults are chosen to be well balanced. More important is the correct adjustment of the minimum level during release. Normally that should be the default .Info level to avoid too much data being sent to the platform.