If you have apps in the App Store they may be breaking

[teacherguy]

Weeks ago I posted about a problem with iOS 10 whereby Livecode apps do not format properly (they appear down and to the left, and partially off the screen). I was hoping that perhaps this was an Apple issue that would be fixed through one of the iOS 10 betas over the summer. We are now on beta 8 and no change. With iOS 10 being released in just a few weeks, this is a huge issue. I am thinking it has something to do with the size of the stack (mine, on the iPad, were created as 1024x768) not translating properly to hi res. If I have to redo everything for hi res that is going to be a massive undertaking. I've never had an issue on hi-res devices, until iOS 10.

Does anyone have any insight? I have contacted Livecode and am waiting to hear back.

[FourthWorld]

What is the bug report number?

[teacherguy]

18312 is the bug number

[teacherguy]

Problem identified

http://quality.livecode.com/show_bug.cgi?id=18327

[FourthWorld]

Thanks for submitting that report.

It seems this problem is specific to iOS 10, yes? Since that version hasn't been released yet, how is this issue affecting apps currently in the app store?

[teacherguy]

It's breaking apps for any users who are on the public beta for iOS 10. More and more users are taking advantage of Apple's beta program.

And obviously it will impact anyone who upgrades when it becomes public in about a week.

[FourthWorld]

It's breaking apps for any users who are on the public beta for iOS 10. More and more users are taking advantage of Apple's beta program.

Currently that's about 0.05%:

iOS Version Stats
https://david-smith.org/iosversionstats/

Moreover, it's beta, so as with any unreleased software the relative few adventurous enough to install unreleased software expect to find issues with it, which is the reason for testing. Here's a brief list of some of the caveats about Apple's beta OS:

iOS 10 Beta Problems: 5 Things to Know
https://www.gottabemobile.com/2016/08/2 ... s-to-know/

The core team at LiveCode spends favorably disproportionate time on iOS, so I'm sure they're working on any compatibility issues as quickly as they can.

But in all fairness, given that any beta OS is in flux until release, it seems reasonable to expect that any developer using as many APIs as the LiveCode team uses to support such a broad scope of features may require some time to make sure they fully account for Apple's issues with backward compatibility.

Filing a bug report with LC is the best first step. Thank you for submitting yours.

Filing one with Apple may also be help ensure their new OS doesn't break other existing apps that, as you report with your LiveCode app, run fine under stable versions of their OS.

And obviously it will impact anyone who upgrades when it becomes public in about a week.

As of this morning the tech sites are reporting that Apple will announce iOS 10's release date tomorrow. How did you get advance notice of the release date?

[FourthWorld]

Looks like the LiveCode team has made some good progress toward diagnosing ways to accommodate Apple's change in iOS 10:
http://quality.livecode.com/show_bug.cgi?id=18327#c3

[teacherguy]

As of this morning the tech sites are reporting that Apple will announce iOS 10's release date tomorrow. How did you get advance notice of the release date?

Special event happens today, presumably iPhone 7 unveil. Usually the phone goes on sale a week and a half later, with the new OS.

I understand that it is tricky to catch everything, and I'm appreciative for the efforts, especially the fact that I can code for iOS at all. The concern I'm trying to express is that by waiting until iOS 10 is released, those of us that have apps in the Store are putting users through an unknown period of time where the apps may not function. Seems to me that we are supposed to be catching those issues prior to the release, which is why the beta of Xcode is always made available in advance. But it seems that LC waits until the GM release to start incorporating things like the simulator and such...not sure why that is the approach since it defeats the purpose of the beta period.

[FourthWorld]

But it seems that LC waits until the GM release to start incorporating things like the simulator and such...not sure why that is the approach since it defeats the purpose of the beta period.

"Seems" is a good choice there. Things may appear one way or another, but when we look at the release history of LiveCode we see release after release focused specifically on addressing issues unique to iOS. On the whole, I think it's safe to say that the team puts in quite an earnest effort with iOS, favorably disproportionate to its market share among the many platforms LiveCode supports.

When you have a specific concern, what you did here is the most helpful: provide a bug report describing the issue, with a recipe for reproducing it. Stay engaged as they ask for more details, as you have. Panos is on the task doing everything humanly possible to address this in a timely manner. It seems likely they'll be able to address it with minimal if any impact on developers, as they've done repeatedly in the past.

But there is another aspect here worth noting: all technical issues with any system can be resolved by identifying the differences between the working and non-working states. Here you have an app that works well under the stable version of iOS, but not under Apple's v10 beta. Your LiveCode app hasn't changed, the OS is what changed. Looking for the differences between the working and non-working states, it would appear the difference here is the OS, not LiveCode.

If compatibility with iOS is any sort of ongoing concern (and those who watch LC's progress in Github are aware of the stellar effort the team puts in to accommodate Apple's frequent changes), it may be worthwhile taking a moment to ponder why that's the case.

LiveCode is supported on both desktop and servers for macOS, Windows, and Linux, and can also deploy to iOS and Android, with a community-supported build for Raspberry Pi. We rarely see that scope of platform coverage in any other language, and almost never with a language that provides integrated GUI support.

For all those platforms, only one requires so much ongoing revision by developers: iOS. Every other OS is maintained by its vendor with a high regard for the customer benefits of backward compatibility. Apple's priorities are apparently different. Just as we've seen with the unusually expensive transitions ftom 68k to PPC, Classic to OS X, PPC to Intel, etc., the iOS changes seem to require similarly disproportionate expense for developers, But as you're seeing with the LiveCode team's work on the issue you reported, they undertake that work with enthusiasm because they use and like Apple OSes extensively throughout their company, and appreciate the value of those OSes for their developer base.

Yes, when software changes in ways that break things in other people's otherwise-working code, it results in stress for everyone. But in all fairness, the team seems to be doing a very good job under the unusual circumstances Apple so frequently introduces.

All that said, given that LC's code is working well with stable versions of iOS and breaks only in the iOS beta made publicly available specifically for this sort of testing, it may be useful to take advantage of this testing period by filing a bug report with Apple as well, which appears at the moment to be the source of the problem by virtue of being the only element that's changed between the working and non-working states.

[teacherguy]

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. When Tom made a similar post we starting communicating with each other and realized that it was surely a bug.

I consider myself a very rudimentary coder. I've never participated in the bug reporting. I now realize that it is part of my responsibility to the platform. I wish I had filed the bug back then instead of just posting about it here. I will definitely be more proactive going forward.

[teacherguy]

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 non-LC 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...in case that provides a hint to anyone.

[FourthWorld]

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.

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.