Patrol is built into a release app, even when it is a dev_dependency

[bartekpacia]

That's what Apple sent us after we released an app using patrol v0.10.2 on Test Flight.

This is the line which is causing this warning.

It also hints at a much bigger problem – Patrol's native code is built into an app binary in release mode, which increases its size. I haven't done any benchmarks, but gRPC which we're using isn't known for being lightweight...

cc @mateuszwojtczak

Related issues:

• Do not create plugins from dev_dependencies flutter/flutter#56591
• Plugins with iOS native code included as dev_dependencies are being embedded in Release version of the app flutter/flutter#49101
• Don't include dev_dependencies in native build scripts flutter/flutter#45714
• integration_test embedded in shipping iOS apps when added to pubspec flutter/flutter#74274

[bartekpacia]

(Android) Verify that Patrol's code is built into the app

1. Build the app (debug mode, release mode - shouldn't matter. We're a dev_dependency, so we shouldn't be included anyway).

   $ flutter build apk
   

2. Use apkanalyzer to see that Patrol's code is included in the resulting dex:

   # run in the directory with app's pubspec.yaml
   $ apkanalyzer -h dex packages build/app/outputs/flutter-apk/app-debug.apk | grep pl.leancode.patrol | wc -l 
   

   In my case, it prints 5112, but it should be 0 instead.

The same can be done for other dev_dependencies that shouldn't land in the app binary, but they do, e.g. integration_test:

$ apkanalyzer -h dex packages build/app/outputs/flutter-apk/app-debug.apk | grep integration_test | wc -l
     344

[KonAtPropertyMe]

Got the same issue @bartekpacia. Looking forward to a fix, although it is not stopping us as we dropped back to 0.9.1 for now.

[bartekpacia]

@KonAtPropertyMe I'm working on a fix (or rather a nicer workaround, because the root cause lies in Flutter itself)

For the time being, you can update to the newest Patrol (v0.10.5) and use the below script (made by @jarekb123) to remove dependency on patrol in your CI:

# This script is run before fastlane build (mainly iOS build)
#
# It's a workaround for Apple app rejection: 
# ITMS-90338: Non-public API usage - The app references non-public selectors in Frameworks/patrol.framework/patrol: terminate.

cp pubspec.yaml pubspec_copy.yaml
sed '/patrol/d' pubspec_copy.yaml > pubspec.yaml
rm pubspec_copy.yaml
flutter pub get

[bartekpacia]

#727 introduced a workaround for this. Now the terminate() function that App Store is angry about is guarded by an #ifdef, which by default evaluates to false.

[jeremiahlukus]

Still getting this on the latest version

The app references non-public selectors in Payload/Runner.app/Frameworks/patrol.framework/patrol: alerts, exists, isHittable, launch, sharedDevice, tap

[bartekpacia]

Oh, so that means App Store has broadened its definition of "non-public selectors". We need to get this fixed ASAP. cc @jBorkowska @mateuszwojtczak - this prevents apps that import patrol to be published on App Store.

@jeremiahlukus For now, you can remove the patrol dependency automatically before building a binary that gets uploaded to App Store.

[bartekpacia]

This should be fixed (again) in v1.0.8.

[bartekpacia]

This is still a problem. Yes, we do have a workaround implemented, but we'd like to see it fixed upstream :)