Feature Requests

When using applications with dependencies (like Autodesk ones) it could be useful to hide them to the end users. These applications are not meant to be ran individually, so there is no point on having them visible for end users. With a visibility check available on provisioning, this could be easily solved. An extra addition could be allowing the hiding per-user. With this functionality testing new apps would be easier: just provision the new app, hide for everyone except testers, and when done just untick the hide check. That request has similarities with: https://feedback.appsanywhere.com/feature-requests/p/hide-application but they ask it from the end user perspective.

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

For example, if I’m never going to use MATLAB, I don’t want to see it mentioned everywhere. This feature would be a new option in more info to ‘hide this application’, removing it from search results and views. A new section for ‘hidden apps’ shows the ones you’ve hidden, and allows you to unhide them, if you change your mind.

Ability to require a VPN connection for app access First raised at the Toronto User Day 22

Feedback from 2022 user days. Customer wants it to be easier to push images out using Intune via AppsAnywhere

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

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

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.

most of our support calls are for applications that are visible to users, but they are unavailable (grayed out) for one reason or another for example they are not on the domain. Is there a way to hide the unavailable apps from the user, depending on where they are coming from they see a different list if for example they connected from Azure virtual desktop, or a different list if they connected from laptop, but I just need a way to hide the grayed out apps. maybe have an option so that the college can decide how to present the apps to the user.