Me porting Runestone from UIKit to AppKit.

Currently leaning towards having separate implementations of TextView for UIKit and AppKit with shared logic moved into separate types. The alternative is a single implementation with lots of if-else-endif macros.

It makes for some duplicated logic but also means that the two implementations can easily be maintained and implemented in isolation.

@simonbs Sound idea. In practice, text views always ends up being a mess with all the different types, delegates, etc.

If you try to manage the different APIs within that code you end up breaking the iOS version while working on the macOS version, etc..

I’d just have completely separate technical implementations with platform independent code shared in platform neutral classes.

I’ve found testing and re-testing changes to be a much bigger time killer than writing separate implementations.

@frankreiff @simonbs Agreed. You have to treat the whole entire thing as a single entity, because it’s always impossible for the different delegate methods to be isolated. They always end up needing to work together in weird ways.

@simonbs I really dislike maintaining macro “if” based multiplatform code. I always try to structure my way out of it, like what you describe.

Much easier to read and reason about I think.

@simonbs Definitely sounds like the way to go. Easier to have platform specific customizations in those iOS and Mac TextViews then.
@simonbs I’d go for separate implementations too.
@simonbs I remember a WWDC talk from several years ago (from before Catalyst) about how Apple implemented Pages across iOS and macOS using the same code base. I can’t find it unfortunately, but I think they used used TextKit and text layers to implement all the juicy stuff with the actual NS/UIViews being super thin. Maybe the video is available in some dark corner of the web.