Hotwire Native: An Early Review
All new tech is wonderful and full of magic… until it isn’t. It’s only when things aren’t 100% right that a technology shows it’s full set of colours. This is my, very early, review of Hotwire Native.
The Pros
For my projects, Hotwire Native has largely delivered on it’s promise of coding for the web, and running on device.
Bridge Components worked very well for web to native communication and felt very Rails-y to me. Adding fully native screens with ViewControllers/Fragments worked very well.
I have experience with completely native Swift apps and making this app felt very natural. The Android app was a challenge, but that was mostly about understanding the platform and would have been true for a completely native application.
Cons
The only framework bug I think I ran into is related to lifecycle events on Android. It looks like returning from a camera capture session is considered an application switch (cause it is), which causes the activity to be recreated, which recreates the WebView, which resets the form that initially asked for the camera. I believe this to be a bug on my part or the framework that I still look to address.
The only other issues I ran into I easily worked around:
- Path configuration settings is a full JSON object on iOS but only a String to String hash on Android. Joe Masilotti recommended adding the stringified object as the value and parsing it out. I’ve done that for now but I think this should match iOS
- There are a few API differences. iOS has a navigation delegate that is called when a visit is proposed. Android doesn’t have a similar API.
Review
Overall, I give Hotwire Native a solid A- rating. t’s just a few minor tweaks away from being a solid A+ framework. I am very happy with how the application worked out and look forward to improving it moving forward.
Looks like I need to go make a few PRs…