What is the current Apple's policy? Speaking about Gatekeeper, they never mention that getting a Developer ID guarantees that your app will be allowed to run with the default Mac App Store and identified developers option. They never say that every valid signed app will be automatically accepted.
I cannot distribute my app in the App Store since it violates its guidelines. But it's useful, does not contain malware, ads or so.
If you sign up as an Apple developer, there are three ways to release your apps:
Through the App Store, in which case Apple pre-screens them before allowing customers to download them. If you choose this option, there is no guarantee that Apple will accept your app (although following their App Store guidelines gives you good odds).
By signing the app with your developer ID, and then distributing it yourself. The developer ID is granted automatically when you sign up as a developer, Apple doesn't screen your app at all, and apps signed this way will run under Gatekeeper's default setting ("Mac App Store and identified developers").
HOWEVER, if it comes to Apple's attention that malware is being distributed with your signature on it, they can revoke your developer ID certificate. If this happens, Gatekeeper will start blocking your signed apps (including any non-malicious ones). Unfortunately, while I think I remember reading a statement from Apple defining what they consider malicious, I can't find it now.
With or without a developer membership, you can distribute unsigned apps. Apple has no say in this, either before or after distribution, but Gatekeeper's default policy will block them.
You can check if Gatekeeper will accept your app's signature..
$spctl -vat execute MyApp.app
you'll see..
MyApp.app: accepted
source=Developer ID
Related
Apple wants apps to be signed. With newer MacOS versions, unsigned apps look less and less welcome.
As a cross-platform developer with almost no knowledge of Apple specifics, I have to learn how to sign Apple apps. A step-by-step recipe would be helpful.
So far I understood all the following is necessary:
Register for an Apple ID [1].
Agree with endless pages of legalese.
Apply for an Apple developer account [2].
Choose among several categories (individual, nonprofit, government, ...).
Accept further pages of legalese.
Agree with unspecified membership fees that are waived for open-source projects.
Wait for unspecified time until you will or will not be admitted by Apple.
Create a certificate from Xcode.
Open or create an arbitrary project to get to the main menu.
In the main menu (Xcode) > Preferences > Accounts > Manage Certificates > "+" (bottom left) to create certificate.
In the main menu (Xcode) > Preferences > Accounts > Download Manual Profiles. Seems to create a file with extension .developerprofile.
From here, an unknown number of steps is missing....
Maybe the last step involves the command codesign [3],
codesign -s <identity> --keychain <full-path-to-keychain> <path-to-disk-image>
What is <identity>?
What is the keychain file?
Who can confirm or correct the above, and supply the missing steps?
Note that the build process shall ultimately be run from CMake. Therefore command-line tools are preferred over GUI actions.
[1] https://appleid.apple.com/account
[2] https://developer.apple.com/
[3] https://stackoverflow.com/a/37923530/1017348
You can build and sign to completion using Xcode, or you can build and then sign and notarise the binaries using codesign, altool, and stapler tools.
Xcode attempts to handle the complexity for you, at the cost of your not needing to understand or know about the individual steps involved. .developerprofile files are part of Xcode and Xcode is not essential to preparing a binary for distribution.
See Apple's Xcode Guide - Distribute your app and Distribute outside the Mac App Store (macOS).
Apple have also published the following guides on code signing and notarizing:
Code Signing Guide
Notarizing macOS Software Before Distribution
Identity
What is <identity>?
identity is common name field of the digital certificate being used to sign the binary. The digital certificate is an X.509 certificate issued by Apple. You can obtain certificates for submission to the Apple app stores, and distribution outside of their stores, through the Apple developer web site.
See Apple Developer - Certificates
Apple Developer Program membership is required to request, download, and use signing certificates issued by Apple. For developers part of a team enrolled as an organization, you must also be the account holder or an admin to request distribution certificates used for submitting apps to the App Store.
Keychain
What is the keychain file?
Keychain files are managed through the Keychain Access application on macOS, see Applications/Utilities/Keychain Access. By default, the user's keychain files are stored in ~/Library/Keychains.
The keychain file is where macOS stores secure user information, such as credentials and certificate keys. The keychain file needs to be specified for the codesign tool to locate the private key associated with the signing certificate.
See Apple Developer - Keychain Services:
Securely store small chunks of data on behalf of the user.
Computer users often have small secrets that they need to store securely. For example, most people manage numerous online accounts. Remembering a complex, unique password for each is impossible, but writing them down is both insecure and tedious. Users typically respond to this situation by recycling simple passwords across many accounts, which is also insecure.
The keychain services API helps you solve this problem by giving your app a mechanism to store small bits of user data in an encrypted database called a keychain. When you securely remember the password for them, you free the user to choose a complicated one.
Support from Apple
If the documentation linked above does not help, please contact Apple. The process you are facing is demanded by Apple, and Apple should burden the support it creates.
As a registered Apple Developer, you have access to Technical Support Incidents:
Requesting Technical Support
A Technical Support Incident (TSI) is a request for code-level support for Apple frameworks, APIs, and tools, and is available to members of the Apple Developer Program and Apple Developer Enterprise Program.
I have a client who forgot to pay for their enterprise account and therefore their apps stopped working, as expected.
However, one would think that it should be sufficient to just start paying again to be able to use the apps as before. But as it seems, all certificates in the apple developer portal are now deleted?!
Is this expected behaviour or will they show up after some time again?
As it is now, we will have to rebuild all apps again with new distribution certificates. Is this the solution?
Short answer to your question:
I wouldn't expect the certs to automatically reappear. I recommend opening a support incident with Apple. Since the account was recently renewed, you should have two incidents available.
There's this section of the App Distribution Guide which talks about re-creating deleted certificates but I'm guessing it's more geared toward iTunes distributed apps and circumstances where certificates (private keys) are deleted but not revoked at Apple's CA.
Instead of recompiling your apps, you might be able to instead push out updated Provisioning Profiles and Certs. See below for more details.
Additional info:
It makes sense that Apple would revoke Enterprise certs upon membership expiration since that's the only way they could force apps to stop working. Since Enterprise apps stop working when either the Provisioning Profile or the Certificate expire, Appple can't push out an expired Provisioning Profile, and there's no in-app check for a Profile either (which is why if you delete your Profile in the developer portal, it won't affect any already downloaded/installed apps), which leaves the only other option: revoke the certs. The affected apps stop working once they sync with Apple's CA. Devices without connectivity will continue working until the Profile expires.
It may be possible to remove your certs from the Certificate Revocation List (CRL) but Apple support would be your only likely resource to help with this.
If you're out of options for re-enabling your old certs, you can update the Provisioning Profiles (and I think Certs) and push that out without recompiling all your apps. Also, if you use wildcard App IDs, an update to one app Provisioning Profile will apply to all installed apps that share that App ID.
If your users' devices are managed via MDM, it's possible to push updated provisioning profiles via MDM, and according to this post, via Device Enrollment Program (DEP). I thought I read a while back that you could also update provisioning profiles from a desktop/laptop to a connected device using iTunes - not sure where that is now. I don't know if it's possible to direct users to a link to update the Profile OTA like they would install an app.
I hope this helps in some way. Please let us know what happens - I fear the same could happen to me, whether a cert is deleted by Apple or a haphazard developer.
As a developer of an app it could be quite a turn off if half of your users cannot open your app because they get following error.
[i know there is a workaround by going to sys preferences->security-> allow apps from "anywhere" but users of our apps are kids, they may not be in the best position to know how to do that]
What things I need to take care of in oder to avoid this warning, or to get apple developer identity?
This app has been published on App Store, so all the provisioning profiles and certificates are there. Now we want to put the app on our website, but before doing that we want to eliminate this gatekeeper hurdle.
In the screenshot above you can see that the right developer is selected while archiving.
The signing identity used for App Store submissions and for independent publishing are different. The latter requires a Developer ID identity be used. See Distributing Applications Outside the Mac App Store for more information about the process.
I have a Mac app that I am planning on launching soon.
I want it to be available for purchase on the MAS however I also want to offer a time trial on my website.
I will sign the time trial version with my developer ID and the MAS version with my distribution cert.
If a user downloads the time trial and then decides to purchase from the MAS:
Will the MAS let them purchase or will it prompt the user that they already have the app installed (due to them sharing the same bundle identifier)?
The reason I want them to share the same bundle identifier is so both the time trial and MAS versions can share their application sandbox data and Keychain data. Is this possible?
(I have considered using IAP and doing away with time trials altogether however IAP does not allow for volume pricing which I would like to utilise.)
The MAS will alert the user that they already have the app installed. Your users will need to delete the trial version first.
No. Even though they have the same bundle identifiers, the system sandbox daemon, sandboxd, will typically reject access to one of the apps (typically the one that they download second). This is because the sandbox directory is cryptographically linked to its host app. In addition to signing the app, your app gets a unique signature, like a SHA-1 hash, that will be radically different each time. This means that when you download the app for a second time (I.e from the website, when it was previously downloaded from the MAS), if the sandbox is linked to an app with a different signature, sandbox access will be denied.
Now, if you're lucky, the user might download the MAS version first and might then (for some reason) move onto the trial. This might work, but there's no guarantee that it will and I wouldn't rely on it. Some have had luck with it, like those that have decided to ditch the MAS over sand boxing frustration.
I have an app that I'm going to put in the Mac App Store. I'd like to add iCloud support for preference syncing, and for that reason, I'd like to distribute the betas signed in such a way that they can access iCloud.
However, I haven't been able to find anything in the Mac documentation library about distributing an app, signed with a distribution key, outside of the App Store, and being able to access iCloud.
So far, my attempts to distribute such an application have met inability to launch on testers' machines, with messages in the Console complaining about the app having the iCloud entitlement.
Is what I'm after possible, or should I abandon iCloud support? If it is possible, what do I need to do to make a distributable, iCloud-capable build?
Edit: To be clear, you can replace “iCloud support” in this question with any other feature that is only available to App Store apps. I mention it to establish that the solution is not “just distribute it unsigned”. iCloud is the goal in my specific case; I'm asking about the general process.
You would need to gather the UUID for the tester's mac, either available via Xcode's Organizer or you can also access it via Apple System Profiler under the hardware overview. After adding it to the developer portal you'd generate a provisioning profile.
In order for them to actually run the application they would need to make use of an iTunes Connect test user account. This is one of two types of accounts that you can create in iTunes Connect, the other being an account with privileges (financial/technical/etc) for your developer membership. The test user account is needed in order for a receipt to be generated and the application actually run. Though you might be able to sidestep the test user account requirement by not actually validating receipts at that phase of development.
If you want to do iCloud or Push you need the UUID.
If you want to test a MAS app that doesn't need iCloud or Push, but does do receipt validation you need only the test user account.
My iCloud Mac app is stil in development, so I didn't try yet. But isn't it possible to sign the app with an entitlement and add a test user to iTC. In the OS X provisioning portal you can already add devices, and you need to add the testers Macs there and re-create the provisioning profile afterwards. After build & archive you "Share..." the app as installer or .app. The user needs to login with the/his test user you created in iTC on her/his Mac.