I’ll demonstrate how you can build apps safe from malicious code and/or malicious exploitation even if you make exceptions to the sandboxing rules - or even if you turn off the sandbox entitlement completely.
In this tutorial I’ll give you in-depth insight into the sandbox and then build an app that, whether sandboxed or not sandboxed, can read and write outside of its container - and can be either sold and distributed outside the Mac App Store (MAS) or through the MAS, both with Apple’s blessings. This is the second part in a three-part series of tutorials on sandboxing, signing, notarizing, and distributing macOS apps outside of the Mac App Store. We’ll discover, when merited, how to read/write outside the sandbox, and when and how to develop apps that are not sandboxed at all.Įditor’s note: If you are new to macOS development, you can check out our macOS tutorial series. Today, we’ll take an in-depth look at the sandbox’s benefits (and drawbacks) to both users and developers.
By ignoring the sandbox - and possibly macOS development entirely - developers run the risk of neglecting to understand a fundamental piece of Apple’s security infrastructure, and fail to take advantage of earning income from developing macOS apps. Some might not even be fully aware of the sandbox’s existence, especially in the case of iOS where all apps must be sandboxed. Did you know that a macOS app can read and write outside of its container when sandboxed? Did you know that a non-sandboxed macOS app has no container? Were you aware that you can sell and distribute non-sandboxed macOS apps without using the Mac App Store? Since the focus of most Apple development seems concentrated on iOS, many developers probably take the sandbox for granted.
0 kommentar(er)
