Re: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???

[Pi Digital via use-livecode]

> ... it is always a good idea when developing for public consumption to 
> develop for the (reasonably) lowest common denominator.


This works with the public. Not so much with a massive set of corporate 
enterprises where IT departments (all of them) will choose to test and roll out 
upgrades/updates not long (maybe a month) after its release. This is decided 
upon because of 2 main factors - 1. security measures implemented in the 
updates based on real world attacks; 2. The next minor update is hot on its 
heels. Apple release bêtas so that IT depts can do the main test ahead of time 
and then on gm they do a final check then release. (Actually, à lot of them 
wait for Apple to release a x.x.01 before release so that all the initial bugs 
are removed :p)

As a supplier to these companies we have to sign off that we are not putting 
their devices and systems at risk by using out of date security measures and 
sdk’s. And so we must be capable of using the very latest Sdks and wares.

But, fortunately, as Panos said, these newer oss and IDEs are covered by 
current releases (9.5.1 and 9.6dp2) although not mentioned in the release 
notes. And that is what was scaring me and potentially newbies off from making 
use of it. If it says it’s not supported I can’t risk installing it and end up 
not being able to revert easily or otherwise stop working. 

It’s just frustrating that these fixes have been sitting on the server waiting 
for release for a couple of months and not just pushed out in even a dp or rc 
form. It would enable us to Have time to test them thoroughly ahead of gm 
release. And even start putting them to use. 

Sean Cole
Pi Digital


> On 13 Mar 2020, at 15:44, Bob Sneidar via use-livecode 
>  wrote:
> 
> Just to diverge a bit (as I am wont to do), when new browsers and features 
> began to be prolific, a lot of web devs would initially develop sites using 
> the new features. What resulted however is that they excluded vast numbers of 
> visitors who could not view their web sites, or had reduced capabilities. 
> 
> By reasonable, I mean for example, making sure an app will run in Windows 7 
> or whatever version of iOS the Apple Store accepts. Unreasonable would be 
> trying to support iOS 7 of Windows XP or Vista. 
> 
> If using the latest SDK and Livecode version doesn't accomplish this, I would 
> consider maintaining an SDK and LC version that does, and avoid using 
> features in your apps that environment cannot support. 
> 
> My 2¢
> 
> Bob S
> 
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???

[Bob Sneidar via use-livecode]

Just to diverge a bit (as I am wont to do), when new browsers and features 
began to be prolific, a lot of web devs would initially develop sites using the 
new features. What resulted however is that they excluded vast numbers of 
visitors who could not view their web sites, or had reduced capabilities. 

What evolved from that period of painful learning is that it is always a good 
idea when developing for public consumption to develop for the (reasonably) 
lowest common denominator. By reasonable, I mean for example, making sure an 
app will run in Windows 7 or whatever version of iOS the Apple Store accepts. 
Unreasonable would be trying to support iOS 7 of Windows XP or Vista. 

If using the latest SDK and Livecode version doesn't accomplish this, I would 
consider maintaining an SDK and LC version that does, and avoid using features 
in your apps that environment cannot support. 

My 2¢

Bob S

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Philosophical questions about the fontNames

[Bob Sneidar via use-livecode]

Also, there are two major types of vector based fonts: TrueType and OpenType. 
OpenType is a Microsoft format, but the same font file can be used for Windows 
and Mac. 

TrueType gets a little tricky. TrueType fonts made for Windows will also work 
for Mac. TrueType made for Mac must be CONVERTED to work with Windows. There 
are free utilities that will do this conversion for you. I use dFontSplitter 
for Mac, but I'm sure there are others. 

HTH
Bob S


> On Mar 13, 2020, at 06:05 , Pi Digital via use-livecode 
>  wrote:
> 
> Hi
> 
> If you need a specific font to work because of look, scale, print, etc I 
> suggest using a font editor app to copy the font you require, rename it to 
> something unique (the name is embedded so just changing the file name changes 
> nothing) and then embed it into your app in LC Standalone Settings. This is 
> the only sure fire way of ensuring what you see in the dev environment is 
> what the user will see on their xyz machine/device/printout. 
> 
> Sean Cole
> Pi
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Can the Browser widget access dev tools?

