Advanced Input Channel

Implements a custom FreeRDP channel to circumvent limitations of [MS-RDPBCGR] mouse events (allow sending relative position updates, more than 5 buttons, ...)
Refactor clients to move generic channel code to client/common
Automatically load the custom channel by all clients and use it, if the server supports it.
Sample implementation in sample server.  I am not allowed to add review comments to codelines (anymore). Not sure why.
So I have to add comments this way:
Just a note: Wasn't able to (fully) implement the server side yet. Some things should be addressed for this:

The AInputEventFlags enum should be moved from  include/freerdp/client/ainput.h to  include/freerdp/channels/ainput.h, so that the server side can use these values too.
The AINPUT_FLAGS_MOVE enum value is currently unused. It should be used for absolute and relative pointer events.
The AInputEventFlags doesn't expose an enum value for PTR_FLAGS_WHEEL_NEGATIVE + Could we use for wheel events the same behaviour like BCGR defines it for the fastpath and slowpath (two's complement)?
This would preserve the behaviour regarding high resolution mouse wheels (and I can also copy-paste the code from the fastpath handling :P)
In  client/common/client.c:

if (mflags & PTR_FLAGS_BUTTON2)
    flags |= AINPUT_FLAGS_BUTTON3;

should be if (mflags & PTR_FLAGS_BUTTON3) in the condition

1. The `AInputEventFlags` enum should be moved from ` include/freerdp/client/ainput.h` to ` include/freerdp/channels/ainput.h`, so that the server side can use these values too.

Ok, will do.

2. The `AINPUT_FLAGS_MOVE` enum value is currently unused. It should be used for absolute and relative pointer events.

True.

3. The `AInputEventFlags` doesn't expose an enum value for `PTR_FLAGS_WHEEL_NEGATIVE` + Could we use for wheel events the same behaviour like BCGR defines it for the fastpath and slowpath (two's complement)?

This flag is not necessary. With this API we can just send the wheel values as signed integer as x or y (depending on which wheel triggered)

   This would preserve the behaviour regarding high resolution mouse wheels (and I can also copy-paste the code from the fastpath handling :P)

4. In ` client/common/client.c`:

if (mflags & PTR_FLAGS_BUTTON2)
    flags |= AINPUT_FLAGS_BUTTON3;

good catch

@pnowack yes, the value conversion issue will stay the same we already had, but we can at least work with a ready to use integer instead of masking out data from the flags. (the value range did not change, just the representation as integer instead of part of a bitmask)

yes, the value conversion issue will stay the same we already had, but we can at least work with a ready to use integer instead of masking out data from the flags. (the value range did not change, just the representation as integer instead of part of a bitmask)

In such case, the conversion from using the two's complement needs to happen in freerdp_client_send_wheel_event, as the feeded flags use the two's complement, i.e. something like this would need to happen: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/blob/9d138b47e9cc62bcf7a54863a0db9823560511ed/src/grd-session-rdp.c#L1305
As otherwise scrolling in the opposite direction would have a different absolute value.

@akallabeth Status report: I have a working branch with g-r-d: https://gitlab.gnome.org/pnowack/gnome-remote-desktop/-/commits/disp-advanced-input
The important part: Relative mouse input works! And that really well.
Some issues that I found (haven't investigated all of them yet):

xfreerdp also forwards the input (at least with relative mouse input), even when it is not focused (xfreerdp can here even be on a different workspace).
Haven't completed checked yet, but: It seems that input now only works with the advanced input channel. If the channel is not opened, no mouse input is forwarded.
Wheel events don't work (yet). Not sure yet, where the problem is. Vertical scroll events don't work at all. Horizontal scroll events only very slow.
Not sure yet, where the issue is. My wheel handling looks currently like this: https://gitlab.gnome.org/pnowack/gnome-remote-desktop/-/commit/c3a869c7bf12319d2dae3ef53de076da0c1f22c3#9f219500e83b691da346f692aa73b8bb5ab03761_0_99

@akallabeth Status report: I have a working branch with g-r-d: https://gitlab.gnome.org/pnowack/gnome-remote-desktop/-/commits/disp-advanced-input
The important part: Relative mouse input works! And that really well.

great! Fixed some fallback handling issues with the latest commits.

Some issues that I found (haven't investigated all of them yet):
* xfreerdp also forwards the input (at least with relative mouse input), even when it is not focused (xfreerdp can here even be on a different workspace).

Does this always happen or only if the mouse is still grabbed?

* Haven't completed checked yet, but: It seems that input now only works with the advanced input channel. If the channel is not opened, no mouse input is forwarded.

Tested against a windows 10, no. The channel is only loaded if the server supports it, otherwise the default input method is used.
Of course, if the server opens the channel all input is sent over it.

Edit: Another thing (just tiny nit): For the other channels, the client side variant and the server side variant also include #include <freerdp/channels/CHANNEL_NAME.h>, the ainput channel does not do it yet. So, I think that #include <freerdp/channels/ainput.h> should be included in #include <freerdp/server/ainput.h> too

done, thx for the hint.

Does this always happen or only if the mouse is still grabbed?

Not sure. When it happened, it only happened with /mouse-relative. I just tried to reproduce it again (no rebuild) and this time I was not able to reproduce the issue. My cmdline is: xfreerdp3 /v:<ip> /network:auto /u:<user> /p:<pw> +async-input /size:1920x1080 /smart-sizing:1920x1080 /f /mouse-relative

Tested against a windows 10, no. The channel is only loaded if the server supports it, otherwise the default input method is used.
Of course, if the server opens the channel all input is sent over it.

It is the case though with gnome-remote-desktop. Just retested this. As soon as I revert the commits that open the channel, or all commits regarding the advanced input channel, no mouse input is possible any more with xfreerdp from master + this MR, while xfreerdp from stable-2.0 works.
Without reverting the advanced input channel commits, xfreerdp from master + this MR works fine again.
The RDP backend in weston might encounter the same situation, as its server backend is FreeRDP-based too (maybe @hardening can check that).

@pnowack ok, that is strange. I´ve added the channel to sfreerdp-server (the sample server) and there I can toggle the channel and the client will send via channel or default fastpath input.

@pnowack even weirder is that this might only happen, if OnChannelConnected is triggered with FreeRDP::Advanced::Input  although the server does not support the channel?

Does this always happen or only if the mouse is still grabbed?

Not sure. When it happened, it only happened with /mouse-relative. I just tried to reproduce it again (no rebuild) and this time I was not able to reproduce the issue. My cmdline is: xfreerdp3 /v: /network:auto /u: /p: +async-input /size:1920x1080 /smart-sizing:1920x1080 /f /mouse-relative

Ok, I know now why I could not reproduce the issue any more. While trying to reproduce the issue, I did not realize, that I hovered over wayland clients.
The issue obviously can only happen, when I hover XWayland client (or any client an X11 session).
Visual Studio Code is runs via XWayand, that is why I reproduced the issue with that client.

even weirder is that this might only happen, if OnChannelConnected is triggered with FreeRDP::Advanced::Input although the server does not support the channel?

Apparently, yet. I actually ran into this issue today at 2am (before writing my first comment here), because at that time I did not have an implementation for the Advanced input channel in g-r-d, and input events did not work, except for xfreerdp from the stable-2.0 branch.
So, somehow this is triggered, despite not being opened.
In case of the issue origin is not found. We could a "ready" PDU to the channel, which the server emits, when it supports the channel. This will workaround the issue, but not solve it. But it is one way to circumvent, in case the cause cannot be found.
With the last push to this MR, the scrolling values are now different for horizontal and vertical scrolling:
0, -120
0, -120
0, -120
0, 120
0, 120
0, 120
7864320, 0
7864320, 0
7864320, 0
7864320, 0
-7864320, 0
-7864320, 0
-7864320, 0

@pnowack ok, the server needs to open the channel or we will not have a OnChannelConnected event. If we do not have such an event we send input the old way.
If you have had such an issue this seems to be a problem with handling dynamic channels? I´d not want to add a workaround if we don´t have to ;)
As for the relative mouse stuff, added a window check so only events originating on the session window will update the mouse positions.
Mouse wheel, oops, conversion of raw value too late, fixed.

@pnowack also tested against freerdp-shadow, also not trying to use ainput channel...

If you have had such an issue this seems to be a problem with handling dynamic channels? I´d not want to add a workaround if we don´t have to ;)
also tested against freerdp-shadow, also not trying to use ainput channel...

