We don't need a Player (was Re: New(?) Idea for Standalones)

[Brian Milby]

The days of distributing apps without a cost to the developer are unfortunately over (Mac/Win).  If you want someone to be able to open an app on their Mac without jumping through hoops, then you need to be a paid developer and do the sign/notarize dance.  LC could help automate parts of the process, but getting the certificates seems to require some manual steps.  First advanced session in LCG covered it last week (but since I don’t do it, I did not fully pay attention to all of the details).

Sent from my iPhone

> On Mar 29, 2021, at 12:38 PM, Roger Guay via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> YES . . . What he said!
> 
>> On Mar 29, 2021, at 8:55 AM, Richard Gaskin via use-livecode <use-livecode at lists.runrev.com> wrote:
>> 
>> TL/DR:
>> 
>> We don't need a generic player.
>> 
>> What we need is an updated Standalone Builder, to provide more complete tooling and better guidance for building a modern standalone.
>> 
>> 
>> 
>> ------------- more complete version ----------------------------
>> 
>> 
>> Background
>> ----------
>> 
>> This thread, and many others like it, didn't start with a desire for a player.  That was merely a response to the challenges of building standalones.
>> 
>> Building standalones is the point of LiveCode, the culmination of everything in LC's user experience.
>> 
>> And it's become a pain point for most, early-prohibitive for some.
>> 
>> OS changes are of course not LC's fault.  But they are LC's opportunity, if the company wants to maintain its place as the easiest solution for making apps.
>> 
>> 
>> 
>> The Last Great Deployment Change
>> --------------------------------
>> 
>> Back in the early days, the IDE's Standalone Builder didn't provide any support for document associations, creator codes, or other essentials we now take for granted.  It was expected we'd open some dev tool from Apple (ResEdit) to set those up.
>> 
>> LC Ltd recognized those steps were cumbersome, and often error-prone where they were being done at all.
>> 
>> So they took the time to completely redesign the Standalone Builder to include support for nearly every detail apps need for solid deployment.
>> 
>> 
>> 
>> The Next Great Deployment Change
>> --------------------------------
>> 
>> Many if not most deployment tooling required by OSes are command-line apps, lending themselves well to being called from another program, such as LC's Standalone Builder.
>> 
>> Automate everything possible.
>> 
>> And where a step can't be automated, guidance and be provided, such as a direct link right in the SB's UI to the necessary steps for completing the process, laid out with sufficient clarity and detail to allow the user to complete the build with confidence.
>> 
>> If a standalone building step is essential, it needs to be handled in the Standalone Builder.
>> 
>> Use direct automation where possible, or a direct link in the UI to step-by-step instructions needed to complete the task.
>> 
>> 
>> 
>> The Business Case
>> -----------------
>> As we've seen here and many other threads like it from time to time, as long as building a standalone in LC is characterized by confusion and dread, people will seek alternatives.
>> 
>> Any alternative either compromises LC's revenue model (based as it is around standalone licensing), or eliminates it (if LC is just as hard to use as anything else, why not use anything else?).
>> 
>> No option provides as much return on investment as focusing on updating the Standalone Builder to be as simple and graceful as it can possibly be.
>> 
>> LC has a strong advantage with its language, made a nearly unbeatable with its integrated GUI object model.
>> 
>> Bring deployment up to par with the rest of the experience, and LC has a chance for a good life ahead, slowing attrition rates while accelerating growth.
>> 
>> -- 
>> Richard Gaskin
>> Fourth World Systems
>> Software Design and Development for the Desktop, Mobile, and the Web
>> ____________________________________________________________________
>> Ambassador at FourthWorld.com                http://www.FourthWorld.com
>> 
>> _______________________________________________
>> 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
> 
> _______________________________________________
> 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