|ReleasedLast Release||Mar 2017|
This workspace contains the source files that build the SDK as a framework (
KISSmetricsSDK.framework) and the required public interface (
KISSmetricsAPI.h). The source files included here are not intended to be used directly in your app.
For implementation details please see: http://support.kissmetrics.com/article/show/ios-sdk-v2
Setting up a framework project requires several steps and may change from one version of Xcode to the next. Rather than listing all the steps here, please refer to this tutorial: http://blog.db-in.com/universal-framework-for-ios/
Import the API class in your AppDelegate and in any classes where you'll be tracking from:
Manual: (Required if
KISSmetricsAPI_options.m is not used)
At the top of the application delegate's
didFinishLaunchingWithOptions method, add:
The customer's settings, including their API key, will live in
We can build this file for them based on selections made during new KM Product setup
and deliver it along with KISSmetricsAPI.framework and
If this file is included, attemps to initialize with sharedAPIWithKey will be ignored.
Even if the provided key is different than the key set in
The SDK will support both ARC/non-ARC and 32bit/64bit projects. One test project is included in this workspace for running application integration tests against the build files directly.
All API files will live in the
KISSmetricsAPI dir outside of any project.
Projects will link to the shared
KISSmetricsAPI Scheme > iPhone Simulatorand
KISSmetricsSDK Scheme > iOS Deviceand
UniversaliOS Scheme > iOS Deviceand
You should find the compiled framework
KISSmetricsAPI.framework in this repo's root dir.
In order to support arm64, arm7, arm7s both the KISSmetricsAPI lib target and UniversaliOS aggregate target need to be built targeting iOS7 with Standard architectures (including 64-bit)(armv7, armv7s, arm64). To confirm that the these architectures were included in the final framework build, cd into the built KISSmetricsAPI.framework dir and run:
otool -V -f KISSmetricsSDK
Internal logging for our own purposes.
KMALog which can be toggled by KMALogVerbose for release of our compiled SDK and only applies under DEBUG. (see KMAMacros.c)
We may wish to define a
KMAInfoLog which will output logs to our customer devs. This should also have a verbose toggle
that the customer dev can control.
Our SDK should always fail gracefully when not in DEBUG. Use
NSAssert to prevent assertions from our SDK when the customer's app has been built for release.
KMAAssert for crucial warnings to the customer devs. Otherwise use
KMAInfoLog (if implemented)
We're using OCMockito to aid in unit and application testing. https://github.com/jonreid/OCMockito
KISSmetricsSDK_framework_builder includes a set of unit tests but because the
framework builder is not an application, application tests of the framework
are conducted under
You should write your application tests in
KISSmetricsSDK_buildFiles_arc_imp first rather
than rebuilding the framework between each change to the SDK.
Any category added to our SDK framework must use a unique name and every method within must also use a unique prefix to avoid conflicts with customer dev categories!
KMAas a class or constants prefix.
kmac_for any public category methods.
kma_as normal for any private methods.