iOS publish app Verify not passed

[robitsrl]

PDFtoImage version

5.1.1

OS

macOS

OS version

iOS

Architecture

arm64

Framework

(Other)

App framework

MAUI NET9

Detailed bug report

Hi,
Eveythings is fine with the lib until you try to publish the app on the Apple store.
The Verify process before doing the upload complein about libpdfium.dylib that can not be used compiled but need a bundle.
I found same articol about this and same one fixed exporting the library in iOS framework but it’a too skilled for me as a principiant maui developer.

[sungaila]

Hi @robitsrl,

unfortunately, you have to wrap the libpdfium.dylib yourself before creating the Apple Store release.

The iOS binaries are taken from this project so you could ask them to pre package these binaries with each release. I don't own any Apple hardware and can't do or test this myself.

What we need are iOS NuGet packages that wrap the libpdfium.dylib as pdfium.framework. That would be super convenient.

Greetings,
David

[SyntaxSnafu]

I think I’ve managed to wrap the pdfium dylib into a framework. The reason I hadn’t succeeded earlier was that in Unity, the import needed to be changed from "pdfium" to "__Internal".

As a result, I now have two PDFToImage.dlls:

• One for all platforms except iOS
• One specifically for iOS, with the import swapped to "__Internal"

I can’t fully verify that it’s working yet, because right after fixing that, I ran into the same error for SkiaSharp not being found. It looks like SkiaSharp has the same issue. Since SkiaSharp loads things internally rather than via DllImport (within PDFToImage), the next step would be to rebuild SkiaSharp’s SkiaApi.cs to use "__Internal". I’m currently running into build issues there, and it’s a bit outside my expertise, so I’m not sure I’ll be able to complete that part.

I don't know if the __Internal part applies outside of Unity application.

Hopefully this info helps the next person who can tackle that last piece and share the fix!

[sungaila]

@SyntaxSnafu Thanks for sharing this info!

I cannot help with the framework wrapping thing, but I might help by fixing the DllImport.

According to this comment, I would have to use "__Internal" for the DllImport and set <NativeReference> for the iOS build.

I will create a new Unity release 5.1.3 and ask you, @SyntaxSnafu, to retest this one. Then you may not need to set __Internal yourself then.

The issue comment was about a static iOS lib. I use these dynamic iOS libs, though. So changing the DllImport or setting NativeReference isn't helping here.

[SyntaxSnafu]

Yes one solution is to use static instead of dynamic.
But if you have to use dynamic then wrapping into a framework is the only way and to access a framework from unity you have to use __Internal. (At least from what I've found)
Though if there are static versions of those libraries that's perfect and resolves the issue in a much easier way.