[Pi Digital via use-livecode]

Here’s where to go

https://developers.google.com/web/feedback

Sean Cole
Pi Digital


> On 13 Mar 2020, at 13:37, Keith Clarke via use-livecode 
>  wrote:
> 
> Hi Sean,
> Thanks for the response - that saves me researching further on browser widget 
> usage for this. 
> 
> I’ve also looked at trying to drive a regular Chrome browser instance on my 
> Mac but there seems to be a more fundamental snag…
> 
> Unlike the Console, the Dev Tools Network settings seem to lack any API 
> https://developers.google.com/web/tools/chrome-devtools/network 
> .
> 
> Good call on raising a change request to Google on tools & throttling 
> persistence - I’ll see if I can find where to do that!
> Best,
> Keith
> 
>> On 13 Mar 2020, at 13:21, Pi Digital via use-livecode 
>>  wrote:
>> 
>> Hi Keith
>> 
>> The chromium engine is not the same as the chrome browser. So the browser 
>> has the dev tools. The engine will have some code base that the browser can 
>> pull from to display as tools. 
>> 
>> The browser widget is a browser in its own right. It does not, at least as 
>> far as I’m aware, embed a chrome browser into a container. It uses the 
>> chromium engine to feed data that can be interpreted and displayed within a 
>> widget canvas. 
>> 
>> So dev tools would have to be written into the widget to access things l’île 
>> the throttling settings so that you could manipulate them using properties 
>> in the UI or by code. 
>> 
>> I hope this leads to solving your rsi problem eventually. It is a pain when 
>> the dev tools disappear when you load a new page and you can’t set it to 
>> stay up and stay throttled. Send a feature request to google. 
>> 
>> All the best 
>> 
>> Sean Cole
>> Pi Digital
>> 
>> 
 On 13 Mar 2020, at 10:55, Keith Clarke via use-livecode 
  wrote:
>>> 
>>> Hi folks,
>>> I understand that the browser widget uses the platform’s default browser 
>>> engine. The (default?) feature set seems to be limited - e.g. no 
>>> right-click (on Mac).
>>> 
>>> There don’t seem to be obvious entries in the dictionary concerning 
>>> developer tools/menu/option. Please can anyone confirm whether it’s 
>>> possible to access Safari (Mac) or Chromium (Windows) Developer Tools 
>>> programmatically from LC - or control the right-click page inspector access 
>>> (and it’s content once displayed)?
>>> 
>>> And, just in case I’m taking the wrong direction of travel, the use case is 
>>> that I’m looking to cobble together a simple test rig to help test page 
>>> load times on limited bandwidth connections using Chrome’s network 
>>> throttling settings, as I’m getting bored (& RSI) from the current manual 
>>> process!
>>> Best,
>>> Keith 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@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@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Can the Browser widget access dev tools?

[Keith Clarke via use-livecode]

Hi Sean,
Thanks for the response - that saves me researching further on browser widget 
usage for this. 

I’ve also looked at trying to drive a regular Chrome browser instance on my Mac 
but there seems to be a more fundamental snag…

Unlike the Console, the Dev Tools Network settings seem to lack any API 
https://developers.google.com/web/tools/chrome-devtools/network 
.

Good call on raising a change request to Google on tools & throttling 
persistence - I’ll see if I can find where to do that!
Best,
Keith

