Hello

I'm not convinced the linker warnings you get are the cause of the crash, though I may be mistaken. It rather looks like to me an incomplete Firebase configuration (missing plist for example).

Please update your builder to the latest version first.

Then, checklist:
- Is the GoogleService-Info.plist file present in your app and correctly filled ?
- Have you added the -ObjC linker flag as instructed by Google ?
- Does the Firebase SDK version you use match the one required by your Unity plugin ?

Also, have you read https://www.pmbaty.com/iosbuildenv/help/thread.php?path=Problem%20solving/&file=how-to-build-admob-google-mobile-ads-sdk-projects-without-cocoapods ?

Let me know if you need more help.

Sorry for the checklist, you did provide most of the information, there was a formatting problem with the page and I believe I read too fast.

The Firebase binary frameworks that you downloaded from Google are either statically or dynamically compiled ; you can't transform a statically compiled binary framework into a dynamically compiled one and vice versa without recompiling it from source, which is what you're trying to avoid.

Your Podfile indicates you need Firebase 8.3.0, so you need to download that one. But it also indicates that you need Google Mobile Ads SDK 8.2, which according to this table https://www.pmbaty.com/iosbuildenv/help/thread.php?path=Problem%20solving/&file=firebase-google-mobile-ads-admob-version-matching-table corresponds to ... Firebase 7.9. That's not the same major version number. Are you sure these two plugins are compatible ?

In my opinion, you should either upgrade your AdMob plugin so that it uses Firebase 8.x, or downgrade your Cloud Messaging plugin so that it uses Firebase 7.x.

Do you have the possibility to verify if this app works correctly when built with Xcode? That would confirm (or infirm) the diagnostic.

:: @Pierre-Marie Baty added on 01 Sep ’21 · 15:48

“you can't transform a statically compiled binary framework into a dynamically compiled one and vice versa”

Correcting myself, because the above phrase makes no sense when I read it to the letter: I meant "you can't transform a binary framework *compiled as a static library* into a binary framework *compiled as a dynamically-loadable one*". I hope it's more clear.

It hints to say that the official AdMob Unity plugin for iOS hasn't been updated in a loooong while...

Ignore the message that invites you to download a newer version. The first thing to do is to make it work with the exact version numbers specified. Does it run when you configure Firebase ?

OK. Let me know when you're ready to give this a try again.

I see you're on a rush, yet solving problems requires method, so make sure you have enough time to proceed calmly so as to follow my guidelines and report back and there's no reason it can't be sorted out.

Interesting. I wonder if a project built with Xcode using the same precompiled frameworks exhibits the same behavior. If it's the case, it would mean something is broken in Google's binary releases of Firebase.

If anyone else is having the same problem, that's something to try. If it works with Xcode (using the Firebase precompiled frameworks, i.e. not CocoaPods) and not with the builder it'd mean I have something to fix. If it doesn't, then I guess a problem report should be sent to the Firebase repository managers.

Please provide the necessary information as requested in the "problem solving" forum welcome text.

I assume your GoogleService-Info.plist is correctly filled.

Are there other messages ? Can you post the logs on Pastebin ?

In these logs I see

%
Jan 19 13:14:00.831 RemoteConsole <stderr>: 2022-01-19 13:14:01.094 NotificationsTest1[385:17957] ERROR: Unable to configure Firebase app (+[FIRInstanceIDCheckinPreferences preferencesFromKeychainContents:]: unrecognized selector sent to class 0x106652190)
%

Such unrecognized selector errors mean that some Objective-C classes are missing from the binary, possibly stripped by the linker, which most often imply that these binaries were built without the -ObjC linker flag.

Are you sure you added that flag to the right target ?

That's correct. Well, it's possible that these Firebase binaries were built by Google without that -ObjC flag then. At the moment I see no other explanation.

Another user seems to be having problems with AdMob and CocoaPods right now and we're on it: https://www.pmbaty.com/iosbuildenv/help/thread.php?path=Problem%20solving/&file=app-crashes-at-startup-when-using-admob

It might be related.

:: @Pierre-Marie Baty added on 19 Jan ’22 · 17:45

*edit* To answer your question, yes, that's what I understood. But that was his case. Things might be different for you (builder version, iOS SDK version, Firebase version...)

The reason of the crash has to be given in the iOS system logs. Can you catch them with the remote debug console and a USB cable and post them on PasteBin ?

OK. It's quite clear. The process ID (PID) that crashed is 627, and its crash spawned a CrashReporter process at pid 628. When you highlight "627" in these logs you see what happens. The first error is here:

%
Jan 20 12:41:32.624 Bilals-iPhone-X SpringBoard(FrontBoard)[58]<Notice>: [application<com.EugeneGames.NotificationsTest>:627] Bootstrap success!

