Javapackager Create Mac App
JavaPackager is a hybrid plugin for Maven and Gradle which provides an easy way to package Java applications in native Windows, Mac OS X or GNU/Linux executables, and generate installers for them. SNAPSHOT version is not released to Maven Central, so you have to install it manually. 👀 See JavaPackager changes and fixes. Launching a GUI app from the command line is not convenient at all. Pic split app mac. One option is to assemble the.app package using Launch4j. However, I didn't have enough patience to do apply the tool. So I tried looking for an alternative solution. So I found this guide: Packaging a Java App for Distribution on a Mac. And the instructions worked just fine! Since Java 1.8 the javapackager tool has been in the JDK. It can produce native executables for windows, linux, and Mac OS. It includes a runtime. If you use Java 1.9 and write modularized code javapackager will use jlink to only include the parts of the JDK you need in the runtime it packages with your app. Here is the 1.8 documentation.
-->Apple lets you purchase multiple licenses for an app that you want to use in your organization on iOS/iPadOS and macOS devices using Apple Business Manager or Apple School Manager. You can then synchronize your volume purchase information with Intune and track your volume-purchased app use. Purchasing app licenses helps you efficiently manage apps within your company and retain ownership and control of purchased apps.
Microsoft Intune helps you manage apps purchased through this program by:
- Synchronizing location tokens you download from Apple Business Manager.
- Tracking how many licenses are available and have been used for purchased apps.
- Helping you install apps up to the number of licenses you own.
Additionally, you can synchronize, manage, and assign books you purchased from Apple Business Manager with Intune to iOS/iPadOS devices. For more information, see How to manage iOS/iPadOS eBooks you purchased through a volume-purchase program.
What are location tokens?
Location tokens are also known as Volume Purchase Program (VPP) tokens. These tokens are used to assign and manage licenses purchased using Apple Business Manager. Content Managers can purchase and associate licenses with location tokens they have permissions to in Apple Business Manager. These location tokens are then downloaded from Apple Business Manager and uploaded in Microsoft Intune. Microsoft Intune supports uploading multiple location tokens per tenant. Each token is valid for one year.
How are purchased apps licensed?
Purchased apps can be assigned to groups using two types of licenses that Apple offers for iOS/iPadOS and macOS devices.
| Action | Device Licensing | User Licensing |
|---|---|---|
| App Store sign-in | Not required. | Each end user must use a unique Apple ID when prompted to sign in to App Store. |
| Device configuration blocking access to App Store | Apps can be installed and updated using Company Portal. | The invitation to join Apple VPP requires access to App Store. If you have set a policy to disable App Store, user licensing for VPP apps will not work. |
| Automatic app update | As configured by the Intune admin in Apple VPP token settings. If the assignment type is available for enrolled devices, available app updates can also be installed from the Company Portal by selecting the Update action on the app details page. | As configured by the Intune admin in Apple VPP token settings. If the assignment type is available for enrolled devices, available app updates can also be installed from the Company Portal by selecting the Update action on the app details page. |
| User Enrollment | Not supported. | Supported using Managed Apple IDs. |
| Books | Not supported. | Supported. |
| Licenses used | 1 license per device. The license is associated with the device. | 1 license for up to 5 devices using the same personal Apple ID. The license is associated with the user. An end user associated with a personal Apple ID and a Managed Apple ID in Intune consumes 2 app licenses. |
| License migration | Apps can migrate silently from user to device licenses. | Apps cannot migrate from device to user licenses. |
Note
Company Portal does not show device-licensed apps on User Enrollment devices because only user-licensed apps can be installed on User Enrollment devices.
What app types are supported?
You can purchase and distribute public as well as private apps using Apple Business Manager.
- Store apps: Using Apple Business Manager, Content Managers can buy both free and paid apps that are available in the App Store.
- Custom Apps: Using Apple Business Manager, Content Managers can also buy Custom Apps made available privately to your organization. These apps are tailored to your organization's specific needs by developers with whom you work directly. Learn more about how to distribute Custom Apps.
Prerequisites
- An Apple Business Manager or Apple School Manager account for your organization.
- Purchased app licenses assigned to one or more location tokens.
- Downloaded location tokens.
Important
- A location token can only be used with one device management solution at a time. Before you start to use purchased apps with Intune, revoke and remove any existing location tokens used with other mobile device management (MDM) vendor.
- A location token is only supported for use on one Intune tenant at a time. Do not reuse the same token for multiple Intune tenants.
- By default, Intune synchronizes the location tokens with Apple twice a day. You can initiate a manual sync at any time from Intune.
- After you have imported the location token to Intune, do not import the same token to any other device management solution. Doing so might result in the loss of license assignment and user records.
Migrate from Volume Purchase Program (VPP) to Apps and Books
If your organization has not migrated to Apple Business Manager or Apple School Manager yet, review Apple's guidance on migrating to Apps and Books before proceeding to manage purchased apps in Intune.
Important
- For the best migration experience, migrate only one VPP purchaser per location. If each purchaser migrates to a unique location, all licenses — assigned and unassigned — will move to Apps and Books.
- Do not delete the existing legacy VPP token in Intune or apps and assignments associated with existing legacy VPP token in Intune. These actions will require all app assignments to be recreated in Intune.
Migrate existing purchased VPP content and tokens to Apps and Books in Apple Business Manager or Apple School Manager as follows:
- Invite VPP purchasers to join your organization and direct each user to select a unique location.
- Ensure that all VPP purchasers within your organization have completed step 1 before proceeding.
- Verify that all purchased apps and licenses have migrated to Apps and Books in Apple Business Manager or Apple School Manager.
- Download the new location token by going to Apple Business (or School) Manager > Settings > Apps and Books > My Server Tokens.
- Update the location token in Microsoft Endpoint Manager admin center by going to Tenant administration > Connectors and tokens > Apple VPP tokens and manually upload the token.
Upload an Apple VPP or location token
- Sign in to the Microsoft Endpoint Manager admin center.
- Select Tenant administration > Connectors and tokens > Apple VPP tokens.
- On the list of VPP tokens pane, select Create. The Create VPP token process is displayed. There are four pages used when creating a VPP token. The first is Basics.
- On the Basics page, specify the following information:
- Token Name - An administrative field for setting the token name.
- Apple ID - Enter the Managed Apple ID of the account associated with the uploaded token.
- VPP token file - If you haven't already, sign up for Apple Business Manager or Apple School Manager. After you sign up, download the Apple VPP token for your account and select it here.
- Click Next to display the Settings page.
- On the Settings page, specify the following information:
Take control of token from another MDM - Setting this option to yes allows the token to be reassigned to Intune from another MDM solution.
Country/Region - Select the VPP country/region store. Intune synchronizes VPP apps for all locales from the specified VPP country/region store.
Warning
Changing the country/region will update the apps metadata and App Store URL on next sync with the Apple service for apps created with this token. The app will not be updated if it does not exist in the new country/region store.
Type of VPP account - Choose from Business or Education.
Automatic app updates - Choose from On or Off to enable automatic updates. When enabled, Intune detects the VPP app updates inside the app store and automatically pushes them to the device when the device checks in.
Note
Automatic app updates for Apple VPP apps will automatically update for both Required and Available install intents. For apps deployed with Available install intent, the automatic update generates a status message for the IT admin informing that a new version of the app is available. This status message is viewable by selecting the app, selecting Device Install Status, and checking the Status Details.
I grant Microsoft permission to send both user and device information to Apple. - You must select I agree to proceed. To review what data Microsoft sends to Apple, see Data Intune sends to Apple.
- Click Next to display the Scope tags page.
- Click Select scope tags to optionally add scope tags for the app. For more information, see Use role-based access control (RBAC) and scope tags for distributed IT.
- Click Next to display the Review + create page. Review the values and settings you entered for the VPP token.
- When you are done, click Create. The token is displayed in the list of tokens pane.
Synchronize a VPP token
You can synchronize the app names, metadata and license information for your purchased apps in Intune by choosing Sync for a selected token.
Assign a volume-purchased app
- Select Apps > All apps.
- On the list of apps pane, choose the app you want to assign, and then choose Assignments.
- On the App name - Assignments pane, choose Add group then, on the Add group pane, choose an Assignment type and choose the Azure AD user or device groups to which you want to assign the app.
- For each group you selected, choose the following settings:
- Type - Choose whether the app will be Available (end users can install the app from the Company Portal), or Required (end user devices will automatically get the app installed).
- License type - Choose from User licensing, or Device licensing.
- Once you are done, choose Save.
Note
The Available deployment intent is not supported for device groups, only user groups are supported. The list of apps displayed is associated with a token. If you have an app that is associated with multiple VPP tokens, you see the same app being displayed multiple times; once for each token.
Note
Intune (or any other MDM for that matter) does not actually install VPP apps. Instead, Intune connects to your VPP account and tells Apple which app licenses to assign to which devices. From there, all the actual installation is handled between Apple and the device.
End-User Prompts for VPP
The end-user will receive prompts for VPP app installation in a number of scenarios. The following table explains each condition:
| # | Scenario | Invite to Apple VPP program | App install prompt | Prompt for Apple ID |
|---|---|---|---|---|
| 1 | BYOD – user licensed (not User Enrollment device) | Y | Y | Y |
| 2 | Corp – user licensed (not supervised device) | Y | Y | Y |
| 3 | Corp – user licensed (supervised device) | Y | N | Y |
| 4 | BYOD – device licensed | N | Y | N |
| 5 | CORP – device licensed (not supervised device) | N | Y | N |
| 6 | CORP – device licensed (supervised device) | N | N | N |
| 7 | Kiosk mode (supervised device) – device licensed | N | N | N |
| 8 | Kiosk mode (supervised device) – user licensed | --- | --- | --- |
Note
It is not recommended to assign VPP apps to Kiosk-mode devices using user licensing.
Revoking app licenses
You can revoke all associated iOS/iPadOS or macOS volume-purchase program (VPP) app licenses based on a given device, user, or app. But there are some differences between iOS/iPadOS and macOS platforms.
| Action | iOS/iPadOS | macOS |
|---|---|---|
| Remove app assignment | When you remove an app that was assigned to a user, Intune reclaims the user or device license and uninstalls the app from the device. | When you remove an app that was assigned to a user, Intune reclaims the user or device license. The app is not uninstalled from the device. |
| Revoke app license | Revoking an app license reclaims the app license from the user or device. You must change the assignment to Uninstall to remove the app from the device. | Revoking an app license reclaims the app license from the user or device. The macOS app with revoked license remains usable on the device, but cannot be updated until a license is reassigned to the user or device. According to Apple, such apps are removed after a 30-day grace period. However, Apple does not provide a means for Intune to remove the app using Uninstall assignment action. |
Note
- Intune reclaims app licenses when an employee leaves the company and is no longer part of the AAD groups.
- When assigning a purchased app with Uninstall intent, Intune both reclaims the license and uninstalls the app.
- App licenses are not reclaimed when a device is removed from Intune management.
Deleting VPP tokens
You can delete an Apple Volume Purchasing Program (VPP) token using the console. This may be necessary when you have duplicate instances of a VPP token. Deleting a token will also delete any associated apps and assignment. Deleting a token revokes associated app licenses but doesn't uninstall the apps.
Note
Intune cannot revoke app licenses after a token has been deleted.
To revoke the license of all VPP apps for a given VPP token, you must first revoke all app licenses associated with the token, then delete the token.
Renewing VPP tokens
You can renew an Apple VPP token by downloading a new token from Apple Business Manager or Apple School Manager and updating the existing token in Intune.
To renew an Apple VPP token, use the following steps:
- Navigate to Apple Business Manager or Apple School Manager.
- Download the new token in Apple Business (or School) Manager, by selecting Settings > Apps and Books > My Server Tokens.
- Update the token in Microsoft Endpoint Manager admin center by selecting Tenant administration > Connectors and tokens > Apple VPP tokens.
- Select the VPP token you are renewing, click Edit on the Basics category, upload the new token on this page, and then save your changes.
Note
You must download a new Apple VPP or location token from Apple Business Manager and update the existing token within Intune when the user, who set up the token in Apple Business Manager, changes their password or the user leaves your Apple Business Manager organization. Tokens that are not renewed will show 'invalid' status in Intune.
Deleting a VPP app
Currently, you cannot delete an iOS/iPadOS VPP app from Microsoft Intune.
Assigning custom role permissions for VPP
Access to Apple VPP tokens and VPP apps can be controlled independently using permissions assigned to custom administrator roles in Intune.
- To allow an Intune custom role to manage Apple VPP tokens, in Microsoft Endpoint Manager admin center, select Tenant administration > Connectors and tokens > Apple VPP tokens, assign permissions for Managed apps.
- To allow an Intune custom role to manage apps purchased using iOS/iPadOS VPP tokens under Apps > All apps, assign permissions for Mobile apps.
Additional information
Apple provides direct assistance to create and renew VPP tokens. For more information, see Distribute content to your users with the Volume Purchase Program (VPP) as part of Apple's documentation.
If Assigned to external MDM is indicated in the Intune portal, then you (the Admin) must remove the VPP token from the 3rd party MDM before using the VPP token in Intune.
If status is Duplicate for a token, then multiple tokens with the same Token Location have been uploaded. Remove the duplicate token to begin syncing the token again. You can still assign and revoke licenses for tokens that are marked as duplicate. However, licenses for new apps and books purchased may not be reflected once a token is marked as duplicate.
Frequently asked questions
How many tokens can I upload?
What is a good budget app for mac. You can upload up to 3,000 tokens in Intune.
How long does the portal take to update the license count once an app is installed or removed from the device?
The license should be updated within a few hours after installing or uninstalling an app. Note that if the end user removes the app from the device, the license is still assigned to that user or device.
Is it possible to oversubscribe an app and, if so, in what circumstance?
Yes. The Intune admin can oversubscribe an app. For example, if the admin purchases 100 licenses for app XYZ, and then targets the app to a group with 500 members in it. The first 100 members (users or devices) will get the license assigned to them, the rest of the members will fail on license assignment.
Next steps
See How to monitor apps for information to help you monitor app assignments.
See How to troubleshoot apps for information on troubleshooting app-related issues.
Summary: Packaging a Java application into an executable Mac bundle is not difficult, but has changed over time; JavaApplicationStub is replaced by JavaAppLauncher; manually building the package content files and hand editing the Info.plist is straightforward, but the organization and properties have changed. Still irritating that JWS/JNLP does not work properly in Safari.Long Version.
I have long been a fan of Macs and of Java, and I have a pathological aversion to writing single-platform code, if for no other reason than my favorite platforms tend to vanish without much notice. Since I am a command-line weenie, use XCode only for text editing and never bother much with 'integrated development environments' (since they tend to vanish too), I am also a fan of 'make', and tend to use it in preference to 'ant' for big projects. I am sure 'ant' is really cool but editing all those build.xml files just doesn't appeal to me. This probably drives the users of my source code crazy, but c'est la vie.
The relevance of the foregoing is that my Neanderthal approach makes keeping up with Apple's and Oracle's changes to the way in which Java is developed and deployed on the Mac a bit of a challenge. I do need to keep up, because my primary development platform is my Mac laptop, since it has the best of all three 'worlds' running on it, the Mac stuff, the Unix stuff and the Windows stuff (under Parallels), and I want my tools to be as useful to as many folks as possible, irrespective of their platform of choice (or that which is inflicted upon them).
Most of the tools in my PixelMed DICOM toolkit, for example, are intended to be run from the command line, but occasionally I try to make something vaguely useful with a user interface (not my forte), like the DoseUtility or DicomCleaner. I deploy these as Java Web Start, which fortunately continues to work fine for Windows, as well for Firefox users on any platform, but since an unfortunate 'security fix' from Apple, is not so great in Safari anymore (it downloads the JNLP file, which you have to go find and open manually, rather than automatically starting; blech!). I haven't been able to find a way to restore JNLP files to the 'CoreTypes safe list', since the 'XProtect.plist XProtect.meta.plist' and 'XProtect.plist' files in '/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/' don't seem to be responsible for this undesirable change in behavior, and I haven't found an editable file that is yet.
Since not everyone likes JWS, and in some deployment environments it is disabled, I have for a while now also been creating selected downloadable executable bundles, both for Windows and the Mac.
Once upon a time, the way to do this to build Mac applications was with a tool that Apple supplied called 'jarbundler'. This did the work of populating the tree of files that constitute a Mac application 'bundle'; every Mac application is really a folder called 'something.app', and it contains various property files and resources, etc., including a binary executable file. In the pre-Oracle days, when Apple supplied its own flavor of Java, the necessary binary file was 'JavaApplicationStub', and jarbundler would stuff that into the necessary place when it ran. There is obsolete documentation of this still available from Apple.
Having used jarbundler once, to see what folder structure it made, I stopped using it and just manually cut and past stuff into the right places for each new application, and mirrored what jarbundler did to the Info.plist file when JVM options needed to be added (such as to control the heap size), and populated the resources with the appropriate jar files, updated the classpaths in Info.plist, etc. Automating updates to such predefined structures in the Makefiles was trivial. Since I was using very little if anything that was Apple-JRE specific in my work, when Apple stopped doing the JRE and Oracle took over, it had very little impact on my process. So now I am in the habit of using various bleeding edge OpenJDK versions depending on the phase of the moon, and everything still seems to work just fine (putting aside changes in the appearance and performance of graphics, a story for another day).
Even though I have been compiling to target the 1.5 JVM for a long time, just in case anybody was still on such an old unsupported JRE, I finally decided to bite the bullet and switch to 1.7. This seemed sensible when I noticed that Java 9 (with which I was experimenting) would no longer compile to such an old target. After monkeying around with the relevant javac options (-target, -source, and -bootclasspath) to silence various (important) warnings, everything seemed good to go.
Until I copied one of these 1.7 targeted jar files into a Mac application bundle, and thought hey, why not rev up the JVMVersion property from '1.5+' to '1.7+'? Then it didn't work anymore and gave me a warning about 'unsupported versions'.
Up to this point, for years I had been smugly ignoring all sorts of anguished messages on the Mac Java mailing list about some new tool called 'appbundler' described by Oracle, and the Apple policy that executable apps could no longer depend on the installed JRE, but instead had to be bundled with their own complete copy of the appropriate JRE (see this link). I was content being a fat dumb and happy ostrich, since things were working fine for me, at least as soon as I disabled all that Gatekeeper nonsense by allowing apps from 'anywhere' to run (i.e., not just from the App Store, and without signatures), which I do routinely.
So, when my exposed ostrich butt got bitten by my 1.7 target changes (or whatever other incidental change was responsible), I finally realized that I had to either deal with this properly, or give up on using and sharing Mac executables. Since I have no idea how many, if any, users of my tools are dependent on these executables (I suspect not many), giving up wouldn't have been so bad except that (a) I don't like to give up so easily, and (b) occasionally the bundled applications are useful to me, since they support such things as putting it in the Dock, dragging and dropping to an icon, etc.
How hard can this be I thought? Just run appbundler, right? Well, it turns out the appbundler depends on using ant, which I don't normally use, and its configuration out of the box doesn't seem to handle the JVM options I wanted to specify. One can download it from java.net, and here is its documentation. I noticed it seemed to be a little old (two years) and doesn't seem to be actively maintained by Oracle, which is a bit worrying. It turns out there is a fork of it that is maintained by others (infinitekind) that has more configuration options, but this all seemed to be getting a little more complicated than I wanted to have to deal with. I found a post from Michael Hall on the Mac Java developers mailing list that mentioned a tool he had written, AppConverter, which would supposedly convert the old to the new. Sounded just like what I needed. Unfortunately, it did nothing when I tried it (did not respond to a drag and drop of an app bundle as promised).
I was a bit bummed at this point, since it looked like I was going to have to trawl through the source of one of the appbundler variants or AppConverter, but then I decided I would first try and just cheat, and see if I could find an example of an already bundled Java app, and copy it.
AppConverter turned out to be useful after all, if only to provide a template for me to copy, since when I opened it up to show the Package Contents, sure enough, it was a Java application, contained a copy of the java binary executable JavaAppLauncher, which is what is used now instead of JavaApplicationStub, and had an Info.plist that showed what was necessary. In addition, it was apparent that the folder where the jar files go has moved, from being in 'Contents/Resources/Java' to 'Contents/Java' (and various posts on the Mac Java developers mailing list mentioned that too).
Java Package Create Mac App Store
So, with a bit of manual editing of the file structure and the Info.plist, and copying the JavaAppLauncher out of AppConverter, I got it to work just fine, without the need to figure out how to run and configure appbundler.By way of example, here is the Package Contents of DicomCleaner the old way:
and here it is the new way:
And here is the old Info.plist:
and here is the new Info.plist:
Note that it is no longer necessary to specify the classpath (not even sure how to); apparently the JavaAppLauncher adds everything in Contents/Java to the classpath automatically.
Rather than have all the Java properties under a single Java key, the JavaAppLauncher seems to use a JVMMainClassName key rather than Java/MainClass, and JVMOptions, rather than Java/VMOptions. Also, I found that in the absence of a specific Java/Properties/apple.laf.useScreenMenuBar key, another item in JVMOptions would work.
Java Package Create Mac App Free
Why whoever wrote appbundler thought that they had to introduce these gratuitous inconsistencies, when they could have perpetuated the old Package Content structure and Java/Properties easily enough, I have no idea, but at least the structure is sufficiently 'obvious' so as to permit morphing one to the other.
Though I had propagated various properties that jarbundler had originally included, and added one that AppConverter had used (Bundle display name), I was interested to know just what the minimal set was, so I started removing stuff to see if it would keep working, and sure enough it would. Here is the bare minimum that 'works' (assuming you don't need any JVM options, don't care what name is displayed in the top line and despite the Apple documentation's list of 'required' properties):
To reiterate, I used the JavaAppLauncher copied out of AppConverter, because it worked, and it wasn't obvious where to get it 'officially'.
I did try copying the JavaAppLauncher binary that is present in the 'com/oracle/appbundler/JavaAppLauncher' in appbundler-1.0.jar, but for some reason that didn't work. I also poked around inside javapackager (vide infra), and extracted 'com/oracle/tools/packager/mac/JavaAppLauncher' from the JDKs 'lib/ant-javafx.jar', but that didn't work either (reported 'com.apple.launchd.peruser .. Job failed to exec(3) for weird reason: 13'), so I will give up for now and stick with what works.
It would be nice to have an 'official' source for JavaAppLauncher though.
In case it has any impact, I was using OS 10.8.5 and JDK 1.8.0_40-ea whilst doing these experiments.
Java Package Create Mac App Download
DavidPS. What I have not done is figure out how to include a bundled JRE, since I haven't had a need to do this myself yet (and am not motivated to bother with the AppStore), but I dare say it should be easy enough to find another example and copy it. I did find what looks like a fairly thorough description in this blog entry by Danno Ferrin about getting stuff ready for the AppStore.
PPS. I will refrain from (much) editorial comment about the pros and cons of requiring an embedded JRE in every tiny app, sufficeth to say I haven't found many reasons to do it, except for turn key applications (such as on a CD) where I do this on Windows a bit, just because one can. I am happy Apple/Oracle have enabled it, but surprised that Apple mandated it (for the AppStore).
PPPS. There is apparently also something from Oracle called 'javafxpackager', which is pretty well documented, and which is supposed to be able to package non-FX apps as well, but I haven't tried it. Learning it looked more complicated than just doing it by hand. Digging deeper, it seems that this has been renamed to just 'javapackager' and is distributed with current JDKs.