> On 13 Mar 2020, at 13:21, Pi Digital via use-livecode 
>  wrote:
> 
> Hi Keith
> 
> The chromium engine is not the same as the chrome browser. So the browser has 
> the dev tools. The engine will have some code base that the browser can pull 
> from to display as tools. 
> 
> The browser widget is a browser in its own right. It does not, at least as 
> far as I’m aware, embed a chrome browser into a container. It uses the 
> chromium engine to feed data that can be interpreted and displayed within a 
> widget canvas. 
> 
> So dev tools would have to be written into the widget to access things l’île 
> the throttling settings so that you could manipulate them using properties in 
> the UI or by code. 
> 
> I hope this leads to solving your rsi problem eventually. It is a pain when 
> the dev tools disappear when you load a new page and you can’t set it to stay 
> up and stay throttled. Send a feature request to google. 
> 
> All the best 
> 
> Sean Cole
> Pi Digital
> 
> 
>> On 13 Mar 2020, at 10:55, Keith Clarke via use-livecode 
>>  wrote:
>> 
>> Hi folks,
>> I understand that the browser widget uses the platform’s default browser 
>> engine. The (default?) feature set seems to be limited - e.g. no right-click 
>> (on Mac).
>> 
>> There don’t seem to be obvious entries in the dictionary concerning 
>> developer tools/menu/option. Please can anyone confirm whether it’s possible 
>> to access Safari (Mac) or Chromium (Windows) Developer Tools 
>> programmatically from LC - or control the right-click page inspector access 
>> (and it’s content once displayed)?
>> 
>> And, just in case I’m taking the wrong direction of travel, the use case is 
>> that I’m looking to cobble together a simple test rig to help test page load 
>> times on limited bandwidth connections using Chrome’s network throttling 
>> settings, as I’m getting bored (& RSI) from the current manual process!
>> Best,
>> Keith 
>> ___
>> use-livecode mailing list
>> use-livecode@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: OAuth2 was Re: google sheets - anybody doing anything besides mergGoogle

[matthias rebbe via use-livecode]

Roland,

i found a forum post from mimu which included also a GoogleCalendarTest stack.

http://forums.livecode.com/viewtopic.php?t=31840

Is that the one you are referring to?

Matthias



> Am 13.03.2020 um 14:00 schrieb R.H. via use-livecode 
> :
> 
> If this would help...
> 
> I am using OAuth2 with the Google Calendar with a stack that was originally
> developed by Denver77 and had been posted the stack "GoogleCalendarTest" to
> the Forum in 2018. It explains clearly how to use Google's oAuthClient and
> actually, I was able to receive the client id, the client secret and use
> Google's OAuth2 protocol.
> 
> Similar, it should work for Google Sheets, Contacts, GMail, etc.
> 
> And it works very well up to date. Only, the token needed to be renewed,
> and Google requires that the user logs in passing all the authentication
> and permission tests if the app has not been registered with Google. A
> Google account is required
> 
> I will ask permission to post this LiveCode Calendar
> "GoogeCalendarTest.livecode" solution again. Or is it still somewhere? I
> could not find on the Forum and other places. I made some changes to it.
> 
> Otherwise, I would try to recreate it if there is a need and also try to
> test it with Google sheets (which I am also using as some clients require
> them).
> 
> Using any Google apps, some basic JavaScript knowledge is usually helpful
> since Google Apps Script (based on JavaScript) is the predominant user
> language working with Google apps and it will have to be used in most cases
> if server work is needed. Google App Script is not client-side.
> 
> https://developers.google.com/apps-script/overview
> 
> Sure, I think, we should develop specialized LC OAuth2 libraries to access
> the apps of the big players and make them available for
> 
> - Google
> - Microsoft
> - Apple
> - Amazon
> - etc.
> 
> in a straight-forward way, or at least a step-by-step instruction how to
> use their products with LC -- which also needs constant monitoring and
> updating for changes such big players introduce from time to time.
> 
> Which end user in the corporate world does not work with GMail, GMail
> contacts, Microsoft Outlook, etc? At least these are standards in the
> corporate world and could increase the attractiveness of LC very much if LC
> would offer help for specialized tasks using such apps as their base.
> 
> Roland
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Can the Browser widget access dev tools?

[Pi Digital via use-livecode]

Hi Keith

The chromium engine is not the same as the chrome browser. So the browser has 
the dev tools. The engine will have some code base that the browser can pull 
from to display as tools. 

The browser widget is a browser in its own right. It does not, at least as far 
as I’m aware, embed a chrome browser into a container. It uses the chromium 
engine to feed data that can be interpreted and displayed within a widget 
canvas. 

