iOS build fails without error logs (SOLVED)


I’ve faced the issue I don’t know how to investigate and fix.

Here is an example project: (212 mb)

When I’m trying to make a build for iOS it fails, but in Build Log there are only warnings, no errors and the log looks like a previous successful build-log. If I delete build folder, then it fails with:

'armv7-ios' could not be built. Sdk version: '5295afb3878441fb12f497df8831148525dcfb10'
Log: '<failed reading log>'

And I saw in build folder that there are no logs, only manifests generated.

There are some native extensions (added as simple folders, not github-links):

  • firebase
  • ironsource with Admob + FB ads + Unity Ads + Vungle + Applovin

The issue appeared after adding firebase. Without firebase it works as before. And it fails only with such exact setup! If I remove ad networks from ironsource/lib/ios/in different combinations it works again, for example:

  • firebase + ironsource + admob -> works
  • firebase + ironsource + admob + facebook -> works
  • firebase + ironsource + admob + applovin -> works
  • firebase + ironsource + admob + facebook + unity ads + vungle -> works
  • firebase + ironsource + admob + facebook + applovin + unity ads -> works
  • firebase + ironsource + admob + facebook + applovin + unity ads + vungle -> does not work

So, when I remove either Vungle or Applovin from the setup it works, but I don’t see any system in this.

When I was preparing the repro-build I’ve noticed, that in unpacked state it’s over 500mb, and here @Mathias_Westerdahl said there is upload limit for 500mb. Can this be a root of the issue? How can I avoid it?



First, the log.txt is actually unpacked from Check if that file was updated, and if so check the log inside it.

However, as you mention, the build might be too large to actually build.
I would have thought it would report a clear message if so, but maybe that error logging broke.

To be frank, 500mb is HUGE. In comparison, a vanilla engine is ~2.5mb.
To cut down on size, we always choose libraries that are small and fast. That’s a good rule of thumb for any software developer.

A workaround is of course to see if you can strip the libraries from unneeded bloat.
Use the lipo tool to strip away those architectures you don’t need (e.g. desktop).
Also use the same tool to just extract the architectures into individual libraries, and put them in each arhicitecture folder. The build size is limited per build, so if you make each architecture’s libraries smaller, it will help.



Nope, “.internal/cache/” folder is empty:
So, if the issue is in the project size - then there is no clear message, unfortunately.

I can understand the point, that it’s a good practice to keep your projects small, but the limit itself looks synthetic and artificial. And why exactly 500mb? If it’s just a matter of one config on backend, can it be simply changed?

I need all these SDKs (and there were not listed other extensions used in my real project, so there are even more) - that’s the reality of modern mobile f2p games development. Throwing any of those away just because there is some size limit for projects to be build sounds crazy (you did not say that, but it sounds so).

A workaround is of course to see if you can strip the libraries from unneeded bloat.

These extensions and libs are 3rd party tools and if we’re saying about good practices - it does not sound good to modify manually 3rd party SDKs. I want to be able to keep my sdks supported and updated and be sure, I can always rely on official docs. I can fix it now by stripping and splitting, but maintaining all this looks complicated (if not say more) :confused: And what if stripping and splitting will be not enough?

Yes, it’s a workaround, but honestly I’d prefer another “workaround” - changing (or removing) size limits (if the issues is really caused by size, I’m still not sure)



I did not say it, but what what I meant is that if there is a choice…

It’s a bandwidth issue on the servers (we’ve always had it)
We’ll discuss this limit within the team.

Well, we do try to keep to good practices. Sometimes that means setting limits.
And sometimes it means reevaluating the current solutions.
For instance, I recognize the fact that it’s very time consuming to fix 3rd party code manually.
And, while I do not like it, I cannot affect the code size of those projects either.

So I think the more pragmatic approach is what you suggest, to increase the size limit.

As to the question: “What should the size limit be?”, neither figure will ever feel good, since we’re increasing it from the amazing 500mb. I will not remove. Maybe 1gb will be enough?

As mentioned, we’ll discuss internally first.



I’d like to add to this by saying that we still plan to make it possible for the community to run your own extender (build) server. I know we’ve said it in the past and it has been delayed several times, but we should be able to offer this solution to you within a month or two.

The build servers, together with build server logs, our download server and the forum are all hosted on AWS. AWS offers a great selection of services with very competitive pricing, but despite this it is by far the largest fixed operating cost we have for Defold, which is why we always have to carefully consider not only the performance implications, but also cost implications, of all changes we make.



I’d be happy to lower your AWS costs by building my projects locally :slight_smile:

Especially by the additional fact, that my builds now are very time consuming and I’ve noticed a strict correlation with the internet connection quality.

Thanks for helping, I’ll try to strip/split some of the largest “.frameworks” for now and will be waiting for new solutions from your side. :+1:

1 Like


Mathias will increase the 500Mb limit to something higher later today.



I’ve now updated the beta server with this new 1GB upload limit.
Please try it out to see if it works for you.



Hmm, I’ve changed the build-server, but it failed with the same scenario :confused:



Hmm, apparently this limit was defined in multiple places. I’m on it…



I’ve now release a new beta-server, please try it again.



Now it works! Thx!