Forge Component
(18)
Published on 4 Nov by David Sousa
18 votes
Published on 4 Nov by David Sousa

We have our app equipped to use Firebase Mobile with the google-services.zip files in place for lower order environments and the production environment. Everything appears to work - the app builds, we are able to receive notifications (with custom notification icons, I might add) and we are gathering analytics. This is working for both configurations (dev and prod). When we try to upload the iOS app into the app store to start testing, however, we are getting the following error messages:

This bundle is invalid - The Info.plist file for /Payload/Forever Us.app/www/firebase.com.foreverus.app is missing or could not be read.

Invalid Bundle - The bundle at '/Payload/Forever Us.app/www/firebase.com.foreverus.app' does not contain a bundle executable.

Has anyone experienced this before? I have confirmed the zip file contains our .json and .plist files as expected. We are also using the technique found at https://www.outsystems.com/forums/discussion/23123/add-drawable-icons-to-mobile-application/#Post90866 to add custom icons to the notifications. The app still doesn't publish when we try to deploy without the dummy-plugin referenced in that post.

Thanks in advance for any help that can be provided. 

Okay, so after a lot of work our team finally worked out that the issue is exactly as we expected - because the name of the app bundle id ends with .app, the app store automated code review system was detecting this folder as another app within the primary app (.ipa files are pretty much just a well-structured zip file). Since this folder did not have all the required files to be a well-formed app, iTunes was rejecting the entirety of the app. 

We could not afford the delay of service to change the bundle id of our app, so we went ahead and adapted the plugin to use zip files in the root of the app payload instead of deployed into a folder. The naming convention remains the same, but, for example, we just had a zip file called firebase.com.foreverus.app.google-services.zip in the root level of the app. 

This solved our issue temporarily, but for all people experiencing this issue in the future: DO NOT INCLUDE a folder in your app where the last part of the name is .app, otherwise you will not be able to get the app into the app store.

Grayson Udstrand wrote:

Okay, so after a lot of work our team finally worked out that the issue is exactly as we expected - because the name of the app bundle id ends with .app, the app store automated code review system was detecting this folder as another app within the primary app (.ipa files are pretty much just a well-structured zip file). Since this folder did not have all the required files to be a well-formed app, iTunes was rejecting the entirety of the app. 

We could not afford the delay of service to change the bundle id of our app, so we went ahead and adapted the plugin to use zip files in the root of the app payload instead of deployed into a folder. The naming convention remains the same, but, for example, we just had a zip file called firebase.com.foreverus.app.google-services.zip in the root level of the app. 

This solved our issue temporarily, but for all people experiencing this issue in the future: DO NOT INCLUDE a folder in your app where the last part of the name is .app, otherwise you will not be able to get the app into the app store.

Hi Grayson,

I am running into the same problem when trying to publish my apps in the Apple store.

Unfortunately changing the app identifier is not an option, so I am trying to fix it using your solution.

I am guessing you made a fork of the firebase plugin in which you did your changes. Is it possible to share this fork?

I am not really happy with this solution, but at the moment I don't see an alternative.

Hope to hear from you.

Best regards, Robert


Hi Robert and Grayson,


From what I understood the problem is the folder name ending in .app because of the appId.

The plugin has logic that looks for the correct configuration files based on the appId, so that multiple environments are supported.

A fix for this problem would be changing the way the configuration files are searched, by changing the folder name to something that doesn't end in .app.

If that solves the issue I'll gladly update the plugin.

Best regards,

David

David Sousa wrote:

Hi Robert and Grayson,


From what I understood the problem is the folder name ending in .app because of the appId.

The plugin has logic that looks for the correct configuration files based on the appId, so that multiple environments are supported.

A fix for this problem would be changing the way the configuration files are searched, by changing the folder name to something that doesn't end in .app.

If that solves the issue I'll gladly update the plugin.

Best regards,

David


Hi David,


I did not receive an answer from Grayson yet. 

But what he describes is exactly the problem that we run into, when deploying to the iOS store.


So if you could update the plugin the way you described then this would solve our problem, and I don't have to make a fork of the plugin which makes me very happy.

Can you tell me how long it will take you to have this solution available? At the moment we are not able to deploy our apps to the iOS store, so I hope it won't take too long :-(


Hope to hear from you soon.

Best regards,

Robert

Solution

Hey Robert,

The latest plugin version (1.0.6) allows a new way of setting up the configuration files.

It still uses a folder for each environment but instead of calling the folder firebase. + appId, you can now also call it appId + .firebase.

The plugin documentation was also updated in order to reflect the changes.

Note that the previous way of setting the configuration files still works, in order to ensure backwards compatibility.

Cheers,

David

Solution

David Sousa wrote:

Hey Robert,

The latest plugin version (1.0.6) allows a new way of setting up the configuration files.

It still uses a folder for each environment but instead of calling the folder firebase. + appId, you can now also call it appId + .firebase.

The plugin documentation was also updated in order to reflect the changes.

Note that the previous way of setting the configuration files still works, in order to ensure backwards compatibility.

Cheers,

David

Thanks David for the quick solution. I will get the new version and implement it in my app!


Hey, sorry for the delay in response. I see David already got a solution out, but in case you were curious here is the fork:

https://github.com/GraysonThrivent/cordova-plugin-firebase

Grayson Udstrand wrote:

Hey, sorry for the delay in response. I see David already got a solution out, but in case you were curious here is the fork:

https://github.com/GraysonThrivent/cordova-plugin-firebase

That being said, I need to remove my implementation because I am in the process of leaving my company. I will see if there's a way to leave it up, but I think everyone should use the supported version. 


Okay if anyone really still needs my workaround because they don't want to use the official solution, here it is:

https://github.com/FathersNelsons/cordova-plugin-firebase