Unable to Register Class TFMXApplicationDelegate - macos

Question

I've read the Embarcadero and other docs, searched the net, and obviously something isn't sinking in. I have a significantly more complex Application and DLL/Dylib, but am now just using this simple example to try and get it to work. When I build the App and DLL for Win32 it works fine and it works fine if I do not make a function call to the DLL. As soon as I make a call to the DLL the error Unable to register Class TFMXApplicationDelegate is raised and the application terminates. This behaviour is the same whether the guest OS is on a VM (parallels) or a physical device (MacBook Pro 15 mid-2015).
QUESTION: How can I ensure that TFMXApplicationDelegate gets Registered, is there a setting or permission I need to set. It seems fairly basic since, according to the Apple documentation:
The app delegate is effectively the root object of your app.
The DPR:
Library pTestDLL;
uses
uTestDLL in 'uTestDLL.pas';
{$R *.res}
end.
And here's the simple PAS file (for the Dylib):
unit uTestDLL;
interface
uses
FMX.Dialogs;
// External functions and procedures
{$IFDEF MSWINDOWS}
function say_Hello(Hello: string): boolean; stdcall; forward;
{$ENDIF MSWINDOWS}
{$IFDEF MACOS}
function _say_Hello(Hello: string): boolean; cdecl; forward;
{$ENDIF MACOS}
exports
{$IFDEF MSWINDOWS}
say_Hello;
{$ENDIF MSWINDOWS}
{$IFDEF MACOS}
_say_Hello;
{$ENDIF MACOS}
Implementation
{$IFDEF MSWINDOWS}
function say_Hello(Hello: string): boolean; stdcall;
{$ENDIF MSWINDOWS}
{$IFDEF MACOS}
function _say_Hello(Hello: string): boolean; cdecl;
{$ENDIF MACOS}
begin
Result := True;
showmessage('In DLL: ' + Hello);
end;
end.
And lastly the simple test application:
unit uDylibTest1;
interface
uses
System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants,
FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics, FMX.Dialogs, FMX.StdCtrls,
FMX.Controls.Presentation;
const
// Windows DLL Names
{$IFDEF MSWINDOWS}
TestDLL = 'pTestDLL.dll';
{$ENDIF MSWINDOWS}
// macOS DYLIB Names
{$IFDEF MACOS}
TestDLL = 'libpTestDLL.dylib';
{$ENDIF MACOS}
type
TfDylibTest = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
procedure FormCreate(Sender: TObject);
procedure FormShow(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
type
TuDylibTest = class(TForm)
private
{ Private declarations }
public
{ Public declarations }
end;
{$IFDEF MSWINDOWS}
function say_Hello(Hello: string): boolean; stdcall; external TestDLL Delayed;
{$ENDIF MSWINDOWS}
{$IFDEF MACOS}
function _say_Hello(Hello: string): boolean; cdecl; external TestDLL;
{$ENDIF MACOS}
var
fDylibTest: TfDylibTest;
implementation
{$R *.fmx}
procedure TfDylibTest.Button1Click(Sender: TObject);
var
b:boolean;
begin
showmessage('B4 function call);
b := False;
// Call the DLL Function
{$IFDEF MSWINDOWS}
b := say_Hello('The string passed to the DLL') then
{$ENDIF MSWINDOWS}
{$IFDEF MACOS}
b := _say_Hello('The string passed to the DLL');
{$ENDIF MACOS}
if b then
showmessage('Say Hello OK')
else
showmessage('Say Hello Failed');
end;
procedure TfDylibTest.FormCreate(Sender: TObject);
begin
showmessage('onCreate');
end;
procedure TfDylibTest.FormShow(Sender: TObject);
begin
showmessage('onShow');
end;
end.

Answer 1

I'm answering tis on behalf of Alexander Brazda López who posted this on the G+ Delphi forum (so I'm not taking credit for someone else's answer):
ShowMessage() use FMX.Dialogs inside a dll. I remember there were some
limitations about this and use bpl instead dll was recomended. I would
try to find some information about this. Just for check, try to use a
reversestring function for test open and calling dll functions its
working.
I cannot comment WRT the veracity of the next part of the response, but to be fair will include it. However the bottom line was that with FMX.Dialogs or FMX.Forms in the uses clause, I got the error. Remove those and the TFMXApplicationDelegate error did not occur.
In the non-trivial 'real' example, I was using the unit for showmessage and for application.processmessages which was in a cross platform function called WaitNoFreeze() which, as the name suggests, puts a wait in the main thread, but does not stop all other activity like sleep().
The problem is not that the dylib is not found, this can be checked by
calling a basic function in the dylib as function sum (a, b: integer):
integer
The problem is when we invoke the UI through some function or use
embedded resources such as forms. This is because if we do not use
bpl, local instances are created instead of shared global instances,
this prevents functions such as RegisterClass or GetMem from sharing
the data. In the case of FMX there are differences due to the api for
the example that Kevin has exposed, in Windows the Handle of the
window is not necessary, so 0 is a valid value, in MacOSX it is
necessary but the value in the dynlib is NULL since it has not been
started, although in the application, but because the FMX instances
are not shared, it is not possible to access this information. It is
the same thing that happens when we try to free a block of memory in a
dll in windows that has been allocated by the application, that is why
we must use a bpl so that the memory manager of the application and
the dll is the same and maintain the same instances regardless of
whether their methods are invoked from the dll or from the exe