[HN Gopher] macOS code injection for fun and no profit (2024)
       ___________________________________________________________________
        
       macOS code injection for fun and no profit (2024)
        
       Author : jstrieb
       Score  : 49 points
       Date   : 2026-03-04 17:05 UTC (3 days ago)
        
 (HTM) web link (mariozechner.at)
 (TXT) w3m dump (mariozechner.at)
        
       | fny wrote:
       | I never understood how people use compiled languages for video
       | games let alone simple GUIs. Even though I'm now competent in a
       | few, and I have LLMs at my disposal, I fall back to electron or
       | React Native just because it's such a pain in the ass to iterate
       | with anything static.
       | 
       | Native devs: what are your go to quality of live improvements?
        
         | colejhudson wrote:
         | re, iteration: Have you encountered ImGui [0]? It's basically
         | standard when prototyping any sort of graphical application.
         | 
         | re, GUIs in statically typed languages: As you might expect,
         | folks typically use a library. See Unreal Engine, raylib,
         | godot, qt, etc. Sans that, any sort of 2D graphics library can
         | get the job done with a little work.
         | 
         | You might also take a look at SwiftUI if you have an Apple
         | device.
         | 
         | [0]: https://github.com/ocornut/imgui
        
         | ellg wrote:
         | what does compilation have to do with iteration speed? There's
         | a lot of ways to get a similar feedback loop that youd get in
         | something like react, like separating out your core gameplay
         | loop into its own compilation unit / dll and reloading it on
         | any changes inside your application
        
         | MaulingMonkey wrote:
         | > video games
         | 
         | Often use dynamic/scripting languages to improve iteration on
         | gameplay code, even if a lot of the fundamental underlying code
         | is native. And add dev-time hot reloading wherever we can so
         | when you change a texture, it reloads [?]immediately without
         | needing to so much as restart the level. We exile as much as we
         | can to tables and other structured data formats which can
         | easily be tweaked and verified by non-coders so we're not a
         | bottleneck for the game designers and artists who want to tweak
         | things, and make that stuff hot-reloadable if possible as well.
         | 
         | We also often have in-house build server farms full of testing
         | code, because it's such a pain in the ass to iterate with
         | anything dynamic. After all, games are huge, and sufficient
         | testing to make sure all your uncompiled unanalyzed
         | typecheckless code works is basically impossible - things are
         | constantly breaking _as committed_ during active development,
         | and a decent amount of engineering work is frequently dedicated
         | to such simple tasks as triaging , collecting, and assigning
         | bugs and crash reports such that whomever broke it knows they
         | need to fix it, as well as allowing devs and designers to work
         | from previous  "known good" commits and builds so they aren't
         | blocked/unable to work on _their_ work - which means internal
         | QA helping identify what 's actually "known good", hosting and
         | distributing multiple build versions internally such that
         | people don't have to rebuild the universe themselves (because
         | that's _several hours_ of build time), etc.
         | 
         | Some crazy people invest in hot-reloadable _native_ code. There
         | 's all kinds of limits on what kinds of changes you can make in
         | such a scenario, but it's entirely possible to build a
         | toolchain where you save a .cpp file, and your build tooling
         | automatically kicks off a rebuild of the affected module(s),
         | triggering a hot reload of the appropriate .dll, causing your
         | new behavior to be picked up without restarting your game
         | process. Which probably means it'll immediately crash due to a
         | null pointer dereference or somesuch because some new
         | initialization code was never triggered by the hot reloading,
         | but hey, at least it theoretically works!
         | 
         | And, of course, nothing is stopping you from creating isolated
         | sandboxes/examples/test cases where you skip all the menuing,
         | compiling unrelated modules, etc. and iterating in that faster
         | context instead of the cumbersome monolith for most of your
         | work.
        
         | chuckadams wrote:
         | Having a faster build step helps: I just stepped back into C
         | recently, and I don't even want to imagine doing it without
         | ccache and meson.
        
       ___________________________________________________________________
       (page generated 2026-03-07 23:00 UTC)