fix: iOS plugins treated as flavors in `shorebird init`

[DK070202]

Description

• While initializing Shorebird in one of my projects via shorebird init Shorebird captures the plugins as app flavor and default flavors also.
• Additionally, I have attached my configuration of flavor in Additional Context.

Screenshots

Steps to reproduce

• I had tried in new fresh flutter project and in that case it works totally fine.

Additional Context

• Here is my build gradle configuration for flavors.

  • productFlavors {
    dev {
        dimension "flavors"
        applicationId "in.x.x.dev"
        resValue "string", "app_name", "x DEV"
    }
    qa {
        dimension "flavors"
        resValue "string", "app_name", "x QA"
    }
    prod {
        applicationId "in.x.x"
        dimension "flavors"
        resValue "string", "app_name", "x"
    }
    }

• I had tried to understand how shorebird init captures schema and I doubt in my case xcodebuild -list is dumping this additional output.

[eseidel]

I'm not sure I fully understand. Are you able to share your shorebird.yaml? That app_ids are not secret, so it's safe to publish your shorebird.yaml anywhere as needed.

[DK070202]

As I found the file unexpected I ended up the deleting shorebird.yaml file, I tried debugging it from my side and I found that the shorebird init command triggers thexcodebuild -list and from its Schemes key is used register apps under the shorebird.yaml.

https://github.com/shorebirdtech/shorebird/blob/a149410cfa1c700cc35c1aa4720fa020ab536519/packages/shorebird_cli/lib/src/executables/xcodebuild.dart#L26-L27

And In my project configuration, the output was like this:

    Schemes:
        abseil
        advertising_id
        app_install_date
        app_set_id
        AppAuth
        BoringSSL-GRPC
        cloud_firestore
        connectivity_plus
        CTNotificationContent
        CTNotificationService
        dev
        device_info_plus
        external_app_launcher
        FBAEMKit
        FBSDKCoreKit
        FBSDKCoreKit_Basics
        Firebase
        firebase_analytics
        firebase_auth
        firebase_core
        firebase_crashlytics
        firebase_database
        firebase_dynamic_links
        firebase_in_app_messaging
        firebase_instance_id
        firebase_messaging
        firebase_performance
        firebase_remote_config
        firebase_storage
        FirebaseABTesting
        FirebaseAnalytics
        FirebaseAppCheckInterop
        FirebaseAuth
        FirebaseAuthInterop
        FirebaseCore
        FirebaseCoreExtension
        FirebaseCoreInternal
        FirebaseCrashlytics
        FirebaseDatabase
        FirebaseDynamicLinks
        FirebaseFirestore
        FirebaseInAppMessaging
        FirebaseInAppMessaging-InAppMessagingDisplayResources
        FirebaseInstallations
        FirebaseMessaging
        FirebasePerformance
        FirebaseRemoteConfig
        FirebaseStorage
        Flutter
        FMDB
        google_sign_in_ios
        GoogleAppMeasurement
        GoogleDataTransport
        GoogleSignIn
        GoogleSignIn-GoogleSignIn
        GoogleUtilities
        gRPC-C++
        gRPC-C++-gRPCCertificates-Cpp
        gRPC-Core
        GTMAppAuth
        GTMSessionFetcher
        image_picker_ios
        integration_test
        isar_flutter_libs
        leveldb-library
        Libuv-gRPC
        open_filex
        path_provider_foundation
        Pods-Runner
        prod
        PromisesObjC
        qa
        ReachabilitySwift
        SDWebImage
        share_plus
        shared_preferences_foundation
        sms_autofill
        Toast
        url_launcher_ios

And for each of these schemes, the shorebird cli has created a project on the shorebird console and created an entry in shorebird.yaml

Where expected output should be like this:

    Schemes:
        dev
        prod
        qa

Solution:

• For me, due to the configuration of my project It was treating my project dependencies as schemes so I removed the reference of Pods.xcodeproj from under Project/Pods and then after triggering shorebird init was running as expected.

• Just deleting those schemes from the Shorebird console was cumbersome 😅, one flag before registering the scheme to shorebird would be very helpfull in such condition.

[bryanoltman]

@DK070202 I'm having some trouble reproducing this. I've:

1. Created a new Flutter project with flutter create
2. Added two dependencies that both use plugins (device_info_plus and path_provider)
3. Ran shorebird init – no flavors were detected
4. Added schemes as per https://docs.flutter.dev/deployment/flavors#creating-flavors-in-ios
5. Ran shorebird init – only the two schemes I added were detected.

Do you know what steps you took that added all of your Pod targets as schemes?

[bryanoltman]

It's possible https://github.com/CocoaPods/CocoaPods/issues/3165 is relevant? The bug is quite old, although it was closed without comment, so I'm not totally sure if it was resolved in any satisfactory way (although it seems to have been, given my inability to reproduce the issue)

[DK070202]

It's possible CocoaPods/CocoaPods#3165 is relevant? The bug is quite old, although it was closed without comment, so I'm not totally sure if it was resolved in any satisfactory way (although it seems to have been, given my inability to reproduce the issue)

Thanks for addressing it quickly by adding scheme output in the init command.

No, @bryanoltman it's not related to this, to confirm this, prior to opening this issue I created a sample project that tried to fire xcodebuild -list command from the iOS root, and the results were expected.

In further to resolve this I have just created a flutter project with very_good_cli for schemes configuration in iOS. I have just compared the project configuration of both projects and found the following things:

Pods.xcodeproj was referenced additionally in this project under the pods folder and in the new project it was not there, we were not doing something like Cross-Project Dependencies so I just removed it, and then after it was working as expected.

Here are more visual details in the Xcode context:

Let me know if any further information is required, thanks!

[bryanoltman]

I'm trying to reproduce locally with the very_good_cli flutter_app template but am running into a number of issues which suggest issues with the template (i.e., gradlew not being executable, running pod install from the ios directory fails, attempting to launch to the simulator from Xcode fails). I'm looking into that separately.

I think this might have been the source of issue though:

Pods.xcodeproj was referenced additionally in this project under the pods folder and in the new project it was not there, we were not doing something like Cross-Project Dependencies so I just removed it, and then after it was working as expected.

It sounds like things are working as expected for you now?

[DK070202]

I think this might have been the source of the issue though:

Yes, exact, and If revert this change(done when I remove the pods reference) in the iOS directory then I can see the output as described in the above issue.

It sounds like things are working as expected for you now?

Yes, at the end!

[bryanoltman]

Great! Closing this as resolved.