• Adds a new target to generate a dynamic framework
• removed a framework search path in the test target which was pointed to an non existent system directory to get rid of a warning

• Add ARKLogging.swift to allow for ARKLog use in Swift.
• Remove support for iOS 6 and 7
• Remove static library build target
• Better ivar naming: ARKLogMessage.creationDate -> ARKLogMessage.date
• Banish use of NS_ASSUME_NONNULL_*

Please provide feedback @peter @natan @shawnwelch @rhgills. Happy to add more Swift to 2.0 if we think there's benefit (that won't screw current clients more than 2.0 already will).

Built on top of #49.

@mthole or @pwesten, mind testing this in Cash/Caviar before this branch goes to master? I no longer work on an app that uses Aardvark 😞.

I'm hoping the @objc changes are fine, since we were already explicitly calling out which swift methods were objc-available.

[RI-11328] Fixes crash when displaying action menu on iPad. Improves initializer correctness.

Changes:

• Obey Apple's guidelines for displaying UIActivityViewController - was causing crashes on iPad when trying to display.
• Enforce passing a non-nil logStore and formatter to the ARKLogTableViewController. Deeper down the stack, the logFormatter is used to add formatted log messages to an array. This fails when one is missing.
• Ensure that we override our superclasses designated initializers. Mark one of our initializers as designated. Ensure our designated initializer calls through to (one of) our superclasses designated initializers.

Because Xcode 12 drops support for iOS 8 deployment target, we need to upgrade Aardvark's deployment target.

• Bumps iOS Deployment Target to 9
• Migrate from deprecated APIs
• Updates to Swift 5
• Update xcodeproj to recommended settings

This moves us from Travis CI to GitHub actions, and parallelizes our builds a bit more, which should speed up CI times.

I also bumped to the latest (non-beta) release of CocoaPods, since we were a bit behind.

#37 didn't do what we needed. Going to 2 pod specs should do it.

CI will fail this PR, since we'll need to publish CoreAardvak before Aardvark will lint.

cc @justinseanmartin @pwesten @natan

Aardvark currently has a lot of responsibilities - adding log messages, viewing those log messages in the app, generating data for a bug report, and sending that bug report via email. Breaking it down into smaller modules unlocks a couple of distinct advantages:

• Support including only necessary portions of the bug reporting system based on build configuration. In particular, consumers should be able to include the core parts of the bug reporting functionality (taking a screenshot, generating attachments, etc.) without including the mail dialogs. By modularizing the core components of generating a bug report, we can make it easier to generate more customizable bug reporting workflows, while still supporting the simple-setup case with the existing email bug reporter.
• Improve extensibility for future additions. In particular, I think there is a lot of power in being able to extend the variety of attachments that can be generated and included in a bug reported, as well as the ways in which that bug report can be shared.

The disadvantage comes in the form of a few extra sets in setting up the dependencies (since there are now more dependencies) and discoverability of new features (since they may be in a not-yet-imported module), but I think these are greatly outweighed by the advantages.

The current frameworks (Aardvark and CoreAardvark) will be broken down into four separate frameworks based on functionality. Frameworks related to the logging functionality with be prefixed with "CoreAardvark" (where CoreAardvark itself is the core logging framework) and frameworks related to the bug reporting functionality will be prefixed with "Aardvark" (where Aardvark itself is the core bug reporting framework). This gives us:

• CoreAardvark - Core log message distribution and storage functionality. This has no dependencies and can be run in app extensions (no change from the current framework).
• CoreAardvarkLoggingUI - User interfaces to view log messages inside an app.
• Aardvark - Core bug reporting functionality. This will include the informational pieces of bug reporting, such as generating a screenshot and view hierarchy description.
• AardvarkMailUI - User interfaces to submit a bug report via the Mail app.

This provides us with a solid foundation to build out new logging and bug reporting functionality in a modular fashion on top of the two core frameworks, CoreAardvark and Aardvark.

In the interest of making the addition of new bug reporting flows simpler, I think we should keep the bug report "attachment" concept in the main Aardvark framework. Since it isn't inherently tied to the mail concepts right now, the only change to the class will be a rename from ARKEmailAttachment to ARKBugReportAttachment.

We can then begin to add new modules over time, which will generally fall into one of the following categories for most cases:

