From f8cb400a928c49c7b868aabb200c23adedb54b09 Mon Sep 17 00:00:00 2001
From: Andreas Linde <mail@andreaslinde.de>
Date: Mon, 15 Oct 2012 00:03:08 +0200
Subject: [PATCH] Improve documentation

---
 Classes/BITCrashManager.h  | 14 +++++++-------
 Classes/BITHockeyManager.h |  9 +++++++++
 Classes/BITUpdateManager.h |  3 +++
 3 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/Classes/BITCrashManager.h b/Classes/BITCrashManager.h
index 777bc71150..d6361d9623 100644
--- a/Classes/BITCrashManager.h
+++ b/Classes/BITCrashManager.h
@@ -59,11 +59,11 @@ static NSString *kBITCrashManagerStatus = @"BITCrashManagerStatus";
  additional textual log information via `BITCrashManagerDelegate` protocol and a way to detect startup crashes so
  you can adjust your startup process to get these crash reports too and delay your app initialization.
  
- Crashes are send the next time the app starts. If `autoSubmitCrashReport` is enabled, crashes will be send
- without any user interaction, otherwise an alert will appear allowing the users to decide wether they want
- to send the report or not. This module is not sending the reports right when the crash happens deliberately, 
- because if is not safe to implement such a mechanism while being async-safe (any Objective-C code is _NOT_
- async-safe!) and not causing more danger like a deadlock of the device, than helping. We found that users
+ Crashes are send the next time the app starts. If `crashManagerStatus` is set to `BITCrashManagerStatusAutoSend`,
+ crashes will be send without any user interaction, otherwise an alert will appear allowing the users to decide
+ wether they want to send the report or not. This module is not sending the reports right when the crash happens
+ deliberately, because if is not safe to implement such a mechanism while being async-safe (any Objective-C code
+ is _NOT_ async-safe!) and not causing more danger like a deadlock of the device, than helping. We found that users
  do start the app again because most don't know what happened, and you will get by far most of the reports.
  
  Sending the reports on startup is done asynchronously (non-blocking). This is the only safe way to ensure
@@ -127,8 +127,8 @@ static NSString *kBITCrashManagerStatus = @"BITCrashManagerStatus";
  If enabled the crash reporting alert will also present an "Always" option, so
  the user doesn't have to approve every single crash over and over again.
  
- If `autoSubmitCrashReport` is enabled, this property has no effect, since no
- alert will be presented.
+ If If `crashManagerStatus` is set to `BITCrashManagerStatusAutoSend`, this property
+ has no effect, since no alert will be presented.
  
  @warning This will cause the dialog not to show the alert description text landscape mode!
  @see crashManagerStatus
diff --git a/Classes/BITHockeyManager.h b/Classes/BITHockeyManager.h
index bf425b84a9..86f3d4d8d4 100644
--- a/Classes/BITHockeyManager.h
+++ b/Classes/BITHockeyManager.h
@@ -124,6 +124,15 @@
                    liveIdentifier:@"<AppIdentifierForLiveAppFromHockeyApp>"
                          delegate:nil];
 
+ We recommend using one app entry on HockeyApp for your beta versions and another one for
+ your live versions. The reason is that you will have way more beta versions than live
+ versions, but on the other side get way more crash reports on the live version. Separating
+ them into two different app entries makes it easier to work with the data. In addition
+ you will likely end up having the same version number for a beta and live version which
+ would mix different data into the same version. Also the live version does not require
+ you to upload any IPA files, uploading only the dSYM package for crash reporting is
+ just fine.
+
  @see configureWithIdentifier:delegate:
  @see startManager
  @see BITHockeyManagerDelegate
diff --git a/Classes/BITUpdateManager.h b/Classes/BITUpdateManager.h
index 656f8d07db..2554d243cd 100644
--- a/Classes/BITUpdateManager.h
+++ b/Classes/BITUpdateManager.h
@@ -62,6 +62,9 @@ typedef enum {
  This modul handles version updates, presents update and version information in a App Store like user interface,
  collects usage information and provides additional authorization options when using Ad-Hoc provisioning profiles.
  
+ This module automatically disables itself when running in an App Store build by default! If you integrate the
+ Atlassian JMC client this module is used to automatically configure JMC, but will not do anything else.
+ 
  To use this module, it is important to implement set the `delegate` property and implement
  `[BITUpdateManagerDelegate customDeviceIdentifierForUpdateManager:]`.