Is the `VideoPlayer` component <here> published an...

# compose-desktop

[rnett]

Is the VideoPlayer component here published anywhere? I can't seem to find it in the plugin's dependency references or on maven central

[Chris Athanas]

Do you mean this: https://github.com/caprica/vlcj ?

[Chris Athanas]

In the example, they are wrapping that component. The problem I’m having is attempting to publish a MacOS .pkg compose-desktop app to the Mac App Store. It crashes when I try to open the video.

I have the VLCJ code commented out.

I’m now trying to use a web view to display video.

Here’s my project: https://github.com/realityexpander/CloudCoverUSA2

[Swapnil Musale]

When we use VLC player Multiplatform project then VLC player should be in installed in Mac system level then only it works

[Chris Athanas]

OK. I’ve been experimenting with trying to get my compose-desktop MacOS app uploaded into the App Store and having a lot of problems.

I am starting to think this is not possible yet, or that there is some crucial undocumented step that needs to be done, as all my apps are rejected when attempting to access any libraries. Plain compose-only apps work fine. But I need to play a video in my app, and I have tried two approaches, via the VideoPlayer (in the compose-desktop examples) and using a web view. Both work fine on my local machine, but not when uploaded to the AppStore.

Older versions of compose-desktop seemed to work, but the current one (compose plugin 1.6.10-dev1584) does not notarize apps properly (fail system error 65).

I am able to use the packagePkg task to build and upload the App via transporter, but the apps crash when downloaded and run when accessing any libraries. The two I have specifically tested are the VideoPlayer example and also trying to use a Webview via JCEF. For the VideoPlayer, the app crashes when accessing the Video. For the webview, It crashes the sandbox when attempting to write a file when downloading the JCEF library. Again, these all work locally.

It’s strange because the Apps pass all the security checks, but fail when downloaded from the TestFlight.

Has someone successfully pushed a MacOS .pkg to the play store that accesses these libraries? I see no examples of this yet in any of the documentation. Plain compose apps that use normal mechanisms work fine.

Any hints?

[Chris Athanas]

And asking the user to install VLC first is not acceptable for my use case. Also, the app runs fine locally without having to install VLC.

[Chris Athanas]

