#Patch not applying on Mac

1 messages · Page 1 of 1 (latest)

odd wind
#

I've been trying to get my Mac app working with updates and nothing seems to work. I've built releases and patches. I have the release version in my Applications folder and it always says the same version. The Console logs says:"[shorebird] Patch 1 is already installed, skipping."

mortal oriole
#

How are you running the app? Are you using shorebird preview?

#

Also you should make sure you're using the latest version of shorebird (via shorebird upgrade and try shorebird cache clear to clear any potentially cached, stale previews.

short zealot
#

Hi other Kevin Moore! 👋

#

We’d love to help. We probably need to see logs to do so. Shorebird preview will show logs while it’s running the app.

odd wind
#

So, I have the latest shorebird (I did have to reinstall as a command I ran corrupted the installation). I'm using shorebird release and using that build. I see the patches/releases on the console

mortal oriole
#

Can you try with “shorebird preview”?

odd wind
#

Sure. What does that do?

#

Just tried. Seems to work. Version is correct

#

Now when I run my app from the Applications directory I seem to get some better logs. However, the version is still not getting updated (I have a dialog that shows the current version)

#

(I restarted the app)

#

Patch 1 successfully downloaded. It will be launched when the app next restarts.

#

The patch request check returns an old version

short zealot
#

Ah, so Shorebird doesn't (can't) change the version number. We just apply patches to versions. You can pull the patch number from Shorebird's updater with package:shorebird_code_push if you'd like to display it.

#

But say you release 1.0.0, then you would patch 1.0.0 as well, just it would be 1.0.0 patch 1, 1.0.0 patch 2, etc., but only shorebird itself knows about those patch numbers, sthe OS does not. So you have to ask the updater package what patch it thinks is installed if you need to know.

#

is the API to read the currently active patch

#

Patch not applying on Mac

odd wind
#

So, part of my patch is to update the version number so I know if the app has been updated. Looking at the logs from Console, seems to indicate that it is finding an older version. The Shorebird console has the latest version and the preview command shows the latest version

short zealot
#

Is the version number encoded in Dart or via the Info.plist?

#

if it's just a value in Dart, that we can patch. if it's in the info.plist we can't patch it.

#

And changing the info.plist value will cause the patch to think it's targeting a differnet release than you intend I think

#

The info.plist version number is one of the ways we identify which app we're patching.

#

version_number + app_id + os + arch is the tupple used to look up a "release"

#

