Forum Xamarin.iOS


The Xamarin Forums have officially moved to the new Microsoft Q&A experience. Microsoft Q&A is the home for technical questions and answers at across all products at Microsoft now including Xamarin!

To create new threads and ask questions head over to Microsoft Q&A for .NET and get involved today.

IPA output location

Since switching to the beta channel I've noticed the IPA file is being placed in a folder e.g.
<path>/bin/iPhone/AppStore/<project> <date time>/<project>.ipa

This is annoying because it ruins my build script. Have I missed something obvious here?

Best Answers

  • JarrodKochJarrodKoch USMember
    Accepted Answer

    For anyone else who runs into problems with the .ipa not being output where it's supposed to be, you can add the following into your .csproj to copy it where it belongs:

    <PropertyGroup> <CreateIpaDependsOn> $(CreateIpaDependsOn); CopyIpa </CreateIpaDependsOn> </PropertyGroup> <Target Name="CopyIpa" Condition="'$(OutputType)' == 'Exe' And '$(ComputedPlatform)' == 'iPhone' And '$(BuildIpa)' == 'true'"> <Copy SourceFiles="$(IpaPackagePath)" DestinationFolder="$(OutputPath)" /> </Target>


  • prashantvcprashantvc USXamarin Team Xamurai

    It's a side effect of the bug fix
    The $(IpaPackagePath) MSBuild variable can be used to locate the .ipa file
    after the build.

  • BrandonSandersBrandonSanders USMember ✭✭

    Hi @prashantvc , it appears that the Bundle is not being appended to the .ipa file name as well. Is this working as intended?

  • JarrodKochJarrodKoch USMember

    Is any of this being addressed? We created shell command scripts to automatically upload to iTunesConnect when we build for AppStore, this has caused us to have to use the painful manual upload process.

  • JarrodKochJarrodKoch USMember

    So, I have tried manually editing my .csproj as described in, unfortunately since the generated folder uses a timestamp for its naming, and this step does not occur in the same second as the creation of the folder, it fails to regenerate the same folder name by once again using DateTime.Now().

    I'm really not keen on changing the Targets files, and it's not clear why there was any need for the generated folder. Will the $(OutputPath) build variable be fixed to contain the true output path? Or will we have the ability to not have the generated folder created at all?

  • JarrodKochJarrodKoch USMember
    Accepted Answer

    For anyone else who runs into problems with the .ipa not being output where it's supposed to be, you can add the following into your .csproj to copy it where it belongs:

    <PropertyGroup> <CreateIpaDependsOn> $(CreateIpaDependsOn); CopyIpa </CreateIpaDependsOn> </PropertyGroup> <Target Name="CopyIpa" Condition="'$(OutputType)' == 'Exe' And '$(ComputedPlatform)' == 'iPhone' And '$(BuildIpa)' == 'true'"> <Copy SourceFiles="$(IpaPackagePath)" DestinationFolder="$(OutputPath)" /> </Target>

  • AlexSAlexS USUniversity ✭✭✭

    Guys from Xamarin, why do we have this problem and when will the fix be available?

  • AlexSAlexS USUniversity ✭✭✭

    According to the support, editing Xamarin.iOS.Common.Targets for now is the suggested workaround.

  • AlexSAlexS USUniversity ✭✭✭
    edited June 2016

    So the fix is to go to the folder /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/2.1/ and open file Xamarin.iOS.Common.targets (or open file directly /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/2.1/Xamarin.iOS.Common.targets).
    Then change line 1607 to

                <IpaPackageName Condition="'$(IpaPackageName)' != '' And !$(IpaPackageName.EndsWith ('.ipa', StringComparison.OrdinalIgnoreCase))">$(IpaPackageName).ipa</IpaPackageName>
                <IpaPackageName Condition="'$(IpaPackageName)' == '' And '$(_BundleVersion)' != ''">$(_AppBundleName)-$(_BundleVersion).ipa</IpaPackageName>
                <IpaPackageName Condition="'$(IpaPackageName)' == ''">$(_AppBundleName).ipa</IpaPackageName>

    and line 1734 to

    These changes are taken from the Xamarin.iOS.Common.targets of previous stable release (5.10.3).

    Thank you everyone who helped to find this problem and solve it!

  • @AlexS Have you seen @JarrodKoch's suggestion of editing your .csproj? Saves you having to back up the target file every time you upgrade Xamarin.

  • AlexSAlexS USUniversity ✭✭✭

    @PhillipWilliamson I did. Having 10+ projects on build server and editing just one .targets file now instead of 10 .csproject files is the option I choose. Next update will overwrite .targets and hopefully fix the problem we are all having here (I know support is working tightly on this). Changing .csproj now will require changing it back after .targets are fixed by the next update.

  • AmlethAmleth AUMember ✭✭
    edited June 2016

    I made a change to Xamarin.iOS.Common.Targets, i only change line 1608 to
    So it looks like the following

        <IpaPackageName Condition="'$(IpaPackageName)' != '' And !$(IpaPackageName.EndsWith ('.ipa', StringComparison.OrdinalIgnoreCase))">$(IpaPackageName).ipa</IpaPackageName>
        <IpaPackageName Condition="'$(IpaPackageName)' == ''">$(_AppBundleName).ipa</IpaPackageName>

    After this change the ipa was in the same place as it was prior to update.

    Also if you are building on Windows the file you need to change is C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets

  • CodyBCodyB USXamarin Team Xamurai

    Hey everyone!

    Another option is to add a copy target to your csproj file, which will copy the IPA to a desired location. I have posted a Q/A style entry on Stack Overflow describing this process:


  • MatthewOConnorMatthewOConnor USBeta ✭✭

    This is very annoying and cost me way too much time today. I sure hope an official fix is in the works.

    For anyone wanting to exactly restore the old behavior where the BundleVersion is included in the ipa file name, I modified the csproj workaround as follows:

    <PropertyGroup> <CreateIpaDependsOn> $(CreateIpaDependsOn); CopyIpa </CreateIpaDependsOn> </PropertyGroup> <Target Name="CopyIpa" Condition="'$(OutputType)' == 'Exe' And '$(ComputedPlatform)' == 'iPhone' And '$(BuildIpa)' == 'true'"> <Copy SourceFiles="$(IpaPackagePath)" DestinationFiles="$(OutputPath)$(_AppBundleName)-$(_BundleVersion).ipa" /> </Target>

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai
    edited June 2016

    For cross-referencing, I have now added this as a known issue / breaking change in the Xamarin.iOS release notes for Cycle 7. Along the way I created a new "product design question" bug report to discuss the trade-offs of this change with the engineering team. I have left that bug as public for now to provide visibility on the discussion. But to help keep the bug moving forward smoothly, I would recommend that users not comment directly on the bug report unless they have some specific constructive input to share. Thanks!

    Of course, feel free to continue to discuss workarounds for the issue in this forum thread as needed.

  • KentCHKentCH USUniversity

    There's also the wider question of how in the hell this kind of breaking change makes it all the way through QA and into stable. smh.

  • GuillaumeGirardGuillaumeGirard CAMember ✭✭

    How to get the $(IpaPackagePath) variable value after running an MSBuild activity in a TFS build process template?

    It is possible to pass-in values to variables already defined on the MSBuild activity (or with the CommandLineArguments property), but I never herd about the possibility to get back values from it...

    The only solutions I currently see is to:

    • Customize project and build process to output the variable value to a file on disk then reload it from the build process template.
    • Set MSBuild logging to verbose then parse output for the variable.

    Not so much fun in every case :)

  • rschmidtrschmidt USMember ✭✭
    edited June 2016

    Just wanted to chime in that this was a time-waster for me, too. Ended up just using find -name to get the path to the file. Variable directory or file names are always a pain for build scripts.

  • What if I want my ipa to show both the public version number and private version number. I have 1.0 for my CFBundleShortVersionString and 34 for my CFBundleVersion. So I want my ipa to be:


    That is what I was used to before this change.

  • Nevermind, I can still achieve that by specifying the IpaPackageName on the command line to control the name that gets put in the weird directory. And then use the new target in my csproj to just copy the filename (with the name I told it to be) to the BuildOutput directory.

  • tohweitohwei USMember ✭✭
    edited September 2016

    I've just done Xamarin update to my build machine through the stable channel (Xamarin.iOS ver That changes also screwed up my script from not able to find the IPA file, and so on.

    I fixed it by simply commented this line
    <!--<IpaPackageDir Condition="'$(IpaPackageDir)' == ''">$(DeviceSpecificOutputPath)$(_AppBundleName) $([System.DateTime]::Now.ToString('yyyy-MM-dd HH-mm-ss')) </IpaPackageDir>–>

    And add this:
    <IpaPackageDir Condition="'$(IpaPackageDir)' == ''">$(DeviceSpecificOutputPath)</IpaPackageDir>

    Depends on what you want it to be. For my case, I removed the AppBundleName as well as the DateTime.

    File Location:

  • BrendanZagaeskiBrendanZagaeski USForum Administrator, Xamarin Team Xamurai

    Note that you can also customize the IpaPackageDir MSBuild property on a project-by-project basis (thank to the Condition="'$(IpaPackageDir)' == '' attribute in the .targets file). One potential advantage of setting the property in the individual project .csproj is that then it won't be necessary to re-patch the .targets file after updating or reinstalling Xamarin.

    Additional details in the release notes:

  • ddotmunchddotmunch DEMember ✭✭

    Oh glad to see I'm not the only one touched by this breaking change. Just imagine the number of hours burned by it. Guess there's way more people already using a mobile DevOps approach than Xamarin imagined - all out of VSTS and with custom scripts.

  • +1 for this change breaking our build pipeline. I'd just like to add that none of the of the official solutions are really suitable. Changing the csproj, along with being a big resource drain to update our 50 or so projects, now requires us to educate every dev here to modify the csproj for all new solutions. Changing the msbuild files requires re-implementing this change on every upgrade of Xamarin.

    Pretty annoyed that this was changed as the out of the box default behaviour. Seemed to be working fine previously.

  • This broke our builds as well, but the time investment in fixing it was only an hour (care of this forum thread). Thanks to everybody who dealt with this before me.

  • BlairLeducBlairLeduc CAUniversity ✭✭
    edited January 2017

    I would like to know who thought putting spaces in a file path was a good idea? And why could have the default not been the same behaviour as before?

    Thank you to those who ran into this before I did.

  • KyleRobitailleKyleRobitaille USUniversity ✭✭

    Thank you Renaud. After upgrading our build machine we once again started having issues. Glad that the original workaround has been fixed, just wish it was made clearer that it was... Appreciate you updating the thread with the new information.

  • AndreiLImaAndreiLIma USMember ✭✭

    @RenaudLaloire , Thanks ... It was exact is happening with my build. for me, it solved.

  • HNAHNA USMember

    According to the accepted answer, simply removing the copy (CopyIpa) routine will fix that particular issue, since the ipa is now moved to the correct location. But looking through the logs, I am seeing a bunch of items with '//' in file path. Not sure what else is going on that's not right. For us, our provisioning profiles are not working anymore. Builds pass, can't install.

    Anyone having any weird issues with Mono 5.0 on Mac OSX build server?

Sign In or Register to comment.