The final sprint of IOS App Development: Beta and deployment

When the developers have been through the ordeal, the completion of an iOS project, the final step is the application of the beta, deployment. So, in this final shot, where do you need the attention of the developer? What are some of the ways we can better help us with the release deployment of iOS apps?

This article focuses on the final stages of iOS app development, how to debug on the real machine, send the app to other testers for beta, and how to upload the app to the App Store for application review after the test is completed, in-depth analysis of the type of Apple account, the debugging of the real machine, the packaging and the crash collection.

Types of Apple accounts

The Apple developer program is divided into four types of individuals, companies, businesses, and educational developers. The personal developer certificate fee is $ one year, and the account can only display the individual ID in the App Store seller. Also, the personal account can only have one developer, 100 Apple iOS devices Udid tested.

The company developer Fee is $ one year, and the account can be displayed in App Store sellers like studios, or a custom team name. Company account can allow multiple developers to collaborate on development, more than the individual account management settings, you can set multiple Apple ID, 4 management level permissions, 100 Apple iOS device Udid test. However, the application needs to fill in the company's code (D-U-N-S), d-u-n-s can be on the official website of the Apple Free Application.

Enterprise Developer Account Fee is $299 one year, the account development application can not be published to the app Store, only enterprise internal application, Apple iOS device Udid number is not limited. Corporate accounts are ideal for apps that don't want to go online, but need to be deployed internally, such as 1000-person iOS devices.

In particular, it is important to note that the so-called Enterprise certificate provided by other channels is actually sharing an enterprise certificate with others, and Apple detects the situation and carries out a number processing. , including apps that have already been installed with the certificate, will not continue to work.

These developer account requests require an important requirement that there is a credit card that supports Visa or MasterCard.

Real-Machine debugging

Using the real machine debugging, you must use the developer certificate, and correctly fill in the app ID, configure the provision profile, the process is as follows:

1. Install the Debug Certificate
2. Fill in the App ID
3. Fill in provision profile based on App ID and download and install to Xcode
4. Real-Machine Debug run

How do I apply for a developer certificate?

The following steps are required:
1. Request a CSR file

• Open keychain Access, request a certificate from a certification authority

• Fill in the e-mail address, common name, tick save to disk, last saved the CSR file to the specified location
  

• Finally save the CSR file to the specified location
  

2. Create a debug certificate

• Select a CSR file
  
• Click on download to download, double-click to install to keychain key string
  

3. Double-click Install

You can see the keychain has the certificate we just installed, there is a triangle on the left, click to expand can see the certificate private key, if there is no private key, the certificate is not available, the general situation is that you download the developer site on the other Mac made on the certificate, you can export from this MAC certificate installed on your computer.

Create AppID

1. Fill in AppID Name

**2. Support for push, Game center and other functions can not be created with the wildcard * AppID, so here we choose explicit App ID

3. Tick the required services, then continue**

Add a Device

1. Fill in the device name, equipment Udid

2. Register

Note: Add up to 100 devices

Create Provisioning Profile

• iOS APP development: Real Machine Debug profile (requires iOS device, only included devices can be debugged)
• APP Store: Upload to AppStore store profile
• In House: Enterprise Release profile (all devices can be installed)
• Ad hoc:ad Hoc profile (requires an iOS device, except that only the included devices can be installed outside of the AppStore, inhouse version basically no difference)

1. Select AppID

2. Select a certificate

3. Select the device (only development, adhoc need to select the device)

4. Fill in the profile Name

5. Click Download to download, double-click Install to Xcode

Xcode Packaging Configurations

The default configurations contains two configurations, debug, release, you can see the build setting a lot of configuration to distinguish between debug, release, can be configured according to different situations different options, most commonly used is based on the real machine debugging, packaging and publishing , respectively, in debug, release select the appropriate certificate, profile.

Personally, Xcode now does not have to duplicate release configuration to create a special package AppStore or adhoc or other configurations, because the feeling is not convenient how much, just omitted the choice certificate, But you still set the archive option.

Generally speaking, adhoc, Appstore\inhouse, both use the same certificate, only the profile is different, simple selection of profile, is not more convenient.

Instruction Set

Let's talk about the instruction set for iOS devices:

• ARM64:

iphone 5s, iphone 6, IPhone6 Plus;
ipad Air, ipad Air 2;
ipad Mini 2, ipad mini 3;

• Armv7s:

iphone 5, iphone 5c;
IPad 4;

• ARMV7:

iphone 3GS, iphone 4, iphone 4S;
ipad, ipad 2, ipad 3, ipad Mini;

• ARMV6:

iphone, iphone 3G;

• Architectures
  This compilation option specifies which instruction sets are supported by the project, and if the number of supported instruction sets is multiple, it compiles a binary package containing multiple instruction sets, resulting in a large package that is eventually compiled.

• Valid architectures
  This compilation specifies the set of instructions that may be supported, and the intersection of the list and the architectures list will be the set of instructions supported by Xcode to eventually generate the binary package.

As shown, the instruction set supported by architectures is architectures, ARMV7, armv7s for the instruction set supported by ARMV7, arm64, Valid arm64, and only a binary package of armv7, arm64 instruction sets is generated.

• Build Active Architecture only
  This compilation is used to set whether to compile only the arm instruction set for the device that is currently in use. Typically, this compilation option is set to Yes,release mode in debug mode to No. This option works with two conditions that must be met before it works:

Note: Many users may find their app is not installed, this time can see their app support instruction set, encountered several users of the instruction set only support arm64, such an app is not arm64 in the case of the device is not installed.

Code Signing

The Code Signing identity contains debug and release two items, where debug refers to selecting a real-Machine debug certificate, and release means selecting a publishing certificate (adhoc, Appstore/inhouse Packaging uses a publishing certificate). In Provisioning profile, regardless of the real-machine debugging, or publish the app, choose the Profile app ID to match the project's Bundleid.

Note: The release of Provisioning profile is not necessarily the profile of the signature IPA, but it will be discussed later.

Export IPA

Export IPA First you need to select the IPA version, export the App store/adhoc/Enterprise Edition IPA, then click Next. If Xcode does not sign in to the Enterprise developer account, you will be prompted to add an Enterprise developer account to Xcode when you choose to export the Enterprise Edition IPA.

Select Certificate

Here's what it says. In the project selection of the certificate, profile may not be signed, the key here, here will be added to the Xcode developer account corresponding to the certificate list, you can choose the signing certificate. If the certificate that is set by the project is consistent and the profile matches, the export is signed according to the project's configured certificate, profiles. If the certificate is inconsistent with the project configuration, the selected certificate will automatically find the matching profile to sign the Export IPA.

This shows the exported IPA with which certificate, profile signature, the arrow next to Profile does not select profile, and then displays the current profile in the Finder. So the final step of the export, as far as possible to confirm the signature of the certificate, profile is not their own designation.

Distribution of IPA documents in beta

There are 3 main ways to distribute IPA documents to testers in beta:

1. Use itunes to sync the IPA to your phone;
2. Download and distribute using the Itms-services protocol;
3. Use third-party tools for download distribution.

Please note that no matter what form of distribution is used, the limit on the number of people in the beta and the udid limits of the app always exist. If you want to add a new tester, developers still need to write udid to provision profile and regenerate the IPA file for distribution.

Distribute in beta with itunes

Distributing with itunes is tricky, and you need to test your users to connect to your itunes computer using a data cable, add an IPA file to itunes, and then sync your itunes app to your phone. Since the domestic users of itunes is not very familiar with, it is not recommended to use this method of distribution in beta.

Download and distribute using the Itms-services protocol

The biggest benefit of using itms-service distribution compared to how itunes is distributed is that the test user does not need to use the data cable, just open the safari to access the page containing the Itms-service connection and click Connect to download the IPA file.

Itms-services principle is itms-services point to a plist file, this plist file contains the address of the IPA file download, the iOS device's safari will automatically download the specified IPA file in plist installed to local.

The trouble with Itms-services is that developers need to build a server themselves, after Apple installs the IPA after iOS 7.1, the storage address of the plist file written to the IPA address must be an HTTPS address.

The structure of the ITMS is referenced below

<a href="itms-services://?action=download-manifest&url=https://xxx/test.plist">安装IOS BetaV1.0 </a>

The structure of the plist is referenced below

<?xml version= "1.0" encoding= "UTF-8"?><Plistversion="1.0" ><Dict><Key>items</Key><Array><Dict><Key>assets</Key><Array><Dict><Key>kind</Key><String>software-package</String><Key>url</Key><string><! [cdata[http://fir.im/xxxxxx]]></String></Dict><Dict><Key>kind</Key><String>display-image</String><Key>needs-shine</Key><Integer>0</Integer><Key>url</Key><string><! [cdata[http://fir.im/xxx]]></String></Dict><Dict><Key>kind</Key><String>full-size-image</String><Key>needs-shine</Key><True/><Key>url</Key><string><! [cdata[http://fir.im/xxx]]></String></Dict></Array><Key>metadata</Key><Dict><Key>bundle-identifier</Key><String>im.fir</String><Key>bundle-version</Key><string><! [cdata[1.3.0]]></String><key>kind</key> <string>software</ string> <key>title </key> < string><! [Cdata[fir plist demo]]></string>  </dict> </dict> </array></dict>< Span class= "Hljs-tag" ></PLIST>         

We can see, although the user is more convenient, but for developers need to write a lot of things, but also to build servers, on OpenSSL, etc., more trouble.

Use third-party tools for in-beta distribution

To avoid the extra effort that developers use with itms-services, you can use third-party tools such as fir.im to quickly distribute the IPA in-beta.

The final sprint of IOS App Development: Beta and deployment