This guide shows you how to use Firebase Performance Monitoring with your app, following these steps:
- Add Firebase to your iOS project
- Add Performance Monitoring to your app
- (Optional) Define a custom trace and one or more counters in your app
- Check the Firebase console for Performance Monitoring results
- Deploy your app and review results in the Firebase console
Performance Monitoring is currently in beta release.
Before you begin, you need a few things set up in your environment:
- Xcode 8.2.1 or later
- An Xcode project targeting iOS 8 or above
- The bundle identifier of your app
- CocoaPods 1.0.0 or later
Add Firebase to your iOS project
Next, you need to add Firebase to your app, add the SDK, and initialize Firebase in your app. For instructions, see Add Firebase to your iOS project.
Add Performance Monitoring to your app
- Open the podfile you created for the project (or create one using the
pod initcommand), and then add the following lines inside the target section:
- In the directory where your podfile is located, run the following command to
install the Performance Monitoring SDK:
- At the end of the command, open the
.xcworkspacefile using Xcode.
- Import the Firebase module in your
- Configure a
FirebaseAppshared instance, typically in your application's
// Use Firebase library to configure APIs FirebaseApp.configure()
// Use Firebase library to configure APIs [FIRApp configure];
- Recompile your app. Automatic traces and HTTP/S network requests are now monitored.
(Optional) Define a custom trace and one or more counters in your app
A custom trace is a report of performance data associated with some of the code in your app. To learn more about custom traces, see the Performance Monitoring overview. You can have multiple custom traces in your app, and it is possible to have more than one custom trace running at a time. Each custom trace can have one or more counters to count performance-related events in your app, and those counters are associated with the traces that create them.
Add the Performance Monitoring module to your header:
Just before the code where you want to start a trace in your app, add the following lines of code to start a trace called
let trace = Performance.startTrace(name: "test trace")
FIRTrace *trace = [FIRPerformance startTraceWithName:@"test trace"];
To count performance-related events that occur in your app (such as cache hits or retries), add a line of code similar to the following each time that the event occurs, using a string other than
retryto name that event if you are counting a different type of event:
Just after the code where you want to stop your trace, add the following line of code:
Check the Firebase console for Performance Monitoring results
- Run your app in the Xcode simulator (Product -> Run).
- Confirm that Performance Monitoring results appear in the Firebase console. Results should appear within 12 hours.
Deploy your app and review results in the Firebase console
After you have validated Performance Monitoring using the Xcode simulator and one or more test devices, you can deploy the updated version of your app to your users and use the Firebase console to monitor performance data.
- Performance Monitoring has known compatibility issues with GTMSQLite. We recommend not using Performance Monitoring with apps that use GTMSQLite.
- Performance Monitoring does not support network requests made using the
- If your app uses delegate methods of the
NSURLSessionclass and does not implement all of the possible delegate methods, those sessions might not be correctly captured by HTTP/S network request monitoring.
- Method swizzling after calling
FirebaseApp.configure()might interfere with the Performance Monitoring SDK.
- Known issues with the iOS 8.0-8.2 Simulator prevent Performance Monitoring from capturing performance events. These issues are fixed in the iOS 8.3 Simulator and later versions.
- Connections established using NSURLSession's backgroundSessionConfiguration will exhibit longer than expected connection times. These connections are executed out-of-process and the timings reflect in-process callback events.