Hello Apple Support Team,
We are developing a macOS application that allows users to import and view PST files (Microsoft Outlook archives). These files contain a complex, proprietary format that requires specialized parsing libraries. To achieve this, we are using Aspose Email for Java, which is currently one of the few reliable libraries that support complete PST parsing across platforms.
Why we are using Java & Aspose
The Aspose Email Java library provides a comprehensive API to extract mail data (including metadata, attachments, and folder structure) from .pst files.
A native Swift or Objective-C alternative with full .pst parsing capability does not exist, which is why we opted for a Java-based helper module that runs in the background and communicates with the macOS app over a Unix domain socket.
How we bundle it
We package the AsposeEmail.jar and a custom JRE (Java Runtime Environment) created using jlink, tailored to run only our jar.
This entire setup (JAR + JRE) is bundled within the Contents/Resources directory of the macOS app, and we invoke the Java runtime using standard process launch APIs from Swift.
Problem during App Store Submission
When we archive the app and submit it to the App Store, the validation step raises an error:
ITMS-90284: Invalid Code Signing - The executable 'com.app.sample.appstore.pkg/Payload/Sample.app/Contents/Resources/custom-jre-universal/lib/cli ent/libjsig.dylib' must be signed with the certificate that is contained in the provisioning profile.
ITMS-90284: Invalid Code Signing - The executable 'com.app.aample.appstore.pkg/Payload/Sample.app/Contents/Resources/custom-jre-universal/lib/cli ent/libjvm.dylib' must be signed with the certificate that is contained in the provisioning profile.
When we attempt to code sign the custom JRE, especially the .dylib files inside, the runtime breaks. Java is unable to launch correctly and throws permission errors and execution failures.
Alternative we thought of (On-Demand Download)
To avoid the code signing issue, we decided to remove the JRE from the bundle and instead download it on demand when the user performs an action like "Import PST".
However, we realized this may violate the App Store Review Guideline 2.5.2:
Our use case, while not dynamically modifying features, does download and execute a Java runtime, which could be interpreted as executing new code post-installation.
How can we proceed?
We are looking for Apple’s guidance on the correct and compliant path forward:
Is there a recommended way to bundle and codesign a custom JRE so it is accepted by the App Store?
Is on-demand download of a custom runtime for a very specific parsing task permitted, assuming it doesn't modify app features but simply supports user-initiated operations?
We would greatly appreciate any guidance or best practices on how to handle this situation, particularly with respect to App Store compliance.
Regards,
Maaz Hussain
Topic:
App Store Distribution & Marketing
SubTopic:
TestFlight
Tags:
App Store
App Review
TestFlight
Code Signing