From what I understood, and granted I could be far off, but can't you use Swift to develop your iOS app and then use Flutter to port over to Android?
Flutter uses Dart. You can use Swift on iOS (and bridge that code back to Dart). However, that Swift code will be for the iOS version of your app only. You'd need to write the equivalent code in Java for the Android version of your app. At which point you might as well just forgo Flutter altogether since you're maintaining 2 different versions of your app.
The big reason for using Flutter is if you're able to write your entire app (or the vast majority of it) in Dart using the Flutter framework.
Ah, thanks! I figured you understood better than some commenters.
yeah still no. If anybody remembers cross-platform apps like PayPal (I haven't used it in years) they're always weird-feeling, because they don't use all the native motifs. I beta tested one for some friends and it was clearly designed by Android guys who just didn't get how apps should look & feel on iOS, re-inventing new ways of working that weren't needed, ignoring 3D touch, still no X support, etc.. Just alien imposters.
You're not a developer are you? Just curious. Hoping actual experienced devs will chime in after looking at the documentation.
Well, it's nothing new, which is not a bad thing, so it really depends on whether they've done a better job than everyone else.
The use of a rendering engine probably means that they will be able to control the look and feel across each platform, so there should be less need to drop out and fix something because of dodgy rendering. They can also craft their own widgets, which gets them away from the lowest-common denominator approach that the earlier frameworks suffered from.
The problem with the rendering engine is that it'll have to get bundled with each app. You're basically looking at an app running on top of a small operating system running on top of larger operating system, so the chances are that this is going to be used by the same folk who use existing cross-platform frameworks: Banks and the like, who can keep their costs down Social media outfits who make their money from a service (Facebook, Twitter) but need cheap apps to allow their users to access the service.
Games? Probably not. High end award-winning innovative apps? No.
But the vast majority of applications are just for entering stuff in and reading information back, which is okay for something like this. I personally would always use the native toolkit. Have a clean separation between your operational logic and your frontend. It'll still be more work than a cross platform framework, but the results will be faster, use less memory and look better for each platform.
Tools like these usually make the devs life easier, but often at the expense of a decent user experience.
Oh, I'm sure folk are using it. As I said, this is nothing new. We’ve had Ruby Motion, Xamarin, and a whole host of apps that are little more than web pages running inside an app frame. I've always had sneaking suspicion that about half the apps on the app store are non-native. And in most cases it shows.
But for me, the best solution is always a conscientious developer and a good native framework.
Apple should be careful here. If a google controlled cross platform language starts to dominate a few things will happen.
Firstly the design language will be android first or only. Secondly if it predominates then new iOS features may lag. It depends on the Dart language bothering to implement them.
Thirdly general mobile devs are less likely to care about how god their iOS skills are and won’t necessarily be watching WWDC for the next big thing. Instead it will be the dart conference where google will tell them they can now use that iOS 12 feature, 3 months later.
Theres a push to conformity in mobile dev already which is unsatisfying and could harm iOS as a pre dominant platform.
I don't see Flutter or any cross-platform language dominating...
First, quality developers will write platform-specific apps using the best tools, languages, APIs, etc for the target platform.
Second, more mediocre developers will use the higher level cross-platform language to create LCD apps for multiple platforms that are (or maybe) just good enough -- but won't run well on either platform.
Third, the maybe just good enough apps won't sell, or if free -- won't be used.
There are too many good iOS apps to waste time trying to use an LCD app.
Unfortunately a lot of people don't care. I mean slack is basically a website pretending to be an app. To be fair it is not that bad but it is huge.
Just what we need, Android ports to iOS. Remember those Windows ports to Mac OS...? Let me guess. Google will encourage developers to build their Android apps and then port them to iOS using Flutter where they will look goofy and not perform as well.
Or they can develop for iOS first and easily port to Android too using Flutter. I know we have a few dev's here who can comment with more insight.
I haven't looked into it deeply, but here's a key point:
Developers create the code of the app in Dart, which is then passed through Flutter's rendering engine and framework, with both tools used to make the code work on each platform natively. The engine is shipped as part of the app package, along with the developer's code, which is used to run the app on the target device, like an iPhone or an Android tablet.
So basically you develop in a programming language which isn't native to iOS (Dart), which then requires you to bundle a special engine with your app to translate the application UI + logic from Dart into the native iOS APIs. Sounds a lot like programming in Java. I've used a few of these types of cross-platform runtime translation engines over the years, and the problem for me is that you'll never get access to the latest platform features because you're always waiting for the engine to support them. And, of course, if such features aren't available on every platform the engine supports, then you may never get access to them. Or you'll have to do a bunch of work to get access to them -- e.g. create your own JNI libraries in Java.
EDIT: Found the process for how to get access to native iOS features (looks a lot like creating JNI libraries): https://flutter.io/platform-channels/
These engines are perfectly fine for simple apps which are doing common things, but not-so-great once you want to get outside of that sandbox and do more interesting things which require platform features which don't fall in that platform common denominator scenario. But since most of Google's apps just go out to the web/cloud for everything they do, it works for them.
Also, QA must be a bitch... That seems to be made for small projects.
There is a huge retroaction loop between testing and various integration stage and this seems like it would put a huge wrench into the equation and introduce another stage of hurt and bugs into the whole thing.
Already right now, dealing with "frameworks" and "middleware" and "deployment platforms" and etc etc etc means development, especially enterprise level dev, is mostly dealing in more and more friction.
All those components were supposed to help reuse, performance and reduce bugs, but right the amount of complexity added means it has become very hard to understand large high performance platforms without getting a splitting headache.
Harder to understand means eventually no one wants to fix it, or wants to upgrade it and well, it dies.
I've dealt with those kind of brillant things, usually suggested by some marketing genius we hit all platforms to make "mo money", and devs HATE THEM WITH A PASSION cause they know they'll be tearing their hair out keeping the whole rickity patched up thing together and will be hobbled by having to produce a similar software for Android and IOS but having to code with a hammer in one hand while they could be doing precision work instead.
yeah still no. If anybody remembers cross-platform apps like PayPal (I haven't used it in years) they're always weird-feeling, because they don't use all the native motifs. I beta tested one for some friends and it was clearly designed by Android guys who just didn't get how apps should look & feel on iOS, re-inventing new ways of working that weren't needed, ignoring 3D touch, still no X support, etc.. Just alien imposters.
You're not a developer are you? Just curious. Hoping actual experienced devs will chime in after looking at the documentation.
Good one. I’ve been a Fortune 100 enterprise developer for almost twenty years and a Webby-winning dotcom webdev before that. We went thru all of this back when it was Java, with the same claims and the same complaints in the end. Native is better and will always be better than cross-platform-kit apps.
Thanks. It was an honest question since I don't recall you mentioning it before. So then you've looked at the documentation, made a bit of sense of it all? Assuming a bad experience with one means a bad experience with all may not be an accurate way of gauging it.
From what I understood, and granted I could be far off, but can't you use Swift to develop your iOS app and then use Flutter to port over to Android?
I usually mention it in the MBP discussions when people argue they aren’t pro enough for pros. Per Apple’s data most of their pros are software devs based on installed tools (Xcode).
Nope, didn’t read this product’s documentation and have no intention to. The pros & cons of write once/run anywhere are likely the same regardless of trendy tool to do so. Even if I wrote it native for iOS and Flutter ported it to Android it wouldn’t be as good as a native Android app. Code and app chrome aside there are even different use patterns/conventions on different platforms.
Comments
But for me, the best solution is always a conscientious developer and a good native framework.
There is a huge retroaction loop between testing and various integration stage and this seems like it would put a huge wrench into the equation and introduce another stage of hurt and bugs into the whole thing.
Already right now, dealing with "frameworks" and "middleware" and "deployment platforms" and etc etc etc means development, especially enterprise level dev, is mostly dealing in more and more friction.
All those components were supposed to help reuse, performance and reduce bugs, but right the amount of complexity added means it has become very hard to understand large high performance platforms without getting a splitting headache.
Harder to understand means eventually no one wants to fix it, or wants to upgrade it and well, it dies.
I've dealt with those kind of brillant things, usually suggested by some marketing genius we hit all platforms to make "mo money",
and devs HATE THEM WITH A PASSION cause they know they'll be tearing their hair out keeping the whole rickity patched up thing together and will be hobbled by having to produce a similar software for Android and IOS but having to code with a hammer in one hand while they could be doing precision work instead.
Nope, didn’t read this product’s documentation and have no intention to. The pros & cons of write once/run anywhere are likely the same regardless of trendy tool to do so. Even if I wrote it native for iOS and Flutter ported it to Android it wouldn’t be as good as a native Android app. Code and app chrome aside there are even different use patterns/conventions on different platforms.