At Ambeteco, we are committed to providing you with the best possible experience when using our software. However, we understand that those who have downloaded or purchased MyQuickMac Lite via the Apple App Store may have encountered a number of restrictions and limitations. This article aims to shed light on these constraints and offer a solution that ensures you can enjoy the full functionality of our software.

The App Store version of MyQuickMac Lite is subject to Apple's stringent rules and regulations. These restrictions are not a reflection of our desire to limit your experience, but rather a necessity to comply with Apple's guidelines. Consequently, if you've downloaded MyQuickMac Lite from the App Store, you may find that a significant portion of the software's functionality is unavailable due to these imposed limitations.

At Ambeteco, our primary objective is to ensure that our users receive the most comprehensive and satisfying experience. The notion of offering software with curtailed functionality is contrary to our ethos. However, the reality of Apple's rules means we are bound by these limitations when distributing our software through their platform.

Recognizing that we cannot alter Apple's policies, we have devised an alternative solution. We invite you to download MyQuickMac Lite directly from our website, where it is available without any restrictions or limitations. This option is entirely free and offers you access to the full functionality of the software.

Unlike many other companies, we pride ourselves on offering unified software and licenses. This means that regardless of where you purchased your MyQuickMac Lite—be it the App Store, our website, or through our partners—you are a valued client. You can download and use MyQuickMac Lite from our website, the App Store, or any other source, and your license will remain valid without any additional charges or complications.

Still, this article is not only about MyQuickMac Lite—it is also about the restrictive environment created by the App Store, finding possible explanations for it while offering alternative ideas.

The true reason that developers never tell you

There is one restriction that has a significant effect on many macOS apps, including MyQuickMac Lite. Because of these restrictions, some developers even decide not to publish their apps on the App Store. Or maybe they simply can't?

Adobe Creative Suite, including Photoshop, Illustrator, Premiere Pro, After Effects, Google Chrome, Mozilla Firefox, Zoom, Dropbox, Spotify, TeamViewer, Skype, Blender, Maya, Cinema4D, Figma.

We all know these apps, and none of them are published on the App Store.

Have you ever wondered why all these apps are not published on the App Store? Obviously, not because they are "unsafe" or because they can't be trusted.

While it is impossible to know for sure—in the end, it was a business decision, and they are rarely made public—we can still analyze the Apple guidelines and try to understand the possible reasons behind the decision.

Apple's guidelines cover a wide range of issues, from user privacy and data security to content restrictions and in-app purchases. Some developers may find these guidelines too restrictive or not in line with their business model, and therefore choose not to list their apps on the App Store. Some of these rules are incredibly strict: for example, it's prohibited to place any external links in your app, even to your own website. Apple believes that developers may use external links to avoid paying a 15% or 30% fee placed by the App Store; this is also why there is no link to our website in the MyQuickMac Lite version for the App Store.

Financial considerations also play a role. As mentioned above, Apple charges a 15% or 30% commission on all in-app purchases and subscriptions made through the App Store. For companies with a large user base and significant revenue, this commission can amount to a substantial sum. By distributing their apps independently, these companies can avoid this fee and retain more of their revenue. This is particularly relevant for apps like Spotify, which rely heavily on subscription revenue.

One of the most significant factors is the technical restrictions. Apps like Adobe Creative Suite, TeamViewer, or Blender require extensive system access to function optimally, which is not possible within the confines of the Sandbox environment. Even launching the app on the startup is a problem: you can only launch the app, but you can't tell it that it was launched from the startup. For example, for messaging apps, it means that they will start just as if you clicked on them—instead of starting minimized, which is certainly better for the user experience.

Developers rarely tell their users about this almost mythical being named "Sandbox". We think that as a software company, we must be as honest as possible about all requirements and rules that we must follow. Below, we will explain what is Sandbox for and why there are so many developers all over the world who eagerly hate it.

The "one and only" restriction: Sandbox

All apps published on the App Store must be "sandboxed". Apple's "Sandbox" is a security feature designed to protect users from potentially harmful actions that an app might perform. Imagine it as a playground where each app gets its own separate space to play in. This space, or "sandbox," is isolated from the rest of the system, meaning that the app can't interact with other apps or access data outside its designated area without explicit permission. This is a great way to prevent malicious software from causing harm, as it restricts what an app can do.

However, while the sandbox is designed with the best intentions, it is also the cause of a significant number of issues. For example, one of the reasons for this is that Sandbox can sometimes hinder an app's performance. Just like a child might feel restricted in a playground with too many rules, an app in a tightly controlled sandbox might not be able to perform as efficiently as it could without those restrictions. This can lead to slower performance, which can be frustrating for users who expect their apps to run smoothly and quickly. Often, a large amount of overhead is also introduced, as the app must ask or check for permission before doing anything related to the system. Imagine that you need to ask for permission for every single action you take, and wait for the confirmation: "Can I wake up? Can I change the position of my hand? Can I close my eyes? Can I breathe?". This is called an overhead.

