Search Unity

  1. Calling all beginners! Join the FPS Beginners Mods Challenge until December 13.
    Dismiss Notice
  2. It's Cyber Week at the Asset Store!
    Dismiss Notice

Impact Of New Notarization Process For Osx Apps?

Discussion in 'OSX' started by ccklokwerks, Apr 11, 2019.

  1. ccklokwerks

    ccklokwerks

    Joined:
    Oct 21, 2014
    Posts:
    62
  2. Polygoat

    Polygoat

    Joined:
    Aug 29, 2015
    Posts:
    7
    I'm also looking into notarizing one of our MacOS apps. Unfortunately there's isn't much information about notarizing a Unity-based app.

    Anyone who already managed to do this successfully?
     
  3. amateurd

    amateurd

    Joined:
    Nov 1, 2016
    Posts:
    23
    I got as far as uploading it successfully. I can't see a way past the errors "The binary uses an SDK older than the 10.9 SDK" and "The executable does not have the hardened runtime enabled"

    I think until Unity fix it we're stuck.
     
    AndyKorth likes this.
  4. dev_arussell

    dev_arussell

    Joined:
    Sep 2, 2018
    Posts:
    3
    I can't speak specifically to Unity 2019, but for a Unity 2018.4 Mac OS build to pass Apple's notarization process I had to open the .NIB files created by Unity in Xcode and change the "Opens In" and "Builds for" to the desired Xcode version and target macOS release. After doing this the build could pass the Apple Notarization process. Please note we aren't distributing in the Mac App Store so there might be other steps required that we didn't need to perform, we just wanted the scary warnings to go away when customers launched our installer.

    There are many other pitfalls along the path to passing Apple's notarization process, but this one is likely to affect anyone trying to distribute Mac OS standalone apps.
    Here are a couple tips to help others:
    - All platform native precompiled libraries need to live in the Contents/Frameworks/ subfolder within your app bundle.
    - Even though Apple's documentation says it is possible and recommended to notarize a .dmg file containing an installer, this actually fails and does not work. Skip notarizing the DMG.
    Edit: more info on this:
    https://kilianvalkhof.com/2019/electron/notarizing-your-electron-application/

    I'd love to hear others experiences with this and any advice they would offer.
    Best of luck!
     
    Last edited: Jul 26, 2019
  5. amateurd

    amateurd

    Joined:
    Nov 1, 2016
    Posts:
    23
    Many thanks, I believe its fixed now in 2019.2 so is okay.
     
  6. x4000

    x4000

    Joined:
    Mar 17, 2010
    Posts:
    307
    Is there an update to what the process is on the new unity builds? Steam is starting to require that all OSX games be notarized soon, as well.
     
  7. adamgryu

    adamgryu

    Joined:
    Mar 1, 2014
    Posts:
    71
    Yes, I was wondering how this will affect MacOS users for my game. Will you need to own a Mac in order to build games for it now?
     
    x4000 likes this.
  8. x4000

    x4000

    Joined:
    Mar 17, 2010
    Posts:
    307
    Unity's documentation has info about prepping your build for the mac app store, but that is NOT the same thing. That's more involved and involves you paying apple money. It's probably worth it, but it's a small enough market I haven't bothered. My games were in the very first wave of OSX games on Steam, and I've always been pleased with that (it's thanks to Unity), but I'd hate to see that all being undermined now 8 years later.
     
  9. AndyKorth

    AndyKorth

    Joined:
    Oct 19, 2009
    Posts:
    25
    I know you need an Apple Developer ID to notarize, but do you also need to pay to be a registered developer to notarize also? It does seem like you can notarize with the command line, so it should be pretty scriptable... although you'll still need a Mac with xcode installed.
     
  10. HiddenJason

    HiddenJason

    Joined:
    Apr 18, 2016
    Posts:
    16
    I found it pretty straightforward with 2018.4.4 through 2018.4.9. I have a post-process ant script that will codesign the app bundle generated from Unity and then submits it for notarization.

    Here's a general-purpose version of my ant script (under MIT License), in case anyone might find it useful. Due to keychain restrictions, it has to be run locally on the Mac - codesign can't properly access the keychain when running from a remote session:

    Code (XML):
    1. <?xml version="1.0" encoding="UTF-8"?>
    2. <!--
    3. Copyright © 2019 Hidden Achievement LLC
    4.  
    5. Permission is hereby granted, free of charge, to any person obtaining a copy
    6. of this software and associated documentation files (the "Software"), to deal
    7. in the Software without restriction, including without limitation the rights
    8. to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
    9. copies of the Software, and to permit persons to whom the Software is
    10. furnished to do so, subject to the following conditions:
    11.  
    12. The above copyright notice and this permission notice shall be included in all
    13. copies or substantial portions of the Software.
    14.  
    15. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
    16. IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
    17. FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
    18. AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
    19. LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
    20. OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
    21. SOFTWARE.
    22. -->
    23. <project name="Unity-Mac-Notarize" xmlns:if="ant:if" xmlns:unless="ant:unless" default="notarize" basedir=".">
    24.     <taskdef resource="net/sf/antcontrib/antlib.xml" />
    25.     <description>
    26.         Signs and notarizes a Unity (or other) app on macOS
    27.     </description>
    28.  
    29.     <!--
    30.         BASIC SETUP
    31.  
    32.         This script assumes that you place some support files in the defined 'support' folder
    33.          By default, the support folder is "etc" under the directory where this script is placed.
    34.          That folder should contain:
    35.          Info.plist
    36.          <app.bundle_id>.entitlements
    37.          apple/<language>.lproj
    38.  
    39.         in the Info.plist, some variables will be replaced:
    40.         ${version} replaced with the value of build.number
    41.         ${shortVersion} replaced with the value of build.version
    42.         ${iconname} replaced with the app executable base name
    43.  
    44.         When calling the script, the following properties are required, either on the command-line or in local.properties:
    45.           app.executable_name - the base name of the executable (e.g. for MyGame.app, this would be MyGame)
    46.           app.bundle_id - the bundle ID of the app (e.g. com.MyCompany.MyGame)
    47.           codesign.key  - the SHA-1 signature of the codesigning key
    48.           notarize.account - the account used for notarization (generally the email address for the Apple ID)
    49.           notarize.keychain_key - the keychain key containing the app-specific password for notarization
    50.           build.version - the version string for the build (usually a 3-part version like 1.2.3)
    51.           build.number - the build number of the build (an integer)
    52.  
    53.         Optionally, the following options can also be provided. Defaults are in square-brackets.
    54.           support_folder [./etc] - folder containing support files, relative to location with this script
    55.           output.unsigned [./Builds/Unsigned] - folder containing the unsigned Unity output .app
    56.           output.signed [./Builds/Signed] - folder that will contain the signed output
    57.     -->
    58.  
    59.  
    60.     <!-- load in local machine settings -->
    61.     <property file="./local.properties" />
    62.  
    63.     <!-- Folder containing support files -->
    64.     <property name="support_folder" location="./etc"/>
    65.  
    66.     <!-- Properties to pass in to the ant task - or modify the script and define here -->
    67.     <!-- base name of the app bundle (e.g. for MyGame.app, this would be MyGame) -->
    68.     <!-- <property name="app.executable_name" value="MyGame"/> -->
    69.     <fail unless="app.executable_name"/>
    70.     <!-- app bundle id -->
    71.     <!-- <property name="app.bundle_id" value="com.mycompany.mygame"/> -->
    72.     <fail unless="app.bundle_id"/>
    73.  
    74.     <property name="output_root" location="./Builds/" />
    75.  
    76.     <!-- Folder containing the unsigned build from Unity -->
    77.     <property name="output.unsigned" location="${output_root}/Unsigned"/>
    78.     <property name="output.signed" location="${output_root}/Signed"/>
    79.  
    80.     <property name="signed_bundle" location="${output.signed}/${app.executable_name}.app"/>
    81.  
    82.     <!-- These must be set, preferably in local.properties -->
    83.     <fail unless="codesign.key"/>
    84.     <fail unless="notarize.account"/>
    85.     <fail unless="notarize.keychain_key"/>
    86.  
    87.     <!-- optional arguments -->
    88.     <!-- codesign.keychain -->
    89.     <!-- <property name="codesign.keychain" value="login"/> -->
    90.  
    91.     <!-- required -->
    92.     <fail unless="build.version" message="Missing required build.version"/>
    93.     <fail unless="build.number" message="Missing required build.number"/>
    94.  
    95.     <target name="codesign">
    96.         <echo message="--- Signing macOS Build in ${output.unsigned} for notarization to ${output.signed} ---"/>
    97.         <mkdir dir="${output.signed}"/>
    98.         <!-- Copy the unsigned bundle to the signed target location -->
    99.         <copy todir="${signed_bundle}" overwrite="true">
    100.             <fileset dir="${output.unsigned}/${app.executable_name}.app">
    101.                 <exclude name="**/*.meta"/>
    102.             </fileset>
    103.         </copy>
    104.  
    105.        <!-- Replace and update Info.plist - set the version numbers and icon -->
    106.         <local name="version"/>
    107.         <property name="version" value="build.number"/>
    108.         <local name="shortVersion"/>
    109.         <property name="shortVersion" value="build.version"/>
    110.         <local name="iconname"/>
    111.         <property name="iconname" value="${app.executable_name}"/>
    112.  
    113.         <copy file="${support_folder}/Info.plist" tofile="${signed_bundle}/Contents/Info.plist" overwrite="true">
    114.             <filterchain>
    115.                 <expandproperties />
    116.             </filterchain>
    117.         </copy>
    118.         <copy todir="${signed_bundle}/Contents/Resources" overwrite="true">
    119.             <fileset dir="${support_folder}/apple">
    120.                 <include name="*.lproj/**"/>
    121.             </fileset>
    122.         </copy>
    123.  
    124.         <!-- sign internal bundles -->
    125.         <foreach target="codesign_helper" param="signFile">
    126.             <path>
    127.                 <fileset dir="${signed_bundle}/Contents/Plugins" casesensitive="yes">
    128.                     <type type="dir"/>
    129.                     <include name="**/*.bundle"/>
    130.                 </fileset>
    131.             </path>
    132.         </foreach>
    133.         <!-- sign dylib files -->
    134.         <foreach target="codesign_helper" param="signFile">
    135.             <path>
    136.                 <fileset dir="${signed_bundle}/Contents/Frameworks" casesensitive="yes">
    137.                     <include name="**/*.dylib"/>
    138.                 </fileset>
    139.             </path>
    140.         </foreach>
    141.  
    142.         <!-- codesign the app -->
    143.         <exec executable="/usr/bin/codesign" failonerror="true">
    144.             <arg value="--force"/>
    145.             <arg value="--deep"/>
    146.             <arg value="--verify"/>
    147.             <arg value="--verbose"/>
    148.             <arg value="--timestamp"/>
    149.             <arg value="--options"/>
    150.             <arg value="runtime"/>
    151.             <arg value="--keychain" if:set="codesign.keychain"/>
    152.             <arg value="${codesign.keychain}" if:set="codesign.keychain"/>
    153.             <arg value="-s"/>
    154.             <arg value="${codesign.key}"/>
    155.             <arg value="--entitlements"/>
    156.           <arg value="${support_folder}/${app.bundle_id}.entitlements"/>
    157.             <arg value="${signed_bundle}"/>
    158.         </exec>
    159.  
    160.         <exec executable="/usr/bin/codesign" failonerror="true">
    161.             <arg value="--verify"/>
    162.             <arg value="--verbose=4"/>
    163.             <arg value="--keychain" if:set="codesign.keychain"/>
    164.             <arg value="${codesign.keychain}" if:set="codesign.keychain"/>
    165.             <arg value="${signed_bundle}"/>
    166.         </exec>
    167.     </target>
    168.  
    169.     <target name="notarize_macos" unless:set="skip-notarize" depends="sign_macos">
    170.         <!-- zip for notarization -->
    171.         <zip destfile="${output_dir}/${app.executable_name}.app.zip">
    172.             <fileset dir="${output.signed}">
    173.                 <include name="${app.executable_name}.app/**"/>
    174.             </fileset>
    175.         </zip>
    176.  
    177.         <exec executable="/usr/bin/xcrun" failonerror="true">
    178.             <arg value="altool"/>
    179.             <arg value="--notarize-app"/>
    180.             <arg value="--type"/>
    181.             <arg value="osx"/>
    182.             <arg value="--primary-bundle-id"/>
    183.             <arg value="${app.bundle_id}.zip"/>
    184.             <arg value="--username"/>
    185.             <arg value="${notarize.account}"/>
    186.             <arg value="--password"/>
    187.             <arg value="@keychain:${notarize.keychain_key}"/>
    188.             <arg value="--file"/>
    189.             <arg value="${output_dir}/macOS/${app.executable_name}.app.zip"/>
    190.         </exec>
    191.     </target>
    192.  
    193.     <target name="codesign_helper">
    194.         <echo message="Code sign ${signFile}"/>
    195.         <exec executable="/usr/bin/codesign" failonerror="true">
    196.             <arg value="--force"/>
    197.             <arg value="--deep"/>
    198.             <arg value="--verify"/>
    199.             <arg value="--verbose"/>
    200.             <arg value="--keychain" if:set="codesign.keychain"/>
    201.             <arg value="${codesign.keychain}" if:set="codesign.keychain"/>
    202.             <arg value="-s"/>
    203.             <arg value="${codesign.key}"/>
    204.             <arg value="${signFile}"/>
    205.         </exec>
    206.     </target>
    207.  
    208.     <target name="notarize" depends="codesign,_notarize">
    209.     </target>
    210.  
    211.     <!-- Staple the received notarization to the app -->
    212.     <!-- run this after notarization is completed -->
    213.     <target name="staple">
    214.         <echo message="--- Stapling notarization to Mac Build at ${signed_bundle} ---"/>
    215.         <exec executable="/usr/bin/xcrun" failonerror="true">
    216.             <arg value="stapler"/>
    217.             <arg value="staple"/>
    218.           <arg value="${signed_bundle}"/>
    219.         </exec>
    220.     </target>
    221. </project>
    222.  
     
    x4000 and AndyKorth like this.
  11. Mauri

    Mauri

    Joined:
    Dec 9, 2010
    Posts:
    1,597
  12. x4000

    x4000

    Joined:
    Mar 17, 2010
    Posts:
    307
    I do frequent patches (sometimes a few a week), and I can't imagine having to cite up my Mac every time I run a build. That would add so much extra time to the whole process. I've got everything scripted out on windows to build for all three OSes, and I only run my Mac when I need to test something specific on it.

    I'm assuming that unity is not expecting us to all start building on a Mac for osx builds, although I'm sure Apple would love that. If this is the route that Apple takes, then unless there's something more efficient for pushing to osx I might wind up dropping osx support above 10.14 and just support windows and Linux. What a bizarre situation to be in.
     
  13. Relspace

    Relspace

    Joined:
    Jun 7, 2018
    Posts:
    2
    Notarizing every app build is cost preventative as a one person team. Because of this and various issues like often having to rewrite sharers to work on mac I'll likely be dropping OSX support.
     
    x4000 likes this.
  14. x4000

    x4000

    Joined:
    Mar 17, 2010
    Posts:
    307
    What sort of shaders are you having to rewrite? Are you doing a lot with tessellation or something? Other than that, I think most things are feature-parity across those platforms.

    But yes, notarizing every app build is going to be bonkers for a one person team like me, too. This is not the sort of future I ever envisioned for the Apple platform: where the code all finally works there, and has done for most of a decade, but they're chasing out developers in an effort to improve security (which hasn't seemed to really be a big issue on that platform anyway).

    It's just nuts; I thought they wanted games on their platform.
     
  15. Antistone

    Antistone

    Joined:
    Feb 22, 2014
    Posts:
    1,499
    That's one motive that one could ascribe to them. I was thinking this is a step in the direction of turning MacOS into a closed platform, like iOS already is. It also makes it harder to develop for MacOS without actually using a Mac...
     
  16. AndyKorth

    AndyKorth

    Joined:
    Oct 19, 2009
    Posts:
    25
    On iOS, Apple has a lot more control over what types of apps can run on a consumer's device. If an app doesn't match Apple's vision for their platform, they can reject it. That might be an app with a security risk, objectionable content, or competing with Apple's other products. Apple isn't reviewing OS X apps now, but now they have the technical means to un-notarize an app and prevent it's execution. I think they're slowly moving towards the Mac App Store being the only way to install software. That would also guarantee Apple a cut of all software used on their platform.

    @x4000
    Regarding shaders: We have y-flipping issues on basically every one of our shaders that runs on OpenGL and DirectX .. because no one ever remembers the UNITY_UV_STARTS_AT_TOP ifdef. There's actually a pretty big list of things to remember.
    https://docs.unity3d.com/Manual/SL-PlatformDifferences.html

    We're sort of approaching the point where you're likely to forget about OpenGL in favor of metal on mac... But you'll definitely have users with hosed games at this point if you forget to test on all 3 graphics APIs. Linux is probably going to default to OpenGLCore.
     
  17. Mauri

    Mauri

    Joined:
    Dec 9, 2010
    Posts:
    1,597
    From here it says:
    You can enroll in the Apple Developer Program here - it costs $99/year as usual (see here):

    See also:
    - Upload a macOS app to be notarized - Xcode Help
    - Distribute outside the Mac App Store (macOS) - Xcode Help
     
    x4000 and AndyKorth like this.
  18. x4000

    x4000

    Joined:
    Mar 17, 2010
    Posts:
    307
    If I have to join the apple developer program, run xcode on every build, and so on, I think I'm done with osx. I released 5 builds last week; thanks to Steam, my total time from compile scripts finishing to being live on three OSes was about 30 minutes, and the bulk of that time was spent writing some added stuff for the release notes.

    Just transferring the software to my mac to then upload it (let alone get a result) would tack on 20+ minutes per build. So I'm guessing an added hour or so added total with that, per release, after I start paying apple yearly as well as get a new build script process up and running.

    To me this is absolutely a pitchfork-style situation. It definitely sounds like they want a closed OS like iOS, and I don't support that in the slightest. Hell, I was excited to give people OSX versions of my games partly specifically so they wouldn't be locked into Windows. Now there's Linux, which is even better for freedom on that front.

    On my most recent product, literally 2% of the customers have booted it up on a mac, and 2% on linux. I'm sure there's some substantial overlap between those groups, but Steam doesn't show those particular stats.

    On my most popular product, I've had 703,263 copies total on Steam, 15,185 of which were ever associated with a mac, and 4,047 of which were ever associated with a linux box. That's... again 2% for OSX, almost exactly. Less for linux since that game is 10 years old and linux wasn't supported until Steam and Unity both added that capability.

    My second most popular product has just under 4% of people having loaded it on a mac at some point, and that's the highest number I have out of any of my games. That one came out in 2014, and the linux install rate is only 1.5%, so that's interesting.

    There's just no way I can justify the costs -- time costs in particular -- to jump through these hoops apple is setting out.
     
    the_mr_matt and Mauri like this.
  19. CrowbarSka

    CrowbarSka

    Joined:
    Dec 15, 2009
    Posts:
    156
    I've just discovered this issue myself, as I'm going through the submission process for a new game on Steam, and I just wanted to echo your feelings @x4000 .

    As a solo indie developer, it's just not worth it for me to pay that annual fee and devote all that extra time and energy to making Mac builds for every patch, when they've historically only represented less than 5% of my total revenue.
     
    x4000 likes this.
  20. srilakshmim

    srilakshmim

    Joined:
    Sep 23, 2013
    Posts:
    12
    @HiddenJason Do we need to notarise the app before processing for steam or after content prepping for the mac file?
     
  21. HiddenJason

    HiddenJason

    Joined:
    Apr 18, 2016
    Posts:
    16
    My process for getting new builds on Steam is:
    • Export a build from Unity
    • Remove .meta files from the .app bundle (causes codesign problems if you leave these)
    • Manually delete dylib files from Contents/MacOS for services I don't use (my 2D game doesn't need AR, VR, XR, Terrain, etc)
    • Codesign all the .dylib files in the app bundle
    • Codesign all the .bundle directories in the app bundle
    • Codesign the app bundle itself, including the --timestamp, --options runtime, and entitlements flags on codesign
    • Zip the app bundle and notarize with altool
    • Wait for the email from Apple saying the bundle was successfully notarized
    • Staple the notarization to the app bundle (with xcrun stapler staple)
    • Run the steam app build with steamcmd
     
    the_mr_matt likes this.
  22. x4000

    x4000

    Joined:
    Mar 17, 2010
    Posts:
    307
    Good grief, that's an insanely long process. But thanks for sharing that.

    I'm curious -- there are a lot of (managed C#) dlls, asset bundles, and other things that I wind up changing far more frequently than the actual executable or app bundle. Are those being signed? Most of my stuff is outside of the app bundle, in a folder right next to it. I know Apple doesn't like that, but I don't much care.

    A lot of the stuff in the folder next to it is being loaded at runtime (including some C# dlls), and actually a fair bit of that code is able to be created by modders.

    What's bonkers about this whole thing is that either they're NOT going to require code-signing of all those pieces of managed code, in which case all sorts of malicious code could be run (but mods work and it's like any other program on any OS), or they ARE scanning those other files as part of the signing and it's thus also breaking modding.
     
    the_mr_matt likes this.
  23. srilakshmim

    srilakshmim

    Joined:
    Sep 23, 2013
    Posts:
    12
    Hey @HiddenJason

    I could directly sign the .app file with out having to run on each file.
    codesign -f -o runtime --deep -s "3rd Party Mac Developer Application: CompanyName(TeamID)" --entitlements /Users/admin/Desktop/TestMacApp.entitlements /Users/admin/Desktop/Main.app

    Entitlement file saved as TestMacApp
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/>
    <key>com.apple.security.files.user-selected.read-only</key>
    <true/>
    </dict>
    </plist>
     
    x4000 likes this.
  24. JesseSTG

    JesseSTG

    Joined:
    Jan 10, 2019
    Posts:
    24
    Can this process be automated in a build pipeline?
     
  25. x4000

    x4000

    Joined:
    Mar 17, 2010
    Posts:
    307
    Yes... ish. Not from windows (problem 1), and there's a part where you have to wait for an email from Apple and then download some stuff from them (problem 2). But aspects of it could be automated.
     
  26. JesseSTG

    JesseSTG

    Joined:
    Jan 10, 2019
    Posts:
    24
    Sucks, but not in the least surprising. The CI service I plan on using supports macOS runners, at least.

    Just once? Or every time I make a build?
     
  27. HiddenJason

    HiddenJason

    Joined:
    Apr 18, 2016
    Posts:
    16
    Every time. You could use the "--notarization-info" option of altool to poll the status of the notarization instead of waiting for the email from Apple, and then staple the notarization once that completes to automate those steps.
     
  28. JesseSTG

    JesseSTG

    Joined:
    Jan 10, 2019
    Posts:
    24
    How long does that take? Minutes? Hours? Days? This sounds like it will chew up my runner minutes...
     
  29. Ukounu

    Ukounu

    Joined:
    Nov 2, 2019
    Posts:
    13
    I distribute a macOS game through Steam, and I never notarized it. I just build a macOS app from Unity, and then upload and publish on Steam. Checked and double checked it right now, and my game launches through Steam client on macOS Catalina (10.15) without any issues or warnings. Am I missing something? If this "notarization" requirement is now mandatory (as this thread suggests), why my game works on macOS Catalina fine without it?
     
    x4000 likes this.
  30. JesseSTG

    JesseSTG

    Joined:
    Jan 10, 2019
    Posts:
    24
    Apple delayed the requirement by a few months. Valve doesn't technically require notarization, but it strongly recommends it. (Honestly, I think they're as confused as we are.)
     
    x4000 likes this.
  31. Ukounu

    Ukounu

    Joined:
    Nov 2, 2019
    Posts:
    13
    After some googling I found this: https://developer.apple.com/news/?id=09032019a
    So, if I understand it correctly, in January 2020 there will be a new update of macOS Catalina, and this notarization requirement will affect all people who install that updated macOS version.
    It's still not quite clear what the consequences will be. If a Steam game is still not notarized after January 2020, will macOS allow to run it after showing some warning message about unsafe app downloaded from Internet, or it will be completely impossible to run such an app, disregardful of any macOS settings and/or user actions?
     
    x4000 likes this.
  32. x4000

    x4000

    Joined:
    Mar 17, 2010
    Posts:
    307
    I also am seeing my games work fine on Steam without notarization, so that's good to know why that is. Valve is saying that any new games submitted to the store will require notarization, but that was a month ago and I agree they also seem baffled on the issue. I don't know what to expect come January for games, either.
     
  33. Antistone

    Antistone

    Joined:
    Feb 22, 2014
    Posts:
    1,499
    Steam's original announcement seemed pretty clear that notarization would be required: "all new applications will need to be 64-bit and notarized by Apple. This new requirement will go into effect October 14th"

    But subsequent posts in various places by Valve employees seem to suggest otherwise: "We suggest notarization, as Apple says they will require it for all apps at some point in the future, however we will allow your game to ship on Steam without notarization at this time as it seems to be working right now in 10.15."

    When I pressed for clarification I got no response.
     
    x4000 likes this.
  34. srilakshmim

    srilakshmim

    Joined:
    Sep 23, 2013
    Posts:
    12
    Yes, The entire process can be automated.

    . Get the app file and codesign all files
    . codesign the .app itself once the files inside are notarised.
    . Create the dmg of file if you need to upload the dmg, or else zip the app and upload for notarisation.

    This is mac command line to find all files in a .app file and codesign them.
    The OIFS part is used to consider new line as a delimiter instead of space, as there might be files with filenames having space in them.

    Get the app file and codesign all files

    OIFS="$IFS"
    IFS=$'\n'

    find "Path/AppName.app" -name '*.meta' -delete

    arr=(`find Path/AppName.app.app -type f`)
    Loop(){
    for item in ${*} ;
    do
    echo ${item}
    echo "--------------------------"
    # if [[ ${item} == *".dylib"* ]]; then
    codesign -v -f -d -o runtime --entitlements ${EntitlementPath} --timestamp -s "${Certificate}" ${item}
    # fi
    done
    }
    Loop ${arr[*]}
    IFS="$OIFS"

    codesign -v -f -d -o runtime --entitlements ${EntitlementPath} --timestamp -s "${Certificate}" "Path/AppName.app"

    Once dmg is created out of app file or .zip is created out of .app file. Follow these steps

    codesign -v -f -d -o runtime --entitlements ${EntitlementPath} --timestamp -s "${Certificate}" ${Path}/${MacFile}.dmg

    codesign -d -vvv ${Path}/${MacFile}.dmg

    xcrun altool --notarize-app -f ${Path}/${MacFile}.dmg --primary-bundle-id ${BundleIdentifier} -u "username" -p "password" --asc-provider "ascprovider" --output-format "xml" > /Users/Shared/Builds/Standalone/${ChangeList}/StandaloneProcessed/Request.xml

    RequestUUID=($(xmlstarlet sel -t -v '//dict[./key[contains(., "RequestUUID")]]/string' -nl /Users/Shared/Builds/Standalone/${ChangeList}/StandaloneProcessed/Request.xml))
    echo ${RequestUUID}

    while true; do
    /usr/bin/xcrun altool --notarization-info ${RequestUUID} -u "username" -p "password" --output-format xml > /Users/Shared/Builds/Standalone/${ChangeList}/StandaloneProcessed/RequestProcessed.xml;
    if [ `/usr/libexec/PlistBuddy -c "Print :notarization-info:Status" /Users/Shared/Builds/Standalone/${ChangeList}/StandaloneProcessed/RequestProcessed.xml` != "in progress" ]; then
    break ;
    fi ;
    sleep 60 ;
    done

    if [ `/usr/libexec/PlistBuddy -c "Print :notarization-info:Status" /Users/Shared/Builds/Standalone/${ChangeList}/StandaloneProcessed/RequestProcessed.xml` == "success" ]; then
    xcrun stapler staple ${ProcessedPath}/${MacFile}.dmg
    fi

    Hope this helps.
    All these steps are done in our Jenkins ci
     
    x4000 and JesseSTG like this.
  35. BasicallyGames

    BasicallyGames

    Joined:
    Aug 31, 2018
    Posts:
    13
    So like... Is it even possible to just test programs without doing all this? Is there a developer mode on Mac or something that will allow me to run unsigned programs? All I want to do is see how an asset runs on Mac, but no way am I going through all this just for a one minute test...
     
    x4000 and JesseSTG like this.
  36. wagenheimer

    wagenheimer

    Joined:
    Jun 1, 2018
    Posts:
    107
    Unity 2019.3 is already exporting XCode Project and it's working well. Is someway simpler to notarize it when using XCode?