Some behaviors of Apple developers that are prone to investigation

Don't step on thunder , No fault .

Preface

Recently, more and more developers have encountered the evil of Apple censorship other survey . It can be seen that Apple's investigation trigger frequency is getting higher and higher . And it's hard to find the rules . Sometimes the machine checks out app Investigation caused by abnormality , Sometimes it is a large-scale investigation in a batch of concentrated time periods .

If it is a large-scale investigation , That's hard for most developers to escape , It's not your fault , That's the apple mechanism . But there are also some developers who do not operate properly . Here are a few developer behaviors that are easy to trigger the investigation .

The number of packages is too frequent

In view of the increasingly strict audit of Apple products nowadays , Many developers are not aware of the risks of improper behavior , Still use what used to be called “ Internet thinking “, We want to win by iterating products in a short, fast and even way , This idea is out of date .

Nowadays, if not already known IP Of “ Trusted products ”, Or there is a significant bug Need to fix , The update frequency of a product should be maintained once a month , Or about three times in two months . Such an update frequency can ensure that there are enough development content iterations for each update , Ensure that the product can improve the quality step by step , It is not prone to audit risks .

Some developers have just launched a product , If the data is good enough , Just want to go to a higher level , If the data is not good enough , And I'm anxious to improve the data through changes , So as to submit a new version as soon as it passes the review , Three or four updates have been completed in one month .

In my experience , Update frequency is too frequent , The early audit may go very smoothly , But at a certain time, Apple will suddenly get stuck in the investigation , And from that time node , You will find that the review you submit later becomes more and more difficult , As if Apple intended not to let you pass the bag .

In this case, I communicate with many friends , It does exist , My understanding is that frequent packaging eventually triggered Apple's confidence in the product “ Right reduction ”, from “ White list ” product , Unfortunately, it became “ Grey list ” product .

Change the title

Change the title , It means that developers do not have convincing reasons , Make major changes to the product brand and name .

For example, the original name of your product is “ Salted fish - Be a salted fish without dreams ”, The next edition suddenly changed to “ Lazy cat - Be a lazy kitten ”. There is little correlation between the two names , There is almost no overlap . Change your name like this , If you don't have a good reason , Basically, it's easy to be judged by apple that you are maliciously rubbing traffic through keywords , Which leads to investigation .

We know , Generally, the name of a product will not be easily changed after it is approved , Some of the words in the subtitle are easy to modify , This is the normal title change in the general sense . Many developers put a product on the shelves , Found that the keywords used in the title did not rank well , Weight too low , It's easy to change names in a hurry . But doing so is easier to trigger Apple's investigation .

So , Product naming is an important thing , It's better to fix it at the beginning , Don't make random changes when you decide , Otherwise, later changes are likely to cost more and more — Yes, of course , Generally speaking, there is no great risk , It's just a little trouble for me .

Add a lot of useless code

If you develop a product that has some additional features that haven't been completed yet , But shielding does not affect the shelf , So you want to shield him for a while and then change it to prepare for the shelf , Please don't do that .

If there is a lot of business code in the project development, but it is not used in the end , It's very easy to trigger an apple survey . therefore , If the whole block of developed code finally decides that the function will not be available for the time being , Then the best way is to remove it from the project first , I'll quote it when I need it next time .

First submission after product transfer

Product transfer is something that developers sometimes cannot avoid , meanwhile , It is also difficult to avoid the risks brought by product transfer . Because the transfer of products always inevitably leads to the association between accounts , Once an account goes wrong , Another account can easily be contaminated .

Even two legal accounts , Submit updates after transferring products , It's also easy to trigger an investigation . So developers must be prepared .

Visual reconstruction

Visual reconstruction and Change the title The problem is similar , If the whole appearance of the product is different from the past , It is easier to trigger an investigation .

If a major revision is necessary , It is recommended to write clearly when updating the list and audit instructions .（ But if the product really needs a major revision , It is not easy to be investigated .）

Entrusted the publisher to release the product

This is a problem that should be paid attention to , Many publishers in China release their products with the code provided by developers , They may also be running online profits , Vest bag and other products , Once there is a problem with the publisher's account, it is blocked , Developers themselves are also vulnerable . Because the code is provided by itself , Then the code framework written by yourself may also be marked with characteristics ！

Read more

Apple developers' self check list of anti Association and new numbers

Apple Developer associated Title literacy post

Mobile developer Alliance group entry guide