Bump TestFlightSDK to 3.0.0

External/TestFlight/README.md

@@ -66,20 +66,6 @@ The TestFlight SDK requires iOS 4.3 or above, the Apple LLVM compiler, and the l
     3. To report crashes to you we install our own uncaught exception handler. If you are not currently using an exception handler of your own then all you need to do is go to the next step. If you currently use an Exception Handler, or you use another framework that does please go to the section on advanced exception handling.
 
 
-## Setting the UDID
-
-For **BETA** apps only: In order for "In App Updates" to work and for user data not to be anonymized, you may provide the device's unique identifier. To send the device identifier call the following method **before** your call to `+[TestFlight takeOff:]` like so:
-
-    [TestFlight setDeviceIdentifier:[[UIDevice currentDevice] uniqueIdentifier]];
-    [TestFlight takeOff:@"Insert your Application Token here"];
-    
-Note: `[[UIDevice currentDevice] uniqueIdentifier]` is deprecated, which means it may be removed from iOS in the future and that it should not be used in production apps. We recommend using it **only** in beta apps. If using it makes you feel uncomfortable, you are not required to include it.
-
-**Note on iOS 7 and Xcode 5**: In iOS 7, `uniqueIdentifier` no longer returns the device's UDID, so iOS 7 users will show up anonymously on TestFlight. Also, when building with ARC, Xcode 5 will not allow you to call `uniqueIdentifier` because it has been removed in iOS 7 from `UIDevice`'s header. We are working on a workaround for this issue.
-
-**DO NOT USE THIS IN PRODUCTION APPS**. When it is time to submit to the App Store comment this line out. Apple will probably reject your app if you leave this line in.
-
-
 ## Uploading your build
     
 After you have integrated the SDK into your application you need to upload your build to TestFlight. You can upload your build on our [website](https://testflightapp.com/dashboard/builds/add/), using our [desktop app](https://testflightapp.com/desktop/), or by using our [upload API](https://testflightapp.com/api/doc/).
@@ -89,23 +75,23 @@ After you have integrated the SDK into your application you need to upload your
 
 ### Session Information
 
-View anonymous information about how often users use your app, how long they use it for, and when they use it. You can see what type of device the user is using, which OS, which language, etc.
+View information about how often users use your app, how long they use it for, and when they use it. You can see what type of device the user is using, which OS, which language, etc.
 
 Sessions automatically start at when the app becomes active and end when the app resigns active. Sessions that start shortly after an end continue the session instead of starting a new one.
 
 NB: Sessions do not start when `takeOff:` is called, `takeOff:` registers callbacks to start sessions when the app is active.
 
-For **beta** users, you can see who the users are if you are **setting the UDID**, they have a TestFlight account, and their device is registered to TestFlight. (See Setting the UDID for more information).
+For **beta** users, you can see who the users are if they have a TestFlight account and their device is registered with TestFlight.
 
 
 ### Crash Reports
 
-The TestFlight SDK automatically reports all crashes (beta and prod) to TestFlight's website where you can view them. Crash reports are sent **at** crash time. TestFlight will also automatically symbolicate all crashes (if you have uploaded your dSYM). For **beta** apps, on the site, you can see which checkpoints the user passed before the crash and see remote logs that were sent before the crash. For **prod** apps, you can see remote logs that were sent before the crash.
+The TestFlight SDK automatically reports all crashes (beta and prod) to TestFlight's website where you can view them. Crash reports are sent **at** crash time. TestFlight will also automatically symbolicate all crashes (if you have uploaded your dSYM). For **beta** apps, on the site, you can see which checkpoints the user passed before the crash and see remote logs that were sent before the crash.
 
 
 ### Beta In App Updates  
 
-If a user is using a **beta** version of your app, you are **setting the UDID**, a new beta version is available, and that user has permission to install it; an in app popup will ask them if they would like to install the update. If they tap "Install", the new version is installed from inside the app.
+If a user is using a **beta** version of your app and that user has permission to install it; an in app popup will ask them if they would like to install the update. If they tap "Install", the new version is installed from inside the app.
 
 NB: For this to work, you must increment your build version before uploading. Otherwise the new and old builds will have the same version number and we won't know if the user needs to update or is already using the new version.
 
@@ -118,7 +104,7 @@ To turn this off set this option before calling `takeOff:`
     
 ### Checkpoints
 
-When a tester does something you care about in your app, you can pass a checkpoint. For example completing a level, adding a todo item, etc. The checkpoint progress is used to provide insight into how your testers are testing your apps. The passed checkpoints are also attached to crashes, which can help when creating steps to replicate. Checkpoints are visible for all beta and prod builds.
+When a tester does something you care about in your app, you can pass a checkpoint. For example completing a level, adding a todo item, etc. The checkpoint progress is used to provide insight into how your testers are testing your apps. The passed checkpoints are also attached to crashes, which can help when creating steps to replicate. Checkpoints are visible for all beta builds.
 
     [TestFlight passCheckpoint:@"CHECKPOINT_NAME"];
 
@@ -126,7 +112,7 @@ Use `passCheckpoint:` to track when a user performs certain tasks in your applic
 
 Checkpoints are meant to tell you if a user visited a place in your app or completed a task. They should not be used for debugging purposes. Instead, use Remote Logging for debugging information (more information below).
 
-NB: Checkpoints are only recorded during sessions.
+NB: Checkpoints are only recorded during BETA sessions.
 
 
 ### Custom Environment Information
@@ -149,7 +135,7 @@ Once users have submitted feedback from inside of the application you can view i
 
 ### Remote Logging
 
-Remote Logging allows you to see the logs your app prints out remotely, on TestFlight's website. You can see logs for **beta sessions** and **prod sessions with crashes**. NB: you cannot see the logs for all prod sessions.
+Remote Logging allows you to see the logs your app prints out remotely, on TestFlight's website. You can see logs for **beta sessions**.
 
 To use it, simply replace all of your `NSLog` calls with `TFLog` calls. An easy way to do this without rewriting all your `NSLog` calls is to add the following macro to your `.pch` file.
 
@@ -175,6 +161,7 @@ If you have your own custom logging, call `TFLog` from your custom logging funct
     [TestFlight setOptions:@{ TFOptionLogToConsole : @NO }];
     [TestFlight setOptions:@{ TFOptionLogToSTDERR : @NO }];
     
+
 ## Advanced Notes
 
 ### Checkpoint API
@@ -186,12 +173,14 @@ When passing a checkpoint, TestFlight logs the checkpoint synchronously (See Rem
 
 All logging is done synchronously. Every time the SDK logs, it must write data to a file. This is to ensure log integrity at crash time. Without this, we could not trust logs at crash time. If you have a high performance app, please email support@testflightapp.com for more options.
 
+
 ### Advanced Session Control
 
 Continuing sessions: You can adjust the amount of time a user can leave the app for and still continue the same session when they come back by changing the `TFOptionSessionKeepAliveTimeout` option. Change it to 0 to turn the feature off.
 
 Manual Session Control: If your app is a music player that continues to play music in the background, a navigation app that continues to function in the background, or any app where a user is considered to be "using" the app even while the app is not active you should use Manual Session Control. Please only use manual session control if you know exactly what you are doing. There are many pitfalls which can result in bad session duration and counts. See `TestFlight+ManualSessions.h` for more information and instructions.
 
+
 ### Advanced Exception/Signal Handling
 
 An uncaught exception means that your application is in an unknown state and there is not much that you can do but try and exit gracefully. Our SDK does its best to get the data we collect in this situation to you while it is crashing, but it is designed in such a way that the important act of saving the data occurs in as safe way a way as possible before trying to send anything. If you do use uncaught exception or signal handlers, install your handlers before calling `takeOff:`. Our SDK will then call your handler while ours is running. For example:

External/TestFlight/TestFlight.h

@@ -6,7 +6,7 @@
 //  Copyright 2011 TestFlight. All rights reserved.
 
 #import <Foundation/Foundation.h>
-#define TESTFLIGHT_SDK_VERSION @"2.1.4"
+#define TESTFLIGHT_SDK_VERSION @"3.0.0"
 #undef TFLog
 
 #if __cplusplus
@@ -14,6 +14,7 @@ extern "C" {
 #endif
     /*
      * Remote Logging
+     * BETA only
      * Note: All Logging is synchronous, see the README for more information.
      */
     void TFLog(NSString *format, ...) __attribute__((format(__NSString__, 1, 2)));
@@ -31,6 +32,7 @@ extern "C" {
 
 /**
  * Add custom environment information
+ * BETA only
  * If you want to track custom information such as a user name from your application you can add it here.
  * NB: This information must be added before the session starts, it is recorded only on session start.
  * 
@@ -64,6 +66,7 @@ extern "C" {
 
 /**
  * Track when a user has passed a checkpoint after the flight has taken off. Eg. passed level 1, posted high score.
+ * BETA only
  * Checkpoints are sent in the background.
  * Note: The checkpoint is logged synchronously (See TFLog and TFOptionLogOnCheckpoint for more information).
  *
@@ -74,33 +77,12 @@ extern "C" {
 /**
  * Submits custom feedback to the site. Sends the data in feedback to the site. This is to be used as the method to submit
  * feedback from custom feedback forms.
+ * BETA only
  *
  * @param feedback Your users feedback, method does nothing if feedback is nil
  */
 + (void)submitFeedback:(NSString*)feedback;
 
-/**
- * Sets the Device Identifier.
- *
- * !! DO NOT CALL IN SUBMITTED APP STORE APP.
- *
- * !! MUST BE CALLED BEFORE +takeOff:
- *
- * This method should only be used during testing so that you can identify a testers test data with them.
- * If you do not provide the identifier you will still see all session data, with checkpoints
- * and logs, but the data will be anonymized.
- * 
- * It is recommended that you only use this method during testing.
- * Apple may reject your app if left in a submitted app.
- *
- * Use:
- * Only use this with the Apple device UDID. DO NOT use Open ID or your own identifier.
- * [TestFlight setDeviceIdentifier:[[UIDevice currentDevice] uniqueIdentifier]];
- *
- * @param deviceIdentifer The current devices device identifier
- */
-+ (void)setDeviceIdentifier:(NSString*)deviceIdentifer;
-
 @end
 
 

External/TestFlight/release_notes.md

@@ -1,30 +1,45 @@
-## 2.1.4
+## 3.0.0 - February 18, 2014
+
+- Remove checkpoints, feedback, and logs from production apps.
+
+## 2.2.2 - February 5, 2014
+
+- Remove `+ (void)setDeviceIdentifier:(NSString *)deviceIdentifer`, it is no longer used
+- On start up, if unsent events are found only attempt to send some of them (this is in case a device doesn't have internet for a while and unsent events build up)
+- Fix crash if you try to run `TFLog(nil)` (thanks Florian!)
+
+## 2.2.1 - January 16, 2014
 
 - Consolidate both SDK versions into one which removes all access to `ASIdentifierManager`
 
-## 2.1.3
+## 2.2 - December 17, 2013
+
+- Restore In App Updates
+- Automatic identification of beta testers
+
+## 2.1.3 - November 25, 2013
 
 - Fix bug in 2.1.2-noadid which caused adid to be collected
 
-## 2.1.2
+## 2.1.2 - November 19, 2013
 
 - Fix for bug that caused events to not get sent properly when using the `TFOptionSessionKeepAliveTimeout` option
 - Fix for bug that caused logs that were sent immediately after start session to sometimes not be sent to server
 
-## 2.1.1
+## 2.1.1 - October 2, 2013
 
 - Create sdk version that removes all access to `ASIdentifierManager`
 - Add UIDevice's `identifierForVendor`
 
-## 2.1
+## 2.1 - September 30, 2013
 
 - Full support for the iPhone 5s’ ARM64 processor while still supporting down to iOS 4.3
 
-## 2.0.2
+## 2.0.2 - August 30, 2013
 
 - Fixed a bug where the sdk would cause an app's CPU usage to rise significantly if the device had no internet connection when the app started
 
-## 2.0.1
+## 2.0.1 - August 22, 2013
 
 - Fixed rare `8badf00d` crash in TFNetworkManager that happened when the app was in the background