Hello

I'm in the process of doing a big upgrade of the CocoaPods daemon (upgrading the OS in the underlying VM, updating Ruby, and updating CocoaPods itself) so the next version (3.60.1) should hopefully fix this problem. It'll be ready in a few days.

Can you provide a log please so that I can better understand what you're describing ?

Yes. I suspect an executable is called which is not the right one. Please open cmd.exe and type "set". Then post the output. This will show me your environment variables. If there is sensitive data, please redact them out before posting.

Alternatively you may try this:
1. Create a new, empty Windows account and try running the builder from there. Does it work ?
2. Try switching your Windows account’s locale to English/U.S. Does it work ? (I’m not particularly hopeful with this one as I usually do my tests from a French version of Windows and it seems unrelated. But we have to try nevertheless).

Okay

Indeed your PATH environment variable is one of the longest I’ve seen, if not the longest at all.

What looks problematic with it is the fact that all your additional search paths are defined *before* the standard search paths. So for example if one of those extra search paths contained a tool that’s named identically to a standard Windows tool (for example "find.exe") then that tool would be called instead of the normal tool. Which might explain the curious error as the substitute tool may expect other parameters than the Windows one.

Creating a new Windows user account with an unpolluted environment and testing in it would confirm or infirm the diagnosis. Can you do that ?

Another thing you can do is this: reset the PATH environment variable to a strict minimal value.

Edit Toolchain\cocoapods\cocoapods.cmd and right after the ":startup" label, add this:

% cocoapods.cmd
:startup

rem // for safety, rebuild a minimalistic, default PATH. This is the default PATH for Windows 10.
set PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\
%

Let me know how it turns out.

PowerShell can execute Ruby which can execute CocoaPods on Windows, but really, if that was a viable solution I wouldn't have gone through the pain of creating such a complicated setup to make it run. the CocoaPods master repo hosts countless user-supplied modules, 99% of which are submitted from an operating system which uses a POSIX-compliant filesystem. What happens when you try to download pods from Windows on a Windows filesystem is that you too often end up with failures because, for example, a random chinese guy created a pod whose name ends with a space character, and that is illegal as a file/directory name on Windows. Or the name contains a slash, or a colon, and Windows can't create it. Or a pod hosts files with very long names in a great number of nested subdirectories which makes the total absolute pathname exceeds the MAX_PATH limit on Windows which is 260 characters. Or...

The only restriction for file names on a POSIX filesystem is that the file names must not contain a slash, which is the directory separator character.

On Windows, the restrictions are many. The filename must not exceed a certain length, it must not contain a dozen forbidden ASCII characters : slashes, backslashes, colons, etc ; it must not *end* with some characters (spaces for example), and its total path from the drive root must not exceed 260 characters. This is just impossible to make CocoaPods work reliably when it runs natively on Windows. Hence the VM.

Looking at what can print "Parameterformat falsch - <something>" among the Windows tools I think it's the "chcp" tool. Its output format changed recently (a very bad thing!) and now it includes a dot. https://github.com/python/cpython/issues/78325

The script tries to store the current codepage by parsing the chcp tool output. It already strips spaces:

% cocoapods.cmd line ~40
rem // get the current codepage
for /f "tokens=2 delims=:" %%a in ('chcp') do set ORIGINAL_CP=%%a
set ORIGINAL_CP=%ORIGINAL_CP: =%
%

but your situation tells me that it should also strip dots from the output:

% cocoapods.cmd line ~40
rem // get the current codepage
for /f "tokens=2 delims=:" %%a in ('chcp') do set ORIGINAL_CP=%%a
set ORIGINAL_CP=%ORIGINAL_CP: =%
set ORIGINAL_CP=%ORIGINAL_CP:.=%
%

Try this patch and let me know what it does please.

The build system makes a lot of effort to compensate for these shell script-based custom build phases. It manages to lay out the necessary frameworks properly, except when there’s resource data files. In this case they must be laid out by hand using a pre-packaging script.

From what I see in your build log, your app seems to build successfully. That means 95% of the job is done.

Now you should test it on your phone ; if it works, congratulations ! If not, use the remote debug console to catch the error logs and provide it with what it needs (a missing Info.plist key with your ad publisher ID is by far the most common cause). Read the framework publisher’s documentation to find out what needs to be done. Post the crash log here if you need help.

There’s no reason it doesn’t work if you followed the steps indicated by IronSource themselves here :

https://developers.is.com/ironsource-mobile/ios/ios-sdk/#step-1

Just read through everything. I see that you need to build using the -ObjC linker flag and that some plist files require to be updated. Have you done so ?

It will solve things, absolutely. Many users already successfully built and published projects that use IronSource. All is needed is to understand the IronSource instructions.

Is this configuration expected ? Yes, it is. Using the CocoaPods daemon helps you *build* your pods automatically, but *configuring* your assets is still to be done manually by following the asset publisher's instructions. The same would be true for Google Ads and other ad frameworks.

The -ObjC linker flag that you should use at build time should already have been added by the CocoaPods daemon. So your next task is to do the changes indicated by IronSource to your project's plist files.

I can't stress enough how important it is to test your iOS app on a real device with the remote debug console enabled. The logs are generally immensely helpful in this situation because they tell you exactly why something doesn't work - and you can deduce what remains to be done to make it work.

:: @Pierre-Marie Baty added on 21 Nov ’23 · 16:17

*edit* About your remark: "Sadly I know only a little of the Xcode part of things. When I build the project from Unity and then just Archive and upload to app store from Xcode in my mac VM, it just simply works fine. I didn't need to do anything like this at all." -- Xcode can do all that automatically, because your project contains shell scripts in its "custom build phase" step. But these scripts run Apple shell commands. They can't run on Windows: the command-line tools are not the same. But these scripts simply do automatically what the IronSource documentation instructs developers to do manually, which is why it has to be replicated by hand (or automated using a tailor-made Windows-specific batch script) when building on Windows.

Don’t hesitate to ask for explanations on anything you would have difficulties to understand.