Add C# data provider support for macOS

[lyonsil]

To decide:

• Which macOS versions to support? Paratext Lite supports Monterey and Ventura. We will need dev/test machines available for each.
• How do we want to handle Unicode support? ParatextData requires ICU.NET now which relies on icu4c libraries. If we don't change ParatextData, then we need to figure out how to get icu4c onto macOS. Microsoft builds some for Windows and Linux, but not macOS. Homebrew has prebuilt icu4c binaries for some macOS versions. Also, ICU.NET will require some updates.

Regarding how Paratext Lite handles this:

Paratext Lite doesn't use icu.net. Paratext Lite has its own really basic LdmlAdapter. Paratext Lite on MacOS shares a lot of the code with the Android version and currently uses the same approach.

Additional resources of interest:

• https://learn.microsoft.com/en-us/dotnet/core/extensions/globalization-icu#macos-behavior
• https://sil-language-software.slack.com/archives/C805N00N8/p1687190320705099
• https://unicode-org.github.io/icu/userguide/icu4c/build#how-to-build-and-install-on-unix
• https://formulae.brew.sh/formula/icu4c

[lyonsil]

Here is some Q&A from Marc Durdin: (Q's from me, A's from him)

---

• How important is it to develop on and target each OS release? Is it reasonable to target specific ones that generally would cover others? Is it most important just to target the newest one? If there are tips/suggestions for where to find market share and usage for different countries and demographics, that would be helpful.

It is difficult to support older versions of iOS and macOS -- Apple deprecate their tools very rapidly, so after a few releases, it becomes nearly impossible to build for the older versions (unless you maintain old build agents with older versions of operating systems to run the older versions of the development tools -- and have separate builds for the various versions). Thus, older iOS/macOS devices are not very useful because they cannot run most software. Generally, we aim to support the latest few releases, and do best-effort for older ones on macOS, where we are not on the App Store. On iOS, we only support the versions supported by App Store deployment (v12+ right now for example). We don't have any good data on market share and usage.

---

• Are there reasonable shortcuts that work for macOS development? For example, if we have a Linux version of software that works, is there anything that would easily run a Linux VM similar to WSL on Windows?

Not really. VMs on macOS are not a great user experience. You'd be better running Parallels and Windows than attempting a Linux VM. We do Linux VMs as developers, and they're a pain to manage. And, you'll alienate a majority of macOS users who prefer to use vanilla macOS. You can target Java or some other cross-platform framework, but it makes for an ugly macOS experience, which is difficult because the users of macOS demand the greatest level of consistency with the platform look and feel. tl;dr: you need a native macOS version.

---

• If we're working with C# and Typescript generally, is VSCode sufficient for development, or are we going to find it hard to work without Xcode?

You will find it hard to work without Xcode -- I personally do all my coding in VSCode when doing macOS work, but anything that involves UI or project management / deployment, etc, kinda requires breaking out Xcode. There are whole industries developed around not using Xcode (e.g. fastlane tools) but they constantly require maintenance because a lot of the infrastructure they work with is undocumented.

---

• How hard is it to publish to the Mac App Store? Is it better to just assume we will side load apps?

Keyman can't be published to Mac App Store because it uses keyboard hooks, which are not permitted. We sideload, and frankly it's probably an easier experience to have your own installer. Most significant apps are available as standalone. So it's probably not a big blocker for users.

My perspective on the App Stores is that they are great for Apple, and offer some benefit for end users in terms of safety, but they are an opaque experience for developers -- we have wasted huge amounts of time dealing with App Store infrastructure issues.

---

• How have you worked with ICU libraries on macOS? It seems that Apple doesn't provide all the icu4c libraries by default, but I see some builds available from Homebrew.

We haven't used the ICU libraries on macOS.

Note: although iOS and macOS are our two smallest platforms in terms of userbase, they are the most work for maintenance for us:

• Apple keep us on the upgrade treadmill on their timetable -- e.g. regular requirements to update to latest xcode to continue publishing to app store, which requires upgrade to macOS to install, which forces us to stop supporting old versions of iOS, macOS. (This also means we can't publish updates to old versions of our apps because we can't build with newer xcode without lots of work!)
• Apple's App Store, code signing, and notarization servers regularly fail, without warning, and break builds.
• Apple's documentation is generally poor quality and inconsistent.
• App Store review processes are fairly arbitrary and every now and then we get a build which fails review (despite not changing anything!) and we have to stop our regular work to address the issue.

[FoolRunning]

I must say that all of that is not encouraging. 😖

[hatton]

For what it's worth I publish the electron app lameta for macs using only vscode, but that's typescript only. I don't publish to the store, but I do have to sign and get the notarization. Apple completely changed this last month, and I found getting the electron app notarized in the new system to be quite a puzzle for lack of documentation. Eventually got it working, so that github action yml may be of use as a reference: https://github.com/onset/lameta

[hatton]

Also, Marc was talking about an app with native UI. If you're doing electron, in my experience,

• Once everything was running on mac, it just kept running. Now I just run some automated UI tests before release.
• Newer versions of electron have a minimum supported mac OS version, so you have to watch that.
• I don't recall ever running xcode.

[katherinejensen00]

Unit testing will look like reenabling unit tests that didn't work on mac before.

[lyonsil]

Discovered a bug in the icu4c library causing test failures. We need to try rolling back to an older icu4c build on macOS if they are available to avoid these errors.

[lyonsil]

Turns out that wasn't a bug in icu4c but a bug in icu-dotnet's handling of UnicodeSet data.

[lyonsil]

sillsdev/libpalaso#1327

[lyonsil]

sillsdev/icu-dotnet#198

[hahn-kev]

@lyonsil I'd be interested to know where you settle on getting the mac native icu4c library from for Paratext, I just ran into the Microsoft nuget package that has windows an linux binaries, but wasn't sure what to do about mac.

[lyonsil]

@hahn-kev We haven't sorted it out yet, but as a first cut I'm assuming we will lean on MacPorts (which is what we are using in the macOS builds for icu-dotnet's GitHub build actions). MacPorts has both binary and build from source options available. Presumably we can bundle a universal build of icu4c libs into the platform installer for macOS.