Google recently reorganized their Cocoapods offerings, moving components like their analytics package back into its own pod and deprecating the Google pod in the process.
It would have been a good time to redo their integration docs as well, but unfortunately, they are still outdated and incomplete.
I’d like to quickly go over how I incorporate Google Analyics into iOS app nowadays.
First, add the tracking ID to your info.plist.
Next, add pod to your Podfile, run pod update, and then add the necessary includes to your bridging header file.
The existing docs tell you to guard against misconfiguration like this:
Unfortunately, this will break as soon as you do a release build, since assertions are removed in release configurations, and a guard block must end execution of the current scope. Here’s a better solution:
You still get the assertion helping you out while debugging, without running into problems later on.
Next you’ll want to some basic configuration.
When you first start integration, I recommend setting the log level to verbose. You could even schemes or your build configurations to set it to different values as needed.
Similarly, I wouldn’t change the dispatchInterval from the default, unless you’re actively working on your analytics code and need events to show up quicker in the reporting dashboard.
If you want google analytics to record uncaught exceptions, you can enable this feature here. However, be aware that this will interfere with other crash reporting libraries like Crashlytics. If you use one of them or another library that registers exception handlers, set trackUncaughtExceptions to false or initialize them after Google Analytics so the exception handler can be reset.
That should cover the basics, but I’ve also included an Analytics helper struct below. It’s similar to what I use in my apps. Using enums for actions and screen names helps to prevent typos from creeping in.
Prior to OS X 10.9, observing NSScrollView scroll events involved either subscribing to bounds changes on the accompanying NSClipView or subclasses the scrollView and overriding scrollWheel(_:).
In 10.9, Apple introduced responsive scrolling and a whole host of related improvements. One of those is LiveScrollNotifications. Live Scroll Events are user-initianted (via touchpad, mouse-wheel, etc) scroll events.
As usual, Xcode 9 introduced new default warnings and tightened existing ones. Some of these changes don’t seem to get applied to existing projects during the upgrade check. For better or worse though, running pod install or pod update has the effect of setting warnings for all pods like it’s a new project. This led to me seeing a lot of warnings in the form of 'RandomCocoaTouchAPI' is only available on iOS 10.0 or newer in certain pods. The build setting responsible is CLANG_WARN_UNGUARDED_AVAILABILITY = YES_AGGRESSIVE.
About me
My name is Robin Kunde. I am a software engineering consultant currently specializing in iOS mobile development and the Swift compiler. I have worked on large e-commerce projects and mobile apps for major retailers in the past.