To explain it simply, in programming, "overhead" refers to the extra processing or memory resources that are needed to manage the tasks a program performs, beyond the resources used for the tasks themselves. Imagine that you're preparing for a party. Your main task is to prepare for a party, yet during it, you may have to walk a lot from one room to another. Then, imagine that each time you go from one room to another, you open the door and then close it. Every single time.

Now, to make it more similar to the programming, let's imagine that you need to move from one room to another 17200 times. Each time you still must open and close the door between these two rooms. Sounds productive?

In this case, opening and closing the door is what "overhead" is—it doesn't directly contribute to the main goal, but it is still necessary. Overhead may seem like an almost innocent little delay that won't take much time, but when you perform it multiple times, overhead suddenly becomes visible and ruins the app's performance. Apple's Sandbox can introduce many overheads to the app, as it is just like opening and closing the door each time when you walk between rooms.

Another issue is that the sandbox can make the user experience more complex. For example, if an app needs to access a file in a different location, it has to ask the user for permission. This might not seem like a big deal, but if you're using an app that needs to access multiple files in different locations, you could find yourself constantly being asked for permission. This can interrupt your workflow and make using the app more cumbersome than it needs to be. This is exactly what happens in MyQuickMac Lite, where after installing the app, you must give the permissions to five folders: Documents, Music, Downloads, Movies, Pictures. It is impossible to skip this part, and you need to manually do the same thing five times. Press the button, open the folder selection dialog, confirm, and repeat. Five times.

In some cases, we have to agree that explicit permissions are a very good idea. For example, you download the app, and it suddenly wants to know your location. Why does that app need it? Is it a GPS navigator or maybe a weather app? If not, then the Sandbox with explicit permissions will truly be a very solution: it will make users much more protected.

Still, there are many cases when asking for explicit permissions is just an unnecessary step that only makes the lives of the users unnecessarily more complex. When you have decided to buy MyQuickMac Lite, you already understand that it will sort your files, and, mentally, you have already agreed to give it permission to whatever folders it needs to work. Do you need to give these permissions again now, in the physical world? If you don't like the idea of sorting your files, you will not even download MyQuickMac Lite in the first place, so why is there a need to ask for explicit permission five times?

Furthermore, the sandbox can also limit the functionality of certain apps. Developers often have to work around the sandbox's restrictions to provide features that users want, and sometimes they even have to delete the features as it is impossible to adhere to the Sandbox's rules. This can lead to less intuitive design choices, make apps harder to use, or even leave users without the functionality they paid for. For instance, a photo editing app might not be able to access all the photos on your device due to sandbox restrictions, requiring you to manually select each photo or folder you want to edit. In our opinion, this does not exactly resonate well with Apple's famous "Human Interface Guidelines".

Then why is it there?

Despite these issues, it's important to remember that the sandbox is there for a reason. It's a crucial part of Apple's commitment to user security and privacy, as the main goal of the Sandbox is to be a defense mechanism against malware. The App Store has millions of apps, and having strict rules and technical restrictions may be the only possible solution to keep it more or less stable.

It is possible to say that Apple's sandbox is a double-edged sword. On one hand, it offers a significant level of protection against potentially harmful apps. On the other hand, it can lead to performance issues and a more complex user experience. Still, taking into account the fact that Apple moderators manually check all apps and thoroughly test them before approving them, and the fact that Sandbox is mostly here for security reasons, why is it needed?

And there is an answer: the apps can be initially planned as malware, and with careful planning, everything is possible. The app can pretend to do its job; for example, malware might pretend to be a weather app but actually have a backdoor in it: meaning that attackers can remotely control the app and use it for their benefit. In this case, Apple Moderators may not notice the malware being hidden and publish it on the App Store. Sandbox should be a solution to this: if the app has a backdoor and the attacker "orders" the app to steal the user's data, there is still Sandbox which should prevent such an attack. In this case, users will still need to give explicit permission for the app to steal their data. Well, if this is true, then why do we still see news like "Apple Removes 17 Malicious Apps From App Store"?

An explanation for this problem is technical illiteracy. And, unfortunately, it is much harder for Apple to combat illiteracy as opposed to malware. When the users themselves voluntarily agree to provide their own data to malware and confirm everything blindly, nothing will help—such users will still inevitably fall into the trap of an attacker. Malware indeed becomes more complex with each passing day. Yet, the defense mechanisms also advance—and they do it quickly. At the same time, dealing with technical illiteracy is undeniably hard.

