https://github.com/codeandtheory/yanalytics-ios
Y—Analytics: a generic analytics wrapper you can put around most any analytics framework
https://github.com/codeandtheory/yanalytics-ios
Last synced: 3 months ago
JSON representation
Y—Analytics: a generic analytics wrapper you can put around most any analytics framework
- Host: GitHub
- URL: https://github.com/codeandtheory/yanalytics-ios
- Owner: codeandtheory
- License: apache-2.0
- Created: 2023-01-12T11:47:15.000Z (about 3 years ago)
- Default Branch: main
- Last Pushed: 2023-05-05T10:04:58.000Z (almost 3 years ago)
- Last Synced: 2025-11-18T09:25:34.529Z (3 months ago)
- Language: Swift
- Size: 203 KB
- Stars: 4
- Watchers: 6
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
[](https://swiftpackageindex.com/yml-org/yanalytics-ios) [](https://swiftpackageindex.com/yml-org/yanalytics-ios)
_An injectable analytics wrapper for Apple platforms._
This lightweight framework provides a generic wrapper for analytics SDK's that is suitable for Dependency Injection. Its objective is to avoid tightly coupling an application with a specific analytics provider.
Licensing
----------
Y—Analytics is licensed under the [Apache 2.0 license](LICENSE).
Documentation
----------
Documentation is automatically generated from source code comments and rendered as a static website hosted via GitHub Pages at: https://yml-org.github.io/yanalytics-ios/
Usage
----------
### `AnalyticsEngine`
is an abstraction meant to represent any analytics package, whether that be Firebase, Adobe, any other 3rd party analytics vendor, or your own custom implementation.
The point is to abtract away the specifics of choice of analytics vendor, so that it may be swapped at any time without incurring major tech debt.
It also encourages the use of dependency injection to provide the analytics engine to components that require it. This should make it easier to write unit tests for all these components (by either injecting a mock or even nothing at all).
`AnalyticsEngine` has exactly one method:
```
public protocol AnalyticsEngine {
/// Track an analytics event
/// - Parameter event: the event to log
func track(event: AnalyticsEvent)
}
```
### `AnalyticsEvent`
is an enum with a few cases for typical events.
```
public enum AnalyticsEvent {
/// Screen view event
/// - Parameter screenName: screen name
case screenView(screenName: String)
/// User property event
/// - Parameters:
/// - name: user property name
/// - value: user property value
case userProperty(name: String, value: String)
/// Generic event
/// - Parameters:
/// - name: event name
/// - parameters: event metadata to track
case event(name: String, parameters: Metadata?)
}
```
### `CompoundAnalyticsEngine`
is a helper implementation of `AnalyticsEngine` that lets you specify an array of engines. This would allow you to combine a logger together with your actual analytics engine (e.g. Firebase) to assist with debugging.
### `ConsoleAnalyticsEngine`
is a simple implementation of `AnalyticsEngine` that logs output using `print` statements. (For most cases you should use `LoggerAnalyticsEngine` instead.)
### `LoggerAnalyticsEngine`
is a simple implementation of `AnalyticsEngine` that logs output using Apple's' `Logger` api.
Installation
----------
You can add Y—Analytics to an Xcode project by adding it as a package dependency.
1. From the **File** menu, select **Add Packages...**
2. Enter "[https://github.com/yml-org/yanalytics-ios](https://github.com/yml-org/yanalytics-ios)" into the package repository URL text field
3. Click **Add Package**
Contributing to Y—Analytics
----------
### Requirements
#### SwiftLint (linter)
```
brew install swiftlint
```
#### Jazzy (documentation)
```
sudo gem install jazzy
```
### Setup
Clone the repo and open `Package.swift` in Xcode.
### Versioning strategy
We utilize [semantic versioning](https://semver.org).
```
{major}.{minor}.{patch}
```
e.g.
```
1.0.5
```
### Branching strategy
We utilize a simplified branching strategy for our frameworks.
* main (and development) branch is `main`
* both feature (and bugfix) branches branch off of `main`
* feature (and bugfix) branches are merged back into `main` as they are completed and approved.
* `main` gets tagged with an updated version # for each release
### Branch naming conventions:
```
feature/{ticket-number}-{short-description}
bugfix/{ticket-number}-{short-description}
```
e.g.
```
feature/CM-44-button
bugfix/CM-236-textview-color
```
### Pull Requests
Prior to submitting a pull request you should:
1. Compile and ensure there are no warnings and no errors.
2. Run all unit tests and confirm that everything passes.
3. Check unit test coverage and confirm that all new / modified code is fully covered.
4. Run `swiftlint` from the command line and confirm that there are no violations.
5. Run `jazzy` from the command line and confirm that you have 100% documentation coverage.
6. Consider using `git rebase -i HEAD~{commit-count}` to squash your last {commit-count} commits together into functional chunks.
7. If HEAD of the parent branch (typically `main`) has been updated since you created your branch, use `git rebase main` to rebase your branch.
* _Never_ merge the parent branch into your branch.
* _Always_ rebase your branch off of the parent branch.
When submitting a pull request:
* Use the [provided pull request template](.github/pull_request_template.md) and populate the Introduction, Purpose, and Scope fields at a minimum.
* If you're submitting before and after screenshots, movies, or GIF's, enter them in a two-column table so that they can be viewed side-by-side.
When merging a pull request:
* Make sure the branch is rebased (not merged) off of the latest HEAD from the parent branch. This keeps our git history easy to read and understand.
* Make sure the branch is deleted upon merge (should be automatic).
### Releasing new versions
* Tag the corresponding commit with the new version (e.g. `1.0.5`)
* Push the local tag to remote
Generating Documentation (via Jazzy)
----------
You can generate your own local set of documentation directly from the source code using the following command from Terminal:
```
jazzy
```
This generates a set of documentation under `/docs`. The default configuration is set in the default config file `.jazzy.yaml` file.
To view additional documentation options type:
```
jazzy --help
```
A GitHub Action automatically runs each time a commit is pushed to `main` that runs Jazzy to generate the documentation for our GitHub page at: https://yml-org.github.io/yanalytics-ios/