So dev tools would have to be written into the widget to access things l’île 
the throttling settings so that you could manipulate them using properties in 
the UI or by code. 

I hope this leads to solving your rsi problem eventually. It is a pain when the 
dev tools disappear when you load a new page and you can’t set it to stay up 
and stay throttled. Send a feature request to google. 

All the best 

Sean Cole
Pi Digital


> On 13 Mar 2020, at 10:55, Keith Clarke via use-livecode 
>  wrote:
> 
> Hi folks,
> I understand that the browser widget uses the platform’s default browser 
> engine. The (default?) feature set seems to be limited - e.g. no right-click 
> (on Mac).
> 
> There don’t seem to be obvious entries in the dictionary concerning developer 
> tools/menu/option. Please can anyone confirm whether it’s possible to access 
> Safari (Mac) or Chromium (Windows) Developer Tools programmatically from LC - 
> or control the right-click page inspector access (and it’s content once 
> displayed)?
> 
> And, just in case I’m taking the wrong direction of travel, the use case is 
> that I’m looking to cobble together a simple test rig to help test page load 
> times on limited bandwidth connections using Chrome’s network throttling 
> settings, as I’m getting bored (& RSI) from the current manual process!
> Best,
> Keith 
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Philosophical questions about the fontNames

[Pi Digital via use-livecode]

Hi

If you need a specific font to work because of look, scale, print, etc I 
suggest using a font editor app to copy the font you require, rename it to 
something unique (the name is embedded so just changing the file name changes 
nothing) and then embed it into your app in LC Standalone Settings. This is the 
only sure fire way of ensuring what you see in the dev environment is what the 
user will see on their xyz machine/device/printout. 

Sean Cole
Pi
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: OAuth2 was Re: google sheets - anybody doing anything besides mergGoogle

[R.H. via use-livecode]

If this would help...

I am using OAuth2 with the Google Calendar with a stack that was originally
developed by Denver77 and had been posted the stack "GoogleCalendarTest" to
the Forum in 2018. It explains clearly how to use Google's oAuthClient and
actually, I was able to receive the client id, the client secret and use
Google's OAuth2 protocol.

Similar, it should work for Google Sheets, Contacts, GMail, etc.

And it works very well up to date. Only, the token needed to be renewed,
and Google requires that the user logs in passing all the authentication
and permission tests if the app has not been registered with Google. A
Google account is required

I will ask permission to post this LiveCode Calendar
"GoogeCalendarTest.livecode" solution again. Or is it still somewhere? I
could not find on the Forum and other places. I made some changes to it.

Otherwise, I would try to recreate it if there is a need and also try to
test it with Google sheets (which I am also using as some clients require
them).

Using any Google apps, some basic JavaScript knowledge is usually helpful
since Google Apps Script (based on JavaScript) is the predominant user
language working with Google apps and it will have to be used in most cases
if server work is needed. Google App Script is not client-side.

https://developers.google.com/apps-script/overview

Sure, I think, we should develop specialized LC OAuth2 libraries to access
the apps of the big players and make them available for

- Google
- Microsoft
- Apple
- Amazon
- etc.

in a straight-forward way, or at least a step-by-step instruction how to
use their products with LC -- which also needs constant monitoring and
updating for changes such big players introduce from time to time.

Which end user in the corporate world does not work with GMail, GMail
contacts, Microsoft Outlook, etc? At least these are standards in the
corporate world and could increase the attractiveness of LC very much if LC
would offer help for specialized tasks using such apps as their base.

Roland
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???

[Pi Digital via use-livecode]

Hi Panos

Thank you for your lengthy descriptive explanation. It’s appreciated. 

Perhaps this should be written in the Release Notes - you know, for 
clarification. So that a newbie or even an oldie knows what to expect. If the 
RN says it’s not supported then they/we will be ‘scared off from using it. ‘It’ 
being either LC or the new OSs/Xcode’s/Eclipses/Whatever’s. Especially as you 
put so much effort into writing it. 

