Are IonIcons bundled assets?

I’ve changed an icon in MainTabNavigaor.js for ios but though it displays correctly in the Expo client it shows “?” in my App Store version. Do I need to deploy a new binary or are there icons in the SDK libs that can be referenced without deploying a new version?

TIA

Dan

Hi @buxtonfringe, could you let me know what SDK version your app is on?

Locally I’ve upgraded to SDK 32 and the ios standalone build has been built and deployed at that version (though before the change of ionicon). The android standalone binary in the Play Store was built against SDK 29 though.

Not sure if it is relevant but I’ve now realised that other js changes don’t seem to have made it through the OTA update route either.

For background a separate organisation (using our buxtonfringe credentials and git source) has done the ios standalone build using their Apple ID and I am then running an expo-cli publish after changing the .js code in my copy of the project. As per App id with identifier <app_identifier> is not available. Please enter a different string. we are now using a bundleIdentifier on ios that is different to the android package id after your previous guidance - and that has allowed us to get a binary successfully submitted to the Apple Store which is great!

Thanks,

Dan

I’ve had a quick look at the cloudfront.net .js file pointed at by the bundleUrl property and it doesn’t have the latest version of .js files that I have published.

https://d1wp6m56sqw74a.cloudfront.net/%40buxtonfringe%2Fbuxtonfringe%2F1.0.3%2Fb48da4c5eceb219bad27da7b36cc0277-29.0.0-android.js

Might that be the problem or would you expect that?

Dan

Hm, that’s weird. Although I’m wondering why the icon would’ve changed to a “?” (or changed at all, for that matter) if you’re still grabbing the old js…

On IOS it was originally showing a ? as I was incorrectly referencing a non-existent icon name on that platform. It’s the attempt to change it to one that does exist that hasn’t worked.

It works from the expo client on IOS @buxtonfringe/buxtonfringe but not from the Apple Store version.

So I think the problem is down to the standalone version not picking up the latest js bundle.

Dan

This is still a problem for me I’m afraid - is there anything that might stop the OTA update picking up the latest published js files?

TIA

Dan

As far as I know, no. Could you take a look at your publish history for me? Let me know if there are any inconsistencies

It looks OK. For example on the android side I see the changes I’m expecting when following the s3Url for the latest publish but it is for the later sdkVersion (32) and version (1.0.4) than the Play Store version (29 and 1.0.3). Did we establish whether this might prevent the latest bundle being sent to the client?

Dan

Did we establish whether this might prevent the latest bundle being sent to the client?

What do you mean by “this”?

Edit: Rereading it, I think you mean is the SDK32 build preventing the SDK29 build from getting updates, and that depends. The updates request sends along a header with supported SDK versions, so if the binary doesn’t support that SDK it won’t fetch those updates. (So for example, let’s say the update you’re sending is SDK32, then the SDK29 binary wouldn’t use that update)

Yes that’s what I meant. Apologies for the confusion. So it looks like that explains why the android apps are not picking up the latest js changes - I’ll build a new version against SDK 32 and get it to the Play Store.

However that still leaves us with a problem on the ios version - which was built against SDK32 and where the s3Url shows that it should now be using an ‘ios-heart’ icon on ios but it shows up as “?”…

tabBarIcon: ({focused}) => (
    <TabBarIcon
      focused={focused}
      name={Platform.OS === 'ios' ? 'ios-heart' : 'md-heart'}
    />
  ),

Any suggestions on this problem?

TIA

Dan

Not sure, I tested this situation on my end and successfully changed to a heart icon after publishing

You could try to configure a manual update?

A new standalone build with SDK32 put to the Play Store has sorted out things on the Android side so thanks for that.

On the ios side a separate organisation (using our buxtonfringe credentials and git source) has done the expo build:ios using their Apple ID and I was hoping then that things would be set up on your servers so that I could also do an expo build:ios logged into the same account but it asks me “How would you like to upload your credentials?” so it looks as though I am not able to share their ios setup - is that correct?

Dan

With a different Apple ID, I don’t believe this is currently possible. Although, since all iOS build credentials are available through the Apple Developer Console, you could try to get those from the separate organization and select Upload my own credentials

But if they’ve added their Apple ID while logged in as buxtonfringe won’t I be using the same Apple ID without having to re-enter it in my local expo setup - so long as I’m also logged in as buxtonfringe?

Dan

Any action that can affect the Apple developer portal requires the user to pass credentials, every time. So you won’t be using the same Apple ID when you log in to your expo account on the CLI, you’d have to input it again

OK, I see. Thanks for the clarification.

I’ve just noticed that the Apple Store version is using a later version (1.0.5) than I am (1.0.4). Do these versions need to match for them to pick up the OTA bundle in my publish?

My app.json has…

    "sdkVersion": "32.0.0",
    "platforms": ["ios", "android"],
    "version": "1.0.4",

Dan

From the looks of https://docs.expo.io/versions/v32.0.0/distribution/advanced-release-channels/#what-version-of-the-app-will-my it is only sdkVersion and platform that determines which release is received.

Closer investigation of the manifest details in some of my Sentry events for ios shows…

id: @derbyportal/buxtonfringe,

I think this means that the ios version is using a different expo account (derbyportal rather than buxtonfringe) and if that is right it explains why my releases are not being picked up on ios!

Dan

1 Like

That would explain it!

I can only apologise for not realising this sooner - but good to have got to the bottom of it!

Dan

1 Like