Progressively Enhanced Turbo Native Apps in the App Store
masilotti.com
masilotti.com
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 :)
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.
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.
[1] https://masilotti.com/turbo-ios/ [2] https://github.com/hotwired/turbo-ios/tree/main/Demo
I'm assuming once it's stable enough to leave beta, the community can polish up some proper documentation for it.
That said, it is definitely stable enough to leave beta. Basecamp and HEY have been running it for years in production.
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.
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!
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'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.
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.
I got it up and running with expo in an hour and it’s solved many problems.
...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).
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)
https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
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.
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.
bridge.webView?.allowsBackForwardNavigationGestures = true;
We just call it on startup and it seems to work.
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.
Is it me or there are way too many buzzwords in a single sentence? And "high-fidelity hybrid" is a real pearl.