After completing the basic automatic packaging process, common problems appeared in daily life. For example, we needed to type IPA with different network environment and certificates each time. Developers could only add 100 devices, but the company used the same account for several projects, and each project team was independent. Coupled with the departure of employees who joined the equipment during the period, very few devices were actually able to participate in the test.

Therefore, our company generally uses the enterprise certificate for testing, so that different projects can share the same certificate, which can not only manage the aspects, but also get rid of the trouble of device number limitation. On the other hand, when testing in-app purchase and other functions, we still need to use the package of adhoc certificate for testing.

Our original packaging strategy was to type corresponding packages according to the parameters entered when executing the script, so that for parallel tests of different tests, several packages would be typed at a time. Taking our company as the packaging server Mac Mini, the time for archive + export of a package was about 20min. For the random combination of packages with different certificates and environments, it will take about 1h20min to type 4 different packages at a time. Moreover, if other colleagues modify new bugs during the packaging process, it cannot be packaged.

So we wondered if we could re-sign it, compile it once, re-sign it, and print a different package.

This article focuses on some of my explorations along the way, aimed at improving the packaging efficiency of different certificate environments.

Re-signing ipA

At first, I looked up relevant information online and followed relevant tutorials, but ultimately failed. If there are students who have successfully re-signed ipA directly, please kindly comment.

I wonder if there was some internal validation that made it impossible to re-sign the IPA. Therefore, I wonder if it is possible to modify the information and re-sign it earlier than the IPA step, just as a try, even if it fails, I can learn new knowledge through exploration. Finally, we successfully reduced the time of 1H20min for 4 packets to less than 30min.

Instead of exporting ipA, modify the. Xcarchive file

The.xcarchive file is a manual archive of the project, or the following script is executed:

xcodebuild archive -workspace ${work_space} -scheme ${scheme} -configuration ${configurationDistribution} -archivePath ${archivePath}
Copy the code

If you’re not familiar with the packaging command, check out my last post on iOS automation packaging for some of my share

Xcarchive = info.plist = info.plist = info.plist = info.plist = info.plist = info.plist = info.plist = info.plist

We can see that there are some properties that are required for the App.

1. Modify info.plist in.xcarchive

Here, if the project BundleIdentifier needs to be changed, modify the CFBundleIdentifier value and change SigningIdentity to the certificate corresponding to the BundleIdentifier. As for the value of SigningIdentity here, you can find the corresponding certificate in the key string and check its information, which is the Common Name in the following figure (English system).

2. Modify App Extension information

This step is for subordinate targets such as Notification Extension in the project target. If there is no App Extension, you can skip this step and view the information related to modifying the main target in the next step.

Open it by folder YourAppName.xcarchive/Products/Applications/YourAppName.app/PlugIns/YourAppNameNotificationServiceExtension.appex , This is not a standard folder and the open command doesn’t seem to work. Look at the directory structure:

2.1 Modifying info.plist Information

App, the Extension of the Bundle Identifier is App Bundle Identifier and its corresponding suffix, such as notificationserviceextension.

Change the Bundle Identifier to the corresponding value. This value refers to the Bundle Identifier of the info.plist directory in the.xcarchive directory, such as com.test.www. Here is the com. Test. www.notificationserviceextension.

2.2 Replacing Provisioning Profiles

Copy the Provisioning Profile to the directory to replace the Provisioning Profile with the same file name embedded. Mobileprovision.

2.3 modify the archived – expanded – entitlements. Xcent

We open archived-expanded/entitlements. Xcent via Xcode, which is essentially a PList file in the format teamId. Bundle Identifier.

Change the two shaded values in the diagram to match the info.plist values of.xcarchive.

2.4 heavy signature

Re-sign the App Extension with the corresponding certificate, where YourCetificateName is still the title of the certificate in the info.plist of.xcarchive.

codesign -f -s "YourCetificateName" YourAppNameNotificationServiceExtension.appex
Copy the code

3. Modify the information about the primary target

With the previous step to modify App Extension step is basically the same, but less step, do not modify Archived -expanded-entitlements. Xcent.

3.1 Modifying Info.plist Information

Go to the.app directory and modify the info.plist Bundle Identifier to match the.xcarchive file.

You can also change other values, such as network environment, test environment, or production environment, but this is just a primer. In fact, there are convenient ways to modify the network environment, such as switching by reading the text on the sticky board, or writing an auxiliary program to open our App and notify the switching environment.

3.2 Replacing Provisioning Profiles

Copy the Provisioning Profile to the directory to replace the Provisioning Profile with the same file name embedded. Mobileprovision.

3.3 heavy signature

Re-sign the.app file with the corresponding certificate, where YourCetificateName is still the title of the certificate in the.xcarchive info.plist.

codesign -f -s "YourCetificateName" YourAppName.app
Copy the code

4. The export package

xcodebuild -exportArchive -archivePath YourAppName.xcarchive -exportPath $(pwd) -exportOptionsPlist YourExportOptionsPlistPath
Copy the code

After success, command console output:

If you’re not familiar with exportOptionsPlist, check out my previous post on iOS automation packaging.

Pay attention to the point

Each step of the above modification, whether it’s Bundler Identifer, Provisioning Profile, or re-signing certificate, needs to be matched. If one step is wrong, the IPA package will not be able to guide out.

My statement may not be so clear, I believe that you operate once, step by step, modify the need to modify the value, in fact, basically at a glance. If you have similar requirements, you are advised to perform operations first and then write scripts to implement automation.

conclusion

After the above operations, the package is compiled only once, and then the related information is modified to export the package corresponding to different certificates. Only several more export operations are performed, greatly saving the packaging time. If you have any ideas or better methods, welcome to discuss together.