In fact, the Delphi compilers have been refactored to be split in:

  • Front-end compiler, which compiles the Delphi source code (but with "classic" or "NextGen" exclusive flavors);
  • Back-end compiler, which generates the binary and links into an executable (may be internal, or LLVM-based).

Currently, Delphi has several cross-compiling tool-chains: it is able to compile, from a 32 bit Windows IDE, to Win32, Win64, OSX, Android and iPhone.
Sounds like if all targets would be reachable with a single source.

Sadly, in practice, you can not share directly your code between "classic" and "NextGen" targets.
If you stick to RAD components, you may not have any particular issue, since all your memory allocation would be defined by TComponent ownership, on all targets.
But if you start writing real OOP code, involving classes, you would reach the breaking changes. The main change being that TObject.Free does nothing on "NextGen"... In real business code, the class destructor does more than just releasing the memory: it would also release resources and react to some business logic. So your code starts to be polluted with $ifdef NEXTGEN blocks, just to call DisposeOf on one target, and Free on another.. For no benefit...

On the other hand, FreePascal (FPC) is a true single cross-compiler.
You have a single compiler, able to compile several flavors of object pascal (including most Delphi syntax, and even a Objective Pascal mode targeting OSX or iOS), then generate assembler and/or binary, using either internal or external tools. You can cross-compile for Linux under Windows, or vice-versa, just from the Lazarus IDE. You can compile for Android or iOS under Windows, Linux or OSX...
Then the RTL would take care of abstracting most of the low-level OS particularities under Windows, Linux, BSD or several other exotic systems. And the LCL will generate UI for several targets.
With a single memory model, sharing most of your source code on all targets... In fact, the object pascal flavors are handled via non exclusive modes, at unit level, so you have the maximum flexibility at hand.

So please be aware that using Delphi for mobile applications is a nice possibility.
The IDE is pleasant, and FMX does pretty good work to leverage the diverse UI targets.
But do not believe that it is all magic, and that a single re-compile will be sufficient: since the compiler is not the same, you would probably need some deep knowledge of the platforms, just to manage the diverse memory model, and reach the right API.

In all cases, do not put your logic (e.g. your SQL) within your mobile app.
A two-tier architecture is clearly not a good design. You would need to re-publish your application - which can be painful - just to fix some little point of logic.
Consider switching to true n-Tier SOA (n>=3), writing your logic on the server side - perhaps using mORMot - then consume those services on your mobile app, which would be a rich be logic-less client.