M1 Macs and LC 9.6.8 RCs and 10.0.0 RCs

[matthias_livecode_150811 at m-r-d.de]

> Am 21.06.2022 um 15:19 schrieb Mark Waddingham via use-livecode <use-livecode at lists.runrev.com>:
> 
> On 2022-06-21 12:18, matthias rebbe via use-livecode wrote:
>>> Am 21.06.2022 um 11:56 schrieb Mark Waddingham via use-livecode <use-livecode at lists.runrev.com>:
>>> Why?
>> First, it's more convenient for the developer.
> 
> I think the end user is more important (in this case) ;)
> 
>> The Intel only and Apple only builds are smaller ins size than the
>> universal build.
> 
> True - universal builds are double the size essentially (well, resources in copy files are *not* duplicated) - however how important is that really?
In my vocational training in the mid 80's the  mantra of my instructors was "SAVE resources!".  
Okay, at that time computers did not have many ram and hard disk space. But anyway, i still keep this mantra in mind when programing or doing other things.
Just because computers nowadays  have plenty of ram and hard disk space does not mean we have to completely fill up it. ;)


> 
> There's a high chance a user might download an app twice from a page offering two architectures - because they aren't necessarily sure which one they need - at which point, you've lost any advantage in splitting them (and just caused user consternation). [ Similar argument holds when users upgrade their machines, and restore from a full backup - which is what the majority of users do ].
> 
Therefore the Universal build would be. That's the reason why i argue for 3 options for macOS.

When i switched to my new Mac Studio there were several 3rd party programs which were only available as single Apple Chips version and not as an universal build. But there might be special reasons for it.

> Besides, if size is a real concern here then there are a couple of tweaks we could do to reduce the size of universal binaries (and indeed, Android APKs) which would see the size difference between universal and non-universal drop to maybe 3-4Mb (and probably only 1-2Mb when compressed - i.e. transmission size). [ This would be a *much* better use of time, than adding an edge-case option to the S/B, IMHO ].
Is it so much work to reimplement that routine? It already existed for PPC.


> 
>> So if i want to build those single platform apps to offer the smaller
>> sized apps  i have to run the standalone building process twice,
>> right? And before i run the 2nd build process i even have to switch
>> the settings, right?
>> That's not very convenient.
> 
> Offering two separate downloads to users is not very convenient to them ;)

Don't think so. Offering 3 separate downloads 1 x Intel, 1 x Apple, 1 x Universal is very convenient.
The user can decide what to download and in case of a doubt the user can download the Universal build.
> 
>> And btw why did this option exist in previous LC versions for an
>> Universal app with PPC and Intel support?
> 
> Well that was getting on for a decade ago - so can't really remember what the exact rationale was back then. However, I dimly recall that universal PPC+Intel binaries would not run on some earlier versions of 'MacOS X' which we still supported (and people still

Don't exaggerate, it was just 8 years ago. ;) 


> had!) at the time - so you actually *needed* to offer a separate PPC download if you still needed to support those really old 'MacOS X' versions.
> 
> These days that's not a problem as there's been a 32-bit -> 64-bit architecture switch since then which means all the macOS versions we currently support work correctly with universal binaries containing slices the OS does not understand.
> 

But with the current problem that a Universal app by default runs in Rosetta although the Rosetta switch is not enabled that is also not very convenient for the customer.


Anyway, i understand your points and can live with the decision.


Regards,
Matthias

> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode