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. >> >
