After googling, finding more and more info and some deep search, I found that the past fail I experienced with the Mac Apps notarization was not because of the notarization itself, but because some progress I did after the notarization. Below I listed some stuff that you need to pay attention in regards to notarize Mac Apps, especially if you’re using Adobe Air like I did. Btw, I’m not really a programmer, so sorry if some of the text below sounds silly to some of you. I’m using Mac 10.13.6 with xCode 10.1 by the way, since my Mac is very old (2012) and I can’t install any newer OS.

1. Don’t use Steam Content Prep.

My first fault was because I use Content Prep from Steam SDK as a habit to prepare the Mac version for Steam. It seems after the Content Prep “warp” the notarization will be annulled, and if we do the opposite (warp first then notarize the warped app), the notarization will be failed. Just, don’t use this tool.

2. Don’t forget ENTITLEMENT.PLIST

This is the culprit which caused me to redo all of my notarization!!!
You can proceed the notarization without using this, but Steam API requires a special setting on entitlement.plist to work (a permission for the dylib file)!! Also, if your game is using Java (as far as I know both of Adobe Air and renpy is using java to build, so I added Java related permission here just for in case). Anyway, it’s a simple xml file, yet it’s very important!!

3. Make sure the file name inside MacOS folder has no space (inside the .app bundle).

So after my first “success” notarization progress, I tested the file (it was fine) then uploaded the file to Steam, and downloaded it to test again if it works but… it’s failed. I somehow have already been suspicious with the file inside MacOS folder inside the app bundle, so I simply edit the file name and the game works again. But—the notarization was annulled. (You can check this by running xcrun stapler validate on Terminal.)

To settle this, first I tried to re-notarize the file with edited name only, but then it caused more rejected notarization, and I realize that rebuild a whole new .app file is easier and faster. Just, especially for Adobe Air user, don’t add space within the name inside <filename> section.

4. Inside Resource folder is still editable (probably?) But not the one inside MacOS folder.

I tried to delete one file and added random folder inside Resource folder and it’s fine. But when I delete/ edit the file name of the original file inside MacOS folder the notarization was annulled.
I haven’t checked the Resource folder thoroughly, so probably there’s still hidden rule in it.

5. Notarized the plugin first before the app is useless.

I noticed that the notarization fail report mostly mentioned about the plugin/ ane I use, so I tried to notarize it first before using it to build the game, but it won’t do T_T just, notarize it once for all when the .app is done.

6. What the notarization based of?

Tbh I’m not really sure of this.
I have 3 files for East Tower – Kuon, for example, and they only different in languages. The final command on notarization is only “xcrun stapler staple xxx.app”, so at first I was wondered, how could they differ which xxx.app has been notarized, if there are three Kuon.app? But, they really can. I tried to notarized English version first, then I try to staple the Japanese version without the notarizing it, but it was failed (the English version notarization won’t be applied to the Japanese version), and it was the same when I tried to staple an earlier version of the English version. Only the correct .app file which has been through the notarization can be stapled.

To put it shortly, there are still some mystery within this progress. I’m not really sure, but it should settle the notarization issue for now even if… well, it’s indeed taking time to notarize a game, especially a big one,  as we need to upload a zip file to Apple server.