In the end, imparting knowledge to others can be a challenging task. How is it possible to teach a person to analyze certain software in order to predict if it will be malware? One of Apple's solutions—which is much more effective than trying to teach users about technology—is making their operating system more and more strict. Developing malware for a system where everything is restricted and must be done with the explicit consent of the user is no fun: in the end, the number of users who blindly agree to everything is, thankfully, quite low.

Let's take an example with an abstract malware "X". Malware "X" steals user data and sends it to the attacker's server. Then, the attacker will try to decrypt the collected information and extract as many benefits as possible: the imagination of the attacker is the only limit here. Some examples may include stealing passwords, card information, personal messages, etc.

Now, let's imagine we are Apple. We need to somehow engineer a solution that will prevent malware such as "X" from attacking our users. What can we do?

Of course, we can take the hard route: it will be better in the long run, yet it is a very tedious journey. We can try to teach our users that they must check many things before downloading and installing some software "X". For example, they need to open the developer's website and see how it looks, how it is structured, if it is up-to-date, if there are any blog/news entries, and if there are social media pages. After this, the users should have their general opinion about the developer's website formed: while it may not be to your taste, the website still should be done professionally, and (ideally), it should have something that from afar resembles a design. Additional checks may include checking company information, for example, when it was established, as there is a very large difference between a company that was established in 2015 and one that was registered one month ago.

Imagine trying to teach people all of that interesting knowledge. These steps may seem very obvious to you - and, if this is the case, then it is amazing - yet most people do not do this. As we are trying to explain the actions of humans, we are most likely going to fail - yet we can still try to name the possible reasons for that behavior. Perhaps people who don't perform these checks simply don't have time for them, as it undeniably requires effort and time to perform any sort of check. Maybe they are not aware of the importance of performing these checks, or they do not understand the consequences of not doing so. It is also possible that they do not possess the necessary skills or knowledge to perform the checks.

Whatever the reason may be, it is essential to educate people on the importance of performing these checks, and to provide them with the necessary knowledge and resources to do so efficiently. Still, promoting a culture of thoroughness and accountability, where individuals take responsibility for ensuring that the right checks are performed at the right time, is a truly challenging and non-trivial mission. What can we do instead that will desirably offer instant results?

Instead of trying to teach people something, we can try to make the platform "fool-proof": One of the best solutions is the introduction of a very restrictive environment - the one where every action must be explicitly confirmed by the user. And this is exactly what Apple did when it started requiring the use of Sandbox back in 2012.

Do you want to allow the app "x" to access the file "~/Application Support/Google Chrome/Passwords"?

This is a win-win situation, as attackers will slowly lose interest in developing malware for such a platform because they will have to spend a lot of effort without the guarantee of success, the system by itself will become more secure, and users will have more control over the apps.

Still, there is a simpler solution...

A simple solution does not exist, as many issues in modern software engineering are quite double-sided. While they may solve the issue, they also introduce new ones or make something slower and less efficient—whether it is the app's performance itself or the user's interaction with the interface. Finding the balance between security and usability, protection and performance, or restrictions and innovation will always be hard—and sadly, we will never find the balance. As harsh as it may sound, the biggest threat to the security of the computer is the person who uses it—not the actions of the App Store moderators, Apple's rules, or security holes.

Here is an unpopular opinion: instead of buying antivirus, it may be better to invest in your knowledge and technical literacy. The best protection you may ever find is logic, critical thinking, and constant analysis.

Still, if we speak of less abstract protection methods, here is one of the simplest yet most effective pieces of advice: never install software you don't trust. By following this advice, you will significantly lower the risk of being attacked by malware. Still, it is important to understand that the risk of being attacked by malware will never be zero.

Instead of trying to prevent malware, it might be more appropriate to be prepared for the consequences of the attack. For example, storing all your sensitive files or documents in encrypted storage, saving your password in powerful password managers that are cryptographically secured, and performing backups. This will protect against the most common types of malware, including stealers, trojans, backdoors, or cryptors. In an ideal situation, everything must be organized in such a way that, even if you are attacked by malware, you can always perform a hard-reset of your computer and then restore everything from your backup.

The battle against malware will always be complex: Even though Apple tries its best to create more and more restrictive environments, security requires a multi-faceted approach that combines robust security measures, user education, and responsible digital behavior. Even though restrictive environments may deter attackers, it is only one piece of the puzzle, as the end-user also has a crucial role to play in maintaining their own security. The digital landscape is ever-evolving, and so must our strategies for safeguarding it. The fight against malware is not just about building higher walls, but also about equipping users with the knowledge and tools they need to protect themselves. After all, the most secure system is not just the one that is hardest to break into, but also the one used by the most informed and vigilant users.