5 ms·

Can you elaborate? Since I mostly work on macOS stuff, I don't understand the workflow that leads to needing this sort of tool. What's the process of writing so

Can you elaborate? Since I mostly work on macOS stuff, I don't understand the workflow that leads to needing this sort of tool. What's the process of writing software for either macOS or iOS that doesn't involve needing macOS or iOS at some point? Like you probably need to test on those systems if you're supporting software for them, right? Is it because development is done on Linux, and only testing is done on, say, macOS? Sorry if this is a stupid question. I just haven't run into this sort of situation before and am trying to better understand it.

bogwog 4y ago
There are a lot of different reasons a project would want something like this. In general though, I think the most common is CI and build automation. Currently, build automation for Mac requires doing some shady stuff with VMs, or renting or buying and maintaining a physical Mac. Being able to do everything on Linux vastly simplifies the infrastructure needed to support that. Even if you're just writing standard native apps with Xcode, being able to build, test, and deploy your app every time you push to the production branch in your Gitlab/Github repo is valuable. With codesign on Linux, you can build that on top of a simple, ~5mb alpine linux container.
- dwaite 4y ago
  > I think the most common is CI and build automation Common practice for CI is to actually run tests, though. How would you validate your macOS/iOS builds are functional without still requiring VMs or real hardware?
  - 90minuteAPI 4y ago
    If those instances are only for tests/validation it could simplify some overall pipelines quite a bit.
  - the_gipsy 4y ago
    That doesn't justify the build part.
  - jtdressel 4y ago
    You could use this in addition to regular macOS machines. You can run tests from un-trusted branches, without worrying that something will expose the signing keys. Then after merging, you have a second machine / set of machines that only does signing. It increases the difficulty of an accidental or intentional leakage of your sensitive keys. (Note: I have not tested this yet)
  - halbersa 4y ago
    We have a pool of MacOS hardware to run tests, and another pool to perform signing. The latter is a security risk so very tightly controlled and locked down. They are a pita to maintain. Being able to sign on Linux will allow us to re-use the existing signing infrastructure we use for literally every other platform other than MacOS. It'll be more secure and much less maintenance.

bogwog 4y ago

There are a lot of different reasons a project would want something like this. In general though, I think the most common is CI and build automation. Currently, build automation for Mac requires doing some shady stuff with VMs, or renting or buying and maintaining a physical Mac. Being able to do everything on Linux vastly simplifies the infrastructure needed to support that. Even if you're just writing standard native apps with Xcode, being able to build, test, and deploy your app every time you push to the production branch in your Gitlab/Github repo is valuable. With codesign on Linux, you can build that on top of a simple, ~5mb alpine linux container.

dwaite 4y ago
> I think the most common is CI and build automation Common practice for CI is to actually run tests, though. How would you validate your macOS/iOS builds are functional without still requiring VMs or real hardware?
- 90minuteAPI 4y ago
  If those instances are only for tests/validation it could simplify some overall pipelines quite a bit.
- the_gipsy 4y ago
  That doesn't justify the build part.
- jtdressel 4y ago
  You could use this in addition to regular macOS machines. You can run tests from un-trusted branches, without worrying that something will expose the signing keys. Then after merging, you have a second machine / set of machines that only does signing. It increases the difficulty of an accidental or intentional leakage of your sensitive keys. (Note: I have not tested this yet)
- halbersa 4y ago
  We have a pool of MacOS hardware to run tests, and another pool to perform signing. The latter is a security risk so very tightly controlled and locked down. They are a pita to maintain. Being able to sign on Linux will allow us to re-use the existing signing infrastructure we use for literally every other platform other than MacOS. It'll be more secure and much less maintenance.