fix: patch not being applied on iOS - using wrong app ID

[adamkoch]

App ID: 0a4358e2-d269-4b1e-990e-d6a7009fe5f0

Description

On Android, everything worked fine. On iOS, I didn't see the patch coming through, following the troubleshooting guide, I checked the iOS logs and sure enough, it's not finding the patch because it's checking the wrong app_id:

[INFO:shorebird.cc(173)] Shorebird updater: no active patch.
Sending patch check request: PatchCheckRequest { app_id: "0a4358e2-d269-4b1e-990e-d6a7009fe5f0", channel: "stable", release_version: "1.2.29+1229", patch_number: None, platform: "ios", arch: "aarch64" }

My production app_id is 0f7a6dc6-bccc-4343-a208-3a63a9cb8b3f and it's checking my beta app id (0f7a6dc6-bccc-4343-a208-3a63a9cb8b3f).

However, when using shorebird CLI, it did choose the prod track fine for the releases and the patches. There is nothing in beta or dev.

Looking at my shorebird.yaml:

app_id: 0a4358e2-d269-4b1e-990e-d6a7009fe5f0
flavors:
  beta: 0a4358e2-d269-4b1e-990e-d6a7009fe5f0
  dev: ae343dd9-879d-442b-a9ba-da0e75d36654
  prod: 0f7a6dc6-bccc-4343-a208-3a63a9cb8b3f

It seems it chose beta as the main app_id. Can I flip the main app_id over to the prod one to fix this?

Thanks!

[bryanoltman]

Can you share the commands you ran to generate the patches and the release?

[bryanoltman]

Can I flip the main app_id over to the prod one to fix this?

This should be fine, but ideally we fix this issue so you don't need to. I'll need to fully understand the steps you took and what you expected the outcome of them to be before we can do that though.

[adamkoch]

Ok I think I worked it out, was my fault, but have yet to test it out.

We use Fastlane to push builds to testflight / app store. Before shorebird, the Fastfile looked like this:

    sh '(cd ../../ && flutter build ios --release --no-codesign)'
    build_app(
        workspace: "Runner.xcworkspace",
        scheme: "Runner",
        export_xcargs: "-allowProvisioningUpdates"
    )
    upload_to_testflight()

So what I did was to replace the flutter build with shorebird:

    sh '(cd ../../ && shorebird release ios --no-codesign --verbose)'
    build_app(
        workspace: "Runner.xcworkspace",
        scheme: "Runner",
        export_xcargs: "-allowProvisioningUpdates"
    )
    upload_to_testflight()

However, what that did, was it kept uploading the release to the beta track of shorebird. Now i see, that's probably because no scheme/flavor was specified and the shorebird.yaml had beta as the main app_id so I guess it was choosing beta.

But because it was doing that, I thought I had to specify a flavor, so I went to xcode and duplicated my "Runner" (prod) scheme so there was a matching "prod" scheme. Then I updated the shorebird command to include --flavor prod:

sh '(cd ../../ && shorebird release ios --flavor prod --no-codesign --verbose)'

That worked, as shorebird now placed the release in prod track, but then I think when xcode went to build the release it built it using the regular Runner scheme (as per the fastlane config above). I'm not quite clear how it still associated itself with the beta shorebird app id though.

So I think the fix is just to go back to running with no flavor/scheme and switch shorebird default app_id to prod so it uses that. Will try later today.

As for the patch command, I ran:

shorebird patch ios --flavor prod --verbose

But I'm guessing I can run without flavor parameter and as long as I update shorebird.yaml to prod as the default it should place it into the prod track again.

[adamkoch]

Ok confirmed, all working as expected now.

• removed my new "prod" scheme and left it to use the existing default "Runner" scheme as the prod one
• ran all shorebird commands without flavor
• updated shorebird.yaml so the default/top-level app_id was the prod track one

Will close this issue.

One suggestion - is when running shorebird init, have a way to choose which track is associated with your flavorless build. Or at least saying which one was chosen and that you can update it yourself in the yaml.

Thanks!