Still, your fix has been sat on github for 2months held ‘at the mercy’ of 
waiting for other bugs to be fixed and features added/completed. In 3 or months 
time Apple will ‘announce’ another major version of iOS MacOS and so on. And, 
at this rate it will be another 12 months (start your stopwatch) before 
‘support’ is added. And so the cycle continues. It could have been sorted and 
fed out 6mths ago without a doubt. 

It has to be remembered that LC is not the only software we have running on our 
systems, each with their own set of ‘requirements’. So of course we will have 
need for the latest os and Xcode. And then the need for multiple Xcode and 
terminal commands to avoid conflicts. So clarity is definitely needed and 
appreciated. Hopefully by painting a picture of the other side of the fence 
helps in understanding ‘why’ getting it out of the door quicker is very much 
needed. 

All the best

Sean Cole
Pi Digital

> On 13 Mar 2020, at 07:46, panagiotis merakos via use-livecode 
>  wrote:
> 
> Hello all,
> 
> Just a clarification, as this has been a source of confusion for a long
> time.
> 
> The current LC 9.x versions do support MacOS Catalina. Also, with the
> latest LiveCode versions (9.5.1 and 9.6 DP-2 - and possibly earlier
> versions too) you can still deploy apps for iOS 13.x - and these apps will
> continue to run even on iOS 14 and 15 in the future.
> 
> You do NOT need the latest Xcode for building apps, if you want your apps
> to run in the latest iOS version.
> 
> There are 2 different places where the iOS version comes to play:
> 
> (1) The iOS version of the device you want your app to run
> 
> (2) The iOS SDK version which is included in each Xcode
> 
> For (1) - you do not need the latest Xcode. Building apps with older Xcode
> versions will work just fine if your device runs the most recent iOS
> version. In fact, when a new LC version is released, and it includes
> support for building with the latest Xcode - it still includes support for
> building with older Xcode versions, if your Mac runs an older MacOS version.
> 
> So one might ask, why do we need to use the latest iOS SDK version (to
> build the app), so why is the LC team each time struggling to include
> support for the latest Xcode (which includes the latest iOS SDK version)?
> 
> The answer is we do NOT always need to use the latest iOS SDK version. But
> when do we *actually* might need it? Well, in the following cases:
> 
> (a) If you want to submit your app to the AppStore and Apple *requires*
> your app to have been built against a minimum iOS SDK version. When this is
> the case, we always release a LC version that supports the required
> Xcode/iOS_SDK version before the deadline posed by Apple
> 
> (b) If your app can support a specific new feature that will be available
> only when built against a specific iOS SDK (imagine iOS SDKs as libraries -
> a newer one can contain new functions/features, so if you want to use these
> new functions you have to use this specific iOS SDK to built the app). An
> example is the TouchID/FaceID support.
> 
> However, note that iOS SDKs with new features are released in the *major*
> Xcode versions, and the minor releases are usually just bugfixes in Xcode
> itself, for which you really do not care, as you do not actually use the
> Xcode IDE to built the iOS app.
> 
> So really in the vast majority of the cases we only need to support major
> Xcode releases, something which does happen, without major delays. So,
> since you can currently build apps against the iOS 13.1 SDK (i.e. using
> Xcode 11.1), there is really no need to add support for Xcode 11.2 or 11.3.
> 
> Similarly, when Xcode 12.x was released, we needed to add support for Xcode
> 12 (or 12.1), but not really for Xcode 12.2, 12.3 etc
> 
> The main reason we continue to add support for minor Xcode releases is that:
> 
> - we do not want to ask people keeping multiple (older) versions of Xcode
> in their machines.
> - a lot of people have enabled auto-updates, so their Xcode version will be
> updated automatically
> - someone downloading Xcode for the first time will probably download the
> latest version
> 
> So for these reasons we are trying - but not always successfully - to
> support the latest minor Xcode updates.
> 
> Hope this helps,
> Panos
> --
> 
>> On Fri, 13 Mar 2020 at 07:18, Richard Gaskin via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>> Sean Cole wrote:
>> 
>>> I've added updates to this bug relating to the script editor issues
>>> and crashes
>>> 
>>> 

