{"id":36518,"date":"2022-07-14T15:30:13","date_gmt":"2022-07-14T19:30:13","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=36518"},"modified":"2022-07-14T15:30:13","modified_gmt":"2022-07-14T19:30:13","slug":"inject-hot-reloading-in-swift","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/07\/14\/inject-hot-reloading-in-swift\/","title":{"rendered":"Inject: Hot Reloading in Swift"},"content":{"rendered":"

Krzysztof Zabłocki<\/a> (tweet<\/a>):<\/p>\n

\n

If you only used Apple platforms, you can be surprised to learn how many platforms have embraced hot-reloading decades ago. Whether you write Node or any other JS framework, there is a setup for you to use hot-reloading. Go<\/code> also offers hot-reloading (This blog leverages that feature).<\/p>\n

[…]<\/p>\n

Eight years have passed since Swift Playgrounds are still here, and they got better, but are they reliable? […] In my experience: not really.<\/p>\n

[…]<\/p>\n

Similar story [with SwiftUI Previews], it’s great when it works, but it works unreliably in bigger projects and tends to break more times than they work.<\/p>\n

[…]<\/p>\n

I recognized that Playgrounds<\/a> approach might have been too heavy-handed, so today, I’m open-sourcing. A very focused micro-library called Inject<\/a> that, when paired with InjectionForXcode<\/a>, will make your Apple development much more efficient and enjoyable!<\/p>\n

[…]<\/p>\n

Hosts leverage auto-closure, so each time you inject code, we create a new instance of your type with the same arguments as initially, allowing you to iterate on any code, memory layout, and everything else. The only thing that you can’t change is your initializer API.<\/p>\n<\/blockquote>\n\n

See also: his previous project Traits<\/a>.<\/p>\n\n

Previously:<\/p>\n