Craig Hockenberry • Iconfactory
This post will explain the technology behind Project Tapestry and how we tested it as a prototype. We’ll keep this discussion at a fairly basic level: if you’re a web or app developer, you’ll have no problems following along.
And if you think I’m going to describe RSS feeds now, think again! We’ve come up with something completely new.
I’m excitedly looking forward to seeing the final product and I hope they make their stretch goal of bringing it to the Mac. 🤞🏼 Please, go read about Project Tapestry, and if you’re so inclined please support their effort. I backed them early, it was a no brainer for me.
I really wanted to talk about the choice the Iconfactory made to create a highly extensible platform for plugins. It’s a darned great idea! And I love their choice of pushing network requests through Project Tapestry itself as a way to guarantee plugins can’t phish out user data or credentials to exploit later. 👍🏼
The project I’m currently involved in is an existing eight year old iOS application built with a mix of UIKit and SwiftUI. On the flip side the Android app of the same age is built using Java and Kotlin with a mix of the original XML based UI and modern Jetpack Compose. They’ve both taken very similar and not unexpected paths.
Enter React Native
Something our client wanted to do is integrate React Native into the existing applications. This has been done before by Airbnb and more recently by Shopify. Each with very different outcomes.
So all of that to say, ours has been successful, in my opinion. We’ve been able to fully integrate React Native and carve out a little set of API’s in the native application we expose to the React Native developers to do work the native application is already doing for them for free. Part of which is all the networking calls.
Over the course of our integration work I’ve done a smidge of TypeScript code to allow other TypeScript devs on the team to make calls into the APIs we’ve exposed in the native application.
Project Tapestry is BETTER!