Jan 20 12:41:32.625 Bilals-iPhone-X runningboardd(Security)[29]<Notice>: Failed to get cs_flags, error=3

Jan 20 12:41:32.625 Bilals-iPhone-X SpringBoard(BaseBoard)[58]<Error>: Unable to get short BSD proc info for 627: No such process
%

It looks like a code signature format problem ("failed to get cs_flags"). I'd like to have a closer look at this project. Could you please send it to me so that I reproduce the problem ?

:: @Pierre-Marie Baty added on 20 Jan ’22 · 13:30

Wait, I am wrong. It's not a code signature *format* problem, it's a code *signature* problem. See:

%
Jan 20 12:41:32.599 Bilals-iPhone-X amfid(Security)[212]<Notice>: Trust evaluate failure: [leaf IssuerCommonName LeafMarkerOid SubjectCommonName]

Jan 20 12:41:32.600 Bilals-iPhone-X backboardd[62]<Notice>: new deferring rules for pid:58: (
  "{<environment=system> -> <pid=58 token=279e24c0> : 1-deferDiscrete: systemGestures}",
   "{<environment=keyboardFocus display=builtin> -> <pid=58 token=279e24c0> : 3-deferDiscrete: Key Window event focus deferral}",
  "{<environment=keyboardFocus display=builtin> -> <pid=58 token=9751770c> : 356-deferDiscrete: Key Window event focus deferral}"
)

Jan 20 12:41:32.602 Bilals-iPhone-X backboardd[62]<Notice>: new resolutions for pid:58 {(
  <display=null environment=system pid=58 token=279e24c0>,
   <display=builtin environment=keyboardFocus pid=58 token=9751770c>,
  <display=builtin environment=cameraButton pid=58>
)}
%

"Trust evaluate failure" means something's wrong with your certificate or provisioning profile.

Here's what happens:

1. You tap the icon
2. iOS notices that you tapped the icon and looks up which app it is for, then asks the security system to launch it and return a new process ID
3. The security subsystem checks for the code signature of that app, and finds a problem with your certificate. It immediately exits instead of yielding a process ID
4. iOS doesn't get the new process ID, thus a cascade of other errors, which translate into a flashing black screen that bombs you back to the phone's icon board.

%
Jan 20 12:41:32.529 Bilals-iPhone-X SpringBoard(SpringBoardHome)[58]<Notice>: Icon tapped: <private>

Jan 20 12:41:32.545 Bilals-iPhone-X SpringBoard(SpringBoard)[58]<Notice>: Activating <private> from icon

Jan 20 12:41:32.545 Bilals-iPhone-X trustd[124]<Notice>: cert[0]: SubjectCommonName =(leaf)[]> 0

Jan 20 12:41:32.552 Bilals-iPhone-X trustd[124]<Notice>: cert[0]: LeafMarkerOid =(leaf)[force]> 0

Jan 20 12:41:32.552 Bilals-iPhone-X trustd[124]<Notice>: cert[0]: IssuerCommonName =(path)[]> 0

Jan 20 12:41:32.555 Bilals-iPhone-X SpringBoard(Security)[58]<Notice>: Trust evaluate failure: [leaf IssuerCommonName LeafMarkerOid SubjectCommonName]
%

I advise you to check your signing certificate ; it's likely either revoked or expired.

Of course. The provisioning profile contains the app's entitlements (i.e. "Application Services" or "Capabilities"). The Google instructions tell you to add the "Push Notifications" capability to your provisioning profile. If you don't do that, the app won't launch.

:: @Pierre-Marie Baty added on 20 Jan ’22 · 14:48

Reminder: "Application services" / "Capabilities" / "Entitlements" (all three are more or less synonyms) are, technically, a list of properties (either in XML .plist format or in DER-encoded format) that are "stamped" in your app's binary at code signature time, covered with your certificate and signed with your private key. These capabilities become a read-only and non-modifiable list of authorizations that the app can claim after iOS.

If your app claims to be entitled to use Push Notifications, iOS will say: "okay, let me verify that you're indeed allowed to have that one" and look into its collection of provisioning profiles for the one that matches your app's bundle ID. When it finds it, it checks whether this authorization is present. If the provisioning profile (generated by Apple, remember) says "this app is allowed to have Push Notifications", it matches what the app claims, and iOS agrees. If there's a discrepancy, the app is killed even before it's started. That's how it works.

I think you're confusing a lot of things related to code signing.

You did need to create a special *provisioning profile* in which the push notifications were listed as enabled for your app. During the creation of this provisioning profile you enlisted your code signing certificate, but that's typically the same code signing certificate as before. It's just that it's enlisted in a different profile. And yes, you need to sign your app using *that* profile.

