Is that issue tracked by the webkit project? Ideally they could fix the
issue in the upstream
On 21/02/2026 17:52, Laurin Murer wrote:
Almost two years later, and I still was not able to publish my app to the App
Store (granted, I gave up for a while).
Now I tried it again, after updating to Java (and FX) 25. However, this issue
still persists. Apples exact wording:
Guideline 2.5.1 - Performance - Software Requirements
Your app uses or references the following non-public or deprecated APIs:
Contents/runtime/Contents/Home/lib/libjfxwebkit.dylib
Symbols:
• _cache_simulate_memory_warning_event
The use of non-public or deprecated APIs is not permitted on the App Store, as
they can lead to a poor user experience should these APIs change and are
otherwise not supported on Apple platforms.
Next Steps
It would be appropriate to revise your binary and remove any references to the
non-public or deprecated APIs identified above.
If you are using third-party libraries, update to the most recent version of
those libraries. If you do not have access to the libraries' source, the
following command line tools can help you identify the location of problematic
code:
- The "strings" tool can output a list of the methods the library calls.
- The "otool -ov" tool will output the Objective-C class structures and their
defined methods.
I doubt, that anyone was able to submit a new App with JavaFX-Web to Apples App
Store in the last few years. This is such a pity, that’s why I give it another
try.
Can anyone help me with that? Michael Hall already had the idea to add a
compiler directive similar to one which was there before 2016-12-14 and no-oped
the problematic memory-cleanup-call for certain platforms/versions.
Does anyone have another idea or is willing to bring this idea forward?
On 13 Jun 2024, at 21:31, Laurin Murer <[email protected]> wrote:
Yes, it sounds like the method cache_simulate_memory_warning_event was never
public (at least I couldn’t find any documentation about it) and Apple started
to enforce its removal. As far as I can tell, a user of JavaFX web cannot fix
this and has currently no chance of publishing a (new?) app to Apples App Store.
For a bit of context, this call is inside the method
MemoryPressureHandler::platformReleaseMemory which is implemented differently
on different platforms:
- cocoa (Mac): with the discussed method
- generic: does nothing (empty implementation)
- unix: calls `malloc_trim(0);`
- win: does nothing (empty implementation)
The currently only solution is the one of Michael Hall to add a compiler
directive similar to one which was there before 2016-12-14 and no-oped it for
certain platforms/versions. I guess this idea would fix the problem of
submitting it to Apples App Store.
Does anyone have another idea or is willing to bring this idea forward?
On 7 Jun 2024, at 17:48, Michael Hall <[email protected]> wrote:
Sorry, I did a little more digging on this.
My best guess is that Apple is rejecting this because they think you are using
a non-public API of their own.
The OpenJFX version of MemoryPressureHandlerCocoa.mm matches what appears to be
the current WebKit version. [1]
Older versions appear somewhat different. Including this…
#if PLATFORM(IOS) || __MAC_OS_X_VERSION_MIN_REQUIRED >= 101000
[2][3]
[3] seems to show where this code was actually introduced with the above
included.
It might be that for a Cocoa version it was thought that this compiler
directive wasn’t needed but it actually still is?
Anyhow, adding something similar now might achieve a no-op that would get past
them flagging this as an error.
‘locate’ on my machine doesn’t seem to show the libcache.dylib mentioned
anywhere other than Xcode and other developer locations.
[1]
https://github.com/WebKit/webkit/blob/main/Source/WTF/wtf/cocoa/MemoryPressureHandlerCocoa.mm
[2]
https://opensource.apple.com/source/WebCore/WebCore-7601.5.17/platform/cocoa/MemoryPressureHandlerCocoa.mm.auto.html
[3]
https://fossies.org/diffs/WebKit/r174650_vs_r189384/Source/WebCore/platform/cocoa/MemoryPressureHandlerCocoa.mm-diff.html
On Jun 6, 2024, at 6:41 PM, Michael Hall <[email protected]> wrote:
Odd, but searching shows this used in a different places and nowhere does it
appear anyone has made any changes to the symbol referencing code.
It seems like some applications should of used this same code as-is.
Sort of strange.
I’m done with what digging I think I’m going to do.
GL.