Can the Browser widget access dev tools?

[Keith Clarke via use-livecode]

Hi folks,
I understand that the browser widget uses the platform’s default browser 
engine. The (default?) feature set seems to be limited - e.g. no right-click 
(on Mac).

There don’t seem to be obvious entries in the dictionary concerning developer 
tools/menu/option. Please can anyone confirm whether it’s possible to access 
Safari (Mac) or Chromium (Windows) Developer Tools programmatically from LC - 
or control the right-click page inspector access (and it’s content once 
displayed)?

And, just in case I’m taking the wrong direction of travel, the use case is 
that I’m looking to cobble together a simple test rig to help test page load 
times on limited bandwidth connections using Chrome’s network throttling 
settings, as I’m getting bored (& RSI) from the current manual process!
Best,
Keith 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC & Catalina; macOS 10.15.x; Xcode 11.3.x; iOS 13.3.x support ???

[panagiotis merakos via use-livecode]

Hello all,

Just a clarification, as this has been a source of confusion for a long
time.

The current LC 9.x versions do support MacOS Catalina. Also, with the
latest LiveCode versions (9.5.1 and 9.6 DP-2 - and possibly earlier
versions too) you can still deploy apps for iOS 13.x - and these apps will
continue to run even on iOS 14 and 15 in the future.

You do NOT need the latest Xcode for building apps, if you want your apps
to run in the latest iOS version.

There are 2 different places where the iOS version comes to play:

(1) The iOS version of the device you want your app to run

(2) The iOS SDK version which is included in each Xcode

For (1) - you do not need the latest Xcode. Building apps with older Xcode
versions will work just fine if your device runs the most recent iOS
version. In fact, when a new LC version is released, and it includes
support for building with the latest Xcode - it still includes support for
building with older Xcode versions, if your Mac runs an older MacOS version.

So one might ask, why do we need to use the latest iOS SDK version (to
build the app), so why is the LC team each time struggling to include
support for the latest Xcode (which includes the latest iOS SDK version)?

The answer is we do NOT always need to use the latest iOS SDK version. But
when do we *actually* might need it? Well, in the following cases:

(a) If you want to submit your app to the AppStore and Apple *requires*
your app to have been built against a minimum iOS SDK version. When this is
the case, we always release a LC version that supports the required
Xcode/iOS_SDK version before the deadline posed by Apple

(b) If your app can support a specific new feature that will be available
only when built against a specific iOS SDK (imagine iOS SDKs as libraries -
a newer one can contain new functions/features, so if you want to use these
new functions you have to use this specific iOS SDK to built the app). An
example is the TouchID/FaceID support.

However, note that iOS SDKs with new features are released in the *major*
Xcode versions, and the minor releases are usually just bugfixes in Xcode
itself, for which you really do not care, as you do not actually use the
Xcode IDE to built the iOS app.

So really in the vast majority of the cases we only need to support major
Xcode releases, something which does happen, without major delays. So,
since you can currently build apps against the iOS 13.1 SDK (i.e. using
Xcode 11.1), there is really no need to add support for Xcode 11.2 or 11.3.

Similarly, when Xcode 12.x was released, we needed to add support for Xcode
12 (or 12.1), but not really for Xcode 12.2, 12.3 etc

The main reason we continue to add support for minor Xcode releases is that:

- we do not want to ask people keeping multiple (older) versions of Xcode
in their machines.
- a lot of people have enabled auto-updates, so their Xcode version will be
updated automatically
- someone downloading Xcode for the first time will probably download the
latest version

So for these reasons we are trying - but not always successfully - to
support the latest minor Xcode updates.

Hope this helps,
Panos
--

On Fri, 13 Mar 2020 at 07:18, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Sean Cole wrote:
>
>  > I've added updates to this bug relating to the script editor issues
>  > and crashes
>  >
>  > https://quality.livecode.com/show_bug.cgi?id=22389
>
> Thank you, Sean.  I'm signed onto the report, and will add any notes I
> can if I see this on my Mac.
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   
>   ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode