I've launched 3 Turbo Native apps to the iOS and Android stores. I found it 80% awesome, 20% frustrating. Of that 20%, some was bugs or missing features in the frameworks, many of which have been resolved.
But mostly it was because expectations not matching reality. When I first heard about Turbo Native I read the pitch as "write all your app on web, and get native free". (Maybe that was my optimism.) In reality you really do need to think about native all the time. You can do your development in the browser, but for almost any app you'll need to at least test in the simulator, and you should test on device. Also, you will have to write native code at some point.
This is not a problem if you have native developers on your team, or if you want to learn Kotlin and Swift, or if you work with a consultant like Joe. It is a bummer if you want to make the one-person app that Rails always talks about. For me the frustrating thing was that I wasn't using these languages often - I wasn't writing native code every day. So when I did need to write/debug native code, half the time was spent remembering how Swift is different to Ruby and how to use Android Studio.
All that said, I still think Turbo Native is a game changer for B2B apps. It's much better than writing 2 native apps from scratch. It's just not a silver bullet!
I also think for a long time the governance of the native projects wasn't ideal, in the sense that it was just whoever at Basecamp had some time to work on it (mostly Jay Ohms - thanks Jay!!). It's exciting to see that Joe has been made a maintainer - well earned, and hopefully it results in some more issues being closed and PRs being shipped :)
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.
Mostly I found Turbo Native is lacking a good minimal walkthrough from rails to shipping on android/ios. To me, looking at it from afar, it's entirely unclear the how much native dev is required to make it even walk.
It's not official, but I have a series of blog posts on going from zero to App Store. [1] You are still required to write a fair amount of native boilerplate code to get an app working. The official Demo app [2] can get you pretty far but doesn't cover things like authentication.
I've recently become an official maintainer of the Turbo Native libraries and hope to help clean up all of this over the next few months.
Yeah, Turbo Native has a lot of Rails-style magic (which is great), but doesn't have a similar Rails-style level of good documentation yet (which is not so great -- discovery and troubleshooting is painful at the moment)
I'm assuming once it's stable enough to leave beta, the community can polish up some proper documentation for it.
Agreed. There is a good amount of boilerplate needed to get a basic app setup. I hope it becomes a bit more "Railsy" with some Omakase-style conventions chosen. Right now, it's left up to you to implement multiple sessions, even though 95% of apps will want this. Auth feels like another area where there's a happy path that'd cover the 95% case, but it's currently left up to you to choose / implement using cookies vs tokens vs ???.
That said, there is a decent amount of documentation around these things, and even as a relatively ignorant Swift programmer, I was able to copy/paste from the docs, and get an application working reasonably well.
That's awesome to hear you were able to get something working.
And yes, 100% with you on this one. It's a very non-Rails like experience going to Turbo Native. You have to configure everything pretty much on your own and are left to figure it out by yourself for new things.
One of my goals is to fix this in the near future!
Although in the case of authentication, Rails has dropped the ball for over a decade on providing an out-of-the-box solution. Practically everyone uses Devise.
Even though the maintainers have pretty much said to use anything else!
I'm guilty myself. I know how Devise works, including all of its quirks, so I refuse to learn something new. I don't think Rails will ever have a built-in authentication solution. But I would love to see more official support for something a bit "lighter" than Devise. And that works out of the box with Turbo.
I believe the maintainers regard authentication, rightly or wrongly, as a business-level feature. Not so much the mechanics of checking a user's credentials but how you want to steer the different authentication flows.
Ayush does a great job diving into both iOS and Android apps in this book. It's also a great resource for Hotwire in general. I learned a ton and agree with 95% of the Turbo Native content he wrote.
If you're a SwiftUI developer I have an issue open at https://github.com/hotwired/turbo-ios/issues/8 to get Turbo SwiftUI off the ground. I have it working in one of my projects, but I'm not a Swift developer so it's pretty much a hack job and doesn't have the APIs I'd like.
I've talked to a few folks about it and have heard responses ranging from "it's a bad idea/can't be done" (mainly because of SwiftUI bugs) to "why would you want to do that?". I think it would be amazing to have a declarative of building out a Hotwire Rails application inside of iOS. Bonus if the Turbo SwiftUI component could run on macOS.
Thanks! It's fun to see how folks are taking advantage of specific native features.
And the Hotwire stack on web is pretty darn powerful. Being able to make live updates and add interaction with minimal JavaScript? And I can keep writing more Ruby? Count me in.
> you can push an update to your website and your mobile app gets new features for free
...has Apple changed its stance on adding features without going through review? I thought that's prohibited (because at least for games that's a big no-no).
Of course, but it's about features that slip in through the web page (for instance via Javascript).
Technically, you're not allowed to ship games which then download interpreted Lua scripts which change or add features to the game for instance. You'll have to release an update through the App Store instead.
(unless Apple has relaxed this rule of course, I haven't checked for the last 4 years or so)
Strada is an unreleased part of Hotwire that's been delayed a few times. But you can still build great hybrid apps without it. The library really only cleans up some code and removes boilerplate around the integration.
I've shipped a PWA to the iOS App Store wrapped inside of Ionic. The single biggest problems on iOS with PWAs shipped in this fashion is the swipe-back navigation doesn't work. There's CSS page transitions, but those aren't the same as Apple's navigation stack controls.
That's not to say PWA's can't be successful! I've found the opposite is true — that Ionic app I referred to early had an App Store rating of 4.8 stars by thousands of reviewers. I wish more people knew this secret.
If you use Capacitor, it’s actually pretty trivial to enable swipeback navigation. All you have to do is write a very simple plugin that sets an option to true on the web view instance. I don’t remember the exact name of the flag, but I can report back with more details tomorrow, if you’re interested.
I was and am responsible for setting up a fairly large Vie app as a PWA with capacitor and I’d say it’s been a mixed bag. The dev experience is not great, but to be honest I blame iOS and macOS for that just as much as capacitor. Sometimes stuff just doesn’t work, and the community libraries to use native features are missing obvious stuff. For example, the capacitor library for working with iOS push notifications is a complete mess, and it’s missing some very basic features, like managing badge numbers in an even slightly sane way.
I dunno if you've tried this yet, but if you follow the basic Capacitor plugin guide, you can make an objective C function that calls this to enable it.
One of the best things about Turbo Native is that it is built ON TOP of UIKit. So you get those native navigation animations, including swipe-back, for free.
Also, most folks refuse or don't know how to add a "web app" to their Home Screen. Launching in the App Store gives you visibility in both discovery and every day browsing.
The separate technologies are called Turbo, Stimulus and Strada, together forming Hotwire. The webpage [0] even looks like they were going for some kinda late-80s synthwave-y aesthetic.
But mostly it was because expectations not matching reality. When I first heard about Turbo Native I read the pitch as "write all your app on web, and get native free". (Maybe that was my optimism.) In reality you really do need to think about native all the time. You can do your development in the browser, but for almost any app you'll need to at least test in the simulator, and you should test on device. Also, you will have to write native code at some point.
This is not a problem if you have native developers on your team, or if you want to learn Kotlin and Swift, or if you work with a consultant like Joe. It is a bummer if you want to make the one-person app that Rails always talks about. For me the frustrating thing was that I wasn't using these languages often - I wasn't writing native code every day. So when I did need to write/debug native code, half the time was spent remembering how Swift is different to Ruby and how to use Android Studio.
All that said, I still think Turbo Native is a game changer for B2B apps. It's much better than writing 2 native apps from scratch. It's just not a silver bullet!
I also think for a long time the governance of the native projects wasn't ideal, in the sense that it was just whoever at Basecamp had some time to work on it (mostly Jay Ohms - thanks Jay!!). It's exciting to see that Joe has been made a maintainer - well earned, and hopefully it results in some more issues being closed and PRs being shipped :)