Just retested. It works now perfectly fine, even when I build g-r-d without advance input support. Don't know why this was not the case in the older versions.

Mouse wheel, oops, conversion of raw value too late, fixed.

Yep, works fine now.

As for the relative mouse stuff, added a window check so only events originating on the session window will update the mouse positions.

Yep, that issue is now also solved.

Other thing: Can you make a define for the 0x10000 value? In g-r-d we use double for the scroll wheel, so I can use the value there.

Actually, something is wrong with the last push: Despite using /mouse-relative, the mouse input is not relative any more, it now always sends absolute mouse motion

@pnowack do you get log warn messages like Relative mouse input but channel %s not available, sending absolute!? Then you´re not using the channel.

do you get log warn messages like Relative mouse input but channel %s not available, sending absolute!?

No, I don't. I see [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel ainput on the client side. And with a debug message, I see that the input events come from via the channel.
The mouse pointer is moved, but AINPUT_FLAGS_REL is not set any more.
My cmdline is (still): xfreerdp3 /v:<ip> /network:auto /u:<user> /p:<pw> +async-input /size:1920x1080 /smart-sizing:1920x1080 /f /mouse-relative

@pnowack ok, got the issue. Now I can properly use the mouse in any mode (against sfreerdp-server):

Channel disabled -> use [MS-RDPBCGR] events
Channel enabled -> use it for all mouse events
Only use relative mouse move, if +mouse-relative +grab-mouse are set: XI_RawMotion et al only work on the root window, so we can not restrict the pointer to any window if the mouse is not grabbed.

@pnowack additionally, added WLOG_TRACE messages to dump channel events (client and server side), grep for com.freerdp.channels.ainput.client or com.freerdp.channels.ainput.server

@akallabeth Checked the last push, the issue is unfortunately still there, no relative mouse events are emitted (only absolute mouse motion) (/mouse-relative is used):
[com.freerdp.channels.ainput.client] - [ainput_send_input_event] sending flags=AINPUT_FLAGS_MOVE [0x00000004], 1393x342
[com.freerdp.channels.drdynvc.client] - write_data: ChannelId=2 size=18
[com.freerdp.client.x11] - xf_unlock_x11_:	[0] from xf_process_x_events
[com.freerdp.client.x11] - xf_lock_x11_:[1] from xf_process_x_events
[com.freerdp.client.x11] - xf_unlock_x11_:	[0] from xf_process_x_events
[com.freerdp.client.x11] - xf_lock_x11_:[1] from xf_process_x_events
[com.freerdp.client.x11] - xf_lock_x11_:[2] from xf_input_show_cursor
[com.freerdp.client.x11] - xf_unlock_x11_:	[1] from xf_input_show_cursor
[com.freerdp.client.x11] - xf_unlock_x11_:	[0] from xf_process_x_events
[com.freerdp.client.x11] - xf_lock_x11_:[1] from xf_process_x_events
[com.freerdp.client.x11] - xf_lock_x11_:[2] from xf_input_show_cursor
[com.freerdp.client.x11] - xf_unlock_x11_:	[1] from xf_input_show_cursor
[com.freerdp.channels.ainput.client] - [ainput_send_input_event] sending flags=AINPUT_FLAGS_MOVE [0x00000004], 1393x342
[com.freerdp.channels.drdynvc.client] - write_data: ChannelId=2 size=18
[com.freerdp.client.x11] - xf_unlock_x11_:	[0] from xf_process_x_events
[com.freerdp.client.x11] - xf_lock_x11_:[1] from xf_process_x_events
[com.freerdp.client.x11] - xf_unlock_x11_:	[0] from xf_process_x_events
[com.freerdp.client.x11] - xf_lock_x11_:[1] from xf_process_x_events
[com.freerdp.client.x11] - xf_lock_x11_:[2] from xf_input_show_cursor
[com.freerdp.client.x11] - xf_unlock_x11_:	[1] from xf_input_show_cursor
[com.freerdp.client.x11] - xf_unlock_x11_:	[0] from xf_process_x_events
[com.freerdp.client.x11] - xf_lock_x11_:[1] from xf_process_x_events
[com.freerdp.client.x11] - xf_lock_x11_:[2] from xf_input_show_cursor
[com.freerdp.client.x11] - xf_unlock_x11_:	[1] from xf_input_show_cursor
[com.freerdp.channels.ainput.client] - [ainput_send_input_event] sending flags=AINPUT_FLAGS_MOVE [0x00000004], 1392x342
[com.freerdp.channels.drdynvc.client] - write_data: ChannelId=2 size=18

I actually still have an older build of this branch, that I made before the fix of the mouse event capture, that happened, even when xfreerdp is not focused (or even on a different workspace), and relative mouse events work there (just with the bugs, that are fixed in the current version, but relative mouse motion work there fine).
In the old(er) build, sometimes both relative and absolute mouse events were emitted (things though worked fine on the server side) (the following are messages, where the server side, checks for the AINPUT_FLAGS_REL flag):
DEBUG: 10:52:59.007: relative_input: 1
DEBUG: 10:52:59.007: relative_input: 0
DEBUG: 10:52:59.007: relative_input: 1
DEBUG: 10:52:59.007: relative_input: 0
DEBUG: 10:52:59.007: relative_input: 1
DEBUG: 10:52:59.008: relative_input: 0
DEBUG: 10:52:59.009: relative_input: 1
DEBUG: 10:52:59.009: relative_input: 0
DEBUG: 10:52:59.010: relative_input: 1
DEBUG: 10:52:59.010: relative_input: 0
DEBUG: 10:52:59.011: relative_input: 1
DEBUG: 10:52:59.012: relative_input: 0
DEBUG: 10:52:59.012: relative_input: 1
DEBUG: 10:52:59.012: relative_input: 0
DEBUG: 10:52:59.013: relative_input: 1
DEBUG: 10:52:59.013: relative_input: 0
DEBUG: 10:52:59.014: relative_input: 1
DEBUG: 10:52:59.014: relative_input: 0

In the current version (since the first push, which fixed the event capture only capturing events, when xfreerdp is focused), AINPUT_FLAGS_REL isn't set any more.
I also tried the wayland variant this time (did disable it before, due to uwac version conflict), but also only absolute mouse motion events.

@pnowack maybe I did not mention that prominently enough, with the latest push relative mouse only works, if mouse grabbing is also enabled. Try +grab-mouse +mouse-relative

@pnowack as far as my tests have shown, XI_RawEvent are only emitted on the root window of a display, so I can´t properly limit that to only the xfreerdp window. Since this is too confusing of a behaviour, I´ve chosen to limit this to only be supported when the mouse is grabbed.

