That is probably the big question that anyone who is starting with Flutter and wants to export their applications to iOS or MacOS and does not have an official Apple device asks; because for those of you who don't know, owning a Mac is the only official way to develop software and release it for the Apple ecosystem.
📽 Video version available on YouTube and Odysee
In this article I'm going to try to answer that question as objectively as possible. Even though buying Apple hardware is the official way to develop and publish apps for iOS and Mac, there are also some unofficial ways; all of them have their advantages and disadvantages:
- Virtualize macOS
- Hackintosh
- Cloud Services (Mac in Cloud)
- Use a CI/CD system
All of the above points are theoretically alternatives to buying a physical Apple device, but are they really safe and efficient ways to develop and publish Flutter apps? I am going to try to unravel the best and the worst of each one of them.
Virtualize MacOS
This way consists of creating a MacOS virtual machine. There are several ways to do it both in Windows and Linux, the main advantage of this route is that no prerequisite is necessary other than having hardware that allows virtualization, and this is something that practically any computer today has. In case your PC does not allow it by default, you may have to enable this option in the BIOS.
Apart from the aforementioned point, the rest of the things are all negative from my point of view. To begin with, we are talking about completely virtualizing an entire system on another host system, which means that don't expect great performance from your virtual Mac, always depending of course on the capabilities of your hardware. Besides that, I think that it is technically possible to connect and debug on an iPhone, however in my tests I have never achieved it, and testing the apps we make on real iOS devices is an essential requirement from my point of view if we want to be serious and make sure everything works fine, without also mentioning that certain features can only be tested on real devices. As if the above weren't bad enough, installing the proprietary MacOS software on hardware not provided by Apple is against Apple's terms and conditions, exposing anyone who tries it to possible penalties or even the total blocking of the Apple account, especially if we try to deploy our application to the AppStore from the XCode of our virtual machine.
In short, trying this system has a low cost but I do not recommend it for all the reasons mentioned.
Hackintosh
Hackintosh is the name given to the purchase of certain hardware components, specially selected for their compatibility with MacOS, and their assembly in the form of a desktop PC or similar, for the subsequent installation of MacOS as a native operating system.
There are several websites that offer installation guides as well as hardware guides to find out what components to buy to assemble a computer like this, the most famous being tonymacx86.
Unlike the previous point, in this case we are not virtualizing but running the operating system directly, so we will not have the performance problem. In fact, there are Internet users who demonstrate how their Hackintosh offers superior performance to official hardware sold by Apple for a fraction of the price. The downside is that this method does have a cost, which is the purchase of all the hardware components for assembling the computer, and there is also the risk of possible incompatibilities or poor system stability, with which it is necessary to know very well what to buy and how to put it all together for an optimal experience.
However, the problem of the terms of use still exists, the applications that we develop on a computer like this are not going to be signed by official hardware, so the risk of bans and blocking by Apple is big, so I cannot recommend this approach.
Cloud Mac
This approach consists of using an operating system in the cloud, the best-known being MacInCloud.
For a modest price we can configure our Mac in the cloud and use it in a conventional way, in fact we would be working with a real Mac but accessing it remotely through the browser.
In this case, the performance would be that of the chosen machine, so the higher the price, the higher the benefits; in addition to being a real Mac sold by Apple, we will not have the legal problem regarding its terms and conditions.
To tell the truth, it's not a service that I've tested enough to be able to talk about it in-depth, so I don't really know if the latency of the connection would let you work with peace of mind, or the practicality of working remotely, or if it makes sense financially to pay a subscription like that if we are going to dedicate ourselves in the long term to iOS or MacOS development.
The main negative point that I see, despite not having tried it, is that it is not possible to debug on a real device, something that as I have already said, I think is absolutely essential to develop with quality. So we would have to deploy the application in TestFlight or use alternative methods as indicated here. However, these mechanisms do not seem to me to offer enough agility and speed to perform multiple trial-and-error cycles to work with ease.
I personally don't see it as an efficient way to work, but for a low price you can at least try it out to see if it meets your needs.
Use a CI/CD system
This method consists of deploying the iOS or MacOS app through a Continuous Integration / Continuous Delivery platform, like Codemagic or Bitrise.
In this case we are not talking about developing, but about deploying, so this method is compatible with the methods mentioned above.
These platforms have real Mac devices, usually Mac minis, which they make available for users to build on. The workflow would be as follows: we would configure the system to work with our GIT service, and by performing some configured actions (such as pushing to a release branch or creating a pull request) a build would be triggered on the platform. This build could include the deployment of the iOS variant in TestFlight, with which we could test the iOS version on a real device.
The problem with this system is the enormous complexity required to test a build without first ensuring the version of iOS or MacOS. To put us in context, when you develop you test that everything works well in your local environment, and when everything is fine, the job is launched in the CI/CD system that ideally executes additional tests that you could hardly execute manually in your local system. But in this case there would be no local testing phase, but directly launching the build in the CI/CD, so if we imagine a typical scenario in which 10, 100 or more test-error cycles could be necessary, which in a local system can take anywhere from a few seconds to a few minutes; launching a job in CI/CD for its subsequent approval and deployment in Test Flight could take an hour or more.
So imagine that to develop a task you need to refactor your code 10 times, and each time it takes you 1 minute to do it. In total it would take you 10 minutes to complete the task. Now imagine that to test each change you have to launch a build and have it launched in TestFlight, this can take at least an hour (usually more), which would take you 10 hours to finish the task.
As you can see, I do not see the viability of this way at all, unless it is combined in some way with one of the previous ways.
Conclusion
To try to give a final conclusion to those of you who are wondering if some of the alternatives to buying an Apple device could be feasible in your path as Flutter developers, I will give you two opinions:
- If you just want to play, without committing to anything, you can try any of the above ways assuming the associated costs and risks.
- If on the other hand, if you want to develop with a minimum of seriousness and efficiency for iOS or MacOS then, definitely, you need to have a Mac.
It is not really necessary to go to the highest range of MacBooks or iMacs, with the Mac mini it is perfectly possible to develop; providing a good balance between power and price.
I understand that what is stated here is not exactly what many of you want to hear, but from my point of view that's the way things are right now.
Thanks for reading this far and good luck.
Disclaimer: I am in no way associated with the brands mentioned in this article.
The cover image is derivated from a photo by Giorgio Trovato on Unsplash
