Apple's developer accounts are mainly divided into four types: Individual, Company, Enterprise , and University, with annual fees of $99, $99, $299, and free respectively). Generally, developers apply for it as individuals or companies. Applications developed with corporate developer accounts cannot be published to the App Store and can only be used within the company. The application process generally takes about a week. Companies and enterprises need Dun & Bradstreet codes. If you have not applied for a Dun & Bradstreet code, please apply for one first. This process takes one to two weeks.
Create certificates, AppID, and generate description files
Generate a certificate request file through the Mac keychain tool and download the certificate. It should be noted that the downloaded certificate can only be used on the computer that requested the certificate. If you want to give it to other developers, you need to export the imported certificate to Personal Information Exchange (.p12) format for others to use. The creation of AppID requires the project's Bundle ID, after which the description file can be created.
Configure App related information in iTunes Connect in the Developer Center
Create a new APP project in the APP option in iTunes Connect in the Developer Center and configure the corresponding information (screenshots of each version are required, run the simulator, adjust it to the maximum (command+1), use command+s to take screenshots, and a 1024*1024 icon without rounded corners)
Use Xcode to package and upload the App
Correctly configure the certificate and description file applied in step 2 into Xcode, and set some properties of Xcode:
1. Select iOS Device in Xcode (you cannot select the simulator here); 2. If the app does not support landscape mode, please uncheck Landscape Left and Landscape Right in the General option; 3. Check the version number and build number; 4. Remove breakpoints, global breakpoints, zombie mode, etc.; 5. Set to Release mode. After that, you can select Xcode-> Product- >Archive to package the project. After packaging is completed, select Upload to App Store to upload. If you don’t want to use Xcode to upload, you can also choose Export to export the ip a file. Please note that when exporting, you must select Save for iOS App Store Deployment. Then upload the ipa file through the Application Loader tool.
Submit for review
After completing the above steps, return to iTunes Connect to view your App information and select the App version you just uploaded in the build version. It may show that it is being processed. You may need to wait a few minutes before checking again. After selecting the version, click Submit for review, and the App will then become a waiting for review state.
Follow-up
The next step is to wait for Apple's reviewers to review the app. If everything goes well, this process will take one to two working days to complete the review. Of course, the premise is that your app complies with Apple's review terms. If the review fails, please modify the application in a timely manner based on the feedback information and submit it again until it meets the requirements. After the review is passed, if you have previously selected automatic release, you can view and download the application on the AppStore.
2. Common pitfalls and solutions in the iOS listing review process
Problem: Lack of necessary review of user-generated content ( UGC )
To prevent the illegal misuse of user-generated content, which could provide users with false information or steal their intellectual property, social apps and apps that contain user-generated content must include the following features: 1. Filter out inappropriate content 2. Provide a reporting mechanism 3. Backend services can provide protection against harassment of users 4. Provide official contact information so that users can quickly contact the developer
Solution: Weixiu Live App provides users with real-time barrage function, so it involves UGC. Their way of dealing with it is to add keyword filtering, and also conduct manual review through room management to deal with users who violate the rules.
Problem: App using IDFA was rejected
IDFA is primarily used to differentiate devices in advertising. AppStore prohibits the listing of apps that collect IDFA without using advertisements, so if the app itself does not have advertisements, when using a third-party SDK, be sure to check whether it contains an IDFA advertising module.
Solution: If the app itself has integrated advertising, you only need to check the correct advertising identifier option when submitting it for review. If the app itself does not integrate advertising but contains IDFA. This situation is usually caused by the integrated third-party SDK containing IDFA. First, find out if there is an SDK version that does not include IDFA. If not, you can refer to the solution of ShareSDK. Add advertisements to the app during the review period through background configuration, and remove the advertisements after the review is completed.
Problem: The application does not support IPv6 network
Starting June 1, 2016, Apple reviewers will review your app on an IPv6 network, so if your app cannot use the IPv6 protocol, it may be rejected.
Solution: The Zhuoyi Duobao and Ledongting Apps were rejected during the launch process due to IPv6 support issues. Their solution was: Coordinate with backend staff to add support for IPv6 networks. Update the relevant third-party SDK on the App side. For example, if the version of ASI or AFN is too low, the problem can be solved by using the latest AFN. Of course, after doing all this, it is best to build an IPv6 network on the Mac for testers to complete the test and then re-release it.
Problem: Third-party login, payment, sharing apps are not installed, and the download is rejected
There are actually two reasons for this question to be rejected. The first is that there is no prompt when the app is not installed. In this case, it is equivalent to the app having an invalid button so it will be rejected. The second is that there is a prompt to download the corresponding third-party App, which is also not allowed by Apple.
Solution: The latest third-party login and other related SDKs that are currently known ( WeChat , QQ, Weibo) have already handled this situation. If they are not installed, they will call the web to log in. Therefore, if you find that you can successfully log in on the web during testing, you do not need to deal with it. In the past, when there was no such processing mechanism, developers needed to call the corresponding interface to first determine whether the corresponding third-party APP was installed. If not, the button needed to be hidden so that it could easily pass the review.
Issue: Virtual product rejected for not using in-app payment (IAP)
According to Apple’s latest official review terms: If you want to unlock some features in your app by paying (for example, subscription content, game currency, game levels, access to premium content, unlocking the full version), you must use in-app payment (IAP). If in this case, the app uses other third-party payment methods, the app will be rejected for listing.
Solution: During the review, hide the corresponding virtual products and release them after they are approved. This method is risky and may result in a warning letter or even a ban. If the number of users is small, it doesn’t matter. Just get the App on the shelves first! During the review, the IAP payment method will be used. After the review is completed, it will be dynamically switched to third-party payment such as Alipay and WeChat through server configuration. This method is similar to Option 1 and also has risks. Learn from 58.com and let users go to the website to purchase products, and then use the functions on the mobile terminal with the account after purchasing the products. Just use IAP honestly.
Problem: Background location access denied
The original text of Apple’s review terms for location services is as follows: Applications that use location services must provide functionality directly related to location services. The use of location-based APIs is not permitted for providing emergency services, or for enabling automatic control of vehicles, aircraft, and other devices (with the exception of small devices such as small drones and toys), remote control of car alarm systems, etc. Before collecting, transmitting, and using a user's location data, make sure you have obtained the user's consent. If your app uses background location services, be sure to explain its purpose in the app. And if you use background positioning, you need to provide a clear reminder to tell users that doing so will speed up battery consumption. The following are the reasons why applications are generally rejected: 1. The app does not require location functionality at all. 2. The application requires positioning function, but only needs to obtain the location of a small number of users for a short time. For example, Meituan and news applications need to obtain the city where the current user is located, but use the background positioning mode. 3. The application does need to use background positioning, such as taxi-hailing software, but there is no interface in the application to display these positioning data.
Solution: 4. If your app does not need the location function at all, but you still add location in the UIBackgroundModes key in the info.plist, then you can remove the UIBackgroundModes key in the plist file. This situation is rare and novices will make this mistake. 5. If you just want to get the location without background positioning, just remove UIBackgroundModes in the info.plist file. 6. This situation is more complicated. The recommended approach is to display the background positioning data in a table or track, and then tell Apple which function requires background positioning when submitting for review, and specifically on which interface to display the background positioning data. Finally, you need to add "Continued use of GPS running in the background can dramatically decrease battery life" to the App description. You can refer to the description of Didi Chuxing, otherwise it will be rejected.
After iOS 10, if you need to call the camera, Bluetooth and other devices, you need to make corresponding configurations in the info.plist file, otherwise the application will crash directly. Before iOS 10, it is inaccessible. In addition, if the permissions configured in the info.plist are not used in the application, it will also be rejected.
Solution: Be sure to pay attention to which permissions your app uses when in use. Do not add useless permissions, and do not lack necessary permissions.
Problem: App update rejected
There should not be any prompts to update the app within the app, and the app can only be updated through the AppStore. Because Apple has its own set of policies for app updates, apps themselves are prohibited from providing an update method as long as it appears within the app.
Solution: If it is not necessary, try to remove the parts of the app that involve app updates. If you really need to use app updates, the recommended method is to obtain the version number of the app on the AppStore when the app is started, and compare it with your own version number. When your own version number is smaller than the version number on the AppStore, prompt to update, otherwise no update-related content will be displayed.
Problem: Treasure Hunt (lottery) apps were rejected
According to AppStore Review Guidelines 20.4, the purchase of lottery tickets or lottery participation rights, whether through third-party payment channels or balance deductions, cannot be carried out within the app.
Solution: The final solution to the problems encountered during the listing of Zhuoyi Duobao App is that during the review process, all payment behaviors are redirected to the Safari browser , and after the review is completed, payment can be made using app platforms such as Alipay.
Problem: Privacy policy rejected
Apps may not transmit user data without obtaining prior permission from the user or informing the user how and where the information will be used.
Solution: Don’t miss the "Website Service Agreement" and "Privacy Terms", and allow users to check them when registering. Also specify what the required user information is used for.
Problem: No test account was provided and the application was rejected
If the app has some features that require an account or other resources (for example, a QR code) to use, but these are not provided to Apple, it may be rejected for listing. The reason is that Apple reviewers are unable to test these features.
Solution: Provide a valid test account and login information, and provide the necessary hardware and resources for the test function (for example, a QR code for testing)
Problem: Access denied without HTTPS
App Transport Security (ATS) is a security feature proposed by Apple to enhance the security of iOS App network communications. It is applicable to iOS App and App Extension. After enabling ATS, it forces the app to connect to network services through HTTPS (instead of HTTP). It was proposed at WWDC 2016: the end of 2016 or the beginning of 2017, but the specific time has not been determined. The App Store listing review has strengthened the review of ATS configuration, that is, it forces the application to connect to the network service through HTTPS, rather than simply setting NSAllowsArbitraryLoads to YES, otherwise the review will not pass.
Solution: ATS was proposed to ensure the security of iOS APP network communications at the system level. The reason why Apple strengthened the review of ATS configuration is to prevent developers from simply shutting down ATS completely when encountering ATS-related scenarios (developers will do so as long as there are no mandatory measures). On this basis, App review will also follow the principle: App Review will require "reasonable justification" for most ATS exceptions. The following is a demo of a statement that Apple officially gave that can pass the review: 1. You must use services provided by a third party, but they do not support HTTPS; 2. You must connect to the device via a domain name, but the device cannot support secure connections; 3. Web content from different sources must be displayed, but it cannot be implemented based on classes supported by NSAllowsArbitraryLoadsInWebContent (UIWebView/WKWebView); 4. Load encrypted media resources and do not involve personal information.
Since Apple has not officially provided a complete description of ATS review, and there is no clear objective definition of what constitutes an appropriate and reasonable statement during ATS review, the above demo description can only be used as a reference.
The author of this article @石斧科技ASO is compiled and published by (Qinggua Media). Please indicate the author information and source when reprinting!