Embedded manifest vs. updates when creating multiple builds without updating the runtime version

[miguelbeafertility]

My setup:

• Managed workflow
• eas-cli/0.54.1
• I’ve tested this scenario with a test app and I can’t find documentation supporting it

Hi,

I’ve been doing a test spike to assemble development and production setups for my new startup and came across a situation I’d need some clarification on.

I believe the easiest way to explain it is if I describe the steps and then finish with some questions.

Assumptions:

• I am running eas build and eas udpate for a profile called staging which has the property channel with value staging as well
• I am NOT updating the runtime version between builds

Build 1:

• I run eas build --profile staging
• On the EAS dashboard I’ll see a deployment with channel staging pointing at branch staging
• Branch staging has no updates yet
• Once I install this build on my phone all works as expected, the manifest that’s running on my device is the one embedded as there’s no update
• I open the app and see a blank screen

Update 1:

• I add a Text component to the intro screen saying hello world
• I run eas update --branch staging --message "foo"
• On the EAS dashboard I’ll now see that the branch staging has an update
• Once I close and open the app installed on my phone I see the same blank screen but with the words hello world

Build 2:

• I remove the Text component from the intro screen
• I run eas build --profile staging
• On the EAS dashboard I see that the staging deployment as a newer build but I still see that it points to the Update 1 with message foo
• When I install this build 2 it won’t download the update
• I open the app and see a blank screen

---

I’m not saying this is not desirable behaviour. I’d say that if the manifest that’s embedded in the build is more recent than the last update that’s the one that should be picked up.

However on the dashboard and by looking at the relationship between the channel and the branch it’s confusing because I don’t know if my latest build will use the embedded manifest or if it will pick-up the latest update.

You can see this on the screenshot below:

• Even though it looks like my latest build is using the update Updating the app test 4 in reality it doesn’t seem to be as it’s showing me the embedded manifest

Would anyone with some experience be able to share their thoughts? Anyone came accross this?

Thanks in advance,
Miguel

[jonsamp]

Hi Miguel,

Thanks for your thorough explanation and questions. I designed and built a lot of the UI you’re referring to, so I probably have the most context.

Everything you described is working as we intended it, and your assumption of “I’d say that if the manifest that’s embedded in the build is more recent than the last update that’s the one that should be picked up” is indeed what is happening. Since the build’s embedded update is more recent than the most recent update, it will not update to an older published update. Instead, it runs its embedded update.

It’s also true that the UI is not clear here and is, in fact, confusing. This is great feedback! I assumed that when making new builds, developers would be moving forward with changes, and not rolling back features, then making a new build.

If you have ideas on what you’d prefer to see/what would make sense to you, let me know. I’ll also work on how to represent this state so that it is clearer.

Finally, if you have other feedback, please let me know,

Jon

[mikearagao]

Hi Jon,

This is Miguel, although I’m now using my developer account to keep the admin one for admin purposes.

I must confess I wasn’t sure anyone would still get back in touch, so I’m quite happy with your message.

Yes, I agree, I’d expect the vast majority of updates to move forward, and with new builds, we’d only have new updates. I’m playing a bit of devil’s advocate here so that I get a good understanding of version control as I’m making infrastructure decisions from scratch in our company - we’re building a new product completely.

I can see you’ve already updated the UI, it’s much clearer now, and it clearly states that a new build relies on the embedded application layer - which is good reassurance for newbies like me. My only other suggestion would be to somehow represent the embedded layers as updates - although that could create some confusion too.

A general comment from me, and with the perfect notion that I’m just one person with one opinion, I’d probably vouch to have more of a concept of application version layer instead of updates. Regardless of being an application layer that’s embedded or one generated by an update we’d abstract and just see them stacked up. I’m sure this will have a lot of implications, but just sharing for the sake of giving some more personalised feedback.

Another thing that I find personally confusing is the concept of branches, as much as I understand the motivation to call them branches, they don’t really behave like branches, I think someone that’s used to git might have a bit of tough time figuring it out - like it happened to me.

---

I did abstain from adding more complexity to my first post, but I did notice something else that’s quite confusing from my perspective. The dates that we see in terms of last updated at, update dates, and so on don’t seem to match. I thought initially it could be a timezone issue, but the minutes don’t match at all. I have a few screenshots of the timestamps we see on different screens for the exact same resources.

My expectation would be that those 3 timestamps in a circle would have the same value. It would be great to understand if that’s just a bug or actually they’re not supposed to be the same.

Thanks for coming back to me once again.

Miguel