We started working on an iOS app a little while back and just released a basic-not-totally-functional-but-usable Beta app yesterday.
This was an open source community effort. I sort of led the way early on by providing some initial direction, but then we let folks better than me take charge of the project.
But I did come in with the high-level technical direction. This could never have happened if I didn't at least have an opinion on what technology and architecture to use. We went with, what I would call, the "Basecamp Approach". Native shell on top of web views.
I included a link to resources from Basecamp in our repo:
This is the repo for the dev.to iOS app.
Released first version, more info: https://twitter.com/bendhalpern/status/1061323718058786822
We will grow to include more native code over time, but for now we are taking the approach of native shell/web views. This approach lost favor early in iOS days, but I believe it is a very valid approach these days. It is inspired by how Basecamp does things. Our tech stack is a bit different, but the ideas are the same.
wkwebviews as much as possible, I think we can make this all pretty awesome and sync up with our web dev work pretty smoothly. And where it makes sense, we can re-implement certain things fully native, or build entirely native features. Life's a journey, not a destination.
- Fork and clone the project.
- Install Carthage. If you use Homebrew…
React Native and Flutter and others are good options. But I felt like even with the cross-platform benefits of view-creation on these platforms, we're still fundamentally having to reimplement efforts from the web on native and coordinate every change brutally synchronously. We could overcome this with a lot of hard work and orchestration, but we'd always be fighting an uphill battle.
In order to keep leveraging the best of the web, keep our build velocity high, and ultimately maintain way more optionality, we took the approach we did.
I have used React Native and Flutter and think they are the right choice for a lot of types of projects, but really not this one. I've gotten the "why not" question literally just about every time this topic comes up. So here’s the answer: we're building a pretty simple native wrapper on top of a capable, and always improving, web application. Phones are getting faster, the web is getting stronger. This was a good choice. Any downside is a necessary tradeoff.
I don't know what the future holds, but in a field of constant uncertainty, I feel like our position is currently pretty well hedged.