Feature Requests

Dependencies as they are currently implemented are functional but could be improved. The 2 specific features that would be beneficial are: * Moving dependencies from an application wide setting to a delivery method specific setting. * Some way to view dependencies from the application that is a dependency.

We have recently found that the IP address ranges used to detect whether a client is "On-site" or not are only checked for the first network adapter (you can see this in the S2HubTracelog.log). VPN connectivity is most-often via a virtual network adapter which is not the primary network adapter so using the VPN range to detect if a device is on-site or not does not work well (at all) in most scenarios. From a software licensing perspective we have at least one application for which we are only licensed to run it if you are physically on-site so having the VPN as part of the "on-site" detection isn't ideal anyway. We have lots of software that will work when off-site but on VPN (requiring an on-prem license server is the most common scenario here) but we have to either make available to all devices, regardless of being on-site or not, which doesn't work well as not everyone has VPN-connectivity meaning there are lots of available apps that can be launched that will fail due to lack of connectivity to license servers. I suppose I'm asking for two different things in this request... 1 - Check more than the first network adapter for specified IP ranges. It is quite possible for a device to have both a wired and wireless adapter when on-site which could break the current detection method depending on how they are connected. This would allow us to add the VPN IP ranges to the on-site detection (we would have to do SOMETHING else to block other unlicensed software in this scenario). 2 - Have a "VPN Connected" detection alongside the "On-site" detection which has a specific set of IP ranges. This would allow us to correctly scope and limit applications based on license type, license restriction and device connectivity. In this scenario you would want to be able to say if device is "On-site" and / or "On VPN" rather than require one or the other or both. I note that this request is similar (but different) to this one... https://feedback.appsanywhere.com/feature-requests/p/vpn-licensing

Ability to add CPU Architecture requirements / restrictions to delivery methods. Windows (x86, x64 and ARM64), macOS (Intel, M1 and M2).

A new community driven Cloudpage packaging and recipe site. Where packages and\or recipes can be submitted for peer review and published. Submitted packages would of course have to meet certain naming convention standards and there might become some duplication of Cloudpage packages across all of the AppsAnywhere users. The benefits of though could be that new version and patches to small les troublesome applications are more likely to be addressed faster. This would help to keep the security bods who don't follow the benefits of containerised applications at bay. Users should be able to follow and favourite their key applications, and be notified if a new version is available to test, check and use at their own discretion. Perhaps a peer based rating scheme for the .stp and recipe's submitted to allow some filtering. (This would leave yourselves to concentrate on the complex auto-license packages also) You could even offer some form of prize for top packagers. ;-) Andy

When creating delivery methods or provisions, it would be very helpful if the UI could indicate (via a pill or other ui) which restrictions require agent validation vs. which can be done via browser strings and other methods.

Management of AppsAnywhere applications would benefit from the ability to use REST methods to interact with resources in the AppsAnywhere Admin portal. For example: • The GET REST method would be used to retrieve information on applications or provisions • The POST REST method would be used to create an application or provision • The PATCH REST method would be used to update an application or provision • The DELETE REST method would be used to delete an application or provision The addition of these capabilities would reduce the manual work required to monitoring and maintaining a large software library in AppsAnywhere. They would also enable these processes to be automated.

We would like to be able to deploy applications via Kandji MDM ( www.kandji.io ), similar to how Jamf is integrated currently.

When a university has decentralized IT departments, they cannot restrict or delegate admin rights to specific parts of the Admin tools to individual users. Similarly to restricting students' visibility to apps by log-in, Admins would only have access to what they are allowed to do.

If making a change to a delivery method - such as applying a hardware profile or updating OS compatibility, it requires changing each one individually. Bulk edit. E.g change all native Adobe delivery methods to have the same hardware profile, or update OS compatibility for each would vastly simplifies DM management, and also solves the OS compatibility problem at the same time.

As all our new Win11 builds are in Azure/entra/intune only we need to have a way to provision machines via Entra machine based groups.