Update on using WebView to play video:
• Works great locally
• When packaged into a .pkg and uploaded to the AppStore and then downloaded, the app crashes when the JCEF file gets created in `main()``. Maybe there is a missing permission? I thought permissions for file access is only for outside the sandbox? The JCEF just downloads a file at startup, and thats causing the crash at the moment.

[Michael Paus]

Your problem description is very confusing and that makes it difficult to make any proposal to fix it. When you say “works great locally” what do actually mean? Running it from your IDE in debug mode or actually running the release distributable? There is a huge difference between these two. Try to install the program on your local machine via the installer you have created. (A similar effect can be achieved by just running the gradle task runReleaseDistibutable.) During the release build ProGuard is used by default and it is a typical problem that it strips something from the code which is later needed and thus makes your code fail. So, you should first verify that your installer can actually provide a working program locally. Anything else does not count. If this fails, then you know that your problem has nothing to do with the uploading to the App Store. It’s then a pure release/packaging problem.

[Chris Athanas]

Thanks for the quick response! I apologize for the confusion here, as I am a beginner to the compose-desktop, and working thru the instructions on the jetbrains site, but it is quite sparse on what I’m trying to accomplish, specifically creating a MacOS release .pkg for distribution on the Apple AppStore. I am confused here, because of the following (and lack of clear instructions):

composeDesktop/run always works fine. App works as expected with libraries.
composeDesktop/runRelease task runs to completion, the App launches but all the network calls fail. Currently investigating why.
composeDesktop/runReleaseDistributable has never worked. Only gives this error:

Execution failed for task ':composeApp:runReleaseDistributable'.
> Process 'command '/Volumes/TRS-83/dev/CloudCoverUSA2/composeApp/build/compose/binaries/main-release/app/Cloud Cover USA 2.app/Contents/MacOS/Cloud Cover USA 2'' finished with non-zero exit value 137

I am able to create a .pkg using composeDesktop/createPkg and successfully sign and upload it via Transporter to TestFlight. The App is accepted by Apple and I am able to download it via TestFlight. So I’m fairly certain the signing portion of this is all operating properly (or I found a major loophole!)

The app runs fine until I try to:
1. Display the VideoPlayer composable, which is a swingPanel wrapped component, per the example in the jetbrains compose-desktop samples.
2. Display a WebView using Kevin Zou’s library.
So Im curious:

1. Why the runRelease app doesn’t function, but run app works fine?
2. Why is the createPkg app is accepted by Apple and I can download it via TestFlight and run it fine, except for these libraries?

I guess my main question is: Is it currently possible to do this? I see other projects on the AppStore that look to be built with earlier versions of compose-desktop. Maybe I’m too early on this? I’m primarily an iOS and Android developer, and compose for those platforms works great, with zero issues like this. So forgive my ignorance!

@Michael Paus per your previous messages, you were not even aware of the ability to generate MacOS .pkg's, so I’m wondering if I’m just too early for this to work? Should I wait for this to be tested and documented?

PS I am excited about this tech, as the app runs perfectly locally… so I know its something than can be fixed somehow!

Thanks in advance!

[Chris Athanas]

Update: I got the runRelease working locally, it was a Proguard configuration issue. It runs now, and I get the following error message when I try to open the `WebView`:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000103b091a8, pid=40674, tid=84227
#
# JRE version: OpenJDK Runtime Environment Corretto-18.0.2.9.1 (18.0.2+9) (build 18.0.2+9-FR)
# Java VM: OpenJDK 64-Bit Server VM Corretto-18.0.2.9.1 (18.0.2+9-FR, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# V  [libjvm.dylib+0x27d1a8]  AccessInternal::PostRuntimeDispatch<G1BarrierSet::AccessBarrier<548964ull, G1BarrierSet>, (AccessInternal::BarrierType)2, 548964ull>::oop_access_barrier(void*)+0x8
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   <https://github.com/corretto/corretto-18/issues/>
#

---------------  S U M M A R Y ------------

Command Line: -Dcompose.application.configure.swing.globals=true -Dcompose.application.resources.dir=/Volumes/TRS-83/dev/CloudCoverUSA2/composeApp/build/compose/tmp/prepareAppResources --add-opens=java.desktop/sun.awt=ALL-UNNAMED --add-opens=java.desktop/java.awt.peer=ALL-UNNAMED --add-opens=java.desktop/sun.awt=ALL-UNNAMED --add-opens=java.desktop/sun.lwawt=ALL-UNNAMED --add-opens=java.desktop/sun.lwawt.macosx=ALL-UNNAMED -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant MainKt

Host: "MacBookPro18,3" arm64, 10 cores, 16G, Darwin 23.4.0, macOS 14.4.1 (23E224)
Time: Sat Apr 20 15:26:45 2024 CDT elapsed time: 8.081680 seconds (0d 0h 0m 8s)

---------------  T H R E A D  ---------------

Current thread (0x0000000127973000):  JavaThread "AWT-EventQueue-0" [_thread_in_vm, id=84227, stack(0x0000000177300000,0x0000000177503000)]

Stack: [0x0000000177300000,0x0000000177503000],  sp=0x0000000177501da0,  free space=2055k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x27d1a8]  AccessInternal::PostRuntimeDispatch<G1BarrierSet::AccessBarrier<548964ull, G1BarrierSet>, (AccessInternal::BarrierType)2, 548964ull>::oop_access_barrier(void*)+0x8
V  [libjvm.dylib+0x5001ac]  jni_NewGlobalRef+0xfc
C  [libjcef.dylib+0x3eb54]  ScopedJNIObjectGlobal::ScopedJNIObjectGlobal(JNIEnv_*, _jobject*)+0x2c
C  [libjcef.dylib+0x548c]  Java_org_cef_browser_CefBrowser_1N_N_1CreateBrowser+0xcc
j  org.cef.browser.CefBrowser_N.N_CreateBrowser(Lorg/cef/handler/CefClientHandler;JLjava/lang/String;ZZLjava/awt/Component;Lorg/cef/browser/CefRequestContext;)Z+0
j  org.cef.browser.CefBrowser_N.lambda$createBrowser$1(Lorg/cef/handler/CefClientHandler;JLjava/lang/String;ZZLjava/awt/Component;)V+34
j  org.cef.browser.CefBrowser_N$$Lambda$247+0x0000000800fc26d8.run()V+28
j  org.cef.browser.CefBrowser_N.executeNative(Ljava/lang/Runnable;Ljava/lang/String;)V+15
j  org.cef.browser.CefBrowser_N.createBrowser(Lorg/cef/handler/CefClientHandler;JLjava/lang/String;ZZLjava/awt/Component;)V+64
j  org.cef.browser.CefBrowserWr.createBrowserIfRequired(Z)Z+103
j  org.cef.browser.CefBrowserWr$1$1.run()V+151
J 3204 c1 java.awt.event.InvocationEvent.dispatch()V java.desktop@18.0.2 (69 bytes) @ 0x000000012a3d4f14 [0x000000012a3d4cc0+0x0000000000000254]
J 3148 c1 java.awt.EventQueue.dispatchEventImpl(Ljava/awt/AWTEvent;Ljava/lang/Object;)V java.desktop@18.0.2 (136 bytes) @ 0x000000012a3aff94 [0x000000012a3ae040+0x0000000000001f54]
J 3271 c1 java.awt.EventQueue$4.run()Ljava/lang/Void; java.desktop@18.0.2 (60 bytes) @ 0x000000012a40add0 [0x000000012a40ac80+0x0000000000000150]
J 2863 c1 java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V java.desktop@18.0.2 (80 bytes) @ 0x000000012a2e1714 [0x000000012a2e1180+0x0000000000000594]
J 3149 c1 java.awt.EventDispatchThread.pumpOneEventForFilters(I)V java.desktop@18.0.2 (113 bytes) @ 0x000000012a3b1e4c [0x000000012a3b1780+0x00000000000006cc]
j  java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+35 java.desktop@18.0.2
j  java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11 java.desktop@18.0.2
j  java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4 java.desktop@18.0.2
j  java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3 java.desktop@18.0.2
j  java.awt.EventDispatchThread.run()V+9 java.desktop@18.0.2
v  ~StubRoutines::call_stub
V  [libjvm.dylib+0x4a59ac]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x390
V  [libjvm.dylib+0x4a4a18]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0xf8
V  [libjvm.dylib+0x4a4ae0]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x64
V  [libjvm.dylib+0x557ea0]  thread_entry(JavaThread*, JavaThread*)+0x9c
V  [libjvm.dylib+0x992aac]  JavaThread::thread_main_inner()+0xb4
V  [libjvm.dylib+0x9913f8]  Thread::call_run()+0xe0
V  [libjvm.dylib+0x7df968]  thread_native_entry(Thread*)+0x158
C  [libsystem_pthread.dylib+0x6f94]  _pthread_start+0x88

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.cef.browser.CefBrowser_N.N_CreateBrowser(Lorg/cef/handler/CefClientHandler;JLjava/lang/String;ZZLjava/awt/Component;Lorg/cef/browser/CefRequestContext;)Z+0
j  org.cef.browser.CefBrowser_N.lambda$createBrowser$1(Lorg/cef/handler/CefClientHandler;JLjava/lang/String;ZZLjava/awt/Component;)V+34
j  org.cef.browser.CefBrowser_N$$Lambda$247+0x0000000800fc26d8.run()V+28
j  org.cef.browser.CefBrowser_N.executeNative(Ljava/lang/Runnable;Ljava/lang/String;)V+15
j  org.cef.browser.CefBrowser_N.createBrowser(Lorg/cef/handler/CefClientHandler;JLjava/lang/String;ZZLjava/awt/Component;)V+64
j  org.cef.browser.CefBrowserWr.createBrowserIfRequired(Z)Z+103
j  org.cef.browser.CefBrowserWr$1$1.run()V+151
J 3204 c1 java.awt.event.InvocationEvent.dispatch()V java.desktop@18.0.2 (69 bytes) @ 0x000000012a3d4f14 [0x000000012a3d4cc0+0x0000000000000254]
J 3148 c1 java.awt.EventQueue.dispatchEventImpl(Ljava/awt/AWTEvent;Ljava/lang/Object;)V java.desktop@18.0.2 (136 bytes) @ 0x000000012a3aff94 [0x000000012a3ae040+0x0000000000001f54]
J 3271 c1 java.awt.EventQueue$4.run()Ljava/lang/Void; java.desktop@18.0.2 (60 bytes) @ 0x000000012a40add0 [0x000000012a40ac80+0x0000000000000150]
J 2863 c1 java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V java.desktop@18.0.2 (80 bytes) @ 0x000000012a2e1714 [0x000000012a2e1180+0x0000000000000594]
J 3149 c1 java.awt.EventDispatchThread.pumpOneEventForFilters(I)V java.desktop@18.0.2 (113 bytes) @ 0x000000012a3b1e4c [0x000000012a3b1780+0x00000000000006cc]
j  java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+35 java.desktop@18.0.2
j  java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11 java.desktop@18.0.2
j  java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4 java.desktop@18.0.2
j  java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3 java.desktop@18.0.2
j  java.awt.EventDispatchThread.run()V+9 java.desktop@18.0.2
v  ~StubRoutines::call_stub

So it’s definitely crashing when trying to create the web browser: org.cef.browser.CefBrowser_N.N_CreateBrowser

[Michael Paus]

How did you come to the conclusion that I “were not even aware of the ability to generate MacOS `.pkg's`”? I am creating DMGs and sometimes PKGs already for more than two years now on a regular basis in my own projects.

