SwiftGenKit for iOS, and maybe tvOS and watchOS

[atfelix]

I need to write some localization tests to ensure that our pluralization files have the same placeholders as our base localization. I would like to use the parsers provided in SwiftGenKit but currently the SwiftGen package is only available on macOS 10.11 or later. I see two potential solutions:

1. Expand the platforms to include iOS and maybe tvOS and watchOS
   • Investigation notes: I think there is a symbol used in one of the related files that currently prevents tvOS and watchOS. iOS was mostly changing import AppKit to import CoreText or adding a type alias for NSColor.
   • Tradeoff: This approach seems easier in terms of code change but it would also expose SwiftGenCLI and swiftgen to the additional platforms, which may create more availability checks throughout the code
2. Create a separate package for SwiftGenKit
   • I don't know how much effort this solution would require

[djbe]

I think you misunderstand the Package platform definition. The tool SwiftGen will only run on your macOS device, but it will generate code for all 4 platforms (iOS, macOS, tvOS and watchOS). SwiftGen is not meant to be included in your app(s) at runtime, it's meant to (pre)build them.

I'd also strongly recommend not using SwiftGenKit for "checking" at runtime if your strings files or other resources are OK. You should be checking all of this at build-time, not run-time.

There are dedicated tools for checking your strings files, such as POEditor (online platform), or local tools such as BartyCrouch.

[atfelix]

I think you misunderstand the Package platform definition. The tool SwiftGen will only run on your macOS device, but it will generate code for all 4 platforms (iOS, macOS, tvOS and watchOS)

Do you have documentation for that? Also, SwiftGenKit won't compile on iOS because of AppKit usage.

SwiftGen is not meant to be included in your app(s) at runtime, it's meant to (pre)build them.

It's not for the app. It's for tests to ensure new translation's placeholders match the base translation. SwiftGenKit parsers provide that functionality.

There are dedicated tools for checking your strings files, such as POEditor (online platform), or local tools such as BartyCrouch.

Strings files aren't the issue; Stringsdict files are, which are much harder to parse. I don't see support for stringsdict files in POEditor and BartyCrouch.

[djbe]

Docs about what the purpose of SwiftGen is, and for which platforms it generates code? Have you tried reading the VERY extensive documentation? Here and here for example.

It's not for the app. It's for tests to ensure new translation's placeholders match the base translation. SwiftGenKit parsers provide that functionality.

Those tests should not be running on-device, but on your Mac.

Tools…

For those tools you're usually working via export/import to XLIFF files, which tools like POEditor and others DO support. If you think a tool (like BartyCrouch) should support stringsdict, then please create an issue there.

[atfelix]

Docs...

I misunderstood your statement. I thought you were claiming SwiftGenKit will compile for the other platforms.

Those tests should not be running on-device, but on your Mac.

The tests run on a Mac but with an iOS simulator, so an iOS SDK. So SwiftGenKit will not work in the iOS test target on an iOS Simulator.

[djbe]

As I mentioned before, even if you write "tests" for these, the tests should be running on macOS. Honestly I'd never write tests for these, tooling outside your project should be responsible for this.

Couple of examples from SwiftGen itself:

• We have unit tests for multiple parts of the tool (parser, generator, CLI, …)
• Outside of those tests, we have certain verification steps that are NOT in the project:
  • Checking if changelog is ok
  • Checking if versions are ok everwhere
  • Checking if our generated output compiles
  • Checking if all our code conforms to certain linting rules
  • …

Only a small subset of these checks are the actual unit tests in Xcode. All the rest is run outside of it, for example using commit hooks on each commit/push, or by our CI for each PR/branch/…. Some of these could be checks placed in build phases of your project, up to you. But not as actual unit tests 🤷