the version_number is read from the app via OS apis (on mac it's part of the Info.plist)

odd wind
#

I use the package_info_plus package that I believe uses the version from pubspec.yaml

#

That is the version I'm updating.

short zealot
#

I think the short answer is Shorebird isn't designed to update the OS/Store "version number" of the app. Since when one is tryhing to patch 1.0.0 with 1.0.1's code, you don't actually end up with a full copy of 1.0.1, only the Dart bits. So insetad we say that's 1.0.0 patch 1. You're welcome to display it however you like, but Shorebird isn't intended dto be able to change the "1.0.0" part (at least as the OS thinks about it).

odd wind
#

So what do you think about the console logs that says it's finding an older version of the app vs the preview command that finds the latest

short zealot
short zealot
odd wind
#

Not sure if you want me to post the logs here

short zealot
#

that's up to you. Although we're happy to recieve logs at [email protected] if you'd prefer them private

odd wind
short zealot
#

app_ids aren't sensistive, fwiw, but thanks!

#

So reading through that. This line suggests there was previously a later version installed, and now it's downgrading: ```
default 07:56:27.187220-0700 Memory Note Organizer [shorebird] release_version changed 1.0.6+7 -> 1.0.5+6, creating new state

odd wind
#

Why would it downgrade? I don't want that

short zealot
#

I suspect you just launched version 1.0.6+7 at one point and then later launched 1.0.5+6 on your dev machine.

#

So after that it then successfully gets a patch (for 1.0.5+6) from our servers: ```
default 07:56:27.276722-0700 Memory Note Organizer [shorebird] Sending patch check request: PatchCheckRequest { app_id: "", channel: "stable", release_version: "1.0.5+6", platform: "macos", arch: "aarch64" }
default 07:56:27.304657-0700 Memory Note Organizer [shorebird] Patch check response: PatchCheckResponse { patch_available: true, patch: Some(Patch { number: 1, hash: "6960c34047b556b56b7d5b822cb749fcc792775e723e44e8619b2945bc6a0594", download_url: "https://cdn.shorebird.cloud/api/v1/patches//macos/aarch64/228795/dlc.vmcode", hash_signature: None }), rolled_back_patch_numbers: Some([]) }
default 07:56:27.304826-0700 Memory Note Organizer [shorebird] Downloading patch from: https://cdn.shorebird.cloud/api/v1/patches//macos/aarch64/228795/dlc.vmcode

#

And then it successfully boots from it.

odd wind
#

That makes no sense. I'm at 1.0.5+6 and I want to go to 1.0.6+7

#

I built a release app at 1.0.5+6

short zealot
#

That's not a thing Shorebird can do. The version number is outside of our control.

#

We can't change the package on disk (including the info.plist) only the Dart code.

#

For us the version number is like the bundle id. It's a thing the system/store controls (and uses) and we just read but can't edit. A patch is made to target a specific release (e.g. patch 1 for version 1.0.1+2), but that patch can't change the underlying number of that release.

odd wind
#

So, what is a good way to verify that we've updated to the latest version?

short zealot
#

You can tell shorebird patch to ignore what the Info.plist currently says (say if you're trying to send newer code to an older release), with shorebird patch release mac --version-number=1.0.2+3, that will tell it to ignore whatever info.plist says on disk currently, and target building the current on-disk code for some specific target relase version. If you don't specify --version-number when patching, it will read the version number out of the on-disk info.plist and assume you're trying to target patching that version.

short zealot
#

That includes a patch number.

#

And we should write a simple example of that.

odd wind
#

Oh, I think I might see the issue. On the pach command, the version number is for the current version you want to patch and not what the version is now

short zealot
#

correct

odd wind
#

Ahh. That's what I'm doing wrong

short zealot
#

it's telling the system "go pull down release X.Y.Z and maek a patch for it"

#

Rather than "I want to call this patch X.Y.Z"

#

version numbers are a "release" concept, patches just target a version number, they don't get to bring their own.

mortal oriole
short zealot
#

Basically all you want is ShorebirdUpdater().readCurrentPatch().then((currentPatch) {print(currentPatch.number);});

#

I typed that by hand just now so might have added/removed a ;, but hopefuly the idea is clear

odd wind
#

[shorebird] Update failed: This app reports version 1.0.5+6, but the binary is different from the version 1.0.5+6 that was submitted to Shorebird.

short zealot
#

How the 1.0.5+6 come to be on this machine? via the store?

odd wind
#

I copied it from the build directory from shorebird release

short zealot
#

Huh, that's unexpected.

#

Did you ever delete any releases on Shorebird's servers by chance?

odd wind
#

No

short zealot
#

Did you attempt to make 1.0.5+6 multiple times by chance?

odd wind
#

Not sure. I've been trying to verify updates for awhile. I usually update the pubspec.yaml version number for each release

short zealot
#

(obviously with your app_id and release id)

#

I'm sorry this has been so much trouble 🙁

#

@sage delta and I may have some updates to make to the docs

odd wind
#

I was thinking about a steps doc with simple instructions on how to release an app and how to update it

short zealot
odd wind
#

If I want to test this, would I: 1. Do a shorebird release. 2. Copy that app to the applications folder. 3. Update my code. 4. Create a patch for that release. 5. Restart my Mac app

short zealot
#

Yeah, that all sounds reasonable. shorebird preview is supposed to automate some of this for you.

mortal oriole
#

I recommend shorebird release, shorebird preview, right click and keep app in dock, update code, shorebird patch, restart app.

odd wind
#

When you do a shorebird preview, does it use the app from the build directory or does it copy it to the applications directory?

#

I've been also trying to test this by copying my app to another computer. I make sure I copy the shorebird built version

mortal oriole
#

It uses the app you released to shorebird’s servers

#

It doesn’t rely on any local state

#

(To ensure you are always using the correct artifact)

sage delta
#

Sorry, just catching up now. If you're running from the build directory, it's possible you're actually running the build that was created when patching (shorebird patch uses flutter build under the hood)

#

So if you want to test the flow locally using the .app from the build folder, you'll want to move/rename it before running the patch command

sage delta