Yes, we’re terribly sorry about the delay. We have finished and verified the fix and merged it to our beta channel in preparation for additional testing. We will however not make the release until Tuesday the 12th of November.
If you wish to test this ahead of the release then please try the latest beta.
I think there are some problems with labels. If I change the name from label, label.set() can’t find it. I assume the gang is already aware of if, but if you need me to investigate and explain the problem a little more let me know.
What problem?
We’re not aware of such a problem with labels afaik. Please describe it in more details and pls provide a small repro if you wouldn’t mind
And the 4th has come and gone and we haven’t made a release yet. We’re obviously very sorry for this. The delay is caused by a series of unexpected problems, mainly iOS 13 related. We’re down to the last issue now and should be able to make a release this week.
UPDATE
I thought I’d let let you know what our current status is.
It’s a bit technical and it’s mainly a heads up for the extension developers 
Basically, the iOS 13 release threw us a curveball, and introduced issues we didn’t have or had avoided in the past.
We couldn’t find an easy way around the issues, but we had to rewrite the app code for iOS. This took a little while, and we thought it went well. And it mostly did. So we planned for the release again.
Then later on, just before release, we noticed another issue. This was of course related to the aforementioned rewrite, and that should have been more obvious, but I missed it.
The new issue stems from the fact that previously the app was bootstrapped in a peculiar way, in order to get a hold of the main event loop. The app would then pump the messages from the main thread.
Now, with the rewrite, the app works as a more normal app, letting the app itself pump the messages, but that also means (as with many UI applications on many OS’es) that the OS callbacks come from a different thread. And the Lua context isn’t thread safe.
We already have that type of setup with Android, and you might have noticed something like a “command queue” in the extensions. That’s the solution.
I.e. when given a callback, store the info for later, then do the callbacks to Lua on the main thread, in the Update function of the extension.
We’re currently in the middle of updating our extensions to be thread safe, and in the mean time adding these recurring helper functions/structs to the DefoldSDK so that you can use the same mechanics later on.
So, no release this week either, but it’s now scheduled for next week.
Again, sorry for the delay, and thanks for your patience.
There are
[[NSOperationQueue mainQueue] addOperationWithBlock:^ {
// Main thread.
}];
and
activity.runOnUiThread(new Runnable() {
@Override
public void run() {
// Main thread.
}
});
for iOS and Android. But for executing callbacks we need a valid Lua state, which is a problem to get inside those constructions.
Yes, you need to store the callback info beforehand.
Although we do occasionally use code like that, the main problem I see is the scheduling of those calls.
When in the frame are those calls executed?
Depending on task, it’s importance varies ofc.
I much prefer to follow the paradigm of the engine, and handle the callbacks during the update of the engine.
Added benefit is that the core code usually consolidates into a smaller, less duplicated code.
This sounds great. This would be helpful in other non-iOS places as well. For example, I avoided implementing FMOD callbacks exactly because I didn’t want to spend time writing a command queue.
This will be great. Dmsdk has lots of useful helper. But since it is not possible to use it locally I prefer not to include it. It would be great if we can download and use the dmsdk locally(or run the build server locally). Cloud build workflow is tough to work with (at least for me).
We are planning to submit one of our casual game to publishers(as soon as possible). We don’t have high expectations but actually we already should sent it. It is highly possible that they will check it out on iOS 13. Currently I’m holding it until the upcoming Defold update.
I know it is tough and I would like to thank you all for your efforts… I hope you guys can fix it next week. 
For iOS 13, not all apps failed, it mostly worked fine. Bit we noticed some global popup didn’t show (e.g. in facebook)
or run the build server locally
It’s still coming, we just got side tracked by this…
I’m using @sergey.lerg’s AdMob and I think it fails with popups(interstitial/rewarded ads) too. Also Android dependencies are made a mess. I want to be sure about the game is working as expected before submitting to publishers.
Since the game is not using the physics, this is the other blocker for me right now:
Which devices affected? I’m not sure why, but an old build of “Look your loot” works correct on iPad Pro 2017 with iPadOS (iOS 13 for iPads), shows ads (admob), and review popup (defreview extension).
It was actually first discovered in the admob extension. First I thought I just need to update the sdk, but alas. https://github.com/Lerg/extension-admob/issues/13
(I guess)It is related to building with new SDKs. Since your build is old, it should be fine. But you’ll come across this problem when you want to build a new version now.
No luck yet on the new version?
1.2.164 released.
Two things:
It seems you are using the beta build: 1.2.164 sha1: 14793…
Yes it says stable, but that’s another issue in our packaging.
You want it to say “editor-alpha” in that dialog.
The info.json is a mix of the new version number and the stable sha1:
{"version": "1.2.164", "sha1": "13261949f45c333806c8aac8bd5b08124ca2810f"}
SO basically, you’ll still get the 1.2.163 when using this sha1.
I’m not sure yet what script updated the stable/info.json, but I hop I can figure it out soon though.
We are now zeroing in on a new release and will be able too release as soon as some additional testing has been completed. It could happen as early as today but may also have to wait until Monday.