Apps are signed with *one* certificate. The only case when you need a second one is when your app has an app extension (that is, a companion binary that runs in the background in iOS). This is not your case here.

The certificates you enlist in a provisioning profile are just the list of signing identities that are allowed to use that profile. For example, most people (including myself) enlist two certificates in each profile they create each time they can: their *development* certificate and their *production* certificate. That makes two certificates in one provisioning profile.

I invite you to read the parts of the documentation again that deal with certificates and profiles, slowly. But clearly, if you're doing things in a hurry, you should stick to the main road (i.e. Xcode) and come back to this alternate way of doing things when you have enough time to wrap your head around it without trying things that you only half understand (no offense intended but that's the feeling that I have).

Are you referring to this documentation ?

https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/establishing_a_certificate-based_connection_to_apns

Or if not, which one ?

:: @Pierre-Marie Baty added on 20 Jan ’22 · 17:11

I think I understand your misunderstanding. SSL certificates != code signing certificates.

Certificates can be used for a lot of things, and their usage (or more technically their usage restriction) is usually indicated by an object ID (OID) in them. OIDs are a series of numbers that have a universally-accepted meaning. For example, the OID for code signing Apple apps is "1.2.840.113635.100.6.1.13" (see http://oid-info.com/get/1.2.840.113635.100.6.1.13 ). Certificates that have this OID can be used for code signing.

"SSL certificates" are certificates whose purpose is to be used to secure network connections using the SSL (Secure Sockets Layer) technology, which is the technology used by HTTPS for example (the S stands for SSL). That is why the https websites you visit have a certificate. Such certificates don't have the Apple code signing OID, you can't use them for code signing your app. You need to install them on the server you want your app to connect to.

Does it begin to make sense ?

:: @Pierre-Marie Baty added on 20 Jan ’22 · 17:25

Erratum (though it's not really relevant to the explanation): the OID for generic code signing is actually 1.3.6.1.5.5.7.3.3, but Apple uses additional 1.2.840.113635.100.6.1.x OIDs in their certificates to specify which context (development, production, ad hoc, etc).

See the addition to my reply above. Also, take the time to read this without hurry (from your link):

“a Client SSL Certificate that allows your notification server to connect to the Apple Push Notification Service is required.”

To underline: the purpose of this SSL certificate is to "allow your notification server to connect to the Apple Push Notification Service". For your Push Notifications to work, you need a push notification server infrastructure. Do you have one ? If so, you need to install this SSL client certificate in it so that it is allowed to connect the Apple Push Notifications master server.

:: @Pierre-Marie Baty added on 20 Jan ’22 · 17:30

In a nutshell: this extra SSL certificate takes no part in code signing, and doesn't even need to appear anywhere in your app. It needs to be copied to your push notification server so that your server initiates its SSL connection to the Apple Push Notification server with it.

Hello

Well, I understand your state of mind. But I'd like to reproduce the problem because there are things that I need to understand better.

Once you got your working build on Windows, have you tried renaming your Pods directory to Pods.bak and letting the CocoaPods daemon re-create the Pods directory to confirm that building this way *still* doesn't work ? I'm asking this because very often, Pods are pushed on the official pods repository that are actually broken, and get fixed sometime later with a version change that nobody notices - especially when the Podfile claims "I need the pod named xxxxx with version *equal or higher than* yyyyy". In this case CocoaPods simply fetches the latest available, buggy or not.

Anyway, if you can send me your project (the one that builds), and I can reproduce the situation you describe, that is:
- that letting the CocoaPods daemon recreate the Pods directory ends up in a non-working build,
- that using the Pods directory that you'll send me instead ends up in a working build,
then I'll agree your refund request, and foremost on my side I'll be able to work out the difference that causes this behaviour, and fix it.

If you use CocoaPods, that's just the way it works.

Unity creates a fresh Xcode project with a Podfile. CocoaPods downloads the source code of every package listed in that Podfile and builds them all in order. Then once each and every CocoaPods dependency is built, your app itself is finally built and linked against the compiled dependencies.

It would behave likewise on your Mac. It is obvious that such a method of managing dependencies is suboptimal, but I can't change the way CocoaPods works unfortunately.

To speed up the build, one can usually gather the compiled libraries and frameworks from the build directory and carefully save them aside, and then inject them in the build process using the linker flags, skipping CocoaPods completely. It's not exactly an user-friendly task because you have to use a different linker flag if what you're injecting is a static or a dynamic library or framework, or if it's a precompiled binary in which case you need to treat it differently. When everything is done correctly, you can get truly tremendeous build speeds because only your project is rebuilt each time, and all the dependencies are reused. Please refer to the documentation to learn how to do that.

You’re welcome.