We’re delaying the release of 1.2.164 until we have solved some iOS 13 related issues. We’re narrowing down the search and should have a solution ready soon. We have a QA session booked for Friday the 1st of November and if the release passes QA we plan to release 1.2.164 on Monday the 4th of November.
@Mathias_Westerdahl managed to solve the issue by rearranging the way we setup the iOS application. We should be good to go for a release on the 4th of November.
15 Likes
2 Likes
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.
10 Likes
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.
1 Like
What problem?
1 Like
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
1 Like
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.
11 Likes
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.
16 Likes
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.
3 Likes
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.
1 Like
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. 
4 Likes
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…
3 Likes
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:
2 Likes
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.
1 Like
No luck yet on the new version?