Quote from Nickj_UK on May 2, 2025, 1:54 pm

As an app it's not on apples store which is the simplest way to install, why it's not there that might be the gouging that anything on the app store has applied per sale which is currently 30%.

The app would have been originally built on windows, a large number of the components will leverage inbuilt components of windows, API's, libraries and so on which you have to be identify all these calls and then identify the equivalent MAC function that will subsitute the original function.
That means virtually rewriting the whole app for quite a small percentage of the global computer market (20% globally) which for the potential returns v's the man hours involved makes zero sense.
If it had been originally developed or was rewitten on a platform that seperates the applications core from the library calls (using a multiplatform software generation tool)  then it's just aiming at a different platform. But again thatmeans fully rewriting the whole app but it would mean that there would be one software core available for Windows, Android, Linus and MAC. But rewriting the whole app for quite a small percentage of the global computer market (20% globally) which again for the potential returns v's the man hours involved makes little sense.

Since 2003 MAC users have had xcode as an ide based development platform, before that and when I used to do some coding on MAC (a long time ago) it was all MAC flavoured C which was a pain as it was missing quite a few features like blocks, only using literal strings, you even had to manually count references. It did improve and there were a few 'more native' tools for producing apps like A/UX.

Luis will give you a better answer but i think it will all come down to time and effort.

Quote from luishp on May 2, 2025, 6:09 pm

@tmcd VisualNEO Win and VisualNEO Web are Windows-only applications primarily due to their dependency on the Windows operating system's architecture and libraries. Here's a clear breakdown of why these tools aren't natively compatible with macOS:

1. Built Using Windows-Specific Technologies

Both VisualNEO Win and VisualNEO Web are developed using programming frameworks and tools (Delphi) that are tightly coupled with the Windows API. This means:

• They depend on .DLL files (Dynamic Link Libraries) and Windows-only runtime components.

• User interface elements are rendered using Windows-specific GUI frameworks like VCL or WinForms.

2. Installer and File System Assumptions

The applications assume a Windows-like environment:

• Installation paths and executable formats (.exe) are designed for Windows.

• They use Windows-style file paths and registry entries, which do not exist in macOS.

3. Lack of Cross-Platform Runtime

Unlike web technologies or Java (which run on a virtual machine), VisualNEO Win and Web do not use a cross-platform runtime. They are compiled as native Windows applications, which inherently cannot run on macOS without emulation.

4. No Native macOS Compilation Option

The internal compiler of VisualNEO Web does allow apps to be exported as web apps or compiled using NW.js for macOS, but the development environment itself (VisualNEO Web IDE) can’t be compiled to run on macOS without significant changes to its source code and dependencies.

5. Solutions for Mac Users

While there’s no official macOS version, Mac users can still run VisualNEO software using:

• Wine (though compatibility may vary)

• Virtual machines like Parallels Desktop or VMware Fusion

• Boot Camp (on older Intel Macs)

Quote from TMcD on May 2, 2025, 8:40 pm

Thanks everyone. Those answers were expected and I understand.

Main question is will the output for web applications actually work then on a Mac browser, Chrome, Safari, etc?

Now a few specific questions:

I’d like to create an interface that will then communicate with webhooks for sending and receiving data, is that possible as the software is now, or would a add-on/plugin be needed?

Same question with APIs. I’d like to be able to send and receive data to APIs in an app I create. Is that possible with the app as it is now?

I guess I’ll add this, Can both VisuaNEO and VisuaNEO Web do both of the above.

Thanks

Quote from luishp on May 3, 2025, 8:08 am

@tmcd

✅ 1. Will VisualNEO Web output work on Mac browsers like Chrome and Safari?

Yes, absolutely. VisualNEO Web generates standard web applications (HTML5, CSS, JavaScript), which means:

• Apps can be run in any modern web browser, including Chrome, Safari, Firefox, and Edge on Mac, Windows, or Linux.

• You can try any of the online samples to check it yourself.

✅ 2. Can you use Webhooks (send/receive data) in VisualNEO Web without plugins?

