32 ms·

Lessons learned from migrating a native iOS app to Flutter

231 points by PanMan 5y ago

deleted 5y ago
[deleted]
K0nserv 5y ago
I was heavily involved with the rollout and maintenance of React Native(RN) at my previous job. This post touches on an interesting point that has just now crystallised in my head. In particular the OP writes: > Fortunately, I could find the bug in the library with my Swift skills, fix it within a day and even submit a patch to the owner of the repository. But I could find and fix it only because the library and my app were written in the same language, and this was a language that I was familiar with. We adopted RN because we had a lot of web developers(hundreds) and wanted to enable them in contributing to our app. We explicitly didn't make it a goal to achieve code sharing, yet we did, to the tune of 90% of the code. Overall RN was successful for us. However, one thing became apparent immediately: the RN developers needed support from native teams. As soon as the RN developers hit a problem that required bridging native APIs or a bug that required platform knowledge, they end up blocked with no way to unblock themselves. Luckily we could create a team of platform experts dedicated to supporting these developers. This highlights the unfortunate paradox with cross platform tech. It's a great choice for solo developers or small startups looking to find product market fit and iterate quickly. They might be fooled into thinking that they can get by without learning the platform native methods and languages, only to find that they end up stuck when the leaky abstraction eventually leaks. On the other hand, a well resourced company that can dedicate a team of platform experts as support for the cross platform developers will not suffer this problem, but is cross platform the right choice for a well resourced company? Such a company has probably already found product market fit and is better of paying the higher cost of native development to build a higher quality app. A big takeaway from my RN experience is: One might expect that an RN developer can get away with knowing less about mobile than a native developer. Counter-intuitively, the opposite is true. A solo RN developer will, of course, need to know JS and React, but when the abstraction leaks they'll also need to be comfortable with Java, Kotlin, Swift, Objective-C, the respective build systems(CocoaPods & Gradle), and even C++. If one considers RN's origin, being an internal Facebook framework. It all makes sense. RN was built to allow more developers at Facebook to contribute to their apps, without requiring them to learn native technologies or languages. Of course, Facebook has the best imaginable team to support these developer, the RN team itself.
- je42 5y ago
  This totally true. I think however, Flutter does a better job in fixing platform related issues. Also, in my experience upgrade to a new version of RN was usually very painful, with Flutter so far it was straight forward.
