We started working on an iOS app a little while back and just released a basic-not-totally-functional-but-usable Beta app yesterday.
...
For further actions, you may consider blocking this person and/or reporting abuse
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?
Why did you even need native apps when DEV.to is PWA?
iOS support for PWA is π€’
Makes sense.
Why and what makes you think that it's time for a native mobile app? Web app does not fit the purpose anymore?
The webapp fits many purposes and weβre still web-first. But there are some niceties or native apps you just canβt get on the web, especially in iOS-land.
Anything in mind for dev.to specially? I can't think of anything at the moment
I love a lot the pwa aspect of it
It's curious that this isn't very different of what Cordova does. The problem with Cordova it the fact that it's dying slowly...
Who put that in your head? Cordova has had more funding and support right now than it ever has before.
Sorry @ben to get out of line here.
@markhust funding and support? Maybe, I can't tell, where can that be seen?
What I can see it inactivity, mainly on community plugins. The problems I face nowadays is deprecated plugins and not updated to match new platforms. See for example cordova-android, it's was updated to v7 a year ago, but practically can't be used since plugins are not compatible with some major changes introduced.
Ionic is an exception, but looking at the new capacitor project looks like they are looking for an alternative to Cordova.
That is true.But you still can use Flutter for Android only dev.It will reduce your dev time considerably.
I feel that the app is well-built in terms of responsiveness to pull this off.
Does this philosophy apply? Don't fix what is not broken I think it comes down to prioritization, time, resource and long term goals, and maintainability when deciding on a technology stack.