teacherguy wrote:Thanks for the background Richard. I'm now much more aware of how small the number of folks coding for iOS actually is. My first clue was weeks back when I first posted here about the issue and no one replied. I just thought there were many iOS folks out there who were not having any issues.
Sometimes a post can go unreplied for some time for many different reasons. With the LC audience including a rather large percentage of Mac users, we see iOS deployment very strong among those making mobile apps with LC. But sometimes a particular issue may not be something many others have encountered. And a frequent thing that happens with me and some others I know is that I tend to use "New Posts" when I log in here, but unless I have time to read them all that listing may not include everything left unread since last time I was here, so it falls off my list and thus off my radar.
All sorts of things may contribute to a post not getting a quick reply, but as you've found the bug DB is the surest way to bring an issue to the core team's attention.
teacherguy wrote:One other thing: While clearly the problem was triggered by iOS, not LC, none of the other apps on my device exhibit this behavior, nor have I been able to find any developers or users who have seen this behavior. So it does appear unique to the way LC is compiling. I fully understand what you are saying about Apple changing things, but just wanted to point out that, as far as I've been able to tell, this is not something affecting Xcode developers.
No doubt, though the difference isn't Xcode per se, since LC uses XCode to compile their Mac and iOS builds (I don't believe there's any other way to do that).
Sometimes there can be a deprecated API, which happens frequently with Apple and something the team tries to stay up on. Other times it may be a particular use of an API that LiveCode has to use differently than other devs because a tool like LC is required to provide far more flexibility for its users than most apps ever attempt (XCode and Cocoa are set up to support apps whose layout is defined in advance, but an xTalk like LiveCode has to dynamically create layouts on the fly - oh the stories I could tell from those who make such tools; daunting to say the least). And other times it might simply be a bug in LC that was never exposed in earlier OS versions. And sometimes it's a bug in the OS.
Hard to say at the moment which of those is the case here, but I'm confident Panos will get to the bottom of it shortly.
In the meantime, kindly indulge an old tale from which I learned a lot:
When I first started developing with the engine we now call LiveCode, back then it was "MetaCard" and the Read Me file in the install included this rather bold claim: "MetaCard is unusually good at exposing bugs in display drivers."
As luck would have it, on my very first project with it I saw some odd cursor rendering anomalies (scrambled bitmaps) in my Windows app, something neither I nor any of my users were seeing with any other apps.
I had a long email exchange with MetaCard's developer, Dr. Scott Raney, trying to get him to understand the seemingly simple logic that if the problems I'm seeing are unique to his app and not seen elsewhere, this can only mean that it's a bug in his app.
He patiently tried to explain to me that there are many different APIs in use, and comparison with any Microsoft app was completely off the table because they were well known to be using APIs not made available to third-party developers. But even when comparing with other third-party apps, he referred me to the note in his Read Me and insisted I first update the display driver before he'd look into it further.
I was more than annoyed. But only at first. Once I checked my display driver version and compared it with the latest at the vendor's site, I found that indeed a newer version was available. And as soon as I updated the driver to the latest version the problem resolved itself. I worked with my customers to do the same, and they all had the same good result. Every single time.
I was never more glad to be so wrong. I gained enough confidence in the engine to be using it for most of my work ever since.
The lesson I learned isn't that the engine is perfect. Not at all. With a million lines of code translating my simple scripts into a dizzying variety of APIs for every OS they support, now and then I find bugs.
But what I did learn is that xTalks are fundamentally different from nearly every other type of application. Most apps just need to do whatever the OS-provided framework lets them, but xTalk developers ask far more. For example, in macOS the provided APIs only render pulsing default buttons against the current OS-defined background, but xTalk developers may put that button over a graphic, or an image, or anything else, and we still need that rendering to antialias well. This requires the engine team to stick their fingers between the fan blades (as the developer of another xTalk I've used likes to put it), to attempt things beyond what OS APIs normally provide.
Along the way we may from time to time find instances where an issue appears in our app that we don't see in apps built for just one platform in a lower-level language limited to the APIs as provided by the OS vendor.
Sometimes that's a bug in the LiveCode engine. And sometimes it's a bug in the OS. And at the outset of bug discovery, sometimes it isn't clear which is the case.
But if you follow the project's progress on Github (see
https://github.com/livecode), the one things that's always clear is that the core team is working 'round the clock to support their uncommonly broad scope of platform coverage with remarkable diligence.