Remove screenshot feedback

[lukeswitz]

Remove screenshot user feedback #188

• Aim to resolve Request: remove screenshotdetector  #188
• Strips out third party user feedback mechanisms natively available in TestFlight
• Realm 5.4.2 x64 config per: https://realm.io/docs/swift/latest/#cocoapods
• Build Debug/Release tested iOS 14 ✅

Notes:

1. CI still failing from syntax in xcodebuild.sh
2. Crashes occasionally: deprecated Crashlytics/Fabric calls & UI update threading
3. Stable version of cocoapods used instead of RC

[farktronix]

This is one of those cases where git doesn't work well- I'd like to do all of the build fix stuff separate from this cleanup so it's easy to see what has changed.

I've been hoping I can get Travis building my branch before I merge that to master, but I think it's time to give up on that goal and just merge it all to master since it has lots of Xcode 12/iOS 14 fixes and Cocoapod updates.

I've opened PR #203 for that. Maybe I should just merge that to master now, but I figured @alecgorge might want to take a look first since there are a ton of changed files there. If he doesn't take a look in the next couple of days I'll just go ahead and merge it.

Would you mind putting just the changes from this branch for removing screenshot feedback on top of PR #203?

[lukeswitz]

Sure, but you’ve included the pods in the repo, thus the “many changed files”. Do what works for you. Proper testing pools and regular updates did more for devOps than all the detailed crashlogs. Capturing users screens this way requires you to handle what’s sent to you. Totally your choice. It’s a very simple adjustment and not much to ask of. The amount of vulnerable deps in your app undoes the security because there’s seldom an update. Privacy measures would be setting the Realm analytic flag and removing all third party bug reporting. TestFlight literally captures screenshots for beta launches now. You can manage the users from mobile. I’m done making a case for privacy and security here. Deaf ears.

Can you please just fix the tapes of mine and my friends that you’ve mislabeled? Tours worth of shows totally off with wrong date & venue is infuriating for us tapers who make this possible. Seeing archive.org misrepresented & misinformation being spread for some of the best shows ever by bands in your app is concerning. I do not have the time to explain why, there’s an entire Infoseek community to gain that knowledge.

Good luck with @alecgeorge.. I’ve been trying to work with him on this for what is now over a year- I have realised I am wasting valuable time with this project, take care.

[farktronix]

First off, I appreciate the pull requests and the work you're putting in to this project!

There's no way around the many changed files when using Cocoapods. My personal style is to prefer making pod updates and build fixes in their own commits because they get so noisy and can hide the actual edits made to files in relisten.

I'm all for removing the custom screenshot and feedback stuff. That was our stopgap measure from back before TestFlight supported capturing screenshots and user feedback.

I would like to keep Wormholy though, since that is only enabled in debug builds (it isn't even built into a release build). We still have a longstanding bug where Relisten receives empty responses, and this is one of the few ways we have a shot at debugging that.

As for the Realm analytics, disabling it wouldn't make a different on end user devices anyway:

// Asynchronously submits build information to Realm if running in an iOS
// simulator or on OS X if a debugger is attached. Does nothing if running on an
// iOS / watchOS device or if a debugger is *not* attached.
//
// To be clear: this does *not* run when your app is in production or on
// your end-user’s devices; it will only run in the simulator or when a debugger
// is attached.

I'm unfamiliar with the issue of the mislabeled tapes. As far as I know Relisten pulls all of its data from Archive.org and some other sources like phish.in. I'm not entirely familiar with how the server side of Relisten works though. Is there an issue # you can point me at with details on the mislabeling?

[lukeswitz]

1. If it provides more privacy to developers I’m all for disabling realm analytics. I’ve read the docs, far less concerning in the privacy space than screenshots & Google Firebase.

2. The PR has extra things because the build is a mess.

3. There’s an issue I opened nearly a year ago and recently about mislabeled shows.

[farktronix]

I'm not sure what the docs say, but I checked the code and it does what they say in the comment:

void RLMSendAnalytics() {
    if (getenv("REALM_DISABLE_ANALYTICS") || !RLMIsDebuggerAttached() || RLMIsRunningInPlayground()) {
        return;
    }
...

https://github.com/realm/realm-cocoa/blob/master/Realm/RLMAnalytics.mm#L241

Yes, the build is a mess. It's always a mess when there's a new major iOS/Xcode version, and I've been working hard on cleaning that mess up. Usually I jump in and update things while the OS is still in beta, but I didn't manage to do that this time. Life happens.

Thanks for the link to the issue. This appears to be server side since I also see those labels in the web app at https://relisten.live. I'm going to move that issue over to the RelistenAPI repository.

[farktronix]

RelistenNet/RelistenApi#45

[farktronix]

One more comment on the contents of this PR- it looks like SimulatorStatusMagic was unnecessarily removed. We depend on that to generate consistent screenshots of the app for App Store submission. It is only included in debug builds so it has no impact on user privacy or security.

[lukeswitz]

cool please close this and open a fresh PR

[lukeswitz]

it has no impact on user privacy or security.

For now. Keep adding third party stuff 🤦‍♂️