@akallabeth Still the same result. cmdline is now xfreerdp3 /v:<ip> /network:auto /u:<user> /p:<pw> +async-input /size:1920x1080 /smart-sizing:1920x1080 /f /mouse-relative +grab-mouse +mouse-relative, but no change.
Not sure if the behaviour is different with plain X11 sessions (I'm in a wayland session, xfreerdp runs via XWayland, but that does not stop mouse pointer grabbing).

@pnowack I´ve just tested again (using debian bullseye, gnome-wayland):

Start sfreerdp-server --port=3333 (check test_icon.ppm, server.key and server.crt are in the same folder)
Connect with xfreerdp /v:localhost:3333 +mouse-relative +grab-mouse /p:
Press i in xfreerdp to enable the ainput channel
See sfreerdp-server log with [14:47:02:778] [22411:22724] [WARN][com.freerdp.server.sample.ainput] - sf_peer_ainput_mouse_event not implemented: 0x00000014, -2x3

@hardening added the option for external thread, anything else to address?


[Discussion] Refuting stubbed methods?

First off before anything, thanks for this lovely gem! I've always been fairly frustrated with mocking libraries but this one does it really nicely.
This is more of a discussion starter than anything else, but what are your thoughts on including a Mocktail.verify_not or something similar? (Not using #refute since that would clash with Minitest::Assertions#refute.)
While it's true that we can easily accomplish this with something like:
assert_raises(Mocktail::VerificationError) do
  Mocktail.verify do
    # ...
  end
end

I just think it'd just be really nice if there was a method for this, kind of in the same Ruby spirit as Minitest having #assert and #refute, Rails having things like #second, #third, and so on.

I completely understand where you're coming from and I may consider this in the future, but after maintaining so many test double libraries in the past (and seeing how they're often abused in practice), I'm very wary of adding public API methods that will be very often used to do the wrong thing.
9 times out of 10, when I see a test that verifies that a call didn't happen, it's an example of over-specification, and not actually necessary (in this sense) for the test; rather, people tend to over-apply it in a way that would look silly if it were, say, refute'ing a dozen values that a method did not return. In general, a unit test shouldn't need to assert the infinite things that the subject under test did not do, but rather what it did.
As a result, I tend to be more explicit with this sort of thing when it does matter (syntactic vinegar, I suppose). The following should work, and it specifies the call that I expect not to happen very explicitly:
Mocktail.verify(times: 0) { dog.wag(:tail) }

Will fail if the double's wag method was called with exactly the symbol :tail.
Of course, when the arguments passed to the double are more dynamic (such as iterating over a loop or something or passed an interpolated string), you could use a matcher to loosen those arguments:
Mocktail.verify(times: 0) { |m| dog.wag(m.any) }

An equivalent thing you could do if the arguments are optional is to pass ignore_extra_args: true to verify().
Or, if you really want to specify that a method was absolutely not called, you could both ignore arity and all unspecified arguments with this very verbose assertion:
Mocktail.verify(times: 0, ignore_arity: true, ignore_extra_args: true) { dog.wag }

Of course, this is a bit verbose relative to the purpose of the test, but in practice of having written a lot of unit tests with mocks over the years, I haven't really found very many cases where it's necessary to verify a call did not occur and I had no control over the arguments that would have been passed.
A way to answer the same question is to use the Mocktail.explain method:
assert_equal 0, Mocktail.explain(dog).reference.calls { |c| c.method == :wag }.size

Though upon looking at the above, I think that Mocktail.explain(dog.method(:wag)) ought to work, and I was surprised it doesn't.

Ok, I've released<EMAIL_ADDRESS>which adds support for passing methods to Mocktail.explain

Great, thanks for the detailed response and links—all makes total sense. I can definitely see how refuting could be abused like you stated. Wasn't aware of the times arg you showed above, so I may try using that if I ever come across a situation where a refutation makes sense again.


Add GUI App (Dataflare)

Hi rqlite, I'm the developer of Dataflare and I noticed that there is nothing about GUI App in rqlite.io yet, so I would like to add Dataflare to rqlite.io.

This is a closed source App
This is a paid App

I'm not sure if this meets your requirements, if not, feel free to close this PR.
Thanks rqlite.

Thanks for your work, but I don't want to give the impression I'm promoting this paid software.

Actually, after thinking about this more, I'll find a way to add this to the rqlite.io website. I think there may be more 3rd party apps in the future, and page listing them would be useful.
Does Dataflare still support rqlite?

Yes, Dataflare supports rqlite. Although Dataflare is not yet perfect, we are continuously improving it.
For cautionary purposes, you can try using Dataflare to assess whether it meets the standards, thus avoiding any inconvenience for rqlite users.
Screenshot:

See https://rqlite.io/docs/api/ui/

Actually, I moved it up a level in the doc hierarchy.


Make Security Bypasses Configurable

Feature Request
At the moment, the existing AMSI and Script Block Logging bypasses are hardcoded in the stager if the generic SafeChecks is set. As a user, I want to decide which bypass to include in the stager generation.

PR merged, closing issue.


[Bug] Apple Silicon - DllNotFoundException

[REQUIRED] Please fill in the following fields:

Unity editor version: 2021.2.0b4 Apple Silicon
Firebase Unity SDK version: 8.1.0
Source you installed the SDK: .unitypackage
Problematic Firebase Component: Auth and others
Other Firebase Components in use: None
Additional SDKs you are using: None
Platform you are using the Unity editor on: Mac / MacBook Air M1
Platform you are targeting: iOS (Any)
Scripting Runtime: Mono (Any)

[REQUIRED] Please describe the issue here:
(Please list the full steps to reproduce the issue. Include device logs, Unity logs, and stack traces if available.)
After importing the FirebaseAuth package into an empty Unity project with the Apple Silicon Version of the Unity Editor and initializing the the module with a simple
FirebaseAuth auth = FirebaseAuth.DefaultInstance;
I get the following Exception when entering play mode:
DllNotFoundException: FirebaseCppApp-8_1_0 assembly: type: member:(null)
Firebase.AppUtilPINVOKE+SWIGExceptionHelper..cctor () (at Z:/tmp/tmp.9PHv6s9T8D/firebase/app/client/unity/proxy/AppUtilPINVOKE.cs:117)
Rethrow as TypeInitializationException: The type initializer for 'SWIGExceptionHelper' threw an exception.
Firebase.AppUtilPINVOKE..cctor () (at Z:/tmp/tmp.9PHv6s9T8D/firebase/app/client/unity/proxy/AppUtilPINVOKE.cs:137)
Rethrow as TypeInitializationException: The type initializer for 'Firebase.AppUtilPINVOKE' threw an exception.
Firebase.AppUtil.SetLogFunction (Firebase.LogUtil+LogMessageDelegate arg0) (at Z:/tmp/tmp.9PHv6s9T8D/firebase/app/client/unity/proxy/AppUtil.cs:64)
Firebase.LogUtil..ctor () (at Z:/tmp/tmp.9PHv6s9T8D/firebase/app/client/unity/proxy/LogUtil.cs:81)
Firebase.LogUtil..cctor () (at Z:/tmp/tmp.9PHv6s9T8D/firebase/app/client/unity/proxy/LogUtil.cs:37)
Rethrow as TypeInitializationException: The type initializer for 'Firebase.LogUtil' threw an exception.
Firebase.FirebaseApp..cctor () (at Z:/tmp/tmp.9PHv6s9T8D/firebase/app/client/unity/proxy/FirebaseApp.cs:67)
Rethrow as TypeInitializationException: The type initializer for 'Firebase.FirebaseApp' threw an exception.
Firebase.Auth.FirebaseAuth.get_DefaultInstance () (at Z:/tmp/tmp.fXb0dO0rk8/firebase/auth/client/unity/proxy/FirebaseAuth.cs:295)
FirebaseAuthTest.Start () (at Assets/FirebaseAuthTest.cs:11)
When doing the same in the Intel version of the Unity beta then a popup appears about an untrusted developer for FirebaseCppApp-8_1_0.bundle, which can be worked around by allowing execution through the MacOs system security settings. But in the Apple Silicon version this popup does never appear.

Hi @tab1887,
Could you try using an LTS version (2020.3.14f1) of the Unity editor and see if the issue persists?

Hi @paulinon,
thanks for checking.
As far as I know there is currently no Unity LTS version built for Apple M1 available. They started to publish the editor for 2021.2.0a19 and now 2021.2.0b4 is the latest (most mature) version of it available.
The SDK is working fine in the Intel version of the same beta, so I believe the issue is caused by the new architecture.
To make this very clear: I'm not targeting M1 for the final build, but just using the M1 version of the editor.
(The build for iOS is even working fine - only in-editor playback fails)
Maybe the dll needs to be provided in a native M1 or universal version or something like this?

Hi, I have intel and M1, I've found that this only happens on m1. any update?
Unity 2021.2.0b9 , MacBook Air m1, lastest Firebase SDK

@fruitdrawing Same here on my M1 MBP however, the intel versions (Unity v2020 & v2019) ran through Rosetta, no issues.

Any update on this? This basically makes firebase unusable with the native Unity Editor on Apple Silicon.

Any update on this? This basically makes firebase unusable with the native Unity Editor on Apple Silicon.

Just to expand on this, it basically makes firebase unusable with any Unity on M1 because the non-native editors are very slow on the M1. About 2x slower than the same editor on an intel chip Macbook.

Any update on this? :)
from Unity m1 forum they are saying like this : It looks like Firebase SDK doesn't have Apple silicon binaries yet - you'll have to ask them to recompile them to support Apple silicon.

Sorry for the inconvenience. Our team is looking at providing M1 support for the Unity SDK. Before that went out, can we try the work around by running Unity in x64 mode using Rosetta, so it will just uses all x64 dlls?

@cynthiajoan Do you have a sense of when we can expect this to be fixed, or how to work around? Unity Editor 2021.2 is now stable and one of its headline features is Apple Silicon support. However, Firebase is completely incompatible with the native Apple Silicon editor, making our projects unusable with the latest stable native version of the editor because they use Firebase. This is an important part of my team's workflow, as running Unity under Rosetta is extremely slow (~4x slower).

