Tech choices for game development can be surprisingly consequential. Smol Dungeon is written in Swift and uses SpriteKit. SpriteKit is a 2D game framework written by Apple. If you ignore the annual $100 developer account fee, it is free to use.
Choosing SpriteKit has a major downside: platform lock-in. If I were to port Smol Dungeon to Android or another platform, I would need to find an entirely new game engine. So tech choices can have serious business implications! I am okay with these tradeoffs. SpriteKit was a fine choice for my needs.
Choosing SpriteKit has a major upside: it's easy to use. You can use it with Swift, which is a programming language I enjoy using (you can also write SpriteKit games with Objective-C). It's performant, has a good feature set, and has a fairly sensible API.
Two other things I'd like to mention about choosing SpriteKit, a closed-source engine. Occasionally, you will want to tweak something about how the engine works and you will not be able to make that change directly, which can be limiting depending on the nature of the change. I am also at the mercy of Apple for archiving my game. I don't expect Smol Dungeon to be some cultural touchstone like ZELDA. Nor do I expect SpriteKit to be deprecated anytime soon. That said, it would be nice to be able to somehow archive the game in a way that interested parties can play it in 10, 100, 1000 years time. Not having access to the source of the engine makes that more difficult.
Swift is a great language for game development. Swift uses automatic reference counting (ARC) for memory management. With ARC you get the ease of developing in a managed language with very predictable performance tradeoffs. For Smol Dungeon, there are never so many entities active that the ARC tax is ever an issue.
Swift Enums are powerful and comfy to use. In the case of Smol Dungeon, enums greatly help in making sure the game state stays valid. Swift requires switches to be exhaustive, making "follow the compiler errors" quite useful when adding new enum values.