To answer your questions:

The main difference between the simple run and the runRelease variants are the ProGuard optimisation and the packaging step. They both can introduce errors if they are not configured properly.

Via modules you have to specify a list of java modules to package with your application. Otherwise jpackage will guess which modules are needed but this is not always correct. In order to make sure that this is not your problem here try to use includeAllModules = true for the moment. (See: https://github.com/JetBrains/compose-multiplatform/tree/master/tutorials/Native_distributions_and_local_execution#configuring-included-jdk-modules)

The other source for errors is ProGuard. In order to make sure that it does not create your problem here just switch it off for the moment. Example:

buildTypes.release {
    proguard {
        version.set("7.4.2")
        isEnabled.set(false)
        optimize.set(false)
        obfuscate.set(false)
        configurationFiles.from(project.file("<http://compose-desktop.pro|compose-desktop.pro>"))
    }
}

You should also specify the latest version of ProGuard like in the example, because you can then also use a later version of Java like 21 for example. You also might want to use a different distribution than Corretto. I use Temurin for example.

If after all this you still get errors, then there must be a specific problem with your libraries. In general, when configured correctly, the packaging works reliably. I am distributing packaged applications for all 3 major desktop platforms, including shared libraries, for quite some time now without problems.

One conclusion so far is that your problem is not related to the upload to Apple because, as you have already found out, you can not even run your packaged release locally. So the release is broken even without Apple being in the loop.

[Chris Athanas]

@Michael Paus Thanks for the quick and thorough reply!

RE: `.pkg`old post: I saw in one of the threads on this slack (somewhere in the pile…), where you said in a reply that you were not aware of the ability to create .pkg's. It’s an old message and saw it in passing which is why I started thinking this was not possible to create pkg’s with the current versions of compose, as the process is very lightly covered, and there is no detailed walk-thru on this yet. If you would like me to find the source of your quote, I will do so, just let me know.

> you can not even run your packaged release locally.
I finally got the runRelease generated apps running locally, and it was indeed a proguard configuration step. Given that Apple accepted my regular .pkg (not generated using release and proguard), am I to assume that using proguard is optional? It seems optional. I have no reason to obfuscate or minimize my code at the moment, so I was intentionally trying to leave out that step in order to minimize the number of problems to solve attempting to get this external library issue fixed.

I have been using the includeAllModules = true , but it doesn’t seem to make a difference.

Still crashes when attempting to access the VLCJ java library. This one seems to be associated with permissions, I see no compose-desktop documentation about how to approach this problem.

> I am distributing packaged applications for all 3 major desktop platforms, including shared libraries, for quite some time now without problems.
Are you including libraries like the WebView or VideoPlayer in your apps? Are you distributing these apps via the AppStore, or some other means?

Pure Kotlin-only libraries can be added to the commonMain with no issues. It’s these wrappers around native libraries that I’m having problems with. 🤨

Thanks again in advance for your help and any insights!

[Chris Athanas]

And accessing the WebView causes a different crash, seems to also be related to permissions. Any clues on how to resolve this for MacOS?

I tried build this with JDK Temurin 21.0.2, but got a build error saying version was incompatible with gradle version.

I tried JDK Temurin 20.0.2, and it had no different result as the results with JDK’s Corretto 18.0.2 & Corretto 20.0.1. These library-access issues seem to be independent of JDK version.

[Michael Paus]

The statement about PKGs is still strange because I have also created PKGs via jpackage (which is used internally here too) long before I switched to Compose back in my JavaFX days. I even contributed to the development of jpackage itself at that time.
To answer some of your questions. ProGuard is enabled by default for release builds but you can switch it off as I showed in the example config above. In so far it is indeed optional.

Are you including libraries like the WebView or VideoPlayer in your apps?

Yes. Not these libraries in particular but others like sqlite for example.

Are you distributing these apps via the AppStore, or some other means?

I do not currently distribute my software via the AppStore. So, I can’t help with that particular issue. I just wanted to make sure that your release artefacts really work locally before you upload them to Apple.
The gradle incompatibility can be fixed by only using Java 21 for the packaging. This can be achieved by setting javaHome in the build configuration or by switching to the latest gradle which hopefully supports Java 21 out of the box. But that is probably not relevant for your current problems.

compose.desktop {
    application {
        mainClass = "MainKt"
        javaHome = ...

[Chris Athanas]

@Michael Paus Thanks for the quick reply!

I am thinking there is something different about how these particular libraries are handled. For example, the WebView library downloads a java package upon launch and attempts to run it. It seems that this is what is causing the security errors. The downloaded files are not signed, and i’m not sure what it takes to solve this, or if it’s even on anyone’s radar.

It works fine in the IDE and demos, so maybe that’s all its intended purpose (showing the experimental examples for compose-desktop)? Just to show the possibilities?

The VideoPlayer is a wrapper around a Swing component, and maybe there are special steps needed to integrate this for MacOS due to all this permissions declarations and signing of files? All these errors are directly related to permissions configurations that work fine in the IDE sandbox but not for produced apps.

These issues are MacOS specific, and don’t occur with windows or linux. These all seem to be related to these specific libraries. I am not seeing any other projects using these libraries in production yet, so I’m leaning on my intuition that this isnt ready yet, and I’ll have to wait for another pioneer to show the way, as this is beyond my current skillset to resolve as it requires much deeper understanding of the interrelation of the JDK and MacOS development. I’m an Android, iOS & Web dev, and I can’t take on the dive into the deep details of another platform at this time!

I saw there was quite a bit of talk around integrating the sqlite libraries, maybe those problems still exist for these particular libraries.

I hope someone sees this or is working on it, because linking these libraries should not be as difficult as it appears to be!

Thanks again for the feedback and advice, and at this point I’m going to punt, and wait for jetbrains to show a full example on how to include these libraries that work just fine in the demos! 😀

[Chris Athanas]

I recently published the iOS version of my Compose KMP app “Cloud Cover USA 2,” and Apple is now making it also available as a MacOS Desktop app! With this version the native movie player works just like the iOS App running on a phone or iPad. No need for Java swing libraries… any standard KMP libraries made for iOS will work out of the box.

So this looks like an alternative solution for deploying MacOS Compose-desktop apps to the AppStore, and the associated problems with the signing permissions for java libraries (that work fine in the IDE sandbox, but there is no documentation about how to get this working for apps distributed on the Apple AppStore.)

Instead of targeting MacOS, you just target iOS, and you will automatically be able to run on MacOS desktop.

This greatly simplifies Apple-targeted KMP app development in many ways. I’m not sure why the MacOS Desktop target needs to exist at this point? Maybe the KMP documentation needs to be updated to reflect this reality, because there is zero mention of it anywhere. I found it by accident.

Here’s the app in the Apple AppStore as proof of concept: https://apps.apple.com/us/app/cloud-cover-usa-2i/id6499233780

Hope this helps someone!

[Michael Paus]

For completeness you should mention, that this only works on ARM macs but not on older Intel ones.

[William Walker]

@Chris Athanas I was experiencing the same issue with my compose desktop project. Even with includeAllModules = true, I couldn’t use the runReleaseDistributable task targeting macOS. debug app would build and run (uber jar), release dmg build failed (proguard jar), pkg build worked but app wouldn’t run after installation with dylib errors like what you were seeing. Based on context of this and other discussions in this Slack community, changing path of installed java SDK to version 21.0.3-tem worked (don’t need javaHome param in compose.desktop{ application {}} block). I used sdkman for simplicity:
sdk install java 21.0.3-tem

Can also enforce in your builds by using jvmToolchain(21) and foojay-resolver-convention gradle settings plugin I believe. Since you’re using lots of third-party deps (some of which are wrappers), if they’re built with an earlier jdk version you may be out of luck. I did find @Michael Paus’s proguard config block necessary in order for builds to succeed. An older version is likely used by default:

buildTypes.release {
   proguard {
      version.set("7.4.2")
      isEnabled.set(false)
      optimize.set(false)
   }
}

Edit to add versions:

compose-multiplatform-plugin = "1.6.10-beta02"
kotlin = "2.0.0-RC1"

implementation(compose.desktop.macos_arm64)

Only building for macOS arm, M1 Pro

[Chris Athanas]

@William Walker Thanks for the thoughtful reply! I’m glad I’m not the only one experiencing these issues!

Per @Michael Paus advice, I am using the Java 21.0.3-tem, with same erroneous results you describe.

The only major difference is you are using Kotlin 2.0.0-RC1 and jvmToolchain(21) .

Are you able to get the VideoPlayer or WebView components to work in your desktop app?

Given that the technique you describe only works with Apple silicon macs and that these older libraries are likely going to be incompatible, as well as Apple is now allowing iOS apps to be available on the Desktop (and Apple Vision!), I’m having trouble seeing the value in creating Mac Desktop target for new apps. Apple hasn’t produced a Intel-based mac since 2021.

I would still like to try your suggestions, do you have a sample project I can look at?

[William Walker]

I am trying to explore the route you went- compiling shared compose to full native (but need to get up to speed on swift dev)

[Chris Athanas]

@William Walker I checked your code, thanks for sharing that!

I don’t see where you have added the VideoPlayer or WebView libraries for the desktop target.

I am able to compile, build and distribute MacOS desktop apps that use pure native Kotlin KMM/KMP libraries without any issues.

The issue appears when I try to include these wrappers around Java libraries (VideoPlayer and webView), that use swing components or download JCEF libraries. Those things don’t work, and there is no solution that I’m currently aware of. Hopefully someone at Jetbrains is working on this. It’s not hard to reproduce.

The issue appears to be a privacy violation, as I can see the code in the stack dump referring and running library code. I’m not a MacOS dev, so I don’t really know what the problem really is, nor how to fix it.

Thanks for your input, it helps narrow down the problem space we are all encountering! WE GONNA WIN THIS RACE!

[Chris Athanas]

@William Walker It’s this component I’m referring to: https://github.com/JetBrains/compose-multiplatform/blob/master/experimental/components/VideoPlayer/library/build.gradle.kts

The uk.co.caprica:vlcj:4.8.2 is the video player library that uses swing. Attempting to access this library at runtime causes a permissions fault & app crash.

[William Walker]

I see, thank you for re-clarifying it’s about consuming the java (native) libraries. Will try accessing those from my app. macOS nowadays frowns on apps using unsigned libs (you’re probably already aware of this. dylib error i was getting was on skiko). my random guess is these projects may have to be re-compiled with new jdk in order to be notarized for use in other projects.

[Chris Athanas]

@William Walker Yes, I would like to see a good solution for this, as its working locally, so I know it’s possible! It’s definitely a JDK interop issue and above my skillset to diagnose. It seems the desktop targeting has issues on windows as well. Maybe JetBrains will be addressing these soon because Compose KMP is currently snowballing into a cross-platform juggernaut.

[Michael Paus]

You could speed up this process by creating an issue on JetBrains GitHub with an as simple as possible reproducer 😉.

[Chris Athanas]

@Michael Paus I’ll file one now that I have a bit more confirmation that it’s not just a skill issue on my part.

Here’s the link to the report, if you want to follow it.
https://github.com/JetBrains/compose-multiplatform/issues/4712

[Michael Paus]

I think your problem is a very special case. After removing all the signing and notarisation stuff from the build config (I don’t have an apple account so that I could just provide my own credentials) I was able to execute run, runRelease and runReleaseDistributable without problems. But, the application tries to use some library from an installed VLC.app as soon as you hit the 5 days button and fails if VLC is not installed on the target system. I don’t know for sure but I believe that this will never be compatible with Apples security policies for the AppStore. I think this is not a technical problem but a security policy problem where we cannot do much about.

[Chris Athanas]

Thanks for the feedback! Yes, the runXXXX work locally, but don’t work when uploaded and downloaded via a the Apple AppStore. Can you test that route?

[Michael Paus]

No, as I said I can’t sign or upload anything to Apple because I do not have an Apple developer account.

[Chris Athanas]

@Michael Paus Ah, ok. Well, that is the main issue I’m encountering, ie: distributing via the App Store. Hoping there is a fix, but the workaround of simply targeting iOS will solve my immediate problem. Thanks for the feedback!