Universal apps are M1 apps. They are also x86 apps. In other words Xojo makes both types of app and stores them in a single app package. You shouldn’t see any speed difference between an Apple silicon app and a universal one, apart from file size.
Which is why App Wrapper 4.5 introduced splitting, so you can give App Wrapper a single App bundle and it can output two zip files, or two installer packages, with each only only containing a single architecture.
I use this with the Sleep Aid updater, so it only downloads the correct architecture for my customers.
You should also check Xojo Issues as I’m sure there’s a feedback or two that I’ve filed over the decades asking for unused object striping and unused property striping. I think I even filed one for Xojo to refactor thier framework so it can strip out unused things from there.
If you ship Console apps as helpers, I was working on a way to get 'em to use the main framework instead of having to have their own frameworks as this can free up multiple megabytes of wasted stuff. I stopped once I realized that “2.0 All The Things” was more important to Xojo than anything else.
Edit: I’d also like to add, that for an unreleased project, I wrote the helper in Objective-C and even when compiled as a UB, it was only a couple of hundred kilobytes, instead of being nearly 7 megabytes. So there is a lot Xojo can do to optimize the size of Xojo made applications.
FWIW, there’s always a cost, usually in terms of size, when using frameworks like this. When you work in objective-C, you specifically include the pieces of the framework that your app needs. Xojo does the same thing except that they need to include everything that they use for their entire framework. Be happy that it’s only 7MB.
And if you want to run the x86 (Intel) version of your application on an Apple Silicon Computer, select the Universal Binary (UB), → Get Information, and you will se the screen shot below (that is for TextEdit):
I do agree you never know what the user will do, or tell you what they did for that matter. However, from a support standpoint, listing requirements for the application and it’s versions would seem to be very important to me. If it turns out a user is running it in an unsupported way, they need to be educated the proper way to run it. I can’t imagine you could flush out every possible issue by testing it this way. Just my 2 cents.
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
There are several things that do behave differently on different architectures. Apple text framework for instance uses different values for text alignment, so what looks fine on x86, ends up wrong with ARM native.
If you work with declares, you may find yourself having to use the iOS values for functions instead of macOS values (Apple are not merging the OSes, it’s all in your head).