12 Replies
      Latest reply on Nov 26, 2018 8:51 AM by kolpanic
      kolpanic Level 1 Level 1 (0 points)

        Hi, all!

         

        I've been working on getting the hardened runtime enabled in the direct sale versions of our macOS apps. I successfully got it working and Apple's notarization service accepted the one app I've been working on.

         

        However, we also sell Mac App Store versions of these apps, and we have shared framework projects that are also used in iOS apps. Each project has different targets depending on the platform and/or distribution channel.

         

        If I activate the "Enable Hardened Runtime" setting at the root project level, will it have any negative effects on the non-DS and non-macOS targets in those projects?

         

        Thanks!

        • Re: Hardened Runtime vs. MAS & iOS Targets?
          KMT Level 9 Level 9 (13,925 points)

          Target level settings take precedence over project level, but if enabled at the project level, it may cause errors to be thrown when building/submitting iOS/non-macOS apps.

           

          Did you enable via Capabilites, or via the 'Hardened Runtime' setting available in the Build Settings tab in All build setting section at the Target level?

            • Re: Hardened Runtime vs. MAS & iOS Targets?
              kolpanic Level 1 Level 1 (0 points)

              Thanks, KMT.

               

              During testing, I enabled it in the Build Settings tab. I didn't realize it was available on the Capabilities tab, because I started with the embedded framework projects, and they don't have that tab.

               

              However, for the app projects, I'll use the Hardened Runtime section of the Capabilities tab when I enable it for real. Since that's available only at the target level, I'll do it there, in the DS targets of our macOS app projects. Also, sInce you note that it may cause errors in non-macOS targets, I'll limit it to the macOS target in the cross-platform framework.

               

              My only remaining concern is enabling it in that macOS FW target, since it's used in both DS and MAS builds of our apps. If it can be safely enabled for the FW embedded in a MAS app, then I'll just turn it on in that target. However, if I have to, I'll create a copy of that target for DS builds and enable it there only.

                • Re: Hardened Runtime vs. MAS & iOS Targets?
                  KMT Level 9 Level 9 (13,925 points)

                  Note I was being generic when I used the word 'errors' - I should have said may cause errors/warnings instead. Where an error risks full stop, and a warning manifests as simply a dialog you might be able dismiss and keep going. Up to you to check and determine what if any effect your process may need to accommodate.

                   

                  Otherwise, sounds like you have a good handle on things. Pls. update on how you get on if you have time, thanks.

                    • Re: Hardened Runtime vs. MAS & iOS Targets?
                      kolpanic Level 1 Level 1 (0 points)

                      Thanks again.

                       

                      Regarding my concern with using the hardened runtime setting with frameworks in MAS apps, I guess we can try it and see what happens. Since it's just a code-signing flag (for frameworks), the worst that can happen is that we submit the app for approvaly an it gets rejected for having an invalid signature.

                       

                      I'll post an update once we ship.

                    • Re: Hardened Runtime vs. MAS & iOS Targets?
                      eskimo Apple Staff Apple Staff (11,065 points)

                      My only remaining concern is enabling it in that macOS FW target …

                      I presume that “FW” means “framework” here.  In that case I’m not sure what you’re concern is.  The hardened runtime is an attribute of the process.  It’s not something that frameworks can opt it to or out of individually.

                      The disposition of the Capabilities tab reflects this.  That tab is present for Mac application target but not for framework targets.

                      Share and Enjoy

                      Quinn “The Eskimo!”
                      Apple Developer Relations, Developer Technical Support, Core OS/Hardware
                      let myEmail = "eskimo" + "1" + "@apple.com"

                        • Re: Hardened Runtime vs. MAS & iOS Targets?
                          kolpanic Level 1 Level 1 (0 points)

                          Thanks for clarifying, Quinn.

                           

                          Yes, "FW" means "framework".

                           

                          However, what about other embedded targets that are application-like, especially deeply embedded ones? We use sandbox-enabled version of Sparkle in our direct sales apps to handle auto-updating. The Sparkle framework contains XPCs and helper apps. In addition, our app contains a share extension. The notarization submission workflow complained when those things weren't signed.

                           

                          I documented my experiences with Sparkle in an issue in their Github repo (https://github.com/sparkle-project/Sparkle/issues/1266#issuecomment-440789584). BTW, I did use the "--deep" flag when manually code signing Sparkle's embedded apps; is that necessary?

                           

                          AFAICT, the "Enable Hardened Runtime" build setting, when turned on (not via the Capabilities tab), just adds the "-o runtime" flag to the codesign step. If that doesn't have to be set for embedded targets that are not applications, then that simplifies things.

                           

                          I notice that the share extension target does have a Capabilities tab. So that may be a good rule of thumb—it only has to be enabled for targets that have a Capabilities tab.

                            • Re: Hardened Runtime vs. MAS & iOS Targets?
                              kolpanic Level 1 Level 1 (0 points)

                              Thanks for the guidance, Quinn.

                               

                              I was able to get our app successfully notarized. I did as you suggested, enabling the hardened runtime in our project only for the app and share extension targets (via the targets' Capabilities tab). Also, I was able to omit the `--deep` option when code signing Sparkle's embedded executables. The Exported Notarized App passes `codesign --verify`, `spctl --assess`, and  `xcrun stapler validate`.

                               

                              However, I've discovered I have one last question. Is there any negative effect of enabling the hardened runtime on MAS targets? Specifically, our app has a share extension target that's used in both the MAS and direct sale app targets.

                                • Re: Hardened Runtime vs. MAS & iOS Targets?
                                  eskimo Apple Staff Apple Staff (11,065 points)

                                  Is there any negative effect of enabling the hardened runtime on MAS targets?

                                  I don’t know for sure, and I’m reluctant to speculate because I don’t want to lead you down the wrong path that might then cause problems in the future.  My recommendation is that your open a DTS tech support incident and talk to our Mac code signing specialist about your specific requirements.

                                  Share and Enjoy

                                  Quinn “The Eskimo!”
                                  Apple Developer Relations, Developer Technical Support, Core OS/Hardware
                                  let myEmail = "eskimo" + "1" + "@apple.com"

                                    • Re: Hardened Runtime vs. MAS & iOS Targets?
                                      kolpanic Level 1 Level 1 (0 points)

                                      I found a forums thread about people with problems submitting MAS apps that had hardened runtime inadvertently enabled. It turned out to be an Apple bug that was subsequently fixed.

                                       

                                      Furthermore, there was this reply from a Sr. Software Engineer at Apple DTS:

                                      > You should be able to submit an app with the hardened runtime enabled to the Mac App Store.

                                       

                                      So, I think we're going take a chance on doing our next MAS submission with the hardened runtime enabled in the shared target. If there's a problem, we'll dupe the target.

                          • Re: Hardened Runtime vs. MAS & iOS Targets?
                            john daniel Level 3 Level 3 (350 points)

                            I'm confused. I don't see any hardened runtime or Capabilties tab at the project level. I only have Info and Build Settings at the project level. Each target has its own Capabilties tab. I have hardened runtime enabled for the Developer ID build and disabled for the Mac App Store build. I didn't set it up this way on purpose. I just do the bare minimum as far as Apple requirements go. Apple doesn't require the hardened runtime for the Mac App Store so I'm not about to turn it on and risk something breaking.

                              • Re: Hardened Runtime vs. MAS & iOS Targets?
                                kolpanic Level 1 Level 1 (0 points)

                                There is an "Enable Hardened Runtime" setting on the Build Settings tab of macOS projects and targets.

                                 

                                However, Quinn recommeds using the Hardened Runtime section on the Capabilities tab of macOS targets (not projects). That tab is only present for app (and app-like) targets.

                                 

                                My main problem has been getting Sparkle properly built (with its deeply embedded XPCs and helper apps) so the app can get notarized.