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:
DEV iOS 💖
This is the repo for the dev.to iOS app.
Status:
Released first version, more info: https://twitter.com/bendhalpern/status/1061323718058786822
Design ethos
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.
https://m.signalvnoise.com/basecamp-3-for-ios-hybrid-architecture-afc071589c25
https://signalvnoise.com/posts/3743-hybrid-sweet-spot-native-navigation-web-content
https://signalvnoise.com/posts/3766-hybrid-how-we-took-basecamp-multi-platform-with-a-tiny-team
https://www.youtube.com/watch?v=SWEts0rlezA
By leveraging 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.
Contributing
- Fork and clone the project.
- Build and run the project in XCode.
- …
But why?
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.
Top comments (41)
Somewhat unrelated, but part of the journey, was using Flutter, being impressed by the environment, developer experience, and potential, but hitting a snag and seeing that the resolution lied in a GitHub issue that had been open since 2015 with no obvious timeline for a fix.
That's a certain type of pain I've been trying to avoid lately.
I'm glad you wrote this post, as I had been wondering why you went down the Swift route. It's a shame you hit that snag. Any chance you could point to the Github issue? You got my curiousity :)
Which GitHub issue would that be?
And if it's not clear: Definitely like Flutter. If I were currently in search of a side project, I'd definitely consider Flutter bigtime. Just wanted to reiterate that since I'm talking to the foremost Darter among us.
PS would you like to moderate the Dart tag?
I was thinking on what you said below:
I've been working on a Flutter app and wanted to see if that Github issue will affect me too.
Sure, wouldn't mind moderating Dart tag
I sort of forget the context I was even in, but I believe this was the issue:
Presumably this requires some compositor work, similar to maps or video?
Towards the bottom it actually looks like progress has been made. I took this as a cue to trend more towards mature tech for a project that didn't really need Flutter.
Made you a Dart mod. Individual comment mods is still a pretty new thing, but you get access to this one additional permission: dev.to/t/dart/edit
More permissions coming as we build new features. Feel free to DM me with any questions along the way.
As the plugin for webviews is already available. I guess one can come up with a version of dev.to in Flutter.
Yes. The issues I ran into were in the details. I got enough info to conclude I wanted to go in a different direction, but others might find different outcomes.
So could you say that you rejected using a framework @ben ? ;)
Seriously, this point about 'hidden' snags buried in ancient, unresolved issues is one of my reasons to avoid silver-bullet frameworks; you want it to do that one thing... but it never will.
Admirable decision to code it up in Swift and then rely on the web to serve content. If I had a I didn't use a framework and it was fine sticker, I'd award it.
Technically you're still using a framework to build the app, and the server side app that's "wrapped" inside the mobile app uses a framework too.
I don't think building a mobile app without using any sort of framework is much of an option
;-)
You took the words right out of my mouth :)
I’ve consistently played both ends of the framework spectrum. Went with vanilla JS for the front end of the web app, now with some libs sprinkled in. But Rails for the backend, which is a framework and a half.
This is actually what Cordova does at the end of the day.
You got a problem with frameworks dude, that's the point. Take it easy.
Agreed. Cross platform tools are the worst of every option. If anybody wants a deepish dive into some cross platform talk I wrote a bit about it: gabekangas.com/blog/2018/2/why-you...
I’m a react native developer and I thought your post really touched on a big issue of choosing a cross platform solution instead of native.
I don’t agree that they are the worst of every option because sure, some things suck, but at the end of the day you can produce a nice native application for 2 platforms with 1 codebase.
I went through all the links on the repo and wow, the hybrid approach is very interesting. It speaks the same language as the idea of going back to server rendered pages instead of full on SPAs.
Effectively it gives super powers to the dev team because they can build an ecosystem of apps around the same responsive web application, with customizations when are needed and if it makes sense, go native.
It's not the solution for every type of app but it decreases the amount of work to get something in the hands of the users.
I wonder why nobody thought about it loudly before, and the entire industry went the route of building totally different apps built on the same API.
I remember observing, and being puzzled by, Android and iOS teams re-implementing the same things over and over and Flutter has probably stemmed from that. Glad there are so many alternative right now: full native, Flutter, React Native, pure PWAs, hybrid apps. Exciting times to be a mobile developer :-)
Remembering that most of us work in companies that are neither Google nor Facebook is a good thing ;-)
ps. have you considered adopting Turbolinks 5 in the future? Sam Stephenson makes a compelling argument for it but IIRC you already have something similar in place (I haven't looked that much at the frontend code for dev.to...)
Just curious, how Dev.to app doesn't break AppStore rule 4.2 (Minimal functionality)?
In short, AppStore doesn't like websites wrapped by WebView.
Have you experienced any issues regarding this?
We have not experienced this issue yet. It's my hypothesis that this is a rule designed or optimized to catch poorly implemented versions of this approach.
Our app may not be quite as snappy as pure native, but it's a pretty good app overall and we definitely make use of native niceties in all the right places.
Good to hear! Your PWA is very snappy and sometimes faster in displaing content, than some "classic" apps with REST backend. Keep up good work!
Can you share sometime is there any secret ingredient for such speed, except CDN and Turbolinks?
What kept you from building a PWA?
(full disclosure: I'm not mobile developer and my knowledge of the ecosystem is very limited)
Aren't PWAs kind of very poorly supported at the moment in iOS? Also, with Flutter becoming popular, I guess there's a sane degree of uncertainty about what will happen to PWA idea. Google is notorious for dropping such procets in favour of newer ones.
The website is already a pwa, I guess there are more plans for the mobile app
The nightmare of cross platform is the native APIs for both Android and iOS devices(IoT, Bluetooth,GPS,notification, running in background, NFC). Flutter is great for UI and performance. I'd invest more to flutter because of Fuchsia in the next 5 years. But I took a break and went back to the web ecosystem. I think the Team should invest to Flutter if the framework is mature enough to meet the needs for the team.
As for bizarre project that requires native APIs, its better to go FULL native.
It's actually kind of refreshing to see someone not choose React Native or Flutter, and bonus points for having a solid reason not to!
Nice post
Thanks!
Why not Meteor? (thought I’d ask since it was mentioned in the clickbait title ;)
Elaboration on this actually does interest me (though, from being a former Meteor user, I do remember watching the enthusiasm die down). I still like Meteor, but I moved away from it since I don't currently have a use for an SPA. Maybe it could be fun for a project in the future though.
One would think that this is a perfect case for cross-platform frameworks such as React Native or Flutter. After all, what's more simple than a webview-mostly app. If that's not a good fit for those then what is?