Creating dylibs for iOS

[TurboMagic 91]

I have some code written in Delphi which should be reused in mobile projects which are unfortunately not written in Delphi.

I have found out that for Android you can create a shared object .so. Strangely not via using the DLL project type but by using
the normal cross platform GUI type and then stripping off the GUI support.

 

Now the question is, can I achieve something similar for iOS?
Can I create a dynamic or static library some other iOS programming environment can consume?

 

I just found this help topic:
https://docwiki.embarcadero.com/RADStudio/Sydney/en/API_(*.bpl,_*.dylib,_*.so)

Would that be a way? (I haven't developed any packages yet and I would only want to export procedural stuff)

Edited March 19 by TurboMagic

[darnocian 70]

If you want to export for other languages, a DLL project is what you want. when you switch platform the project will generate a so, etc.  You just need to add the exports. Note that symbols may be exported differently on different platforms. E.g. there may be an _ in front of names when importing… best way to validate is to dump exports on the shared object once it is created.i haven’t tested android recently, but did Linux.

Edited March 20 by darnocian

[TurboMagic 91]

Thanks for the reply. As I haven't done any iOS development yet I don't have a MAC yet and thus wanted
to investigate first whether it is possible for iOS at all.

 

For Android it is possible but as written not via a library/DLL project! That won't properly work!
As described one needs to generate a FMX project for this, as each of those generates an SO
and then you strip out the FMX part and only grab the generated SO, which in a normal FMX project
would be packed into the APK/AAB.

[Dave Nottage 493]

On 3/19/2024 at 6:10 PM, TurboMagic said:

Can I create a dynamic or static library some other iOS programming environment can consume?

https://stackoverflow.com/a/36041595/3164070

[TurboMagic 91]

Thanks for the answer! Does this mean this is "self contained"? That's how I understood this. For as non package developer
it always sounded like packages require that you provide the used RTL packages as well, but I guess this is not the case here?

[TurboMagic 91]

Another question turned up now: from the shared objects (.so) I can create for Android I know, that I need to create one for 32 bit and one for 64 bit
and need to place them into the right folders on the target device via deployment manager. Both have the same name though.

 

Now what about .a files?
When I generate them for 32 and 64 bit they will get output in the ios32 and ios64 or Android32 and Android64 subolders I guess.
But the user of them using a different programming environment,, how has he to handle them? Place them into bitnnes/cpu dependant folders
and have something conditional in his application so the right variant will be linked in?

[darnocian 70]

Sorry. A bit late to answer now...

 

.a files is a normally a C static library. In C are essentially a container around compiled .o files. There is no point to distribute .a files, unless someone is going to link against it. Typically static libraries are only useful during dev for users of libraries, and not so much for applications as they would get linked in. 

 

Your main deliverables from an app perspective would be the executable along with any shared libraries (dlls/so/dylib). Nothing stopping you from shipping anything you want of course.

 

With shared library, the developer using the shared lib just needs to know the directory and filename, and then reference the library and functions appropriately as required. The main thing is that it is clear what platform is used and being able to distinguish 32/64bit. There is no universal convention from what I'm aware of. If you are using Delphi, use the Delphi convention... it is clear enough. <platform>/<configuration>. although, if you are only going to ship release builds, just do <platform>

Edited March 29 by darnocian

[TurboMagic 91]

Sorry, but it's now still unclear how to handle iOS in this regards (I don't have the toolchain for this one yet):

 

1. Can Delphi create a dylib for iOS somebody else wih some other language could consume?
   (the StackOverflow post doesn't talk about dylibs)
   I know that it can for Android if creating a normal FMX app and stripping the FMX part out of that. But for iOS?
 

2. What would speak against .a files? What's the downside of those getting linked into the application of the person
    consuming those?

 

I simply need to create something somebodfy else in some different language has to use and that needs to work
on Android and on iOS. And before investing time into some implementation which will not work on iOS at the end
I wanted to get clarification about that one.

[TurboMagic 91]

So the recommendation is still the one from the stack overflow post: to build a static lib, which results in a .a file?