- nicoburns 5y ago
  I think the way to set it up is to have the senior engineers on your RN team be the ones who know everything: they are experts in JavaScript, but they are also comfortable dropping down into Swift/Objective-C and Kotlin/Java when needed. Then you can have junior engineers who are more focussed on the JS side of things (at least to begin with). They key thing here being that the people who can unblock are on the same team as the people who may need to be unblocked and can thus prioritise doing so quickly. If you need extensive native code for custom modules (we haven't yet needed this at my work) then it would make sense to have native developers on each platform take a lead of that. But there should absolutely be people on your RN team who can do integration work and bug fixing independently of that team. I think the key is: if you're working with cross-platform tech then you ought to have cross platform developers.
  - K0nserv 5y ago
    Absolutely, but this speaks to the paradox I think. Cross platform is an attractive choice, precisely when you don't have a such a person. For example, as a solo developer with no native knowledge who wants to ship an app or a small startup hiring their first mobile developer. Being proficient in all of Web(JS, React), Android(Kotlin, Java, Gradle), and iOS(Swift, Objective-C, CocoaPods) is a pretty significant ask for a single person too. Personally, I check two of those boxes(iOS and Web), adding Android as well would be a bit much.
    - nicoburns 5y ago
      Hmm... I don't necessarily think it needs to be a single person knowing everything. For example a team made up of you, someone else who knew android and web, and a bunch of people who only knew web would work really well I think. Those who were experts in the native platforms would be responsible for bringing the rest of the team up to speed (providing context, advice, pointing to learning resources, etc). As someone who came to a react-native project (as the lead) with a web and cordova background and no prior react-native or native platform experience, I've found that just knowing about the ios and android build systems and being able to add basic code to the AppDelegate (ios) and MainActivity (android) has been entirely sufficient for our needs. It would be different if we needed custom native modules (although I'm confident I could learn - I think learning something specific like that would be easier than trying to work out how to structure a whole native app), but then the react-native ecosystem is pretty broad these days. A lot of things are covered.
gundamdoubleO 5y ago
I don't hear much about Kotlin Multiplatform when looking into cross platform mobile apps. Has anyone used it?
- fathyb 5y ago
  I've used Kotlin Native around 6 months ago, which seems to be the iOS target for Kotlin Multiplatform. I ended up switching to Go, as much as I didn't want to, because of memory leaks when interacting with the official HTTP client (Ktor). The multithreading through coroutines is pretty experimental and unstable. The community is small, and there is not a lot of actually multiplatform Kotlin libraries, although I saw some libraries making progress towards it. I found myself having to write bindings to C libraries a lot. The language is very promising though, it's great with the JVM or JS as target.
- izacus 5y ago
  It's still very early and very alpha - enough that it'll probably massively block at least one of your important production releases. It's promising though, although it doesn't really solve the same kind of issues as Flutter - Flutter is a UI library first and formost. While Kotlin Multiplatform will most likely replace cases where we use C++ for porability now - internal, shared libraries.
torstenvl 5y ago
https://archive.fo/XpChE https://archive.fo/XpChE
elmcrest 5y ago
While I agree that the bug fixing capabilities of the flutter team could be improved, it‘s still reasonable to assume that they‘re primarily caring about Google‘s issues - given Google pays the party. Still, you comparison isn‘t really a good fit IMHO because it seems you’re „just“ wrapping html content into the native ecosystem, which defeats somehow the purpose of actual native apps. And even if you‘ll only target iOS I‘d say Flutter is still a more pleasant and more productive tech to use compared to f.e. SwiftUI - of course this only applies for actual native code. Still interesting to read, thx for the article. I might modify the title though since I wouldn’t consider a html wrapper a native app you‘re migrating to flutter.
- james_in_the_uk 5y ago
  In OP’s use case he describes the purposes of the having the html content wrapped in an app: easy access in an emergency. I am curious as to why the tech community feels so strongly against html content wrapped as an app. There is a lot of valuable reference content which would benefit from being freed from the rigid structure of an ebook, and so suit an app very well, but doesn’t need ‘native’ functionality per se. Putting that content into PWA makes it harder to monetise. App distribution model works well.
- asah 5y ago
  On iOS, key features are not available in browsers, notably notifications.
theHNAcct 5y ago
used ionic for some small stuff years ago. Kind of assumed it had lost the cross platform race considering how little I see about it. I thought React Native was the lead runner in the cross platform wars right now, anyone care to correct me or give me their take on where it's all at?
- izacus 5y ago
  Flutter seems to have been gaining a lot - React Native is still popular due to size of the web crowd who refuses to look outside their little ecosystem box. But mostly, companies have been reporting that Flutter is much easier to maintain and much easier to reliably deploy across devices - it also doesn't suffer from NPM hell / dependency rot in the same way RN projects do. I'd say both are on about the equal footing these days.
  - klabb3 5y ago
    > the web crowd who refuses to look outside their little ecosystem box I mean, we usually don't require other developers to actively work in 3 different stacks because there are theoretically better languages around the corner. In fact we even make fun of premature fanboyism such as RIIR. Today, the web works for most purposes, but when it doesn't, you may need native apps. It then makes perfect sense that people can reuse skills, ecosystems and tooling. From a UI perspective, any modern web rendering engine can do pretty much anything GUI fast and consistently. Dart is a tiny language in comparison, and last I checked Flutter's web target backend used an opaque canvas element for all rendering, which wasn't just terrible for accessibility but also super laggy. I am still excited about Flutter but they have a lot to prove before I'll frown at the web folks.
    - datavirtue 5y ago
      I would say that the web does not work for most purposes unless I ignore the horrendous architecture that is imposed by using it. I bet only 1% of developers these days have written a native or desktop app. If they had, there would be a gravitational pull moving away from defaulting to the web. I can hit any API from a Swing or WPF app and look damn good doing it with blistering performance. It shows whenever project owners start asking developers to work around or prevent the use of browser based navigation like the back button. The browser is like a hand grenade being rolled under a software project. The ultimate shitty dependency.
leecommamichael 5y ago
Because Dart has a useful standard library, you’re still getting a much more manageable dependency tree than any JS framework could provide.
- klabb3 5y ago
  Is this based on experience? Not saying you're wrong, but I've been bit before by putting emphasis on the language when what I really needed was tooling and a healthy ecosystem.
  - leecommamichael 5y ago
    My experience with Flutter was more enjoyable than with native iOS or React Native. I don’t enjoy Javascript for many reasons in addition to it’s lack of standard library. Swift is a fine language if only the compiler could keep up with a large project. Dart is both fast to compile and has a usable suite of standard libraries.
- capableweb 5y ago
  Is the standard library much better than Swift/Objective-C? As the migration was from a native iOS application to Flutter, I'm not sure why you're pulling in "JS framework" in your argument.
  - leecommamichael 5y ago
    The author dedicated a fair amount of the post to say whether cross-platform frameworks are a good idea, the majority of posts here seem to be focused on the same subject. Given a lot of discussion about Ionic and React Native here, I figured I would toss in my two-cents. To my memory of working with Swift, I wasn’t left wanting much when I moved to Dart. Dart isn’t as interested in value-semantics as Swift, so there are all kinds of Dart packages for immutable classes and collections, so that’s a notable miss. I believe they’re planning to add something more like Swift’s struct to Dart. (dataclass proposal)
ChrisMarshallNY 5y ago
In the article, he mentions the need for a DOM parser dependency for his app, as Swift “does not have one.” > AEXML was needed to parse some XHTML files as the native iOS SDK does not provide a DOM parser. I have used Foundation XML parsers[0] for many years, but they are general-purpose; not specifically modeled on DOM or HTML, which probably limits usefulness on some Web content. That said, if he has control of the content (don’t know the app, so I am not sure), then there should be no reason that they couldn’t render it in XHTML, so the Foundation parser could be used reliably. In the article, he mentions that the content is XHTML. I have to assume that AEXML[1] is easier to use than the built-in parser. It uses Foundation parsing (it actually seems to be a lightweight wrapper for the built-in parser), under the hood (and seems to be a very well-written dependency). So, it could be posited that he would only need one dependency for his native version, if he wanted to handle the XHTML parsing, himself. Personally, I am a huge believer in native platform development, having many, many scars from the compromises required for cross-platform solutions. That said, I totally understand why folks prefer cross-platform development, and can’t, in good conscience, recommend a native approach for all apps. [0] https://developer.apple.com/documentation/foundation/archives_and_serialization/xml_processing_and_modeling https://developer.apple.com/documentation/foundation/archive... [1] https://github.com/tadija/AEXML https://github.com/tadija/AEXML
samwillis 5y ago
I looked into Flutter last year for an app I was developing that needed to use a webview for a large part of its functionality (I wanted to use a ProseMirror rich text editor). From what I could see it felt very much like webview was a neglected part of the framework; multiple incomplete community implementations, a work in progress “official” one, very long lists of bugs. There was massive problems with “contenteditable”. What the article is describing with random bugs on random devices what I saw in the bug tracker. Ultimately I went with Ionic/Capacitor and it was a great experience. Very easy to get up and running. I also experimented with combining Capacitor with NativeScript (they launched a way to use the two together) and it seemed like a brilliant way of exposing native functionality to Capacitor without having to drop all the way down to Swift/Kotlin. The only significant complaint I have about Capacitor is on iOS and a WebKit bug (Ionic can’t fix it). With WebKit on iOS if you have an overflow:scroll with a text input of any kind (basically any app you build) the text cursor or selection highlight will remain visible outside the overflow area when you scroll. So for example if you select text in an input and scroll the view so the input is under a fixed toolbar, the selection highlight or cursor is visible infront of the toolbar. It looks very messy, I wish Apple would fix it. I would, however, definitely use Ionic/Capacitor again, particularly if a webview was a major part of the app or as a small team targeting web and multiple mobile apps.
- ChrisMarshallNY 5y ago
  I have written a series of native Swift apps that I retired, in favor of an Ionic app that another developer wrote. The Ionic app isn't as rich as the native ones, but it doesn't need to be. I'd recommend Ionic for a lot of server-based solutions.
- yesimahuman 5y ago
  Glad to hear Ionic and Capacitor worked great for you! On the Web View side, one other thing we’ve been working on is a mobile micro-frontend product called Portals that is focused on enabling teams to bring in web experiences into their native apps. We’ve seen some really interesting adoption of it from traditional native teams. We will be supporting Flutter and RN this year. It’s probably the best web view experience out there at the moment: https://ionic.io/portals https://ionic.io/portals
axegon_ 5y ago
Disclosure: never done any iOS development, only android as a hobby/personal projects. I'll be first to admit I have always hated Java with a passion. So when Kotlin came along I was thrilled. It still piggybacked on the wretched and slow as hell JVM but at least the syntax was pleasant to work with and didn't offer one way to get from A to B which involved 3 abstract classes, 5 factories and two ultra wide monitors to fit your class names. Flutter came out iirc about a year later and I was on a bus going to a friends's house on the other end of the country. I pulled out my laptop and spent the next 4 hours fiddling with it. And even though it was young and far not mature, I have to admit, I enjoyed it and managed to make a fully functioning app in that time. I had fiddled with dart a bit while I was still in university iirc, just because it was a promising alternative to js(which I also hate with a passion). And even with my rusty memories of it, I felt right at home. It is true, flutter gives you a far greater flexibility when you are building a UI than any of the native solutions. But I feel like the author(s) of the article made one fundamental mistake - depending heavily on components developed by other people. The truth is, flutter is a good choice when you want to do a custom UI at a relatively low price(in terms of how much time and effort you need to spend on it, compared to the native solutions). In addition for cross platform development, dart, unlike javascript, is entirely predictable. BUT! If you are working on a complex application which requires a lot of resources and clever ways to keep a low footprint, you might be better off with the native solutions(even though dart has a very mature ffi). I guess a similar comparison would be something like tinygo and micro python for embedded development - good enough for simple things, but anything beyond that, sack them and stick to C/C++.
Aulig 5y ago
I've also encountered a couple bugs in the webview package. But I feel like the support has been getting better.
shaan7 5y ago
> Any piece of code that is not your own and that your app depends on adds to the technical debt of your app. I find this ^ strange. There is a difference between using a library and technical debt. We use libraries so that we do not have to solve a problem that someone already has. Tech debt is a "shortcut" that you took when implementing a system because $deadlines/$budget/etc. An example might be calling a binary to do something for a PoC because interacting with a library will be more effort. Using libraries is a good thing, it would be sad* if all of us keep solving the same problems over and over again. Tech debt, on the other hand, is debt, something you want to avoid as much as you can. * personally I find having to re-solve solved problems one of the most frustrating things when programming, it takes away all the joy
- mtzet 5y ago
  The article expands upon this point in great detail. To wit: > Flutter's HttpServer that crashed on iOS if the user briefly switched to another app and then back to mine. The author is seemingly capable of writing a solution to the concrete problem, and even debugging and fixing issues in simple libraries, but fixing this issue in Flutter itself (which is much more complex than a concrete solution) is too complicated, leaving him at the mercy of the Flutter maintainers. He may be saved from solving an old problem again, but it seems that he now has a new, much harder problem to solve. In this context, I think it makes sense to describe using the Flutter library as a technial debt in your definition above. You say that libraries are a Good Thing (tm), but how would you handle such an issue?
- truculent 5y ago
  I think your definition of tech debt is too narrow. As with "real" debt, it can be accrued strategically (like, say, a mortgage), but you will still have to pay interest on it (in this case, by struggling to debug/fix the code). As with a mortgage, you may decide this is worth it. Or, in the case of a shortcut, you may decide it needs to be fixed ASAP, because the ongoing cost is too high.
- twobitshifter 5y ago
  I agree and I would not call all dependencies a form of tech debt. They become debt only when you need to replace the dependency to do what you want to do. At that point the work to fix a bug or add a feature will fall to you, and it will become a debt. However to preemptively call all libraries technical debt rubs me the wrong way, combined with the author saying debt is always a bad thing. I always see debt in that context as “work that was put off”. On the other hand, if you don’t use libraries you’ll end up with an enormous pile of technical work to do, likely outside your core-knowledge, just to get your project off the ground. Nobody can afford that, and you need to borrow from existing libraries to get your app off the ground. In that way it could be analogous to debt, but in the way that debt can be good.
josefrichter 5y ago
I dare to say 99% of the time I can spot a non-native app within seconds of using it. RN & co. are fantastic for quick MVP. For serious product it might be actually faster to build native for both platforms. You will start hitting the limitations of RN very soon, even in core functionalities like navigation.
- krly 5y ago
  Yep. Building native for both platforms is becoming easier and easier with MVVM, SwiftUI, and Jetpack Compose.
  - MrDresden 5y ago
    After 10+ years of Android development I honestly feel like I am cheating when writing UI code using Compose these days. Also do Dart/Flutter development along side it and.... they (D/F) just feel so damn verbose and messy by comparison. edit: I can also mirror what the author of the article mentions. Any update in OS versions or the Flutter framework can seriously cripple some of the packages that you'll need to use in order to make a functioning application. Massive time will be spent hunting down the weirdest issues. But to be fair, that can also happen on the native side. They are usually just much easier to find and fix.
- _fat_santa 5y ago
  Yet a shocking number of apps from major companies are all built in this manner. I think the reason it's so damn popular is RN & co. get "close enough" to where many companies can get away with having an cross platform app, especially for React Native apps once you dial everything in and get used to the quirks compared to Native.
  - josefrichter 5y ago
    True. It’s inexcusable for large global corporations, to be fair. Typical culprits include banks and airlines - those are some of the most awful apps around.
- deleted 5y ago
user249 5y ago
The cool thing about Flutter is that it draws components to the Skia canvas. I wasn't even aware it had a WebView. I'm not sure why you would use Flutter if your app consists mostly of a WebView. The bugs that were found are probably not fixed because they are very low priority. You don't save a whole lot by using a WebView in Flutter rather than building a simple shell around the iOS and Android WebView. Without knowing the details, I'd guess that the programmer is using the wrong tool for the job.
- _0w8t 5y ago
  Yep. Webview itself is a cross-platform way to develop things. Adding few native UI elements in addition should not take much efforts. Flutter is when one do not want to use Webview in the first place.
  - ToddWBurgess 5y ago
    Flutter dev here. The Flutter webview is basically a wrapper for the native iOS and Android implementations. A native Android app using a webview and a Flutter app running on Android using a webview is using the same native webview. It is like that for a lot of the Flutter libraries. They basically implement native versions of the functionality and make it available to Flutter. The Dart language has FFI so if you want to get "even more native" you can do Android and iOS system calls in your Flutter app using languages like C, C++, Rust or even Assembly.
    - mwattsun 5y ago
      I was really drawn to Dart when it came out in 2012 and still use it for hobby projects. I know Google uses it internally a lot and is used in the experimental Fuchsia OS. And of course Flutter. I wish Google would put more resources into doing the next version. It appears Bob Nystrom is the only person working on it https://old.reddit.com/r/dartlang/comments/rvqivf/what_is_the_fate_of_the_records_feature/hrahfwa/ https://old.reddit.com/r/dartlang/comments/rvqivf/what_is_th... I wrote a fairly complicated web app in 2013 in Dart. I just updated it to Dart 2.0 and nullability and it still works, which impressed me. Someday people will catch on to Dart, probably if and when Fuchsia gets popular https://fuchsia.dev/ https://fuchsia.dev/
npunt 5y ago
Worth noting this article is almost a year old now (Feb 2021), prior to Flutter 2.0 which supports web-based apps with CanvasKit. Flutter was only officially (1.0) launched 3 years ago.
- candiddevmike 5y ago
  I have read a lot of feedback that, while flutter web is now stable, it seems a little premature. The performance of canvas rendering with flutter appears to be universally bad, especially on mobile, and there are some UX issues around scrollbars, insane bundle sizes, and long initial load times. Anyone have some success stories of using flutter web? I read you can output HTML/CSS/JS instead of canvas and a lot of these issues go away, is that true?
wiradikusuma 5y ago
"After some research.. ..I decided to give it a go." Hmm.. From my experience, every time I pick a new language / framework, always always always do proof-of-concept for ALL features you might need: camera, GPS, webview, deeplinking, etc. Don't want surprises. Esp. if you already have an existing app, you should have a clear visibility of what's needed.
vood 5y ago
Can you explain why mobile developers run away from third party components? I'm a full stack/data engineer and use third party components all the time. In fact, I'd choose a popular and maintained component for the job, instead of writing it myself. I have no issues using as many components as I need. This seems like a bad practice in mobile. If I encounter a bug in my dependencies, I find it, fix and send the fix to the maintainer. The same as I would do with my own code.
- jefflinwood 5y ago
  In this particular case, the problem is that the plugins require Dart glue code, and a native implementation on both iOS and Android. So if you run into a problem with a component, it's much more complicated to fix it. In general, using third party components with native mobile apps is pretty straightforward.
  - kitsunesoba 5y ago
    Even for full native, I try to keep the number of third party dependencies down and limit them to libraries that fill legitimate voids in system functionality or are only light sugar around system stuff for a few reasons: - Many libraries have zero guarantees as to how long they’ll be maintained or if their maintainer(s) will keep pace with new system releases, build tool changes, etc - It’s less unfamiliar code that I’ll need to wade through at some point - Fewer libraries reduces lock-in that can encumber refactors and other major changes - I don’t have to waste as much time and energy “translating” things between different libraries with related functions I used to not be as avoidant of a long dependency list, but over the years I learned that for both iOS and Android, each library represents a liability across multiple dimensions that WILL become a problem at some point, probably sooner than later. Mobile platforms aren’t like their desktop/server counterparts where the various APIs have barely changed in decades, and they aren’t like the web where everything continues to be supported for practically forever. Things change, and it’s important to be able to keep up with that. This is a lot easier to manage under iOS than under Android, incidentally. Cocoa Touch still sees tweaks but it’s quite mature, and very deep and capable. You can build a world class app with just Cocoa Touch alone without too much trouble. With Android Framework on the other hand, much of what’s built in is incapable, with bits and pieces constantly shifting in and out of being supported, making it the norm to bring in a laundry list of libraries for super basic stuff (e.g. everybody uses Square’s OkHTTP for networking on Android while on iOS, not using the built in URLSession and associated APIs is very strange).
intrasight 5y ago
I've been doing cross-platform development on and off for 30 years. Back in the DataViews days we had a team of two dozen professionals working on this problem and made good bank selling developer seats for about $15K each. Flash forward 30 years, and here's what's changed: 1. Users expect this stuff for free 2. For the most part it is, but only because the tools are being developed by big-tech and serve their interests more than yours What hasn't changed: 1. compile-time. I just don't get it. Computers are like 5000x faster 2. cross-platform is hard and involves lots of compromises 3. it's hard to make money selling tools
- jmnicolas 5y ago
  > and made good bank selling developer seats for about $15K each. > 1. Users expect this stuff for free I learned Flutter for my own needs, I make about 25k€ / year after taxes, I couldn't afford to pay this kind of money for hobby stuff. Even Embarcadero stuff at 5k a seat is way too much (I can get a good used car for this price). Even at work I have to fight to get better hardware than Raspberry Pis (they regularly have black screens that only a few hard reboots solve). The problem is that we don't live in the same world: there are companies where money flows and other companies where every cent has to be justified because money doesn't grow magically under unicorns hooves ...
yesimahuman 5y ago
You mention Ionic at the end, so I have to comment as the co-founder :) The first thought is on maintenance and support from Google/Facebook compared to someone like Ionic. One of the things people don't think about before it's too late is support, and Ionic is unique in mobile in that we actually make money from supporting our technology directly for customers. We have direct support available for our auth/security/data storage plugins, cloud services, and open source projects. We literally will respond to customer support tickets and make fixes/patches on a weekend if we have to. Is there any other company out there doing what Ionic is in mobile? You mention having issues with the Web View component, is Google or Facebook ever going to prioritize your issues? It's not likely, they don't have that kind of business model around their technology like Ionic does. Facebook builds RN for itself, and who knows what Google's end-goal is with Flutter (drive GCP adoption? push its ad network?) but it's certainly not to monetize it through dedicated support for the most significant users of it. I'm proud that the Ionic stack is the most user-aligned offering out there because we're literally in the business of supporting and extending users of our OSS stack. On the Web View side, we've recently shipped one of the first mobile micro-frontend projects in the ecosystem called Ionic Portals which is basically an awesome Web View component powered by our tech and expertise building web view experiences on mobile. Right now it doesn't have RN or Flutter bindings but we are working on them this year. This has been a pretty interesting shift for us and we're now working with traditional native teams not using the traditional Ionic stack: https://ionic.io/portals https://ionic.io/portals
- nvahalik 5y ago
  > We have direct support available It would be great if Ionic offered consulting for things like Cordova -> Capacitor migrations. However, the last time I talked to sales it seemed like the best we could get was a report on what plugins we could or couldn't use with Capacitor. > we're literally in the business of supporting and extending users of our OSS stack Can you define that a little bit better? Because I've contacted Ionic sales before about seemingly well-used but under-maintained plugins and was basically told we were on our own. AppFlow isn't a horrible product—but the recent price increases gave me a sour taste. What am I getting for my money? OK. I'm getting a build system which is nice, but I can't stomach paying the new (nearly 10x) price just to be able to do things like kick off builds from CI or the CLI. What I _would_ pay for is help with other OSS plugin issues, consulting to migrate to Capacitor, training and help with maintaining custom projects, or better yet general development support when things go south (like the dreaded white-screen of death). Anyway, we've been happy with Ionic and are always excited to see things improve. I don't mean to be downer—rather I'd love to give you guys money so long as it makes sense!
intrasight 5y ago
Honest question to those who've been there and don that. What's the right solution path for a very small (3-4 people) team to build a relatively polished mobile app? Options I see are: 1. Native iOS followed by Native Android 2. Flutter 3. React Native 4. Capacitor 5. Microsoft toolkit of the day I may soon embark on such a task with such a small team. I am leaning towards #1.
- ToddWBurgess 5y ago
  I work on a Flutter app with a small team that does both iOS and Android from the same code base. It works really well for our use case given the size of our team. I also have experience with both native Android and iOS. The way Android and iOS handle apps is completely different and jumping between the two requires a lot of mental context switching. Something to think about is all mobile apps come with the typical boilerplate. Think about a screen that displays the results from a REST call. You will need to create the screen for the Android app using either XML or Jetpack Compose frameworks. The iOS will need to create a screen using storyboards or SwiftUI frameworks. That is a lot to maintain. With Flutter you create the screens just once in Flutter and the only framework choice is Flutter. Now at some point in the future when the REST call adds a new field you have twice the work to do with native solutions then you do with Flutter to add it to your screen. I would also like to correct misconception about Flutter. Flutter doesn't eliminate the need to do cross platform development. You still need to know the native tooling, native build cycles and native programming languages if you want to get a Flutter app out the door.
  - intrasight 5y ago
    So how does Flutter really help vs just get in the way - if you have to "do cross platform development" anyway?
    - ToddWBurgess 5y ago
      You will end up writing less code. You won't have to tackle advanced subjects like managing app state in Android and iOS. You can use a Flutter state management solution that works on both platforms. You won't have to feature match your two apps because they will all use the same code base. If you are a small teams looking to get something out the door, all of these are points in favour of Flutter. It works better for teams will constraints such as team size, budget and time.
pjmlp 5y ago
Just embrace C++ for business logic (supported natively by both SDKs) and use native views, and for most CRUD apps, mobile Web works just fine. Anything else, might look enticing, however as the author points out brings lots of attrition and failures can happen at any level of the stack, thus requiring native programing knowledge to sort them out anyway. So instead of being experts in two stacks, the team now needs to be expert in three stacks.
- zerr 5y ago
  The thing is, for most mobile apps, 99% code are views, with a very tiny part that can be called "business logic". Doesn't really make sense to involve C++/JNI bridges hassle.
  - pjmlp 5y ago
    Hence my remark regarding CRUD apps and mobile Web. Even if native views are required, the business logic can be driven from Web APIs, or DSL like JSON files.
  - aaaaaaaaaaab 5y ago
    If your app is like that, then maybe it shouldn’t be an app at all, rather a website.
  - therockhead 5y ago
    > C++/JNI bridges hassle For the projects I worked on, the bridges were automatically generated, so no hassle for the developer. Admittedly we built our own code gen system which of course was not free.
- bbkane 5y ago
  Dropbox used to do this but eventually abandoned it, due to the cost of maintaining C++ code that works on multiple platforms. Turns out that might be more difficult than maintaining native code for each platform. https://dropbox.tech/mobile/the-not-so-hidden-cost-of-sharing-code-between-ios-and-android https://dropbox.tech/mobile/the-not-so-hidden-cost-of-sharin...
zerr 5y ago
As a side note, for some reason, cross-platform frameworks such as Flutter are quite popular in developing countries.
- ToddWBurgess 5y ago
  My theory on why Flutter is popular in developing countries is a Flutter app compiled in release mode is turned into AOT code. This gives it a performance boost on apps that are constrained by low CPU and memory resources. I expect that that most HN users probably have a flagship mobile phone with lots of CPU, RAM and reliable mobile data options. The other 90% of the world can not say that and a lot more sensitive to apps that require advanced phones and operating environments to function.
  - jmnicolas 5y ago
    Wouldn't it be more logical to build only for Android then? There probably are few Apple devices in developing countries and native is much faster than Flutter. There's a video on YT where a guy (from India I think) shows the starting time of a todo app built with RN, Flutter and native. Native is lightning fast.
    - Apocryphon 5y ago
      Platforms are international. If they can target both platforms along the way that allows them to crack into the more lucrative iOS market.
- higerordermap 5y ago
  I am from India and pretty sure the reason here is it's much easier to make UIs in flutter than in Android native. Nothing specific to India being a developing country. It's natural to see students using easier stuff as well. Most of student projects you come across is using react, flutter, firebase, MongoDB, as opposed to Angular/Vue, Android native/Jetpack, postgresql etc.. which have much higher barrier to entry. But this may have to do with developing countries having more recent developers, and less established developers.
asdev 5y ago
it's amazing to me how crappy the mobile development experience is in 2022 with any technology(React Native, Flutter, native)
datavirtue 5y ago
I tried Flutter for two weeks before hoping out hard. Can't put my finger on it but the combination of chaining everything into a huge nested pile of shit and....Google really turned me off. I was far more productive in Xamarin Forms. "Any piece of code that is not your own and that your app depends on adds to the technical debt of your app." We need to start pulling in dependencies as code instead of binaries. It should become part of our project and we should remove that which we do not need and maintain or patch those parts that need it manually...one our own. The number of dependencies in projects cause a great deal of bloat, cross-cutting nightmares, and unending security vulnerabilities that make us desperately seek support in the form of new binaries from unpaid contributors. It is not professional, dignified, or safe. If you need StringUtils.isEmpty you should not be pulling in the apache commons jar. Just clip the code you need and squirrel it away in your project.
davidkhess 5y ago
I find Qt/QML for cross-platform mobile applications to be a great solution. It uses the same basic architecture as Flutter – they both do not use native widgets and instead draw the entire UI on a blank graphics canvas. I think that approach preserves the most code between platforms and reduces the kinds of presentation hitches that HTML web view and hybrid native widget approaches can run into. In relation to the particular problems of technical debt related to third party modules mentioned in this article, QML rides on top of Qt which is a 26 year old C++ cross-platform toolkit with a lot of mature technology in it. I.e. there is a lot more "batteries included". There are still plenty of times you have to "go native" to integrate something Qt doesn't cover but it apparently isn't as often as with Flutter.
- arthur_sav 5y ago
  Can you give me an example of a good mobile app built with Qt/QML? I feel like only big corps can justify such apps where users have no choice but to use it because their boss forced them to.
  - davidkhess 5y ago
    I built the initial version of this app for a startup: https://apps.apple.com/us/app/listeners-on-call/id1498666617#?platform=iphone https://apps.apple.com/us/app/listeners-on-call/id1498666617... It has a very good UX designer and I've developed multiple commercial Qt/QML mobile applications previously. I think the economics make sense with the following assumptions: * The startup doesn't have the resources to build for two platforms natively (yet). * The developer(s) can get their hands dirty and "go native" on either platform when needed.
    - arthur_sav 5y ago
      User review: "Tried using the app- no listeners were available. Cheaply made." Users know. That's why most of these apps die within 1-2 years. Have you used any airline app? Have you used any "cross platform" bank app? I've actually switched banks because i preferred the one with the better mobile app. A bad app just shows how outdated they are. Not saying there's no demand for building such apps, businesses clearly don't care (yet). When they start losing business they'll have to care.
arthur_sav 5y ago
I've built both native and cross platform apps. People and especially managers think that cross platform apps will save them money/time. However, they don't realisize that cross platform solves one problem and creates ten. The developer experience is worse, the user experience is worse and you end up with a pile of mess after 1-2 years.
- WA 5y ago
  I have an Ionic app used by thousands of people daily since 2017 on both, Android and iOS. There are certainly some downsides, but it really didn’t create 10 problems for every solved one. Ironically, I have an older native iOS app and it briefly stopped working on iOS 14.5 for no reason with the message "developer needs to update this app", like when apps had to switch to 64 bit. A few months later, the very same app started to work again in a later iOS version. I follow a few native iOS devs on twitter and it looks like they have to deal with quite a lot of shit in Xcode and Swift all the time. I don’t. My app has been running pretty stable. And yes, dev saves time. One code base for 3 platforms, dev experience is pretty great (hot code reloading, same IDE for all platforms 98% of the time).
  - arthur_sav 5y ago
    Then it suits your use case. I've basically made a living from re-writting cross platforms apps back to native. Company creates cross platform app. They get some traction. They try to scale but it becomes harder every day. They hire me to go native.
- aaaaaaaaaaab 5y ago
  Managers are incentivized to show pretty numbers about code reuse and platform feature parity to upper management, because that’s how they get their bonuses. Also webdevs are cheaper than mobile engineers. Upper management gets soaking wet from stuff like this.
deleted 5y ago
[deleted]
sysOpOpPERAND 5y ago
i love working with flutter and dart. really hoping the job market opens up more for those. one major annoyance for me is having to create a class to handle the data from a json. i would love to see dot notation access to keys like how javascript handles json, it turns it automatically into an object after using .json() but overall i enjoy working with it and it is always good to see posts popping up on HN about it
timsneath 5y ago
Tim here from the Flutter team; thanks for the post. There are some good points here: in particular, that no single framework or toolkit is the "holy grail". We all live in a world of trade-offs, and anyone who claims that any single technology is the panacea for all problems is selling a mirage. I really appreciate the constructive critique in the article: both the good (getting an app up and running quickly), and the more painful to read ("Flutter's ability to execute leads a lot to be desired, particularly on iOS"). While Google is the primary sponsor for Flutter, it's an open source project, and so as ever having reproducible bug reports and ideally pull requests is how we make it better. The raison d'être for Flutter is simple: we don't think you should have to write the same code six times for your app to reach each major desktop, mobile and web platform. This abstraction is not free, but we think it's worth the bet, and there are some cool apps being built with Flutter, plenty of which have been awarded accolades like Apple Editor's Choice. We're not the solution for every app out there, but there are startups who don't have the developer team size to build multiple apps but can benefit from Flutter, as well as larger companies for whom Flutter lets them unify their app development team behind a single codebase. A few quick comments I wanted to make: - Yes, we have a large number of open issues -- over 9,000 at the last count, but not all issues are bugs. We're somewhat unique in bringing together tools, packages, framework and engine issues into a single database, also merging feature requests, bugs and even API doc requests together. Our general philosophy is that it's better to have it out in the open rather than (for example) to prematurely close issues that we don't plan to work on ourselves. We're also not unique as a large open source project in having lots of open issues (also see projects like PyTorch, Rust and VSCode). Lastly, it's important to count the number of issues _closed_, which is over 50,000, representing bugs fixed, new features implemented, and so on. We document the triage process here: https://github.com/flutter/flutter/wiki/Triage https://github.com/flutter/flutter/wiki/Triage - I'm surprised that the author considers packages an inevitable weakness. We've deliberately kept the core of Flutter relatively small, because it enables us to iterate on packages at their own pace. We could have taken the approach of building things like XML parsing, HTTP servers, geolocation and so on into the core of Flutter, but it wouldn't automatically make them more robust. With a package model, we can fix a specific issue without requiring a whole release cycle for every part of Flutter. Over the last year since the author wrote this article, our package maturity has greatly improved, and I'd be interested to know whether this is noticeable. - Lastly, the underlying fear expressed in the article seems to be that Google will at some point just give up with Flutter. I understand this, since we don't have an immaculate reputation in terms of long-term support. I will say that this question doesn't come up internally with our stakeholders, though. There are over 400,000 apps in the Play Store that use Flutter; about 1,000 Google engineers building highly-strategic products using Flutter; and a healthy ads revenue from apps that use Flutter. The project more than pays for itself, and I can't honestly envisage any scenario in the next decade where Google would choose to squander all that. Keep the feedback coming: we're listening.
awinter-py 5y ago
xcode is the opposite of a tool and it is somehow getting worse with age. apple has exactly one job and apparently it's to make xcode into a hot pile of garbage. flutter is like terraform. Is dart a good language? No, it's a piece of shit. Most languages are. Dart, moreover, is the reason the google ads dashboard melts your laptop. But it saves you from the peril of directly gazing upon something much, much worse. ios devs all have stockholm syndrome and will tell you 'it's not that bad' as they upgrade their dependencies for the 60th time to keep up with some unnecessary framework change aapl is forcing them to do because nice app store ranking, shame if something happened to it
chubs 5y ago
Apologies for the naked plug, but I've had so many clients over the years try and fail to get cross-platform apps to work that i'm currently working to try make something that will actually work, freed from the incentives of the big companies pushing eg flutter and RN. It's slow going however... if you think there's a future in this kind of thing, consider asking your boss to sponsor it to help speed development? The idea is to write in a Swift-ish language, compiled to native code on both platforms, and wrap the native components, but do it in a way that learns the lessons from eg RN's difficulties to include a sensible cross-platform navigation component. (the project is github.com/soniclang/sonic)
egberts1 5y ago
And the holy grail of writing an app for all mobile platforms shall remains … illusive (and elusive as well).

231 points by PanMan 5y ago

deleted 5y ago

[deleted]

I was heavily involved with the rollout and maintenance of React Native(RN) at my previous job. This post touches on an interesting point that has just now crystallised in my head. In particular the OP writes: > Fortunately, I could find the bug in the library with my Swift skills, fix it within a day and even submit a patch to the owner of the repository. But I could find and fix it only because the library and my app were written in the same language, and this was a language that I was familiar with. We adopted RN because we had a lot of web developers(hundreds) and wanted to enable them in contributing to our app. We explicitly didn't make it a goal to achieve code sharing, yet we did, to the tune of 90% of the code. Overall RN was successful for us. However, one thing became apparent immediately: the RN developers needed support from native teams. As soon as the RN developers hit a problem that required bridging native APIs or a bug that required platform knowledge, they end up blocked with no way to unblock themselves. Luckily we could create a team of platform experts dedicated to supporting these developers. This highlights the unfortunate paradox with cross platform tech. It's a great choice for solo developers or small startups looking to find product market fit and iterate quickly. They might be fooled into thinking that they can get by without learning the platform native methods and languages, only to find that they end up stuck when the leaky abstraction eventually leaks. On the other hand, a well resourced company that can dedicate a team of platform experts as support for the cross platform developers will not suffer this problem, but is cross platform the right choice for a well resourced company? Such a company has probably already found product market fit and is better of paying the higher cost of native development to build a higher quality app. A big takeaway from my RN experience is: One might expect that an RN developer can get away with knowing less about mobile than a native developer. Counter-intuitively, the opposite is true. A solo RN developer will, of course, need to know JS and React, but when the abstraction leaks they'll also need to be comfortable with Java, Kotlin, Swift, Objective-C, the respective build systems(CocoaPods & Gradle), and even C++. If one considers RN's origin, being an internal Facebook framework. It all makes sense. RN was built to allow more developers at Facebook to contribute to their apps, without requiring them to learn native technologies or languages. Of course, Facebook has the best imaginable team to support these developer, the RN team itself.

je42 5y ago
This totally true. I think however, Flutter does a better job in fixing platform related issues. Also, in my experience upgrade to a new version of RN was usually very painful, with Flutter so far it was straight forward.
nicoburns 5y ago
I think the way to set it up is to have the senior engineers on your RN team be the ones who know everything: they are experts in JavaScript, but they are also comfortable dropping down into Swift/Objective-C and Kotlin/Java when needed. Then you can have junior engineers who are more focussed on the JS side of things (at least to begin with). They key thing here being that the people who can unblock are on the same team as the people who may need to be unblocked and can thus prioritise doing so quickly. If you need extensive native code for custom modules (we haven't yet needed this at my work) then it would make sense to have native developers on each platform take a lead of that. But there should absolutely be people on your RN team who can do integration work and bug fixing independently of that team. I think the key is: if you're working with cross-platform tech then you ought to have cross platform developers.
- K0nserv 5y ago
  Absolutely, but this speaks to the paradox I think. Cross platform is an attractive choice, precisely when you don't have a such a person. For example, as a solo developer with no native knowledge who wants to ship an app or a small startup hiring their first mobile developer. Being proficient in all of Web(JS, React), Android(Kotlin, Java, Gradle), and iOS(Swift, Objective-C, CocoaPods) is a pretty significant ask for a single person too. Personally, I check two of those boxes(iOS and Web), adding Android as well would be a bit much.
  - nicoburns 5y ago
    Hmm... I don't necessarily think it needs to be a single person knowing everything. For example a team made up of you, someone else who knew android and web, and a bunch of people who only knew web would work really well I think. Those who were experts in the native platforms would be responsible for bringing the rest of the team up to speed (providing context, advice, pointing to learning resources, etc). As someone who came to a react-native project (as the lead) with a web and cordova background and no prior react-native or native platform experience, I've found that just knowing about the ios and android build systems and being able to add basic code to the AppDelegate (ios) and MainActivity (android) has been entirely sufficient for our needs. It would be different if we needed custom native modules (although I'm confident I could learn - I think learning something specific like that would be easier than trying to work out how to structure a whole native app), but then the react-native ecosystem is pretty broad these days. A lot of things are covered.

gundamdoubleO 5y ago

I don't hear much about Kotlin Multiplatform when looking into cross platform mobile apps. Has anyone used it?

fathyb 5y ago
I've used Kotlin Native around 6 months ago, which seems to be the iOS target for Kotlin Multiplatform. I ended up switching to Go, as much as I didn't want to, because of memory leaks when interacting with the official HTTP client (Ktor). The multithreading through coroutines is pretty experimental and unstable. The community is small, and there is not a lot of actually multiplatform Kotlin libraries, although I saw some libraries making progress towards it. I found myself having to write bindings to C libraries a lot. The language is very promising though, it's great with the JVM or JS as target.
izacus 5y ago
It's still very early and very alpha - enough that it'll probably massively block at least one of your important production releases. It's promising though, although it doesn't really solve the same kind of issues as Flutter - Flutter is a UI library first and formost. While Kotlin Multiplatform will most likely replace cases where we use C++ for porability now - internal, shared libraries.

torstenvl 5y ago

https://archive.fo/XpChE https://archive.fo/XpChE

elmcrest 5y ago

While I agree that the bug fixing capabilities of the flutter team could be improved, it‘s still reasonable to assume that they‘re primarily caring about Google‘s issues - given Google pays the party. Still, you comparison isn‘t really a good fit IMHO because it seems you’re „just“ wrapping html content into the native ecosystem, which defeats somehow the purpose of actual native apps. And even if you‘ll only target iOS I‘d say Flutter is still a more pleasant and more productive tech to use compared to f.e. SwiftUI - of course this only applies for actual native code. Still interesting to read, thx for the article. I might modify the title though since I wouldn’t consider a html wrapper a native app you‘re migrating to flutter.

james_in_the_uk 5y ago
In OP’s use case he describes the purposes of the having the html content wrapped in an app: easy access in an emergency. I am curious as to why the tech community feels so strongly against html content wrapped as an app. There is a lot of valuable reference content which would benefit from being freed from the rigid structure of an ebook, and so suit an app very well, but doesn’t need ‘native’ functionality per se. Putting that content into PWA makes it harder to monetise. App distribution model works well.
asah 5y ago
On iOS, key features are not available in browsers, notably notifications.

theHNAcct 5y ago

used ionic for some small stuff years ago. Kind of assumed it had lost the cross platform race considering how little I see about it. I thought React Native was the lead runner in the cross platform wars right now, anyone care to correct me or give me their take on where it's all at?

izacus 5y ago
Flutter seems to have been gaining a lot - React Native is still popular due to size of the web crowd who refuses to look outside their little ecosystem box. But mostly, companies have been reporting that Flutter is much easier to maintain and much easier to reliably deploy across devices - it also doesn't suffer from NPM hell / dependency rot in the same way RN projects do. I'd say both are on about the equal footing these days.
- klabb3 5y ago
  > the web crowd who refuses to look outside their little ecosystem box I mean, we usually don't require other developers to actively work in 3 different stacks because there are theoretically better languages around the corner. In fact we even make fun of premature fanboyism such as RIIR. Today, the web works for most purposes, but when it doesn't, you may need native apps. It then makes perfect sense that people can reuse skills, ecosystems and tooling. From a UI perspective, any modern web rendering engine can do pretty much anything GUI fast and consistently. Dart is a tiny language in comparison, and last I checked Flutter's web target backend used an opaque canvas element for all rendering, which wasn't just terrible for accessibility but also super laggy. I am still excited about Flutter but they have a lot to prove before I'll frown at the web folks.
  - datavirtue 5y ago
    I would say that the web does not work for most purposes unless I ignore the horrendous architecture that is imposed by using it. I bet only 1% of developers these days have written a native or desktop app. If they had, there would be a gravitational pull moving away from defaulting to the web. I can hit any API from a Swing or WPF app and look damn good doing it with blistering performance. It shows whenever project owners start asking developers to work around or prevent the use of browser based navigation like the back button. The browser is like a hand grenade being rolled under a software project. The ultimate shitty dependency.

leecommamichael 5y ago

Because Dart has a useful standard library, you’re still getting a much more manageable dependency tree than any JS framework could provide.

klabb3 5y ago
Is this based on experience? Not saying you're wrong, but I've been bit before by putting emphasis on the language when what I really needed was tooling and a healthy ecosystem.
- leecommamichael 5y ago
  My experience with Flutter was more enjoyable than with native iOS or React Native. I don’t enjoy Javascript for many reasons in addition to it’s lack of standard library. Swift is a fine language if only the compiler could keep up with a large project. Dart is both fast to compile and has a usable suite of standard libraries.
capableweb 5y ago
Is the standard library much better than Swift/Objective-C? As the migration was from a native iOS application to Flutter, I'm not sure why you're pulling in "JS framework" in your argument.
- leecommamichael 5y ago
  The author dedicated a fair amount of the post to say whether cross-platform frameworks are a good idea, the majority of posts here seem to be focused on the same subject. Given a lot of discussion about Ionic and React Native here, I figured I would toss in my two-cents. To my memory of working with Swift, I wasn’t left wanting much when I moved to Dart. Dart isn’t as interested in value-semantics as Swift, so there are all kinds of Dart packages for immutable classes and collections, so that’s a notable miss. I believe they’re planning to add something more like Swift’s struct to Dart. (dataclass proposal)

ChrisMarshallNY 5y ago

In the article, he mentions the need for a DOM parser dependency for his app, as Swift “does not have one.” > AEXML was needed to parse some XHTML files as the native iOS SDK does not provide a DOM parser. I have used Foundation XML parsers[0] for many years, but they are general-purpose; not specifically modeled on DOM or HTML, which probably limits usefulness on some Web content. That said, if he has control of the content (don’t know the app, so I am not sure), then there should be no reason that they couldn’t render it in XHTML, so the Foundation parser could be used reliably. In the article, he mentions that the content is XHTML. I have to assume that AEXML[1] is easier to use than the built-in parser. It uses Foundation parsing (it actually seems to be a lightweight wrapper for the built-in parser), under the hood (and seems to be a very well-written dependency). So, it could be posited that he would only need one dependency for his native version, if he wanted to handle the XHTML parsing, himself. Personally, I am a huge believer in native platform development, having many, many scars from the compromises required for cross-platform solutions. That said, I totally understand why folks prefer cross-platform development, and can’t, in good conscience, recommend a native approach for all apps. [0] https://developer.apple.com/documentation/foundation/archives_and_serialization/xml_processing_and_modeling https://developer.apple.com/documentation/foundation/archive... [1] https://github.com/tadija/AEXML https://github.com/tadija/AEXML

samwillis 5y ago

I looked into Flutter last year for an app I was developing that needed to use a webview for a large part of its functionality (I wanted to use a ProseMirror rich text editor). From what I could see it felt very much like webview was a neglected part of the framework; multiple incomplete community implementations, a work in progress “official” one, very long lists of bugs. There was massive problems with “contenteditable”. What the article is describing with random bugs on random devices what I saw in the bug tracker. Ultimately I went with Ionic/Capacitor and it was a great experience. Very easy to get up and running. I also experimented with combining Capacitor with NativeScript (they launched a way to use the two together) and it seemed like a brilliant way of exposing native functionality to Capacitor without having to drop all the way down to Swift/Kotlin. The only significant complaint I have about Capacitor is on iOS and a WebKit bug (Ionic can’t fix it). With WebKit on iOS if you have an overflow:scroll with a text input of any kind (basically any app you build) the text cursor or selection highlight will remain visible outside the overflow area when you scroll. So for example if you select text in an input and scroll the view so the input is under a fixed toolbar, the selection highlight or cursor is visible infront of the toolbar. It looks very messy, I wish Apple would fix it. I would, however, definitely use Ionic/Capacitor again, particularly if a webview was a major part of the app or as a small team targeting web and multiple mobile apps.

ChrisMarshallNY 5y ago
I have written a series of native Swift apps that I retired, in favor of an Ionic app that another developer wrote. The Ionic app isn't as rich as the native ones, but it doesn't need to be. I'd recommend Ionic for a lot of server-based solutions.
yesimahuman 5y ago
Glad to hear Ionic and Capacitor worked great for you! On the Web View side, one other thing we’ve been working on is a mobile micro-frontend product called Portals that is focused on enabling teams to bring in web experiences into their native apps. We’ve seen some really interesting adoption of it from traditional native teams. We will be supporting Flutter and RN this year. It’s probably the best web view experience out there at the moment: https://ionic.io/portals https://ionic.io/portals

axegon_ 5y ago

Disclosure: never done any iOS development, only android as a hobby/personal projects. I'll be first to admit I have always hated Java with a passion. So when Kotlin came along I was thrilled. It still piggybacked on the wretched and slow as hell JVM but at least the syntax was pleasant to work with and didn't offer one way to get from A to B which involved 3 abstract classes, 5 factories and two ultra wide monitors to fit your class names. Flutter came out iirc about a year later and I was on a bus going to a friends's house on the other end of the country. I pulled out my laptop and spent the next 4 hours fiddling with it. And even though it was young and far not mature, I have to admit, I enjoyed it and managed to make a fully functioning app in that time. I had fiddled with dart a bit while I was still in university iirc, just because it was a promising alternative to js(which I also hate with a passion). And even with my rusty memories of it, I felt right at home. It is true, flutter gives you a far greater flexibility when you are building a UI than any of the native solutions. But I feel like the author(s) of the article made one fundamental mistake - depending heavily on components developed by other people. The truth is, flutter is a good choice when you want to do a custom UI at a relatively low price(in terms of how much time and effort you need to spend on it, compared to the native solutions). In addition for cross platform development, dart, unlike javascript, is entirely predictable. BUT! If you are working on a complex application which requires a lot of resources and clever ways to keep a low footprint, you might be better off with the native solutions(even though dart has a very mature ffi). I guess a similar comparison would be something like tinygo and micro python for embedded development - good enough for simple things, but anything beyond that, sack them and stick to C/C++.

Aulig 5y ago

I've also encountered a couple bugs in the webview package. But I feel like the support has been getting better.

shaan7 5y ago

> Any piece of code that is not your own and that your app depends on adds to the technical debt of your app. I find this ^ strange. There is a difference between using a library and technical debt. We use libraries so that we do not have to solve a problem that someone already has. Tech debt is a "shortcut" that you took when implementing a system because $deadlines/$budget/etc. An example might be calling a binary to do something for a PoC because interacting with a library will be more effort. Using libraries is a good thing, it would be sad* if all of us keep solving the same problems over and over again. Tech debt, on the other hand, is debt, something you want to avoid as much as you can. * personally I find having to re-solve solved problems one of the most frustrating things when programming, it takes away all the joy

mtzet 5y ago
The article expands upon this point in great detail. To wit: > Flutter's HttpServer that crashed on iOS if the user briefly switched to another app and then back to mine. The author is seemingly capable of writing a solution to the concrete problem, and even debugging and fixing issues in simple libraries, but fixing this issue in Flutter itself (which is much more complex than a concrete solution) is too complicated, leaving him at the mercy of the Flutter maintainers. He may be saved from solving an old problem again, but it seems that he now has a new, much harder problem to solve. In this context, I think it makes sense to describe using the Flutter library as a technial debt in your definition above. You say that libraries are a Good Thing (tm), but how would you handle such an issue?
truculent 5y ago
I think your definition of tech debt is too narrow. As with "real" debt, it can be accrued strategically (like, say, a mortgage), but you will still have to pay interest on it (in this case, by struggling to debug/fix the code). As with a mortgage, you may decide this is worth it. Or, in the case of a shortcut, you may decide it needs to be fixed ASAP, because the ongoing cost is too high.
twobitshifter 5y ago
I agree and I would not call all dependencies a form of tech debt. They become debt only when you need to replace the dependency to do what you want to do. At that point the work to fix a bug or add a feature will fall to you, and it will become a debt. However to preemptively call all libraries technical debt rubs me the wrong way, combined with the author saying debt is always a bad thing. I always see debt in that context as “work that was put off”. On the other hand, if you don’t use libraries you’ll end up with an enormous pile of technical work to do, likely outside your core-knowledge, just to get your project off the ground. Nobody can afford that, and you need to borrow from existing libraries to get your app off the ground. In that way it could be analogous to debt, but in the way that debt can be good.

josefrichter 5y ago

I dare to say 99% of the time I can spot a non-native app within seconds of using it. RN & co. are fantastic for quick MVP. For serious product it might be actually faster to build native for both platforms. You will start hitting the limitations of RN very soon, even in core functionalities like navigation.

krly 5y ago
Yep. Building native for both platforms is becoming easier and easier with MVVM, SwiftUI, and Jetpack Compose.
- MrDresden 5y ago
  After 10+ years of Android development I honestly feel like I am cheating when writing UI code using Compose these days. Also do Dart/Flutter development along side it and.... they (D/F) just feel so damn verbose and messy by comparison. edit: I can also mirror what the author of the article mentions. Any update in OS versions or the Flutter framework can seriously cripple some of the packages that you'll need to use in order to make a functioning application. Massive time will be spent hunting down the weirdest issues. But to be fair, that can also happen on the native side. They are usually just much easier to find and fix.
_fat_santa 5y ago
Yet a shocking number of apps from major companies are all built in this manner. I think the reason it's so damn popular is RN & co. get "close enough" to where many companies can get away with having an cross platform app, especially for React Native apps once you dial everything in and get used to the quirks compared to Native.
- josefrichter 5y ago
  True. It’s inexcusable for large global corporations, to be fair. Typical culprits include banks and airlines - those are some of the most awful apps around.
deleted 5y ago

user249 5y ago

The cool thing about Flutter is that it draws components to the Skia canvas. I wasn't even aware it had a WebView. I'm not sure why you would use Flutter if your app consists mostly of a WebView. The bugs that were found are probably not fixed because they are very low priority. You don't save a whole lot by using a WebView in Flutter rather than building a simple shell around the iOS and Android WebView. Without knowing the details, I'd guess that the programmer is using the wrong tool for the job.

_0w8t 5y ago
Yep. Webview itself is a cross-platform way to develop things. Adding few native UI elements in addition should not take much efforts. Flutter is when one do not want to use Webview in the first place.
- ToddWBurgess 5y ago
  Flutter dev here. The Flutter webview is basically a wrapper for the native iOS and Android implementations. A native Android app using a webview and a Flutter app running on Android using a webview is using the same native webview. It is like that for a lot of the Flutter libraries. They basically implement native versions of the functionality and make it available to Flutter. The Dart language has FFI so if you want to get "even more native" you can do Android and iOS system calls in your Flutter app using languages like C, C++, Rust or even Assembly.
  - mwattsun 5y ago
    I was really drawn to Dart when it came out in 2012 and still use it for hobby projects. I know Google uses it internally a lot and is used in the experimental Fuchsia OS. And of course Flutter. I wish Google would put more resources into doing the next version. It appears Bob Nystrom is the only person working on it https://old.reddit.com/r/dartlang/comments/rvqivf/what_is_the_fate_of_the_records_feature/hrahfwa/ https://old.reddit.com/r/dartlang/comments/rvqivf/what_is_th... I wrote a fairly complicated web app in 2013 in Dart. I just updated it to Dart 2.0 and nullability and it still works, which impressed me. Someday people will catch on to Dart, probably if and when Fuchsia gets popular https://fuchsia.dev/ https://fuchsia.dev/

npunt 5y ago

Worth noting this article is almost a year old now (Feb 2021), prior to Flutter 2.0 which supports web-based apps with CanvasKit. Flutter was only officially (1.0) launched 3 years ago.

candiddevmike 5y ago
I have read a lot of feedback that, while flutter web is now stable, it seems a little premature. The performance of canvas rendering with flutter appears to be universally bad, especially on mobile, and there are some UX issues around scrollbars, insane bundle sizes, and long initial load times. Anyone have some success stories of using flutter web? I read you can output HTML/CSS/JS instead of canvas and a lot of these issues go away, is that true?

wiradikusuma 5y ago

"After some research.. ..I decided to give it a go." Hmm.. From my experience, every time I pick a new language / framework, always always always do proof-of-concept for ALL features you might need: camera, GPS, webview, deeplinking, etc. Don't want surprises. Esp. if you already have an existing app, you should have a clear visibility of what's needed.

vood 5y ago

Can you explain why mobile developers run away from third party components? I'm a full stack/data engineer and use third party components all the time. In fact, I'd choose a popular and maintained component for the job, instead of writing it myself. I have no issues using as many components as I need. This seems like a bad practice in mobile. If I encounter a bug in my dependencies, I find it, fix and send the fix to the maintainer. The same as I would do with my own code.

jefflinwood 5y ago
In this particular case, the problem is that the plugins require Dart glue code, and a native implementation on both iOS and Android. So if you run into a problem with a component, it's much more complicated to fix it. In general, using third party components with native mobile apps is pretty straightforward.
- kitsunesoba 5y ago
  Even for full native, I try to keep the number of third party dependencies down and limit them to libraries that fill legitimate voids in system functionality or are only light sugar around system stuff for a few reasons: - Many libraries have zero guarantees as to how long they’ll be maintained or if their maintainer(s) will keep pace with new system releases, build tool changes, etc - It’s less unfamiliar code that I’ll need to wade through at some point - Fewer libraries reduces lock-in that can encumber refactors and other major changes - I don’t have to waste as much time and energy “translating” things between different libraries with related functions I used to not be as avoidant of a long dependency list, but over the years I learned that for both iOS and Android, each library represents a liability across multiple dimensions that WILL become a problem at some point, probably sooner than later. Mobile platforms aren’t like their desktop/server counterparts where the various APIs have barely changed in decades, and they aren’t like the web where everything continues to be supported for practically forever. Things change, and it’s important to be able to keep up with that. This is a lot easier to manage under iOS than under Android, incidentally. Cocoa Touch still sees tweaks but it’s quite mature, and very deep and capable. You can build a world class app with just Cocoa Touch alone without too much trouble. With Android Framework on the other hand, much of what’s built in is incapable, with bits and pieces constantly shifting in and out of being supported, making it the norm to bring in a laundry list of libraries for super basic stuff (e.g. everybody uses Square’s OkHTTP for networking on Android while on iOS, not using the built in URLSession and associated APIs is very strange).

intrasight 5y ago

I've been doing cross-platform development on and off for 30 years. Back in the DataViews days we had a team of two dozen professionals working on this problem and made good bank selling developer seats for about $15K each. Flash forward 30 years, and here's what's changed: 1. Users expect this stuff for free 2. For the most part it is, but only because the tools are being developed by big-tech and serve their interests more than yours What hasn't changed: 1. compile-time. I just don't get it. Computers are like 5000x faster 2. cross-platform is hard and involves lots of compromises 3. it's hard to make money selling tools

jmnicolas 5y ago
> and made good bank selling developer seats for about $15K each. > 1. Users expect this stuff for free I learned Flutter for my own needs, I make about 25k€ / year after taxes, I couldn't afford to pay this kind of money for hobby stuff. Even Embarcadero stuff at 5k a seat is way too much (I can get a good used car for this price). Even at work I have to fight to get better hardware than Raspberry Pis (they regularly have black screens that only a few hard reboots solve). The problem is that we don't live in the same world: there are companies where money flows and other companies where every cent has to be justified because money doesn't grow magically under unicorns hooves ...

yesimahuman 5y ago

You mention Ionic at the end, so I have to comment as the co-founder :) The first thought is on maintenance and support from Google/Facebook compared to someone like Ionic. One of the things people don't think about before it's too late is support, and Ionic is unique in mobile in that we actually make money from supporting our technology directly for customers. We have direct support available for our auth/security/data storage plugins, cloud services, and open source projects. We literally will respond to customer support tickets and make fixes/patches on a weekend if we have to. Is there any other company out there doing what Ionic is in mobile? You mention having issues with the Web View component, is Google or Facebook ever going to prioritize your issues? It's not likely, they don't have that kind of business model around their technology like Ionic does. Facebook builds RN for itself, and who knows what Google's end-goal is with Flutter (drive GCP adoption? push its ad network?) but it's certainly not to monetize it through dedicated support for the most significant users of it. I'm proud that the Ionic stack is the most user-aligned offering out there because we're literally in the business of supporting and extending users of our OSS stack. On the Web View side, we've recently shipped one of the first mobile micro-frontend projects in the ecosystem called Ionic Portals which is basically an awesome Web View component powered by our tech and expertise building web view experiences on mobile. Right now it doesn't have RN or Flutter bindings but we are working on them this year. This has been a pretty interesting shift for us and we're now working with traditional native teams not using the traditional Ionic stack: https://ionic.io/portals https://ionic.io/portals

nvahalik 5y ago
> We have direct support available It would be great if Ionic offered consulting for things like Cordova -> Capacitor migrations. However, the last time I talked to sales it seemed like the best we could get was a report on what plugins we could or couldn't use with Capacitor. > we're literally in the business of supporting and extending users of our OSS stack Can you define that a little bit better? Because I've contacted Ionic sales before about seemingly well-used but under-maintained plugins and was basically told we were on our own. AppFlow isn't a horrible product—but the recent price increases gave me a sour taste. What am I getting for my money? OK. I'm getting a build system which is nice, but I can't stomach paying the new (nearly 10x) price just to be able to do things like kick off builds from CI or the CLI. What I _would_ pay for is help with other OSS plugin issues, consulting to migrate to Capacitor, training and help with maintaining custom projects, or better yet general development support when things go south (like the dreaded white-screen of death). Anyway, we've been happy with Ionic and are always excited to see things improve. I don't mean to be downer—rather I'd love to give you guys money so long as it makes sense!

intrasight 5y ago

Honest question to those who've been there and don that. What's the right solution path for a very small (3-4 people) team to build a relatively polished mobile app? Options I see are: 1. Native iOS followed by Native Android 2. Flutter 3. React Native 4. Capacitor 5. Microsoft toolkit of the day I may soon embark on such a task with such a small team. I am leaning towards #1.

ToddWBurgess 5y ago
I work on a Flutter app with a small team that does both iOS and Android from the same code base. It works really well for our use case given the size of our team. I also have experience with both native Android and iOS. The way Android and iOS handle apps is completely different and jumping between the two requires a lot of mental context switching. Something to think about is all mobile apps come with the typical boilerplate. Think about a screen that displays the results from a REST call. You will need to create the screen for the Android app using either XML or Jetpack Compose frameworks. The iOS will need to create a screen using storyboards or SwiftUI frameworks. That is a lot to maintain. With Flutter you create the screens just once in Flutter and the only framework choice is Flutter. Now at some point in the future when the REST call adds a new field you have twice the work to do with native solutions then you do with Flutter to add it to your screen. I would also like to correct misconception about Flutter. Flutter doesn't eliminate the need to do cross platform development. You still need to know the native tooling, native build cycles and native programming languages if you want to get a Flutter app out the door.
- intrasight 5y ago
  So how does Flutter really help vs just get in the way - if you have to "do cross platform development" anyway?
  - ToddWBurgess 5y ago
    You will end up writing less code. You won't have to tackle advanced subjects like managing app state in Android and iOS. You can use a Flutter state management solution that works on both platforms. You won't have to feature match your two apps because they will all use the same code base. If you are a small teams looking to get something out the door, all of these are points in favour of Flutter. It works better for teams will constraints such as team size, budget and time.

pjmlp 5y ago

Just embrace C++ for business logic (supported natively by both SDKs) and use native views, and for most CRUD apps, mobile Web works just fine. Anything else, might look enticing, however as the author points out brings lots of attrition and failures can happen at any level of the stack, thus requiring native programing knowledge to sort them out anyway. So instead of being experts in two stacks, the team now needs to be expert in three stacks.

zerr 5y ago
The thing is, for most mobile apps, 99% code are views, with a very tiny part that can be called "business logic". Doesn't really make sense to involve C++/JNI bridges hassle.
- pjmlp 5y ago
  Hence my remark regarding CRUD apps and mobile Web. Even if native views are required, the business logic can be driven from Web APIs, or DSL like JSON files.
- aaaaaaaaaaab 5y ago
  If your app is like that, then maybe it shouldn’t be an app at all, rather a website.
- therockhead 5y ago
  > C++/JNI bridges hassle For the projects I worked on, the bridges were automatically generated, so no hassle for the developer. Admittedly we built our own code gen system which of course was not free.
bbkane 5y ago
Dropbox used to do this but eventually abandoned it, due to the cost of maintaining C++ code that works on multiple platforms. Turns out that might be more difficult than maintaining native code for each platform. https://dropbox.tech/mobile/the-not-so-hidden-cost-of-sharing-code-between-ios-and-android https://dropbox.tech/mobile/the-not-so-hidden-cost-of-sharin...

zerr 5y ago

As a side note, for some reason, cross-platform frameworks such as Flutter are quite popular in developing countries.

ToddWBurgess 5y ago
My theory on why Flutter is popular in developing countries is a Flutter app compiled in release mode is turned into AOT code. This gives it a performance boost on apps that are constrained by low CPU and memory resources. I expect that that most HN users probably have a flagship mobile phone with lots of CPU, RAM and reliable mobile data options. The other 90% of the world can not say that and a lot more sensitive to apps that require advanced phones and operating environments to function.
- jmnicolas 5y ago
  Wouldn't it be more logical to build only for Android then? There probably are few Apple devices in developing countries and native is much faster than Flutter. There's a video on YT where a guy (from India I think) shows the starting time of a todo app built with RN, Flutter and native. Native is lightning fast.
  - Apocryphon 5y ago
    Platforms are international. If they can target both platforms along the way that allows them to crack into the more lucrative iOS market.
higerordermap 5y ago
I am from India and pretty sure the reason here is it's much easier to make UIs in flutter than in Android native. Nothing specific to India being a developing country. It's natural to see students using easier stuff as well. Most of student projects you come across is using react, flutter, firebase, MongoDB, as opposed to Angular/Vue, Android native/Jetpack, postgresql etc.. which have much higher barrier to entry. But this may have to do with developing countries having more recent developers, and less established developers.

asdev 5y ago

it's amazing to me how crappy the mobile development experience is in 2022 with any technology(React Native, Flutter, native)

datavirtue 5y ago

I tried Flutter for two weeks before hoping out hard. Can't put my finger on it but the combination of chaining everything into a huge nested pile of shit and....Google really turned me off. I was far more productive in Xamarin Forms. "Any piece of code that is not your own and that your app depends on adds to the technical debt of your app." We need to start pulling in dependencies as code instead of binaries. It should become part of our project and we should remove that which we do not need and maintain or patch those parts that need it manually...one our own. The number of dependencies in projects cause a great deal of bloat, cross-cutting nightmares, and unending security vulnerabilities that make us desperately seek support in the form of new binaries from unpaid contributors. It is not professional, dignified, or safe. If you need StringUtils.isEmpty you should not be pulling in the apache commons jar. Just clip the code you need and squirrel it away in your project.

davidkhess 5y ago

I find Qt/QML for cross-platform mobile applications to be a great solution. It uses the same basic architecture as Flutter – they both do not use native widgets and instead draw the entire UI on a blank graphics canvas. I think that approach preserves the most code between platforms and reduces the kinds of presentation hitches that HTML web view and hybrid native widget approaches can run into. In relation to the particular problems of technical debt related to third party modules mentioned in this article, QML rides on top of Qt which is a 26 year old C++ cross-platform toolkit with a lot of mature technology in it. I.e. there is a lot more "batteries included". There are still plenty of times you have to "go native" to integrate something Qt doesn't cover but it apparently isn't as often as with Flutter.

arthur_sav 5y ago
Can you give me an example of a good mobile app built with Qt/QML? I feel like only big corps can justify such apps where users have no choice but to use it because their boss forced them to.
- davidkhess 5y ago
  I built the initial version of this app for a startup: https://apps.apple.com/us/app/listeners-on-call/id1498666617#?platform=iphone https://apps.apple.com/us/app/listeners-on-call/id1498666617... It has a very good UX designer and I've developed multiple commercial Qt/QML mobile applications previously. I think the economics make sense with the following assumptions: * The startup doesn't have the resources to build for two platforms natively (yet). * The developer(s) can get their hands dirty and "go native" on either platform when needed.
  - arthur_sav 5y ago
    User review: "Tried using the app- no listeners were available. Cheaply made." Users know. That's why most of these apps die within 1-2 years. Have you used any airline app? Have you used any "cross platform" bank app? I've actually switched banks because i preferred the one with the better mobile app. A bad app just shows how outdated they are. Not saying there's no demand for building such apps, businesses clearly don't care (yet). When they start losing business they'll have to care.

arthur_sav 5y ago

I've built both native and cross platform apps. People and especially managers think that cross platform apps will save them money/time. However, they don't realisize that cross platform solves one problem and creates ten. The developer experience is worse, the user experience is worse and you end up with a pile of mess after 1-2 years.

WA 5y ago
I have an Ionic app used by thousands of people daily since 2017 on both, Android and iOS. There are certainly some downsides, but it really didn’t create 10 problems for every solved one. Ironically, I have an older native iOS app and it briefly stopped working on iOS 14.5 for no reason with the message "developer needs to update this app", like when apps had to switch to 64 bit. A few months later, the very same app started to work again in a later iOS version. I follow a few native iOS devs on twitter and it looks like they have to deal with quite a lot of shit in Xcode and Swift all the time. I don’t. My app has been running pretty stable. And yes, dev saves time. One code base for 3 platforms, dev experience is pretty great (hot code reloading, same IDE for all platforms 98% of the time).
- arthur_sav 5y ago
  Then it suits your use case. I've basically made a living from re-writting cross platforms apps back to native. Company creates cross platform app. They get some traction. They try to scale but it becomes harder every day. They hire me to go native.
aaaaaaaaaaab 5y ago
Managers are incentivized to show pretty numbers about code reuse and platform feature parity to upper management, because that’s how they get their bonuses. Also webdevs are cheaper than mobile engineers. Upper management gets soaking wet from stuff like this.

deleted 5y ago

[deleted]

sysOpOpPERAND 5y ago

i love working with flutter and dart. really hoping the job market opens up more for those. one major annoyance for me is having to create a class to handle the data from a json. i would love to see dot notation access to keys like how javascript handles json, it turns it automatically into an object after using .json() but overall i enjoy working with it and it is always good to see posts popping up on HN about it

timsneath 5y ago

Tim here from the Flutter team; thanks for the post. There are some good points here: in particular, that no single framework or toolkit is the "holy grail". We all live in a world of trade-offs, and anyone who claims that any single technology is the panacea for all problems is selling a mirage. I really appreciate the constructive critique in the article: both the good (getting an app up and running quickly), and the more painful to read ("Flutter's ability to execute leads a lot to be desired, particularly on iOS"). While Google is the primary sponsor for Flutter, it's an open source project, and so as ever having reproducible bug reports and ideally pull requests is how we make it better. The raison d'être for Flutter is simple: we don't think you should have to write the same code six times for your app to reach each major desktop, mobile and web platform. This abstraction is not free, but we think it's worth the bet, and there are some cool apps being built with Flutter, plenty of which have been awarded accolades like Apple Editor's Choice. We're not the solution for every app out there, but there are startups who don't have the developer team size to build multiple apps but can benefit from Flutter, as well as larger companies for whom Flutter lets them unify their app development team behind a single codebase. A few quick comments I wanted to make: - Yes, we have a large number of open issues -- over 9,000 at the last count, but not all issues are bugs. We're somewhat unique in bringing together tools, packages, framework and engine issues into a single database, also merging feature requests, bugs and even API doc requests together. Our general philosophy is that it's better to have it out in the open rather than (for example) to prematurely close issues that we don't plan to work on ourselves. We're also not unique as a large open source project in having lots of open issues (also see projects like PyTorch, Rust and VSCode). Lastly, it's important to count the number of issues _closed_, which is over 50,000, representing bugs fixed, new features implemented, and so on. We document the triage process here: https://github.com/flutter/flutter/wiki/Triage https://github.com/flutter/flutter/wiki/Triage - I'm surprised that the author considers packages an inevitable weakness. We've deliberately kept the core of Flutter relatively small, because it enables us to iterate on packages at their own pace. We could have taken the approach of building things like XML parsing, HTTP servers, geolocation and so on into the core of Flutter, but it wouldn't automatically make them more robust. With a package model, we can fix a specific issue without requiring a whole release cycle for every part of Flutter. Over the last year since the author wrote this article, our package maturity has greatly improved, and I'd be interested to know whether this is noticeable. - Lastly, the underlying fear expressed in the article seems to be that Google will at some point just give up with Flutter. I understand this, since we don't have an immaculate reputation in terms of long-term support. I will say that this question doesn't come up internally with our stakeholders, though. There are over 400,000 apps in the Play Store that use Flutter; about 1,000 Google engineers building highly-strategic products using Flutter; and a healthy ads revenue from apps that use Flutter. The project more than pays for itself, and I can't honestly envisage any scenario in the next decade where Google would choose to squander all that. Keep the feedback coming: we're listening.

awinter-py 5y ago

xcode is the opposite of a tool and it is somehow getting worse with age. apple has exactly one job and apparently it's to make xcode into a hot pile of garbage. flutter is like terraform. Is dart a good language? No, it's a piece of shit. Most languages are. Dart, moreover, is the reason the google ads dashboard melts your laptop. But it saves you from the peril of directly gazing upon something much, much worse. ios devs all have stockholm syndrome and will tell you 'it's not that bad' as they upgrade their dependencies for the 60th time to keep up with some unnecessary framework change aapl is forcing them to do because nice app store ranking, shame if something happened to it

chubs 5y ago

Apologies for the naked plug, but I've had so many clients over the years try and fail to get cross-platform apps to work that i'm currently working to try make something that will actually work, freed from the incentives of the big companies pushing eg flutter and RN. It's slow going however... if you think there's a future in this kind of thing, consider asking your boss to sponsor it to help speed development? The idea is to write in a Swift-ish language, compiled to native code on both platforms, and wrap the native components, but do it in a way that learns the lessons from eg RN's difficulties to include a sensible cross-platform navigation component. (the project is github.com/soniclang/sonic)

egberts1 5y ago

And the holy grail of writing an app for all mobile platforms shall remains … illusive (and elusive as well).