This does generally work, but it requires a lot of manual effort to setup the environment correctly with Xcode's SDKs to satisfy the compiler / linker.
Also a mac mini is £700 which is the equivalent of ~3 days work for most trades here in Britain. I you value your time as much as a joiner and if it’s going to take you more than 3 days to get your environment setup and keep it maintained then you’re better off just buying a mac.
I work in games for a fully remote company. a Mac mini takes ~5 hours to compile and cook (read: prep the assets) for our game. It's not reasonable to ask someone to have that mac at home, and even if it was, you have to have it somewhere where it's available, has high speed internet, and that person is responsible for the hardware - making sure it stays on when it's needed etc. That person also needs to deal with any hardware failures/ warranty replacements. Instead, we could lease a mac from AWS for £20 for a day, run a build and use that.
That doesn't mean that this is a scalable solution for running our business on, but for the occasional one off mac build to make sure it's not fallen behind, it works just fine for us.
The difference between $20 per day and $2.40 per day at our current scale is practically 0 - we do a build every 2 weeks or so. We would save $500 a year on our current scale, which is likely less than it would cost in my salary to set up a scaleway account, spin up an M1 instance and configure it. Definitely worth it if/when we look at having more machines up and running though, thanks!
In some other countries I have seen an iMac been shared across teams that would take turns at the device.
In Germany I would state the same statement, we live between Windows and macOS on the office, but I also have some care for those that aren't so lucky.
Plus, I’ve found that most iOS codebases, tend to rely on parts of Foundation and the Objective-C runtime that are not implemented on Linux, even if the code doesn’t touch UIKit at all.
In this case I meant taking an approach similar to this one for bazel[0] that is not limited to only code that works on Linux. It would only allow you to build on Linux and would require any testing / running would still happen on macOS, but that might still be worth it in some cases. Theoretically you could deploy your iOS app that way as well.
The feature could be a workaround for a bug. That is, one of their internal services didn't handle being blocked well, and instead of fixing that service they just added that feature as a temporary workaround to make sure the new firewall functionality didn't break any important/core features of MacOS
I'm not saying this is what happened, but without actually knowing what happened we can't assume the intention was to exclude everything in this list forever either.
There's no link because the tweet was deleted soon afterward. The tweet seems to have been very ill-advised.
I don't know how anyone can describe this as a "bug", because as the linked article describes, there's an explicit "ContentFilterExclusionList" in the Info.plist file with a list of the specific Apple services excluded. That's not by accident, it's by design.
I don't think I'd call it a bug. It's a poor decision. I can easily believe that it wasn't a decision made with malicious intent; the culture at Apple seems (at least from the outside, judging by results) to encourage an "it's okay to give our own software special exceptions" mentality.
"The bugs were related to Apple deprecating network kernel extensions (NKEs) in Big Sur and introducing a new system called Network Extension Framework, and Apple engineers not having enough time to iron out all the bugs before the Big Sur launch last fall."
> The entire pbxproj format is horrible, but at least you have stuff like BUCK (https://buckbuild.com/) that can mitigate some of that.
FWIW I'm still not sure what the BUCK workflow is suppose to look like for most teams. It seems like if you use BUCK you're expected to not use Xcode even as an editor, yet there isn't another editor to pick up the slack (assuming you want autocompletion and decent highlighting). I think there's still a lot of work to be done for it to be a viable replacement, even for Objective-C, for Swift it's even further away.
The videos from many WWDC sessions are altered. So even if you got the right session it may not have this. I've been in sessions where much less interesting this have happened that haven't made it in to the video. Also last WWDC they started pre-recording sessions so they could be up on the web sooner. Many of the video sessions from last year don't have any audience noise and differ significantly from the live session.
One really nice benefit is that you don't have to duplicate any type information. Once you define your model with the data types you expect, mapper infers those types and converts the JSON values accordingly. It seems like with SwiftyJSON (which I haven't used) you have to duplicate this by calling things like `.stringValue` etc.
Interesting, i'll have to give it a shot to see how it works. Any plans to provide integrations for something like alamofire? If I could abstract all of the work to a special response handler i'd definitely switch over
