App Center Analytics (iOS)
Important
Visual Studio App Center is scheduled for retirement on March 31, 2025. While you can continue to use Visual Studio App Center until it is fully retired, there are several recommended alternatives that you may consider migrating to.
App Center Analytics helps you understand user behavior and customer engagement to improve your app. The SDK automatically captures session count and device properties like model, OS version, etc. You can define your own custom events to measure things that matter to you. All the information captured is available in the App Center portal for you to analyze the data.
Note
iOS devices without a SIM card won't send the report with carrier country code to the App Center portal. If you want to provide a country value, use the setCountryCode
method to override the country code from your device location.
Note
In the 4.0.0
version of App Center breaking changes were introduced. Follow the Migrate to App Center SDK 4.0.0 and higher section to migrate App Center from previous versions.
Follow the Get started section if you haven't set up the SDK in your application yet.
Session and device information
Once you add App Center Analytics to your app and start the SDK, it will automatically track sessions and device properties including OS Version, model, and so on, without any additional code.
Note
On Mac Catalyst apps, the amount of sessions may be lower than on iOS apps. Lifecycle events used to track sessions on Mac Catalyst behave differently from those on iOS.
The SDK automatically reports a user's country code if the device has a mobile data modem and a SIM card installed. WiFi-only devices won't report a country code by default. To set the country code of those users, you must retrieve your user's location yourself and use the setCountryCode:
method in the SDK. Our advice is to be mindful about tracking user locations, and use a low location resolution. The sample below uses kCLLocationAccuracyKilometer
.
- Make sure that you enable Location Services on the device.
- Get the device's current location using
CLLocationManager
. - Convert the location into an ISO country code using
CLGeocoder
. - Override the carrier country code using the SDK's
setCountryCode
method.
Use the following code to get the device's location and override the carrier country code in the app:
Add the CLLocationManagerDelegate protocol to the AppDelegate and add the locationManager property:
@interface AppDelegate () <CLLocationManagerDelegate>
@property(nonatomic) CLLocationManager *locationManager;
@end
class AppDelegate: CLLocationManagerDelegate {
private var locationManager: CLLocationManager = CLLocationManager()
}
In the didFinishLaunchingWithOptions: method set-up the location manager:
self.locationManager = [[CLLocationManager alloc] init];
self.locationManager.delegate = self;
self.locationManager.desiredAccuracy = kCLLocationAccuracyKilometer;
[self.locationManager requestWhenInUseAuthorization];
self.locationManager.delegate = self
self.locationManager.desiredAccuracy = kCLLocationAccuracyKilometer
self.locationManager.requestWhenInUseAuthorization()
Note
The requestWhenInUseAuthorization
method is unavailable for macOS. Remove calls to that method when developing for macOS.
Add the delegate methods:
- (void)locationManager:(CLLocationManager *)manager didChangeAuthorizationStatus:(CLAuthorizationStatus)status {
if (status == kCLAuthorizationStatusAuthorizedWhenInUse) {
[manager requestLocation];
}
}
- (void)locationManger:(CLLocationManager *)manager didUpdateLocations:(NSArray<CLLocation *> *)locations {
CLLocation *location = [locations lastObject];
CLGeocoder *geocoder = [[CLGeocoder alloc] init];
[geocoder reverseGeocodeLocation:location
completionHandler:^(NSArray *placemarks, NSError *error) {
if (placemarks.count == 0 || error)
return;
CLPlacemark *pm = [placemarks firstObject];
[MSACAppCenter setCountryCode:pm.ISOcountryCode];
}]
}
- (void)locationManager:(CLLocationManager *)manager didFailWithError:(NSError *)error {
NSLog(@"Failed to find user's location: \(error.localizedDescription)");
}
func locationManager(_ manager: CLLocationManager, didChangeAuthorization status: CLAuthorizationStatus) {
if (status == kCLAuthorizationStatusAuthorizedWhenInUse) {
manager.requestLocation()
}
}
func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) {
let userLocation:CLLocation = locations[0] as CLLocation
CLGeocoder().reverseGeocodeLocation(userLocation) { (placemarks, error) in
if error == nil {
AppCenter.countryCode = placemarks?.first?.isoCountryCode
}
}
}
func locationManager(_ Manager: CLLocationManager, didFailWithError error: Error) {
print("Failed to find user's location: \(error.localizedDescription)")
}
Custom events
You can track your own custom events with up to 20 properties to know what's happening in your app, understand user actions, and see the aggregates in the App Center portal.
Once you've started the SDK, use the trackEvent:withProperties
method to track your events with properties. You can send up to 200 distinct event names. Also, there's a maximum limit of 256 characters per event name and 125 characters per event property name and event property value.
NSDictionary *properties = @{@"Category" : @"Music", @"FileName" : @"favorite.avi"};
[MSACAnalytics trackEvent:@"Video clicked" withProperties: properties];
Analytics.trackEvent("Video clicked", withProperties: ["Category" : "Music", "FileName" : "favorite.avi"])
Properties for events are entirely optional – if you just want to track an event, use this sample instead:
[MSACAnalytics trackEvent:@"Video clicked"];
Analytics.trackEvent("Video clicked")
Event priority and persistence
You can track business critical events that have higher importance than other events.
- Developers can set priority of events as Normal (
FlagsNormal
in the API) or Critical (FlagsCritical
in the API). - Events with priority set as Critical will be retrieved from storage first and sent before Normal events.
- When the local storage is full and new events need to be stored. The oldest events with the lowest priority are deleted first to make room for the new ones.
- If the storage is full of logs with Critical priority, then tracking an event with Normal priority will fail as the SDK can't make room in that case.
- If you also use the Crashes service, crash logs are set as Critical and share the same storage as events.
- The transmission interval is only applied to Normal events, Critical events will be sent after 3 seconds.
You can use the following API to track an event as Critical:
NSDictionary *properties = @{@"Category" : @"Music", @"FileName" : @"favorite.avi"};
[MSACAnalytics trackEvent:@"Video clicked" withProperties:properties flags:MSACFlagsCritical];
// If you're using name only, you can pass nil as properties.
let properties = ["Category" : "Music", "FileName" : "favorite.avi"];
Analytics.trackEvent("Video clicked", withProperties: properties, flags: .critical)
// If you're using name only, you can pass nil as properties.
Pause and resume sending logs
Pausing the event transmission can be useful in scenarios when the app needs to control the network bandwidth for more business critical needs. You can pause sending logs to the App Center backend. When paused, events can still be tracked and saved, but they aren't sent right away. Any events your app tracks while paused will only be sent once you call resume
.
[MSACAnalytics pause];
[MSACAnalytics resume];
Analytics.pause()
Analytics.resume()
Enable or disable App Center Analytics at runtime
You can enable and disable App Center Analytics at runtime. If you disable it, the SDK won't collect any more analytics information for the app.
[MSACAnalytics setEnabled:NO];
Analytics.enabled = false
To enable App Center Analytics again, use the same API but pass YES
/true
as a parameter.
[MSACAnalytics setEnabled:YES];
Analytics.enabled = true
The state is persisted in the device's storage across application launches.
Note
This method must only be used after Analytics
has been started.
Check if App Center Analytics is enabled
You can also check if App Center Analytics is enabled or not.
[MSACAnalytics isEnabled];
Analytics.enabled
Note
This method must only be used after Analytics
has been started, it will always return NO
or false
before start.
Manage start session
By default, the session ID depends on the lifecycle of the application. If you want to control the start of a new session manually, follow the next steps:
Note
Pay attention that each call of Analytics.StartSession() API will generate a new session. If in manual session tracker mode this API will not be called then all sending logs will have a null session value.
Note
Pay attention that after a new application launch the session id will be regenerated.
- Call the following method before the SDK start:
[MSACAnalytics enableManualSessionTracker];
Analytics.enableManualSessionTracker()
- Then you can use the
startSession
API after theAppCenter.start
:
[MSACAnalytics startSession];
Analytics.startSession()
Local storage size
By default, the SDK stores all logs up to 10 MB. Developers can use an API to increase the storage size and the SDK will keep storing logs until the storage is full.
No internet access
When there isn't any network connectivity, the SDK saves up to 10 MB of logs in the local storage. Once the storage is full, the SDK starts discarding old logs to make room for the new logs. Once network connectivity returns, the SDK sends logs in the batch of 50 or after every 6 seconds (by default).
Note
The logs older than 25 days will be discarded.
Batching event logs
The App Center SDK uploads logs in a batch of 50 and if the SDK doesn't have 50 logs to send, it will still send logs after 6 seconds (by default). There can be a maximum of three batches sent in parallel. The transmission interval can be changed:
// Change transmission interval to 10 seconds.
[MSACAnalytics setTransmissionInterval:10000];
// Change transmission interval to 10 seconds.
Analytics.transmissionInterval = 10000
The transmission interval value must be between 6 seconds and 86400 seconds (one day) and this method must be called before the service is started.
Retry and back-off logic
App Center SDK supports back-off retries on recoverable network errors. Below is the retry logic:
- Three tries maximum per request.
- Each request has its own retry state machine.
- All the transmission channels are disabled (until next app process) after one request exhausts all its retries.
Back-off logic
- 50% randomization, first retry between 5 and 10 seconds, second retry between 2.5 and 5 minutes, last try between 10 and 20 minutes.
- If network switches from off to on (or from wi-fi to mobile), retry states are reset and requests are retried immediately.