Feature Requests

Dear ionCube Support Team, I am writing to request your guidance regarding the future of ionCube products on Apple Silicon Macs. Apple has officially informed developers and users that Rosetta 2 will no longer be available as a general-purpose translation layer for Intel (x86_64) applications starting with macOS 28 (expected in 2027). Full Rosetta 2 support is planned to continue through macOS 27, after which only a limited subset of Rosetta functionality will remain — primarily for legacy gaming titles and certain x86 binaries running inside Linux virtual machines. Additionally, starting with macOS 26.4, macOS now displays warnings when launching applications that depend on Rosetta 2, indicating that these applications will not be supported once general-purpose Rosetta support ends. Given this transition, I would like to understand the recommended path for using ionCube on macOS with native ARM64 (Apple Silicon) support, rather than relying on Rosetta-based x86_64 binaries. Could you please advise on the following points? ionCube Loader on macOS ARM64 I understand that a native “macOS ARM M1 (arm64 64 bits)” Loader package is available. Is this the officially recommended approach for Apple Silicon Macs going forward? Are all currently supported PHP versions available as native ARM64 loaders, and do you plan to maintain full parity with the x86_64 macOS builds? ionCube Encoder on macOS ARM64 If I am using the ionCube Encoder on macOS for development, is a native ARM64 version available, or is the Encoder still distributed only as an x86_64 binary? If only x86_64 is currently available, do you have a roadmap or timeline for a native Apple Silicon Encoder release before Rosetta 2 general-purpose support ends? Migration and best practices For users currently running x86_64 PHP and/or ionCube components under Rosetta on Apple Silicon Macs, what is your recommended migration plan? Should we switch entirely to native ARM64 PHP installations and ARM64 ionCube Loaders now, or are there specific configurations we should avoid? Encoded file compatibility Will PHP files encoded on an x86_64 macOS environment remain fully compatible when executed with the native ARM64 Loader on the same or newer PHP versions? Are there any encoding options or platform targets we should select today to ensure long-term compatibility on Apple Silicon without Rosetta? Long-term macOS support Do you intend to discontinue support for the x86_64 macOS Loader and Encoder builds in line with Apple’s Rosetta phase-out, and should we plan our development and deployment environments exclusively around ARM64 on macOS from now on? My goal is to prepare our local development and testing environment on macOS (Apple Silicon) in a sustainable way, without depending on Rosetta, well before Apple removes general-purpose x86 support. I would greatly appreciate any documentation, migration notes, or official recommendations you can share on this topic. Thank you for your time and assistance.

FrankenPHP (previously added to the PHPFoundation) seems to be incompatible with ioncube [1] encoded php code. As the project is also now under the umbrella of the PHP Foundation [2] we will certainly see more adoption of the app server. It would be great if the ioncube extension could be built with FrankenPHP as well. [1] https://github.com/dunglas/frankenphp/issues/901 [2] https://thephp.foundation/blog/2025/05/15/frankenphp/

Ben from ionCube here. Just a quick update from us as we continue with development of ionCube Encoder. In late 2025 we launched ionCube Encoder 15 and have since continued to work on improvements to that product as well as our latest Loader release which supports the running of PHP 8.2-8.4 encoded files on up to PHP 8.5. Our latest development news mostly surrounds general improvements and bug fixes but we're also actively working on ongoing changes to our Online Licensing system to improve usability and the interface as a whole. If you haven't had a look yet then I would really recommend it as it saves a lot of time on developing your own license management interface - reach out if you would like to try it out and we'll issue your account with some free access and would be grateful for your feedback. As always, we really encourage you to reach out with feedback whether it's via this page or emailing me via sales@ioncube.com . I'm always reviewing feedback but sometimes this is posted to third-party sites and so I don't get to see it as fast as I would like so do reach out if you have things you want to discuss.

When compiling php with x86-64-v3 everything works fine. But as soon as I enable the ioncube loader, and process a addslashes function, I get memory corruption due to it clobbering the sse registers via the sse4.2 instructions, If I manually add mmx save/restore in the addslashes function, things work again like normal. This shows the ioncube loader is also using the mmx/sse registers without being safe when calling back into php functions that may or may not be also using them. php[2729078] general protection fault ip:566336 sp:7ffed56bd1a0 error:0 in php[400000+329000] the gdb backtraces always show ioncube in the stack path calling zend_hash_* functions when it dies, but wrapping the addslashes function has caused the issue to go away when using ioncube.

It would be interesting to have the Encoding Key stored remotely so users don't really get access too it as in its not shipped with the product. Providing the key can be accessed remotely the script will always be able to be decoded and the key can be called by ionCube on runtime?

I want to be able to remove the licensed machines through the interface, because I currently do not have access to these machines because they were virtual machines and there is nowhere to remove them.... I do not have access to log in to them because they were docker instances with a MAC address

Hello everyone, I'm actually very happy with IonCube, I've been using for more than 5y, but now that we've this portal to suggest some features, I'm here to suggest this new option for the licenses. My idea is to have something like we've in TLS X.509 certificates, the OSCP Stapling functionality, to validate if one issued license still valid between the issue date and the expire date, for example: I issue one license of one year for one of my customers, but 9 months later this customer isn't paying me more, so I need to revoke their license, but nowadays it's not possible if I don't have access to the server of my customer. Some customers try to debug the code or crack them, so with this new feature would be possible to revoke or invalidate their license. Idk how it can be implemented, we'd need to look at OSCP Stapling specifications for more technical details, maybe just adding the possibility to do some web hooks in the moment of license validation or something like that. What do you guys think about? It's actually a good idea to have something like this? Kind regards, Murilo Chianfa.

Hello Please add loaders fo windows arm arch. Thanks

Online licensing currently takes Pro/Cerberus Edition Encoder features and puts them online. We're looking to expand on licensing functionality through the online portal. One feature we're investigating the posibility of is including links to download licenses that users can give to their own customers. Licenses would be stored in your account and then your users can access license downloads either via an automated email you can send or a download link.

Give users the option to import users and licenses from existing projects or their own data sources.