With Apple’s frequent revocation and tightening of corporate distribution certificates, the gauthoring industry has also iterated on dark technology, known as supersignatures.

Super signature installation process demonstration

From the perspective of the whole installation process, the super signature eliminates the step of setting up a trusted corporate certificate, makes the experience easier and more acceptable than corporate distribution, and distribution is ridiculously expensive, which makes you wonder what’s in the new bottle.

Today we will help you to explain the process, as well as the technical difficulties of this mechanism.

Signature principle

The principle of signing is a simple one, using apple’s ad-Hoc distribution channel for developers to distribute installed devices as development devices.

Since the signature is ad-hoc, the advantages and disadvantages of Ad-hoc are also inherited:

Advantage:

  1. It can be directly distributed and run after installation without requiring users to perform trust operations on enterprise certificates
  2. Currently stable, there will be no business risk caused by certificate revocation (the risk of Subsequent Apple policy is very high)

Disadvantages:

  1. The number of iPhone devices with a single developer account is only 100, resulting in a very high distribution cost ($99 / year /100 devices)
  2. The developer account needs to write the UDID of the installation device in advance. In the case of impassable tool chain, it is relatively difficult and tedious to obtain the USER’S UDID, and it is not commercially feasible to write the UDID manually. Of course, this shortcoming has been solved at present

The overall architecture

Here’s how it works:

  1. After the device installation description file is installed, the device UDID is sent to the server.
  2. After receiving the UDID, the server registers the UDID under a developer account.
  3. Regenerate the description file for the signature and sign the IPA.
  4. Then iPA is transmitted to the Server and itMS-Services is used for users to download.

The technical details

Obtain the UDID using the configuration file

Apple allows developers to get the UDID of an IOS device (including other parameters) through an operation between an IOS device and a Web server. Here’s an overview:

  1. Create a.mobileconfig XML description file on your Web server.
  2. Mobileconfig describes the installation of a file;
  3. The data required by the server, such as the UDID, needs to be configured in the.mobileconfig description file and the URL where the server receives the data.
  4. When the user installs the description file, the device calls back the URL you set. If your URL returns a 302 redirect, Safari redirects to the address you specified.

Apple Developer Center Automation tool

The next key is how to register new developer devices and update Provisioning Profiles in seconds after the user’s UDID is obtained. And here we need an open source tool (Spaceship) :

Spaceship exposed the Apple Developer Center API and executed two orders of magnitude faster than parsing Developer Web pages, landing the Provisioning Profile in a very short time. This framework addresses the key issues of the entire mechanism and becomes the cornerstone of the entire tool chain. In fact, a platform has already completed the technical reserve of UDID acquisition and application signature distribution, except for this API.

Here is a comparison of the speed of parsing developer Web pages versus direct access to the API:

Cool!!!!!!! Very good! Applause for Spaceship again 👏👏👏👏

How do I automatically sign packets

There should be 10,000 solutions that can be implemented through command-line scripts /Python scripts/other third parties.

The Sigh framework is recommended to solve this problem.

The Sigh is simple to use and configure, a command-only tool, rich configuration options (consult the documentation yourself), and an active community.

Go directly to the demo diagram:

Otas distribute signed applications

Emmmm should also have 10,000 solutions here, so choose AppDeploy. The reason for inclusion is very simple, the frame has Logo(face society is so real…) .

The deployment process is visualized as follows (command line invocation is also supported) :

conclusion

With the strength of the open source community we managed to identify the key technical points on the whole mechanic and must say the Fastlane team did an excellent job providing a critical link in the tool chain to make ad-hoc automated distribution possible.

Apple’s control over App distribution review can be said to be very strict, which has both security concerns and monopoly interests behind it. But in any case, it is a measure that does more good than harm to the end user, and App approval protects millions of mobile phone users from malicious programs. Personally, I strongly object to this form of distribution bypassing censorship. I would also like to point out that the distribution platform bypassing APPLE’s review in this way is a serious violation of Section 3.3.3 of APPLE’s Developer Program License Agreement:

Without Apple’s prior written approval or permission In accordance with Section 3.3.25 (In-App Purchase API), Applications may not provide, unlock, or activate additional features or features through Distribution channels other than the App Store, Custom App Distribution, or TestFlight.

Open source tool chain

Obtain the third-party library of the device UDID:

Github.com/shaojiankui…

Apple Developer Center Automation Tools:

Github.com/fastlane/fa…

Automatic signature package tool:

Github.com/fastlane/fa…

OTA Distribution application tools:

Github.com/atelierdumo…

The resources

The Over – the – Air Profile Delivery Concepts (access device UDID official documents) : developer.apple.com/library/arc…

APPLE developer program license agreement: download.developer.apple.com/Documentati…

This post is sponsored by your likes/likes/comments