PinpointKit is an open-source iOS library in Swift that lets your testers and users send feedback with annotated screenshots using a simple gesture.

With the Xcode 10 GM available:

• [x] Perform recommended updates from Xcode on the framework and sample project.
• [x] Migrate to the latest Swift version.
• [x] Ensure both the framework and sample projects compile without warning.
• [x] Test all 3 install methods (CocoaPods, Carthage, and manual).
• [x] Update the README for Xcode and Swift Requirements.
• [x] Smoke test the sample project built with these updates on iOS 12 and earlier OS versions, creating follow-up bugs/issues for anything that behaves abnormally.

There didnt seem to be a great reason that this was an abstract base class, and leaves possibility for things to break without warning (or a new annotation to be implemented wrong, or based on some private behavior)

This also lets use make the current annotations final

WIP-ish, relatively rough, etc

Closes #268

What It Does

This PR replaces GLKView with MTKView to fix warnings related to GLKView:

• 'GLKView' is deprecated: first deprecated in iOS 12.0 - OpenGLES API deprecated

How to Test

Add a blur annotation to your screenshot.

Notes

I added a workaround to resolve the issue of image flipping vertically when run in the simulator. See this article for reference.

Off the top of my head, the various components that we’d need that can not be extracted from Pinpoint.app would be:

• [ ] Initialization/UIWindow gesture recognizer integration
• [ ] View controller traversal/presentation
• [ ] Launch view controller design and development
• [ ] System log consumption
• [ ] Delegate protocol design

Closes #124

The example given in #124 would be nice, but would require exposing PinpointKit’s configuration as a var would introduce shared mutable state on PinpointKit, which is avoided in much of the framework. Instead, I dropped defaultPinpointKit and added a convenience initializer to PinpointKit to keep things immutable:

public convenience init(feedbackRecipients: [String], delegate: PinpointKitDelegate? = nil) {
    let configuration = Configuration(feedbackRecipients: feedbackRecipients)

    self.init(configuration: configuration, delegate: delegate)
}

I’m open to discussion on the pros and cons of both approaches. Now, instead of using PinpointKit.defaultPinpointKit, for use with ShakeDetectingWindow:

class AppDelegate: UIResponder, UIApplicationDelegate {
    let pinpointKit = PinpointKit(feedbackRecipients: ["[email protected]"])
    lazy var window: UIWindow? = ShakeDetectingWindow(frame: UIScreen.mainScreen().bounds, delegate: self.pinpointKit)
}

Note since we no longer have defaultPinpointKit which lives forever, the caller must keep a reference to their configured PinpointKit. This is because the ShakeDetectingWindow’s delegate is weak (as it should be), and we’re using an instance of PinpointKit as the delegate.

Similarly, without ShakeDetectingWindow, in our example project, we must keep a separate reference to our PinpointKit:

final class ViewController: UITableViewController {

+   let pinpointKit = PinpointKit(feedbackRecipients: ["[email protected]"])

    override func viewDidLoad() {
        super.viewDidLoad()

        // Hides the infinite cells footer.
        tableView.tableFooterView = UIView()
    }

    override func viewDidAppear(animated: Bool) {
        super.viewDidAppear(animated)

-       PinpointKit.defaultPinpointKit.show(fromViewController: self)        
+       pinpointKit.show(fromViewController: self)
    }
}

What it is

Creates a UIWindow subclass to detect a shake motion. See: #10.

To Do

• [ ] ~~Can probably use Many Controllers to avoid subclassing UIWindow in general, since -motionEnded:withEvent: is a UIResponder method. There’s nothing requiring this to be a UIWindow at all.~~ (not going to do this)
• [x] Delegate back to PinpointKit to actually present.
• [x] Add this to the example project.

Almost all of #15.

Screenshot

What it Does

Implements a screenshot detector class.

How to Test

I tested this in a sample project (attached here).

Notes

Haven’t hooked this up yet to anything in PinpointKit.

TestDetector.zip

Resolves https://github.com/Lickability/PinpointKit/issues/7.

This creates a project file to work in, with the directory structure and scheme sharing required to eventually support CocoaPods, Carthage, and the Swift Package Manager. It also creates an Asset Catalog, named PinpointKitMedia.xcassets to avoid conflicts with the default asset catalog name (Media.xcassets) in the “Quick Open...” Xcode menu when consuming this Framework.

What it Does

• Adds the ability to customize bar buttons on EditImageViewController
• Introduces a new Appearance property, editorDoneButtonFont, since the editorTextAnnotationDoneButtonFont was being used for more than just the text annotation dismiss button.
• Renames editorTextAnnotationDoneButtonFont to editorTextAnnotationDismissButtonFont for better disambiguation.

How to Test

1. Run git revert -n 0db8fa2, which uses a custom implementation of EditImageViewControllerBarButtonItemProviding.
2. View the test code in ViewController.swift, which makes the right bar button item log to the console, and the left bar button item dismiss.
3. Make some modifications like setting allowsHidingBarButtonItemsWhileEditingTextAnnotations to true in this test implementation, and verify the results.

Closes #134 by allowing the customization of Feedback’s body and title.

To test with a sample subclass, run git revert -n e9403c8 in Terminal and see the incorporation of MySender in ViewController.swift.

This PR makes a few properties on Feedback public vars instead of lets. This allows for interception / copying / modifying of Feedback by subclassing MailSender as seen in 93b9f71. I’d like to open the discussion on alternatives though, as I don’t think making the developer subclass is necessarily the most ideal solution to specifying an email subject and body.

Pros

• Simple for developer to implement.
• Allows for up-to-the-moment variation in feedback data, such as additionalInformation, as opposed to another solution in which more feedback information would be specified up front in Configuration, which would be static if you wanted to initialize PinpointKit only once.

Cons

• Requires inheritance for a fairly basic customization.
• Mix of some feedback details being specified up front (i.e. feedbackRecipients) and others at the time of sending. Maybe we should consider a FeedbackConfiguration struct instead of passing feedbackRecipients only through PinpointKit and Configuration initializers. Having only that as a solution, though, still doesn’t allow for up-to-the-moment variation (see the pro above).

What should the interface from which the app can respond to reports created via PinpointKit look like?

In my quick-and-dirty attempt to rip out the email dependency from BugshotKit, I ended up with a delegate protocol that looks like:

@protocol BugshotKitDelegate

- (BOOL)bugshotKitShouldPresent;

- (void)bugshotKitDidSubmit:(nonnull BSKSubmission *)submission;

@end

@interface BSKSubmission : NSObject

@property (nonatomic, readonly, nonnull) NSString *appName;
@property (nonatomic, readonly, nonnull) NSString *appVersion;
@property (nonatomic, readonly, nonnull) NSString *modelIdentifier;
@property (nonatomic, readonly, nonnull) NSString *systemVersion;
@property (nonatomic, readonly, nonnull) UIImage *screenshot;
@property (nonatomic, readonly, nonnull) NSString *log;

@end

In my implementation of this delegate callback, I present a custom compose sheet that posts to Trello. One tricky part was determining which view controller I should present this Trello composer from. Perhaps the PinpointKit delegate protocol should pass the view controller that it presented itself from, so the delegate can easily make use of it afterwards (I am imagining PinpointKit will recursively walk the view controller hierarchy to determine where it should present from?).