Jen can you post the bug ID # that was emailed to you here in the thread as a reference?
@nipon.ph The current version of Corona SDK’s public build should work with Xcode 6, however the Xcode simulator might not launch correctly. That has been fixed in a daily build open to Pro and Enterprise subscribers. As far as AdMob goes, Starter accounts can use AdMob.
Hey…
I’m using the most recent daily builds and although I get the notification popup to access location data, the app fails to find my location; my app was rejected over this, huge waste of time.
Did you test it on a device before submitting it?
Can you try and build our sample app for locations and test it on a device and see if you’re having the same issue?
If you feel there is a bug, engineering will need to see a sample project that has the issue. It will need to have a config.lua and build.settings that you are using. It will need any assets necessary to run. Compress all of that into a .zip file and then file a bug report.
Thanks
Rob
I made the unfortunate assumption everything would work using iOS 7.1, but it broke on iOS 8 regardless. I now have secured a test device that can run iOS 8+.
Now Working
I moved the hidden native.mapView on screen and it started working; found my location without a hitch. Any idea?
I also got the device log from previous builds and the console read:
“location icon should be set to active”
then a couple seconds later (before successfully returning any location data, with map functionality still running)
“location icon should be set to inactive”
Thank you,
Aidan Wolf
Depending on the device you’re testing on it may or may not be able to find the GPS satellites. It can take a few minutes for them to sync up or in some buildings you can’t get the GPS going at all. The native.newMapView() is dependent on the GPS’s ability to determine where you are.
So I did some more testing on iPhone 4 (7.1.2), iPhone 5s (8.0), and iPhone 6 (8.1), and the gps finding location was dependent on if the mapView was visible on screen. Off screen it could not find location, on screen it took under 2 seconds.
Hello,
We have two new issue with iOS8.1
It seems that using Native Map generate Memory Warning on iOS 8 with daily v2014.2490
The second one is that :setLabel() function for widget’s button doesn’t work with v2014.2490
Can you fix that as soon as possible please?
The map is totaly unusable.
Hey GBF,
I’m using v.2014.2468 for iOS 8, I did not receive a memory warning while testing, though I might have missed it? I just submitted my app for review again, hopefully there’s not a hiccup. You might want to move back to an earlier daily build and use iOS 8.
I think Corona Labs is up to its eyeballs in new fixes and honestly the manner in which they are dealing with it comes across as unprofessional.
Luckily my issues with Corona and iOS 8 did not come at a financial cost, but they definitely wasted 2 weeks of my time and 2 weeks of my Pro license. What would have made sense to me is the Corona staff going through absolutely every API to check what works and what doesn’t, release that list on their blog, and check it off as the engineers make fixes. Simply waiting for the storm of bug reports or leaving devs to scourer the forums for the slightest bit of info isn’t right. Kind of feels like Compatibility v1.0 all over again, almost like they’re focusing on big ideas rather than bugs like before (Corona Cards?) This rant comes from the heart CL.
thank you,
Aidan Wolf
We work on bugs submitted using our bug reporting system. If you have a bug, please submit it and a test case along with complete details so we can reproduce it. Saying there are problems in the forums doesn’t help us find and fix the issue.
Thanks,
Tom
Hi all, just wanted to chime in on a few sentiments I’m seeing here. I definitely understand how frustrating it can be to encounter bugs and try to figure out how to work around them. Just like you, we build our stuff on other people’s stuff — in our case, it’s the OS’s put out by Apple, Google, and Microsoft.
Let me first talk about some of our approaches and thoughts. You might not agree with how we approach them, but at least you know where we come from.
First, when there is a new version of an OS, there will inevitably be growing pains that any developer will have to face. It’s a fact of life. Our team (collectively and individually) have learnd that if you want to target the newer OS, you should expect to bleed. That’s why it’s best to be conservative.
We designed Corona so that your apps should be forward compatible with newer versions of an OS. Consequently, there is usually no need to switch to the newer OS target right away, and so our rule of thumb is that if you have an app built against an older OS, you should continue to target that older OS.
This is especially true, if you are about to ship your app. Minimize the moving parts.
Second, when Apple (or Google, etc) releases new versions of its OS, we do tend to wait-and-see, at least until the later betas. That’s deliberate. In the past (too often, in fact), we’d get bug reports against Corona only to find out that these were bugs in the OS, later to be fixed by Apple. A poignant example that comes to mind is that the Mac version of the Corona Simulator would not work on Yosemite due to OpenGL/layer-backed regressions that later got fixed by Apple (no changes in Corona were needed).
Third, we have to make some assumptions about what is going to work and what doesn’t in a new version. For example, we have to assume the OpenGL APIs on a new version of the OS will continue to work as they have in the past. So, it’s not practical for us to go through each OS-level API to make sure that it works according to spec, as that would not be an effective use of time or resources. In other words, we do expect the majority of APIs in a new version of an OS to be consistent with the previous.
And so finding the tiny minority of things that breaks between releases is really difficult. It’s like finding a needle in a haystack. What we do focus on is whether our set of test cases continues to work, in hopes that everything passes (or that we find that needle). So for example, with rendering, we exercise a set of test projects to make sure things are working as expected.
Finally, let me address one area of complaints here that’s relevant, and that is mapviews:
@GBF Comm, we just re-ran our test and everything works fine. This is why we ask for test projects because it’s a 100% certainty that our assumptions about how you set things up code-wise are different from how you actually set things up, and the critical clues lie in those differences.
@AidanWolf, if there’s a sudden change in behavior such as the fact that offscreen mapviews have worse performance from onscreen mapviews, that’s not something Corona is doing specifically to distinguish those cases. That suggests it’s an OS-level thing. And if I were to hazard a guess, it’s b/c Apple wants to optimize performance for the intended use case of MKMapView objects (which is what Corona is wrapping) which is that the user is interacting with a mapview onscreen.
Walter, thank you for the thorough response! You brought to light many aspects of transitioning & compatibility I never considered previously. I wish you luck with the iOS8-related bugs.
Have a good one,
Aidan Wolf
Hi Walter,
Thank you for the detailed report on the iOS 8 issues. Appreciate it.
BTW, you may want to remove the parentheses_ “)”_ from the link to the blog post – otherwise, clicking on it will send us to error 404 page.
Naomi
Thanks Naomi. Just fixed the link.
There is an issue with Facebook plugin (how surprising) - submitted Case 35950.
Basically the app is force closed with a message “failed to scene-update in time” while in the background.
In the latest build CoronaSDK 2014.2445 admob ads working on ios8, but stopped working on ios7. After displaying advertisements everywhere application crash when changing scenes. So now everything is very bad.
About the problem with starting the iOS-simulator outside of Xcode:
The tool ios-sim was updated to work with Xcode 6 a while ago, we use the new version and it solves some of the problems, the iOS-simulator now can be opened again:
https://github.com/phonegap/ios-sim
But the changed the internal paths to the content that is displayed in the iOS-simulator, so I guess you’ll have to adapt your code (as we have to adapt ours for our animation editor that calls the iOS-simulator directly.
Best,
Andreas
Walter, great post and update on the issues vs progress. Thank you very much.
I have one question.
Given Corona Labs history and track record, why is Apple not giving you some of the information ahead of time (on an NDA basis) so you can get the changes / fixes aligned ahead of time? It appears that Corona Labs does not have any additional insight over and above what any $99 paying Apple Dev license holding person has. This worries me.
Is this something you plan to address at Apple leadership level at some point?
Thanks,
Kerem
I’m not sure apple know what they’re going to do next… 
That isn’t how it works with anyone besides the SDK previews Apple gives to specific companies when they want to demo a new API (i.e. getting Unreal on Metal). Corona has had plenty of lead time like everyone else. Most of these changes were documented and effective in iOS 8 beta 1 which shipped over three months ago.
This post doesn’t even cover the 6 and 6 plus, which are stuck serving unoptimized @2x assets until we can build against iOS 8. Honestly, it’s a little concerning.