Joe Masilotti

If your like this approach to building hybrid native mobile apps, I highly recommend following Joe Masilotti at https://masilotti.com/ I only read three emails newsletters, and Joe’s is one of them because it’s roughly once per month and it keeps me current on all the things happening with Hotwire and Turbo Native apps.

Turbo Native in its current form requires a fair amount of iOS knowledge (and code!) to get working. I'm trying to fill that gap with my blog, workshops, and live streaming sessions. [1] But it's no excuse for what this library could be if we invest more time into it. In an ideal world the library handles 90% of the boilerplate required to make an iOS app work. I'm talking authentication, pushing/presenting controllers, sensible defaults for Path Configuration, etc. All the stuff that I have to add to every single Turbo Native app I work with. (12+ since I last counted.) Then devs can focus on differentiation and exciting features like push notifications, native integrations, fancy animations... while the core of the logic remains on the Rails app. I'm hoping that getting more maintainers (like me!) on the repo will help kickstart this. And I'm excited to see more interest on both HN and Twitter in the framework. [1] https://masilotti.com

Not a coincidence, he's someone who's writing about hotwire a lot: https://masilotti.com/hotwire-native/

I'm a rails dev too, last year I was making a mobile web app where I was concerned about frontend, so I started making a SPA in mithril.js and using Rails as the API. Later I abandoned the SPA and went back to rails views, using turbolinks to make it fast. In reality rails + turbolinks is fast enough for most cases, and then I can sprinkle in extra javascript or use SPA on one or two pages as needed. The reason I think it's almost better to avoid SPA + API approach is to keep the codebase simple and easier for one person to maintain. https://www.youtube.com/watch?v=SWEts0rlezA http://masilotti.com/beermenus-and-turbolinks/