Yes, you can. VisualNEO Web includes built-in HTTP communication capabilities through NeoScript commands. For example:

• You can use the Send or POST actions with JavaScript or via plugins like neoAjax to communicate with webhooks.

• No external plugin is required unless you need more advanced handling or response parsing.

If needed, neoAjax plugin simplifies asynchronous HTTP requests (GET/POST), which are common in webhook use cases.

✅ 3. Can you work with APIs (send/receive data) in VisualNEO Web?

Yes. You can:

• Send and receive data to/from REST APIs using neoAjax (plugin) or JavaScript actions directly in NeoScript.

• Parse and handle JSON responses using built-in commands like ParseJSON, StringifyJSON, and variable management.

So again, you don’t necessarily need an add-on, but using the neoAjax plugin can simplify the process and improve maintainability.

✅ 4. Can both VisualNEO Win and VisualNEO Web handle webhooks and APIs?

• VisualNEO Web is fully capable of webhooks and API communication using the techniques above.

• VisualNEO Win, is not the appropiate tool for this but can also perform simple HTTP requests, though the approach uses different commands (like Download, Upload, or integrating Windows DLLs or VBScript).

Please check the online documentation for more information.

Quote from Nickj_UK on May 4, 2025, 1:16 pm

A server based web technology app will work, just remember that safari has what you'd call in the web dev world "limited platform availability", that is it's only found on a small percentage of global users machines.
Pretty exclusively in the EU Apple has been forced to allow browsers NOT based on WEBKIT, globally the predominant web engine remains as WEBKIT on Apples OS's.
This means that in the EU if you use Chrome it will use BLINK which is a fork of WEBKIT but with access to around 17,000 extensions compared to WEBKITS 3-400.
Apple web devs tend to focus on WEBKIT because outside of the EU it's exclusively what they have on that platform, in the EU we'll assume our targets are BLINK, GECKO, TRIDENT or EDGEHTML and WEBKIT. I'd point out that this use of different web engines within the EU is quite true at the platform level as in the EU Apple although users can opt to use alternative browser engines ONLY IF they are on OS 17.4 or later. Also a large number of Apple OS users tend to remain within the Apple eco-system

So what does that mean to you?

Standards and conventions are slightly different, as an example WEBKIT uses a different property for adjusting text sizes to the standard text size adjust properties. People who need to enlarge all the text across a web page using browser level scaling can hit problems with very inconsistent text re-sizing that can produce a very mangled page layout, in some cases it can be severe enough that the page renders are unuseable.
You have to write in get arounds for some things, luckily it's all pretty well documented and as long as you stick to HTML standards everything will work more or less as you expect them to.
How you do this depends on which OS you are using to produce your HTML, I'm guessing on an Apple machine using some dedicated software that will conform primarily to WEBKIT standards but should produce something that all web engines can digest or at least fail gracefully.
Mostly if it conforms to the WC3 standards as far as HTML, CSS, and JavaScript are concerned it should be good, there may still be some inconsitencies but on the whole everything should work.
It's really helpful if you use CSS resets and always use cross-browser WC3 compatible frameworks.
So Doctype, structure, semantics, responsive frameworks, CSS resets (for different platforms), JS JQuery (to abstract quirks) and Cross-Browser Compatible Libraries and Frameworks (ionic, capacitor) will make compatible pages.
Surprisingly TextEdit and ACode are good platforms to write you HTML and CSS on, a sharp learning curve though. I used to write pretty much everything at one time using just a plain text editor then went over to Notepad++ in late 2003. Things got busy and i went over to what was them macromedias dreamweaver but still did quite a lot on notepad++.

The most helpful part of your toolset is going to be WC3 markup validation tools for your base HTML and CSS pages ~ WC3 Validator
There are cross-browser validation tools like lambdatest, Saucelabs and Browser stack but these are more for commercial or more critical web page/site checks, if you use cross compatible base code it should be OK.

I excpect that you know this all already, but there will be people here who don't.