OK, rather than wait for an answer, I just decided — hey, Firebase is open source... I'll build it damn myself :) And, sure enough, I have managed to build .unitypackages for Firebase that include Apple Silicon native DLLs, and they work on my shiny new M1 Pro laptop. Finally, Firebase works in the Apple Silicon editor! I did have issues building the Firestore SDK in particular, but my project doesn't use that, so I don't mind.

Hi @aroman,
could you please let me know if you've got the Firebase Auth actually working? Are you using that in your project?
Encouraged by your success report I went through the build process myself and finally (after some hours of tweaking and fixing prerequisites) I ended up with some nice native DLLs inside the produced Unity packages.
(I did provide the option -DCMAKE_OSX_DEPLOYMENT_TARGET="10.15"  to work around the linker errors for Firestore and had to remove some XCTest bundles as somehow XCTest could not be found in my XCode install)
With these newly built packages installed I got rid of the original "Dll not found" error - so that looks good - but unfortunately the Firebase Auth is not working for me. Whenever I try to login (with email and password) or try to register a new user, I get internal exceptions :-( The same C# code works fine with the intel version of Unity and the latest official SDK release, so I guess the issue is caused by my build.
Any chance you did experience the same and could provide any idea how to fix this?
Here is the exception message that I get:
System.AggregateException: One or more errors occurred. (One or more errors occurred. (An internal error has occurred.)) ---> System.AggregateException: One or more errors occurred. (An internal error has occurred.) ---> Firebase.FirebaseException: An internal error has occurred.
   --- End of inner exception stack trace ---
   --- End of inner exception stack trace ---
---> (Inner Exception #0) System.AggregateException: One or more errors occurred. (An internal error has occurred.) ---> Firebase.FirebaseException: An internal error has occurred.
   --- End of inner exception stack trace ---
---> (Inner Exception #0) Firebase.FirebaseException: An internal error has occurred.<---
<---

UnityEngine.Debug:Log (object)
LoginFunctions/<>c__DisplayClass6_0:<doLogin>b__0 (System.Threading.Tasks.Task`1<Firebase.Auth.FirebaseUser>) (at Assets/Scripts/LoginFunctions.cs:63)
Firebase.Extensions.TaskExtension/<>c__DisplayClass4_1`1<Firebase.Auth.FirebaseUser>:<ContinueWithOnMainThread>b__1 ()
Firebase.Dispatcher/<>c__DisplayClass5_0`1<bool>:<RunAsync>b__0 ()
Firebase.ExceptionAggregator:Wrap (System.Action)
Firebase.Dispatcher:PollJobs ()
Firebase.Platform.FirebaseHandler:Update ()
Firebase.Platform.FirebaseMonoBehaviour:Update ()

hey @tab1887, happy to compare notes —

I didn't end up importing the Firebase Auth package to my project, as my project doesn't use the service, so unfortunately I'm not much help for you there.

For Firestore not compiling, check https://github.com/firebase/firebase-cpp-sdk/issues/712 for the proper fix (should be making its way downstream soon)

I likewise had to edit the CMakeLists.txt to exclude building the tests, as I also had that issue with the XCTest being missing.

I have no reason to think the result would be any different, but if you'd like to try using the FirebaseAuth.unitypackage I built (in case there was some issue with your build), I've uploaded all of the unitypackages for Apple Silicon that I built here:

https://github.com/aroman/firebase-unity-applesilicon

@aroman
thank you man, you are great.
Is it too much to ask for you to upload .tgz versions of these files?

@aroman , thank you very much for the prompt response and for providing your build results.
Unfortunately the result is the same for me, even with your version of FirebaseAuth.
Enabling debug output reveals that there is an issue with loading user data from the keystore (I'd guess that is Keychain under MacOS):
LoadUserData: Key com.*******.firebase.auth/__FIRAPP_DEFAULT not found
Failed to read user data for app (__FIRAPP_DEFAULT).  This could happen if the current user doesn't have access to the keystore, the keystore has been corrupted or the app intentionally deleted the stored data.

This seems to be handled in firebase-cpp-sdk/app/src/secure/user_secure_darwin_internal.mm
but I have no clue what is going wrong there :( I guess i'll have to wait patiently until an official release is supporting Apple silicon :-/

Hi @cynthiajoan any update on this issue?

Just for info: In the meantime I was able to get my project running in the Unity M1 editor with Auth, Firestore, and Functions.
It turned out that the keystore issue reported above was a red herring - this happens also on the official Intel version for me and somehow doesn't stop the app from working.
My main issue was a wrong OpenSSL version being used in the build process: OpenSSL 3.0.0 was installed by Homebrew, but that resulted in failed handshakes with www.googleapis.com.
Once replaced with OpenSSL 1.1.1 the Auth was working.
Additionally I had to delete the LevelDB data files manually from my library, as they seem to be incompatible between Intel and Apple versions (crashed when reading schema version)
I still would love to see an official release soon. Unfortunately the packages coming out of the build process are much smaller than the official ones and currently I can't build my Unity project for IOS - still trying to figure out how to "mix" versions to get it all working. But from my experience so far, I would guess that for someone more familiar with this SDK project, it shouldn't be too hard to get a fully working release together.

Unfortunately the packages coming out of the build process are much smaller than the official ones and currently I can't build my Unity project for IOS - still trying to figure out how to "mix" versions to get it all working. But from my experience so far, I would guess that for someone more familiar with this SDK project, it shouldn't be too hard to get a fully working release together.

I noticed the same thing -- the packages I built were much smaller, and I wasn't able to build with them. My solution to that problem was to use the latest official packages provided by Firebase, then ONLY add the AppleSilicon compiled .bundles to my project. In this way, I've been able to get the project to both build for normal release targets, and work in-editor.

Hello @aroman. Please, can you upload those .bundle files for the latest version? (8.6.1)

Ok friends, I have a present for you. I have created a repo with the bundle files for the latest version (8.6.2, just released this morning) and instructions for exactly where to stick them. Use at your own risk, and definitely not tested thoroughly, but so far it works for me. Maybe it will encourage the firebase team to do this for real 🙃 Have a good weekend everyone! ❤
https://github.com/aroman/firebase-unity-applesilicon

@aroman  Thanks for the repo.
I checked it and FirebaseCppFirestore.bundle is missing.
Is there a problem building it?

@aroman Thanks for the repo.
I checked it and FirebaseCppFirestore.bundle is missing. Is there a problem building it?

ah yeah, i had disabled building firestore because of https://github.com/firebase/firebase-cpp-sdk/issues/712. I'll see if I can rebuild it now that the issue is closed.

So, firestore for desktop gets firestore core from the firebase-ios-sdk repo. That repo has been updated to include the fix, but it hasn't been released yet. Probably will need to wait for that to happen before it can be built. The build process is complex and I haven't been able to find a way to apply the patch directly, since it's quite a few levels upstream at this point. tl;dr no firestore yet. i'll update the repo

@aroman thank you for your effort

@aroman thanks a lot for those .bundles. Unfortunately the FirebaseAuth doesn't work. Trying to follow @tab1887 's instruction to build again, but got a python error: ImportError: No module named absl. I did pip install absl and pip3install absl though

@aroman Thank you very much for providing the detailed instructions of how to replace only the bundles for a fully working install. This is most appreciated.
 Even after a fresh clone (or git pull) I always end up with a zip for 8.5.0. There seem to be no tags or releases available in the firebase-unity-sdk repo. What am I missing?
Regarding the missing fix for Firestore, the workaround posted here (-DCMAKE_OSX_DEPLOYMENT_TARGET="10.15") is working just fine for me. Not sure why, but it works ;-)

@tab1887 Could you share your firestore.bundle file?

@aroman Thank you very much for providing the detailed instructions of how to replace only the bundles for a fully working install. This is most appreciated.
 Even after a fresh clone (or git pull) I always end up with a zip for 8.5.0. There seem to be no tags or releases available in the firebase-unity-sdk repo. What am I missing?
Regarding the missing fix for Firestore, the workaround posted here (-DCMAKE_OSX_DEPLOYMENT_TARGET="10.15") is working just fine for me. Not sure why, but it works ;-)

Ahh. I also ran into this issue :) It seems that the firebase-unity-sdk repo isn't actually kept up to date with the latest releases. My guess is that the Firebase team is in the progress migrating to a fully open-source repo (since the repo was only created this year, but the SDK has been around for much longer), and right now the true source of truth is still part of some Google internal tooling. Perhaps @ a-maurice could clarify.
My solution in the meantime:
~/Projects/firebase/firebase-unity-sdk main* ❯ git diff cmake/firebase_unity_version.cmake                                                    (2s)
diff --git a/cmake/firebase_unity_version.cmake b/cmake/firebase_unity_version.cmake
index 79efa00..0079e7d 100644
--- a/cmake/firebase_unity_version.cmake
+++ b/cmake/firebase_unity_version.cmake
@@ -14,7 +14,7 @@

 # This file defines the version numbers used by the Firebase Unity SDK.

-set(FIREBASE_UNITY_SDK_VERSION "8.5.0"
+set(FIREBASE_UNITY_SDK_VERSION "8.6.2"
     CACHE STRING "The version of the Unity SDK, used in the names of files.")

 set(FIREBASE_IOS_POD_VERSION "8.3.0"
@@ -29,7 +29,7 @@ set(FIREBASE_UNITY_JAR_RESOLVER_VERSION

 # https://github.com/firebase/firebase-cpp-sdk
 set(FIREBASE_CPP_SDK_PRESET_VERSION
-  "v8.6.0"
+  "v8.7.0"
    CACHE STRING
   "Version tag of Firebase CPP SDK to download (if no local or not passed in) and use (no trailing .0)"
 )

Another tip, the build script for mac (build_bash.sh) does not take advantage of parallel code compilation. You can build the project much much faster if you change the make like in that script to make -j10.

I've just noticed that i'm getting this error logged in unity whenver my database is updated:
firebase-cpp-sdk/database/src/desktop/core/sync_tree.cc(459): visibility == kOverwriteVisible || !persist
seems like everything is still working well though

@aroman , many thanks again for your quick help. With your diff info I was able to build 8.6.2 and finally got to a point where I could work on my actual project again with this nice M1 performance boost. That really makes me happy :-)
@kerembaydogan , I have uploaded my arm64 bundles here.
Disclaimer: This is mostly untested, so use at your own risk.

@tab1887 Thanks for the bundles.
with your bundles I am getting this error.

libc++abi: terminating with uncaught exception of type firebase::firestore::FirestoreInternalError: FIRESTORE INTERNAL ASSERTION FAILED: /Users/tim/Documents/firebase/firebase-unity-sdk/macos_unity/bin/external/src/firestore/Firestore/core/src/local/leveldb_migrations.cc(395) static LevelDbMigrations::SchemaVersion firebase::firestore::local::LevelDbMigrations::ReadSchemaVersion(leveldb::DB *): Failed to read version string from LevelDB, error: 'Corruption: corrupted compressed block contents' (expected status.ok()) ERROR: FIRESTORE INTERNAL ASSERTION FAILED: /Users/tim/Documents/firebase/firebase-unity-sdk /macos_unity/bin/external/src/firestore/Firestore/core/src/local/leveldb_migrations.cc(395) static LevelDbMigrations::SchemaVersion firebase::firestore::local::LevelDbMigrations::ReadSchemaVersion(leveldb::DB *): Failed to read version string from LevelDB, error: 'Corruption: corrupted compressed block contents' (expected status.ok()) Obtained 0 stack frames. Launching bug reporter

@kerembaydogan I had the same issue at first. I guess this is some kind of incompatibility between intel and arm versions of the leveldb that is used for firestore. The SDK tries to check the current schema version and fails.
For me the solution was to simply delete the existing files from
~/Library/Application Support/firestore/__FIRAPP_DEFAULT/[your_app_id]/main/
This will obviously delete the current Firestore state / local cache. Not sure if it has any other side effects. But after deleting everything there, it was automatically recreated with the next app start and all was working for me.
(IIrc there was one more path with a firestoe .ldb file somewhere under ~/Library/ that I had deleted, but I can't remember where exactly that was)

Hello @cynthiajoan , it's been a long time since there's been any communication about this.
Is there any update or ETA on this bug?

since no one assigned to this issue, I have to mention every contributor.
Is there any update?
Is Apple Silicon Support for Unity Editor on the roadmap? Or do we have to compile our own bundle files?
Thanks.
@stewartmiles @jonsimantov @a-maurice @chkuang-g @Montoli @vimanyu @DellaBitta @Thaina @cynthiajoan @samtstern

if anyone is interested, I have built the firebase unity SDK version 8.7.0 for apple silicon.
I can share .bundle files.

Here you go:
https://github.com/kerembaydogan/firebase-unity-apple-silicon

BTW If Pull Requests are welcome, I think we can provide some help.

We are still in the process of moving the Firebase Unity's primary development to GitHub, but if you have a PR to add Apple Silicon support, we can take a look at it as we get closer to finishing that transition.

My current solution to this problem is building two separate SDK packages, one for arm64 and one for x86_64
If this is ok for you I can add a flag to the build process and update scripts according to that.
If including two separate .bundle files for two architectures is possible on same tgz/unitypackage I can also try to do that.
Third option is building a universal .bunle file (if it is possible),
But I could not find a way to build universal (arm64/x86) bundle file because of the ssl dependencies.

I went down the road of trying to have separate arm64 and x86_64 bundle files and getting Unity to use the right one depending on the architecture. But it runs into problems because both bundle files must have the same name because Swig loads them by name, but Unity complains about having two bundles with the same name (even if we configure their metadata such that the x86_64 one is only used on Intel Macs and the arm64 one is only used on Apple Silicon Macs).
So I think the only viable approach is to build a single fat/universal bundle. I ran into the same openssl problem you probably did when doing that, and am currently compiling a fat openssl library to try linking against that. Unfortunately that's not supported out of the box, so it's a rather manual process of compiling openssl seprately for x86_64 and arm64 and then using lipo to create a universal .a file.
I'll report back shortly on how that goes.

So that seems to work. I have universal .bundle files which I can use instead of the bundle files that shipped with 8.7.0 and everything runs fine on my Apple Silicon Mac. Unfortunately I no longer have an Intel Mac to test them on, so I can't be 100% sure they work on the Intel Mac, but I would expect them to. All the indications are that both architectures are included:

The process here was not too complicated, but I can't easily turn it into a PR because I don't know what Google uses for openssl when it builds Firebase libraries for distribution. OpenSSL does not make it easy to compile for multiple architectures, unfortunately, so I had to do a rather manual process.
I started with the latest openssl from Github, and then configured it once for x86_64:

@samskivert Wonderful news

The final step, which I'm not 100% sure is necessary, but probably is, is that Unity maintains metadata on the .bundle files which specify which architectures they can run on. That is set to Intel in the currently shipped 8.7.0 libraries, so I had to go in and manually change that to "Any CPU".
Because I use the .tgz files and upload them to my own NPM registry, I had to unpack the shipped 8.7.0 .tgz files, replace the .bundle files in the Firebase/Plugins/x86_64 directories, load that up in a scratch Unity project so that I could tweak the .meta file to specify "Any CPU" and then finally publish the results to my own NPM server. And I had to do that individually for all the Firebase libraries we use. Fun times!
But it all works, so that's a plus. :) If anyone with an Intel Mac but not enough patience to go through this whole process themselves wants to try out these .bundle files on their machine to confirm that they also work on Intel Macs, LMK. I can put them up somewhere.

For anyone that has Firebase compiling locally but wants to avoid the trouble of building openssl, you can find my universal build here: https://samskivert.com/openssl-universal.tgz

Also FWIW, I just confirmed that a standalone build of our game for macOS works with these libraries (on an Apple Silicon Mac).

If anyone with an Intel Mac but not enough patience to go through this whole process themselves wants to try out these .bundle files on their machine to confirm that they also work on Intel Macs, LMK. I can put them up somewhere.

@samskivert I have both Intel and Apple Silicon Macs available and would like to test your .bundle files!

Great, grab them from here: https://samskivert.com/firebase-bundles.zip and copy whichever of the ones you use over top of the ones installed by the 8.7.0 unitypackage.

@samskivert Also tried testing your bundles and using Silicon Unity 2021.2.7 on M1, I can't get any different behavior from vanilla firebase 8.7.0 - same "DllNotFoundException: FirebaseCppApp-8_7_0 assembly: type: member:(null)" exception. I've installed all the modules we need using .unitypackages and replaced the bundle files in the Firebase/Plugins/x86_64 directory (there is just one for me) - anything else that needs to be done?

@kjyv Did you rename the x86_64 x86_64.meta to  arm64 arm64.meta?

You shouldn't need to rename the directory to arm64, but what you do need to do is go in and inspect the .bundle files in Unity, and then you need to set CPU to "Any CPU" in platform settings for the standalone platform:

Then "Apply" that change (to all .bundle files you need).

@kerembaydogan No, I don't think that was supposed to be necessary as the bundles are universal. But I did try creating a new arm64 folder, made sure it was set to Silicon target and deleted the x86_64 folder, no difference.
All files already had Any CPU set when I checked.

@kjyv Sorry, I did not realize the bundles are universal.

So another guy I work with is having trouble getting these to work as well and we can't figure out what is different. Do you happen to be using a MacBook rather than a MacBook Pro? That's the only thing we can tell is different between his system and mine, and he encounters that same problem in Unity and in with our standalone built client. It's a very mysterious error.

When he tries to run our standalone build, it logs the following errors:

No, also Macbook Pro (that would be really weird to make a difference). I'm seeing the same log messages but thought this would be some generic path Unity tries when not finding the actual file. Could there be a hardcoded path somehow in the binaries from you build that only works on you machine?

@samskivert Which version of unity and arm64 or x86_64?

Yeah, I just got confirmation that it doesn't work on another guy's ASi Mac either. So maybe there are somehow hardcoded paths in the .bundle files I compiled? That would be very surprising, but at this point we have no idea what else could be going on.
I'm using Unity 2021.2.7f1 and an ASi MacBook Pro. The other two guys are using same version of Unity and one has an ASi MacBook Pro and one has an ASi MacBook.

@samskivert did you clear the firestore files from (if using firestore)
~/Library/Application Support/firestore/__FIRAPP_DEFAULT/[your_app_id]/main/

We're not using Firestore, just Firebase Auth and Firebase Messaging.

So it's definitely some kind of hardcoded path problem because if I rename the directory in which I built all the firebase stuff, things start failing on my machine. So now I have to figure out what exactly is referencing things in there and then how to make it not do that. Will report back! :)

Using otool -l FirebaseCppApp-8_7_0.bundle I can see
Load command 20
          cmd LC_RPATH
      cmdsize 96
         path /Users/mdb/ops/firebase/firebase-unity-sdk/build/bin/external/src/curl-build/lib (offset 12)

I just tracked that down via a much more painful process. Thanks for the otool tip! :)

Now I'm trying to figure out why that is getting linked dynamically. I certainly did not tell the Firestore build system to do that, and I assume they must not do that normally...

Well, I continue to wrestle with getting it to build without a dynamically linked libcurl. In theory I should be able to add -DCURL_STATICLIB in the right places (presently hacked into firebase-cpp-sdk/app/rest/CMakeLists.txt because that's what introduces the libcurl dependency) but continues to insist on building it dynamically.
I will continue to beat my head against it, but if anyone was waiting around for quick fixes, I'm afraid I have none to offer. I'll report back when I hopefully eventually sort it out.
It's particularly strange that I built arm64-only .bundle files a week or so ago and everyone on my team was able to successfully use those with no weird libcurl.dylib dependency. And the only thing I changed with this new build was adding the x86_64 arch back in and using a new fat OpenSSL build instead of the (arm64-only) one installed by Homebrew. So I don't know how that changed anything involving libcurl.

You probably need to rebuild curl as static library, I don't think you can link a shared library statically. And anyway you probably need to specify your openssl version for it instead of it being the one from brew on your system

Maybe also the openssl build you did is pulling in the libcurl dependency but your build is using the shared library from your system and should link to an included curl

OK, that was an adventure. I now know far more about CMake than I ever wanted to. Also, it didn't help that this firebase-cpp-sdk commit fdf6ffe58ddca8a0dc5108254ebab3a210f40b0c broke the firebase-unity-sdk build and they have not pushed an update to fix it to their Github. So I had to diagnose and work around that problem as well.
But in the end, the problems were overcome and we have bundle files that do not spuriously reference dynamic libraries on my harddrive. The solution turned out to be quite trivial, in spite being quite hard to finally arrive at. Simple add this argument when running cmake:

@samskivert Unfortunately still getting the DLLNotFound error on play using your latest bundles.
I have tried most of the suggestions posted here about changing the folder name (arm64 vs x86_64), changing the CPU (Any CPU vs Apple Silicon), cand hanging architecture support (Editor/Standalone/All) and all combinations, but they all give the same error.

Hrm, my team mates are able to use these bundles and based on the emojis on my comment posting the new bundles, I'm guessing the other people on this thread are also able to use them.
You shouldn't have to change the folder name, that doesn't mean anything to Unity. And the inspector settings should be like the image I posted earlier in the thread: Editor and Standalone players only and in the macOS section, Any CPU. You have to press "Apply" after you change any settings in the inspector, so make sure you're doing that.
Otherwise, I don't know what could be different between your configuration and ours. Maybe make sure you don't have duplicate copies of the Firebase libraries anywhere?

@Blueteak If you are using packagemanager, you should also delete this folder;
/Users/<YOUR_USERNAME>/Library/Unity/cache

Anyhow, updated bundle files are available at that same URL: https://samskivert.com/firebase-bundles.zip

Thanks a lot for this @samskivert - made my day! Question: you don't happen to have one for Firestore? (FirebaseCppFirestore.bundle)

I originally omitted Firestore because we didn't use it and someone else said they ran into trouble building it. But I went back and turned it on and it seemed to build fine.
So I updated the firebase-bundles.zip to include the Firestore shared library, and with the latest Github revision of firebase-cpp-sdk and firebase-unity-sdk (nothing much important changed but at least firebase-unity-sdk is now fixed vis a vis some reorganizing changes made in firebase-cpp-sdk in December).

Thanks for the bundles @samskivert , I tried them out, but still getting this error log on my side, as I did with my homebuilt .bundles as well: /Users/mdb/ops/firebase/firebase-cpp-sdk/database/src/desktop/core/sync_tree.cc(459): visibility == kOverwriteVisible || !persist
It might be because I'm using transactions?
Everything seems to be functioning though it's just I thought I should mention it so firebase devs can look at it.
Still looking forward to the official versions. @cynthiajoan

Awesome! @samskivert your bundles worked like a charm for me. Now it's possible to bridge the time until there is official support.
Thanks a lot!

Experiencing the same issue "dllNotFound.... 8.7.0". Tried the Bundles from @samskivert (thanks for all your effort) but still no luck on my Macbook Pro M1 Max with Unity 2021.2.6. Any help on what we could still try to fix this.

It work on my MacBook M1 pro with unity 2021.2.8f1 Silicon. Also get the DLLNotFound error. In my case never get the popup to allow execution, but it appears to me in security

For latest 8.8.0 SDK - the same issue:
DllNotFoundException: FirebaseCppApp-8_8_0 assembly: type: member:(null)

I'm getting this issue as well on 8.8.0. I even converted all Firebase and Google plugins to use UPM, and still no luck. I'm on Unity 2020.3.26f1 and i get this DLLNotFoundException error when i try to run on Android mode in the Editor. It triggers when it tries to run FirebaseApp.CheckAndFixDependenciesAsync().

I'm getting this issue as well on 8.8.0. I even converted all Firebase and Google plugins to use UPM, and still no luck. I'm on Unity 2020.3.26f1 and i get this DLLNotFoundException error when i try to run on Android mode in the Editor. It triggers when it tries to run FirebaseApp.CheckAndFixDependenciesAsync().

Check some of the earlier posts in this thread. Until Google adds support for Apple Silicon, firebase won't work in the editor. As a workaround in the meantime (it could be many months before they get around to it -- they haven't even committed to a timeframe for doing this work), we've been building firebase-unity from source ourselves and compiling it for Apple Silicon. Some folks above have been posting their .unitypackages. I have instructions in an earlier comment with tips on how to do this yourself. It works fine, in production.

I'm getting this issue as well on 8.8.0. I even converted all Firebase and Google plugins to use UPM, and still no luck. I'm on Unity 2020.3.26f1 and i get this DLLNotFoundException error when i try to run on Android mode in the Editor. It triggers when it tries to run FirebaseApp.CheckAndFixDependenciesAsync().

Check some of the earlier posts in this thread. Has nothing to do with how you install Firebase, this isn't a bug, it's a feature Google has yet to implement. Until Google adds support for Apple Silicon, firebase won't work in the editor. As a workaround in the meantime (it could be many months before they get around to it -- they haven't even committed to a timeframe for doing this work), we've been building firebase-unity from source ourselves and compiling it for Apple Silicon. Some folks above have been posting their .unitypackages. I have instructions in an earlier comment with tips on how to do this yourself.  You can run a local NPM server like verdaccio and upload your own customized tgz files there.

@samskivert @aroman Can we kindly ask you to share the latest arm64 binaries for 8.8.0? Thanks🙏

Alas, I was hoping Google would have fixed things upstream by now, but no such luck.
I pulled the latest Firebase C++ SDK and Firebase Unity SDK and rebuilt everything. Seemed to go smoothly, so the updated .bundle files are here:
https://samskivert.com/firebase-bundles.zip
But I haven't tested them (yet) and the Github project still says version number 8.7.0, so I don't know if they've synced everything out to Github that went into the 8.8.0 release. Hopefully it all works! I'll test it out myself soon, but I need to rebuild .tgzs and upload them to our private NPM repository which is some extra work that you all don't have to wait around for.

Never mind, it's been too long since I last build them. I say what version number goes in there and forgot to update it. Doing that now and new .zip file coming shortly.

OK, updated 8.8.0 bundles are here: https://samskivert.com/firebase-bundles.zip

@samskivert Thanks a lot! That was super quick. Going to try that soon.

Is there any roadmap for when Firebase officially supports this?

@samskivert Thank you! That worked like a charm, I did also clicked "apply" on the new bundles, and it is working now!

@samskivert I finally got to implement your bundles into my project and I just wanted to shout out a big THANK YOU, SIR!
As @Przemo0c said, it works like a charm. I have tested the Universal Binaries successfully on both Intel an Apple Silicon Macs in my compiled project. For anyone coming in at this time: It is a three step process:

Install Firebase Unity SDK 8.8.0 modules you need into your Unity project
Replace the bundle files you use in your project with the Universal Binaries by @samskivert
Inspect the bundles in the Unity editor, set them to "Any CPU" and press "Apply"

Thanks again!
Danny

first, thank you @samskivert for helping a lot of users above according to the emojis. But for me it's somehow didn't work. I think it's because I am a newbie with unity. I have tried all possible options above, even with setting Any CPU, when I start to change it Any CPU and click the Run button Unity falls into Not Responding state and never work anymore, only force quit required.
Steps I performed, may you will find not correct one:

In Aseests->Import Package -> Custom Package and in finder picked a FirebaseDatabase.unitypakage
Clicked to Run game to see that error still reproducible. Stopped the game.
Opened Finder navigated to the project folder then into Firebase/Plugins/x86_64/. From the firebase-bundles.zip I have found the FirebaseCppApp-8_8_0.bundle and replaced it with the filed in X86_86 folder.
Found in Unity the FirebaseCppApp-8_8_0.bundle and then in Platform Settings set to Any CPU for both: Editor and Standalone to use "Any CPU".
The Unity falls into the endless and not responding anymore.

What I am doing not correctly?

@h4rdmol It shouldn't cause Unity to freeze, but did you check the security & privacy window? You should allow the bundle to execute in this window.

bundle allowed in Privacy

my issue is solved. The problem was in code which cause the unity to freeze.
many thanks to @samskivert for the bundles.

Unity 2021.2.12, Firebase SDK 8.8.0.
still have this issue.

For those with Apple Silicon macs who were eager to upgrade to macOS Monterey 12.3 (as a result of a missing python executable in /usr/bin) and are now stuck with a non-functional Unity project, I created a fixed arm64 binaries and shared it here:
https://github.com/techyworm10/firebase-unity-sdk-arm64
** This is not an official fix that is not available yet.
Alternatively, you can just replace the Firebase.Editor dll files:
https://github.com/techyworm10/firebase-unity-sdk-editor-python-fix

For those with Apple Silicon macs who were eager to upgrade to macOS Monterey 12.3 and are now stuck with a non-functional Unity project (as a result of a missing python executable in /usr/bin), I created a fixed arm64 binaries and shared it here: https://github.com/techyworm10/firebase-unity-sdk-arm64 ** This is not an official fix that is not available yet.
Alternatively, you can just replace the Firebase.Editor dll files: https://github.com/techyworm10/firebase-unity-sdk-editor-python-fix

Thanks for providing this, @techyworm10. I followed the advice above and replaced my Firebase.Editor dll files, and am now receiving the following error:
DllNotFoundException: FirebaseCppApp-8_8_0
Firebase.AppUtilPINVOKE+SWIGExceptionHelper..cctor () (at Z:/tmp/tmp.iyw5dxgCiD/firebase/app/client/unity/proxy/AppUtilPINVOKE.cs:117)
Rethrow as TypeInitializationException: The type initializer for 'SWIGExceptionHelper' threw an exception.
Firebase.AppUtilPINVOKE..cctor () (at Z:/tmp/tmp.iyw5dxgCiD/firebase/app/client/unity/proxy/AppUtilPINVOKE.cs:137)
Rethrow as TypeInitializationException: The type initializer for 'Firebase.AppUtilPINVOKE' threw an exception.
Firebase.AppUtil.SetLogFunction (Firebase.LogUtil+LogMessageDelegate arg0) (at Z:/tmp/tmp.iyw5dxgCiD/firebase/app/client/unity/proxy/AppUtil.cs:64)
Firebase.LogUtil..ctor () (at Z:/tmp/tmp.iyw5dxgCiD/firebase/app/client/unity/proxy/LogUtil.cs:81)
Firebase.LogUtil..cctor () (at Z:/tmp/tmp.iyw5dxgCiD/firebase/app/client/unity/proxy/LogUtil.cs:37)
Rethrow as TypeInitializationException: The type initializer for 'Firebase.LogUtil' threw an exception.
Firebase.FirebaseApp..cctor () (at Z:/tmp/tmp.iyw5dxgCiD/firebase/app/client/unity/proxy/FirebaseApp.cs:67)
Rethrow as TypeInitializationException: The type initializer for 'Firebase.FirebaseApp' threw an exception.
Tamarin.FirebaseX.FirebaseAPI.Init () (at <b534ca57979b46f4961f32efea5186e1>:0)
Tamarin.FirebaseX.FirebaseAPI+<Start>d__15.MoveNext () (at <b534ca57979b46f4961f32efea5186e1>:0)
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () (at <695d1cc93cca45069c528c15c9fdd749>:0)
System.Runtime.CompilerServices.AsyncMethodBuilderCore+<>c.<ThrowAsync>b__6_0 (System.Object state) (at <695d1cc93cca45069c528c15c9fdd749>:0)
UnityEngine.UnitySynchronizationContext+WorkRequest.Invoke () (at /Users/bokken/buildslave/unity/build/Runtime/Export/Scripting/UnitySynchronizationContext.cs:153)
UnityEngine.UnitySynchronizationContext:ExecuteTasks() (at /Users/bokken/buildslave/unity/build/Runtime/Export/Scripting/UnitySynchronizationContext.cs:107)

Any insights?

For those with Apple Silicon macs who were eager to upgrade to macOS Monterey 12.3 and are now stuck with a non-functional Unity project (as a result of a missing python executable in /usr/bin), I created a fixed arm64 binaries and shared it here: https://github.com/techyworm10/firebase-unity-sdk-arm64 ** This is not an official fix that is not available yet.
Alternatively, you can just replace the Firebase.Editor dll files: https://github.com/techyworm10/firebase-unity-sdk-editor-python-fix

Thanks for providing this, @techyworm10. I followed the advice above and replaced my Firebase.Editor dll files, and am now receiving the following error:
DllNotFoundException: FirebaseCppApp-8_8_0
Firebase.AppUtilPINVOKE+SWIGExceptionHelper..cctor () (at Z:/tmp/tmp.iyw5dxgCiD/firebase/app/client/unity/proxy/AppUtilPINVOKE.cs:117)
Rethrow as TypeInitializationException: The type initializer for 'SWIGExceptionHelper' threw an exception.
Firebase.AppUtilPINVOKE..cctor () (at Z:/tmp/tmp.iyw5dxgCiD/firebase/app/client/unity/proxy/AppUtilPINVOKE.cs:137)
Rethrow as TypeInitializationException: The type initializer for 'Firebase.AppUtilPINVOKE' threw an exception.
Firebase.AppUtil.SetLogFunction (Firebase.LogUtil+LogMessageDelegate arg0) (at Z:/tmp/tmp.iyw5dxgCiD/firebase/app/client/unity/proxy/AppUtil.cs:64)
Firebase.LogUtil..ctor () (at Z:/tmp/tmp.iyw5dxgCiD/firebase/app/client/unity/proxy/LogUtil.cs:81)
Firebase.LogUtil..cctor () (at Z:/tmp/tmp.iyw5dxgCiD/firebase/app/client/unity/proxy/LogUtil.cs:37)
Rethrow as TypeInitializationException: The type initializer for 'Firebase.LogUtil' threw an exception.
Firebase.FirebaseApp..cctor () (at Z:/tmp/tmp.iyw5dxgCiD/firebase/app/client/unity/proxy/FirebaseApp.cs:67)
Rethrow as TypeInitializationException: The type initializer for 'Firebase.FirebaseApp' threw an exception.
Tamarin.FirebaseX.FirebaseAPI.Init () (at <b534ca57979b46f4961f32efea5186e1>:0)
Tamarin.FirebaseX.FirebaseAPI+<Start>d__15.MoveNext () (at <b534ca57979b46f4961f32efea5186e1>:0)
--- End of stack trace from previous location where exception was thrown ---
System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () (at <695d1cc93cca45069c528c15c9fdd749>:0)
System.Runtime.CompilerServices.AsyncMethodBuilderCore+<>c.<ThrowAsync>b__6_0 (System.Object state) (at <695d1cc93cca45069c528c15c9fdd749>:0)
UnityEngine.UnitySynchronizationContext+WorkRequest.Invoke () (at /Users/bokken/buildslave/unity/build/Runtime/Export/Scripting/UnitySynchronizationContext.cs:153)
UnityEngine.UnitySynchronizationContext:ExecuteTasks() (at /Users/bokken/buildslave/unity/build/Runtime/Export/Scripting/UnitySynchronizationContext.cs:107)

Any insights?

I think that fixes the python error, but to fix the DllNotFoundException you still need to use for example the workaround by @samskivert:

OK, updated 8.8.0 bundles are here: https://samskivert.com/firebase-bundles.zip

You need to install the Firebase packages that you want to use from the official Firebase packages provided by Google either the .unitypackage or the .tgz depending on how you want to install them.  You need to replace the Firebase/Plugins/x86_64/FirebaseCppApp-8_7_0.bundle file, for example, with the one from the .zip file.
Note: you can only copy it directly into your Unity project if you installed via the .unitypackage files. If you're using the .tgz files, you need to unpack them, replace the .bundle files in question, repack them and then install that modified .tgz file.

Is there any instructions on how to build this for silicon? I've noticed 8.9 is out and wanting to try to use it, but the error is still there currently. I'm not very good with a mac, it's just what we use at work. Thanks!

Hi, I wrote an article on how to build an SDK for Apple Silicon.
Sorry for the Japanese, but the command part is important and I hope it will be useful for someone.
https://qiita.com/atr-toru/items/b65647993a022b966175

Can anyone build the tar for version 8.9.0!

Hi, I wrote an article on how to build an SDK for Apple Silicon. Sorry for the Japanese, but the command part is important and I hope it will be useful for someone.
https://qiita.com/atr-toru/items/b65647993a022b966175

Thanks celp, I couldn't quite get it to work sadly. When I ran the build command, it gave a few errors and the macos_unity folder was always empty. I think I'm just not understanding part of the steps.

Any news when we may expect fix this issue in 8.9.0 ?

Any update for this issue ???

I have succeeded with the following steps. Thanks to all of you for your support.

Get Firestore ver 8.8.0 by referring to Get previous versions of Firebase for Unity - Qiita.
Tap dotnet4/FirebaseFirestore.unitypackage in the Firebase Unity SDK 8.8.0 module to install.
Bundle file for use in your project with [[Bug] Apple Silicon - DllNotFoundException - Issue #1100 - firebase/quickstart-unity](https://github.com/firebase/ quickstart-unity/issues/1100#issuecomment-1029364297) file.
Overwrite the file under Firebase/Editor with this file.

So I've tried the whole thing with Firebase 8.8.0 version (because there is no solution for the newest 8.9.0 release) specifically with FirebaseAuthentication. I've used @samskivert's 8.8.0 bundle and did the whole replacing and applying process. But still when I'm going into Play-Mode I'm getting the DllNotFound-Exception (I'm on Unity Editor 2021.3.1f1).
Anyone got any clues what the problem might be? (Or maybe this whole solution doesn't even support play-mode? Do I have to build it manually through command line?) Please enlighten me.

@vincentkrp It works in play mode as well.
Check your Mac's security & privacy settings. The system might be blocking the bundle (it must be allowed once).

@techyworm10 Thx for the help, but sadly that doesn't look like it's working for me either. Because in my security settings there is no such message for software being blocked so i can't even allow it like you suggested (normally the message should be there when I'm entering play mode, right?)

@techyworm10 Thx for the help, but sadly that doesn't look like it's working for me either.

You can unblock the bundle via terminal:
xattr -d com.apple.quarantine path/to/file.bundle

Doesn't seem like that works either. Because when trying to do that, I get following output in terminal:
Traceback (most recent call last):
File "/usr/bin/xattr-2.7", line 7, in
from pkg_resources import load_entry_point
ImportError: No module named pkg_resources

Doesn't seem like that works either. Because when trying to do that, I get following output in terminal:
Traceback (most recent call last):
File "/usr/bin/xattr-2.7", line 7, in
from pkg_resources import load_entry_point
ImportError: No module named pkg_resources

That's inconvenient. You can check file /usr/bin/xattr. That should result in something like this:
`/usr/bin/xattr: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64

Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e
Mach-O 64-bit executable arm64e]
/usr/bin/xattr (for architecture x86_64):	Mach-O 64-bit executable x86_64
/usr/bin/xattr (for architecture arm64e):	Mach-O 64-bit executable arm64e`

A quick Google search showed that the issue you are experiencing may be due to some borked Python wrapper for xattr that is in your PATH, homebrew may cause this.
Anyway, calling xattr directly may fix the issue if the executable is present in /usr/bin:
/usr/bin/xattr -d com.apple.quarantine path/to/file.bundle
If this doesn't work you may consider reinstalling macOS as xattr is a rather important system tool, e.g. this usecase of overriding security / quarantine for missing notarization of .app and .bundle files.

Still no official support for Apple Silicon? It's getting pretty ridiculous. 🙄

This is crazy. It's been more than a year since Apple Silicon came out and still no support. Unity released Unity 2021 LTS with Apple Silicon support but no one who uses Firebase can migrate to the Unity 2021. We have to stay on Unity 2020 which constantly crashes and works extremely slow on M1 macs.
Please, someone, do this already 🙏


@react-dnd/asap trigger swc error env and jsc.target cannot be used together

Describe the bug
i'm using swc with @react-dnd, my swc transform options  is
{
 filename<EMAIL_ADDRESS>  sourceMaps: true,
  jsc: {
    transform: { react: [Object], legacyDecorator: true },
    externalHelpers: true
  },
  module: { type: 'es6', noInterop: false },
  env: { loose: false, targets: [ 'chrome 55' ] }
}

i was set config.env first
but @react-dnd/asap also set swcrc by self。
it caused error
`env` and `jsc.target` cannot be used together

Expected behavior
maybe @react-dnd should remove .swcrc file when this package is publishing

same here env and jsc.target cannot be used together.


"Delete Application

Ability to delete an application, but ONLY by a User with Admin AND Vetting roles. This is only Shawn, the executive director, and Rohin with all roles for testing as of this Issue posting.

Wait to do this until the Search function in Reports is operational in production.

Moved to new GitHub


Allowing for side-loading of /persist content + silly fix for exit status of linuxkit

This change allows for content of the /persist partition to be specified upfront (the default is still 1M of 0s). In addition just got to fixing the fact that a failing linuxkit (before pipe) wouldn't fail the build. Sad!

Yeah thanks @eriknordmark -- I'll be using all PRs this week to fine tune our Actions usage. Will pull this one now.


⚠ Avatar API Endpoint has degraded performance

In 55f6855, Avatar API Endpoint (https://avatar.roblox.com/v1/avatar-rules) experienced degraded performance:

HTTP code: 200
Response time: 1595 ms

Resolved: Avatar API Endpoint performance has improved in a7c7e88.