• Attachment vendors - Frameworks that provide additional data that can be attached to a bug report.
• Bug reporting workflows - Frameworks that provide alternate ways to file a bug report. For example, #47 mentions using the Gmail SDK to provide an alternate mail client to the built-in mail dialog. This could be provided as an alternate bug reporter podspec that has a dependency on that SDK. Similarly, we could introduce new bug reporters that connect directly to various services' APIs, for instance to create a new issue on GitHub.

With this, the frameworks will be broken down into small components and restructured as follows:

| | Current | Proposed | | :--- | :---: | :---: | | Log methods (Aardvark.log(), ARKLog(), ARKLogWithType()) | CoreAardvark | CoreAardvark | | Log message primitives (ARKLogMessage, ARKLogType) | CoreAardvark | CoreAardvark | | Log storage (ARKLogStore, ARKDataArchive, file management utilities) | CoreAardvark | CoreAardvark | | Log distribution (ARKLogDistributor, ARKLogObserver) | CoreAardvark | CoreAardvark | | Exception logging (ARKExceptionLogging) | CoreAardvark | CoreAardvark | | Log formatting (ARKLogFormatter, ARKDefaultLogFormatter | Aardvark | CoreAardvark | | In-app log viewing (view controllers and sharing utilities) | Aardvark | CoreAardvarkLoggingUI | | Screenshot logging (ARKLogScreenshot() and distributor additions) | Aardvark | Aardvark | | Bug reporter protocol (ARKBugReporter) | Aardvark | Aardvark | | Bug report attachments (ARKBugReportAttachment) | Aardvark | Aardvark | | Convenience method to add (generic) bug reporter via gesture | Aardvark | Aardvark | | Email bug reporter (ARKEmailBugReporter, ARKEmailBugReportConfiguration) | Aardvark | AardvarkMailUI | | Convenience method to add email bug reporter via gesture | Aardvark | AardvarkMailUI |

Steps: (I used aardvark sample app)

• Run aarvark against any iOS 9 device
• Two finder long tap to trigger a bug report
• after coming back to the app try and trigger another bug report by a long 2 finger tap. Notice that the Compose report code is never called.

Things work again after restart

When bugs are reported from a beta OS, the prefilled email body looked like:

System Version: 11.0

It's useful to be able to determine which beta/build of the OS, and this PR updates it to be:

System: Version 11.0 (Build 15A5361a)

@jbmorgan pointed out that by default, under ARC, the lifetime of a variable caught in an exception does not end when a scope ends https://clang.llvm.org/docs/AutomaticReferenceCounting.html#exceptions

by making a __weak reference before entering an @try block, we can avoid leaking memory when hitting assertions around low disk space (to avoid also crashing due to low memory!)

similarly @JaviSoto pointed out that we should combine data into one object before calling write, to ensure we atomically write everything or nothing.

The AardvarkLoggingUI podspec has a source file pattern that matches Swift code however the pod is Objective-C only.

  s.source_files = 'Sources/AardvarkLoggingUI/**/*.{h,m,swift}'

The highlighted errors can often contain red herrings in the form of old errors that aren't relevant to the issue that was seen just prior to filing the bug report. While some errors can have downstream effects much later, I've found that more often than not an older error message is unrelated and simply adds noise.

This filters out error messages that are older than 1 hour from the highlighted errors. The time interval is configurable, so developers can adjust as appropriate for their app's behavior.

This stems from a desire to have bug reporters (in particular the ARKEmailBugReporter) treat the log store as just another attachment, rather than special casing it. Currently the only major behavioral difference between the log stores and the other attachments is that the reporter pulls the recent errors out of the logs and surfaces them at the top level. This is vital behavior in the case where attachments aren't available, but it's also very useful when there are attachments to provide a quick hint as to what the problem might be before digging into each attachment.

I think it would be fairly straightforward to introduce a highlightsSummary property (exact naming TBD) to ARKBugReportAttachment so that any attachment could optionally surface highlights at the top level. This would also unblock making the log store be a regular attachment, since the recent error logic could be easily moved to the LogStoreAttachmentGenerator.

The default log store get lazily created the first time you access the defaultLogStore property. If you follow the one-line setup approach, this happens immediately since we access the default log store in order to create the bug reporter. If you don't use this setup, however, instead opting to create the bug reporter later, calling log(...) will send the message nowhere (or really will send the message to other log observers you've added, but not the default log store).

I think the expected behavior would be to create the default log store the first time log(...) is called if it doesn't already exist.