Because Everyone is Interested in Hex Coordinate Systems
One of the considerations talked about in implementing hex grids is storage strategy. An easy part of the answer is to use key-value storage for implementing the grid, the more complex wrinkle in an Apple-provided language is deciding on what value type to use as the key.
My first pass at the code I used a tuple with (x:Int, y:Int) as the key. I later decided to use NSIndexPath in hopes that it will make life easier tying in with Apple APIs later. That added some strange conceptual overhead with a mismatch from col/row and section/row when writing code in practice in tests. This means I wrote a custom constructor extension on NSIndexPath to simplify creating values, and generally adds some small bits of cruft to the code. I’m contemplating if it’s worth the effort to write a custom struct to store coordinates, and then I can add a toIndexPath() -> NSIndexPath function if I end up needing to represent the cell coordinates as index path values in the future.