App Center Analytics (macOS)

Article
11/28/2022

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.

Learn more about support timelines and alternatives.

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

Carrier country and carrier name aren't available on App Center Analytics for macOS, but you can set carrier country with 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 the AppCenter.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.

Share via

App Center Analytics (macOS)

Session and device information

Custom events

Event priority and persistence

Pause and resume sending logs

Enable or disable App Center Analytics at runtime

Check if App Center Analytics is enabled

Manage start session

Local storage size

No internet access

Batching event logs

Retry and back-off logic

Feedback

Additional resources