Many people have encountered installation failures when installing iOS internal beta applications. There are many reasons for installation failures. Below we summarize some common reasons as follows to facilitate developers to troubleshoot.

Please return to the iOS system desktop, then open Settings - General - Profile and Device Management, then click the corresponding profile to enter, and then click the button Trust. For specific solutions, please see: Running Enterprise Edition Applications

If you are the developer of the application, please check whether the signature of the application is correct. The reason for this problem is generally due to incorrect signature of the application. Generally speaking, for the Adhoc signature method, you need to focus on checking whether the current device UDID has been registered; for the in-house signature (ie, enterprise signature) method, you need to focus on checking whether the certificate has been revoked. If you are not the developer of this application, please contact the developer for resolution.

The reason for this problem is usually because the user has installed the same application from Apple's official App Store. The solution is: first delete the previously installed application from your device, and then install it from Dandelion.

This problem is usually caused by the user's network or mobile phone cache error. You can try the following two methods to solve it:

Reason 1: When the developer packages the App, export When installing the iOS App's installation package file (.ipa file), the App-Store method was selected.

When exporting iOS .ipa files, some developers choose the App-Store method. The .ipa files exported in this way are only suitable for uploading to the Apple App Store and cannot be installed through Dandelion. . If the .ipa file is exported in this way, when it is transferred to Dandelion, Dandelion will display "App-Store version". This version cannot be installed through Dandelion.

Reason two: When exporting the iOS App installation package file (.ipa file), the Ad-hoc method was selected, but the device UDID was not added.

When exporting the iOS installation package file, if you choose the Ad-hoc method (generally used for Apple personal developer accounts), then if you want a certain device to be able to install it, you must install it on this device. The UDID of the device is added to the certificate file (. mobileprovision file) used when exporting the installation package before it can be installed on this device.

After the installation package file exported using the Ad-hoc method is uploaded to Dandelion, Dandelion will be displayed as "internal beta version", and the UDID contained in the certificate of the installation package will be displayed in the application management. list. Developers can check whether the UDID of a certain device has been added to the certificate of the installation package based on the displayed UDID list.

Reason three: When exporting the installation package file (.ipa file) of the iOS App, the In-house method was selected, but the certificate has expired or been revoked.

When exporting the iOS installation package file, if the In-house method is selected (generally used for Apple enterprise developer accounts), at this time, if the installation fails, developers can check their Whether the enterprise developer certificate has expired or been revoked. Because Apple has strict management of enterprise developer certificates, if developers use it improperly, the enterprise certificate may be officially revoked by Apple. The installation package exported from the revoked enterprise certificate cannot be installed correctly.

Reason 4: The developer did not set the correct Architecture in Xcode when generating the App installation package.

The Architecture of an iOS application determines which device models the iOS application can be installed on. For example, if an application only adds the arm64 Architecture in Xcode, then after the final packaged installation package file is uploaded to Dandelion, it cannot be installed on iPad mini, iPhone5 and other devices (because these devices are Not arm64 architecture). In other words, if it needs to be installable on a certain device, the App must support the Architecture of that device.

Therefore, the correct solution is to make the App support as many Architectures as possible when generating the App installation package.

The specific operation method is: in Xcode - Build Settings - Architecture, add armv7, armv7s, arm64 so that all devices can be installed. Then, set "Build active architecture only" to NO . Architecture types supported by various iOS devices. Please click here to view .

Reason 5: The iOS system version supported by the App does not match the current device system version.

If the iOS system version supported by the App is too low or too high, the App may not be installed successfully. For example, if an App is set to only support systems above iOS 11.0, then if it is installed on a system lower than this version, it will not be installed successfully.

Therefore, the solution is also very simple. We should try to make the App support a wider range of system versions as much as possible.

The specific operation method is: in Xcode - General - Deployment Info - Deployment Target, set a version as low as possible for the App, such as iOS 6.0.

Reason 6: The App is already installed on the device, and the installed App and the App to be installed are packaged with different certificates.

In this case, the App installation will also fail. The solution is very simple. Users only need to delete the originally installed App on the device and then reinstall the new App.

Reason seven: LSRequiresIPhoneOS in the Info.plist file is not set, or NO is set.

For iOS Apps, if LSRequiresIPhoneOS in the Info.plist file is not set, or is set to NO, the installation package (.ipa package) exported by Xcode will not include the Payload folder. , but is replaced by a folder called Applications. When installing such an installation package, it will be judged as an invalid installation package by iOS, so it cannot be installed correctly.

The solution is also very simple, just set LSRequiresIPhoneOS in the Info.plist file to YES and then repackage. The specific operation is: open the Info.plist file in Xcode, and then check whether LSRequiresIPhoneOS has been set. If not, add one, and then set the type of LSRequiresIPhoneOS to Boolean and the value to YES.

After setting up, you can see that the value of Application requires iPhone environment is YES in the Info.plist file.

In addition, you can also use Dandelion’s Mac OS client to package and upload apps. Dandelion’s Mac OS client automatically handles this problem when packaging the installation package.

Cause 8: The network is interrupted or abnormal.

In this case, users can check whether the network connected to their mobile phone is stable and the speed is normal. Can you open other websites, change Wi-Fi, or switch from Wi-Fi to 3G/4G, etc., and then reinstall.

After trying this way, the problem can usually be solved.

If the problem still cannot be solved after troubleshooting according to the above methods, you can use Dandelion's Mac OS client to view the installation log.

Dandelion’s Mac OS client provides the function of viewing App installation logs in real time. Developers can easily and accurately determine the reasons for specific installation failures based on the App installation logs. For specific methods, please see : View the iOS installation log