I hope that Apple finds a way to block this shit. Follow the iOS rules or fuck off. Man i hate Windows shit on my Mac and i hate Android apps on iOS. And of course Apple also made some shity software. For example iTunes.
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.
"Write once, run anywhere!" they said...
AIR, that phrase was later amended to "Write once, debug everywhere!" That says it all...
And feel right nowhere.
LOL... guess we'll have to amend the phrase again!
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.
Google blinked. They should be pushing devs to use their 1st party native APIs. That strategy can't be working, so instead they are trying the well-worn path of cross-platform compatibility to coax developers to their platform. Developers would seem to win, and not-so-great apps are better for your ecosystem than no apps; but users dislike sub-par applications and eventually migrate to developers using native APIs.
File this alongside Flash and Java Swing. There's a long line of attempts by smaller ecosystems to obtain more apps when faced with a more successful competitor, from OS/2's DAPIE to Microsoft paying for Windows Phone ports. There's no reason to think this attempt will do anything to stem the market's iOS-first approach.
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.
And I did. The link you gave me was exactly the same site as the one I edited my post with. Just a bit deeper down into the part of the documentation where it talks about how many hoops you have to jump through to mix native iOS code (written in Swift or Obj-C) with Dart. I'm trying to go deeper, but you're still believing we're on the surface.
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.
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.
"Write once, run anywhere!" they said...
AIR, that phrase was later amended to "Write once, debug everywhere!" That says it all...
Flutter lets you reuse your existing Java, Swift, and ObjC code, and access native features and SDKs on iOS and Android.
If Flutter is like the other middlewares, only when Flutter is updated to support the new APIs and hardware features will you be able to utilize them. It’s never been instant as the middleware platform itself must be updated to support the target platform features.
Nothing new to see here. Cross platform middleware layers that work with native code support, e.g., Xamarin, have been around for several years and are core to Microsoft's app development toolsets. These all support the most popular modern programming languages like modern C++, C#, Swift, Python, etc.. There's also a plethora of web technology based middleware like PhoneGap to provide cross platform app execution environments. These tend to support languages like JavaScript and execution models like Node.js. All of these are quite mature and developers have a great deal of flexibility in choosing and mixing & matching languages, toolkits, protocols, development tools, etc.
I've never found a one-size-fits-all technology that is without compromises that ultimately limit its appeal. In fact, I've never seen a single language or toolset, much less a big conglomeration of things like Xamarin, .NET, or the many similar tools that resemble what Google is offering, that lives up to all of it's promises. This technology changes so often and is ultimately so huge and complex that developers struggle to reach proficiency in any one area, much less the 5 or 6 areas that a cross platform framework require. The promises always reach far beyond what most development organizations are able to achieve, and in the midst of these struggles, yet another cluster of technology arrives that promises even more. I've seen this pattern repeating constantly since at least the early 1990s with frameworks that offered cross platform GUI compatibility from a single (app) source code base for DOS, OS2, Windows, MFC, Borland (Windows), and Turbo Pascal.
Is that even allowed, for iOS? I thought one needs to develop with Xcode/Swift for iOS - no porting. I must be missing something.
You still have to use Xcode. Flutter generates Xcode-compatible code.
What version of Xcode? The latest release of Xcode is 9.3 Beta 3... Prolly, new release in next month.
What about Swift? Latest version of Swift is Version 4. Swift Version 4, likely, will see quite a few dot releases this year as the language implementors focus on ABI Stability.
Even Swift 3 is evolving as certain dot releases are no longer supported and many language constructs are changed or deprecated.
What about evolving APIs -- ARKit, Airplay 2, for example?
My point here, is that just generating Xcode-compatible code is not and end result -- rather it is a starting point for making a Flutter App run on iOS. If you want anything but an outdated, vanilla iOS app, you will have to exploit the latest, hardware, languages, APIs...
If you do that then you will have created a separate codebase customized/optimized for iOS and iDevice hardware... With no way to push that codebase up the chain to Flutter. It is unlikely that you would update your customized/optimized app with Flutter -- as you'd just generate more outdated, vanilla code and have to repeat the customization/optimization.
Dick. I offered you a partial answer in Post 18. The rest of the documentation which probably answers any other questions you have at the moment is here: https://flutter.io/
...and note that this is still in beta anyway and no doubt there are improvements and optimizations still coming.
Mmm... Been down that path (High-Level Code Generation) many times before don't care to go down it again.
For example in 1960, I went to work for a Lockheed subsidiary as the only programmer for an IBM 1401 Punched Card Computer. IBM provided several high-level code generators: Faster; RPG; CoBOL -- as well as a low-level symbolic programming language.
I vividly remember when IBM dropped 1401 CoBOL, because it had a square root function that was needed for an upcoming app... So I gave it ago...
Long story short, the app compiled fine, but wouldn't run... The high-level CoBOL generated square root subroutine took over 3K of memory... our 1401 had only 2K of memory.
To solidify the significance of this -- I was able to adapt an iterative square root process form a [punched card] calculator that did the job. It was simple, straight-forward and, AIR, took about 100 characters of memory.
FWIW, the link you provided was mostly Java (or Android) cod)... Never did like the language for [client] computer apps (OK for servers)... And I don't (won't) type semicolons anymore. The syntax of both Java (Android) and Objectve-C is too verbose -- difficult to write, read and maintain. With all its evolutionary changes, I prefer Swift!
If Flutter is like the other middlewares, only when Flutter is updated to support the new APIs and hardware features will you be able to utilize them. It’s never been instant as the middleware platform itself must be updated to support the target platform features.
^^^This
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.
I've never found a one-size-fits-all technology that is without compromises that ultimately limit its appeal. In fact, I've never seen a single language or toolset, much less a big conglomeration of things like Xamarin, .NET, or the many similar tools that resemble what Google is offering, that lives up to all of it's promises. This technology changes so often and is ultimately so huge and complex that developers struggle to reach proficiency in any one area, much less the 5 or 6 areas that a cross platform framework require. The promises always reach far beyond what most development organizations are able to achieve, and in the midst of these struggles, yet another cluster of technology arrives that promises even more. I've seen this pattern repeating constantly since at least the early 1990s with frameworks that offered cross platform GUI compatibility from a single (app) source code base for DOS, OS2, Windows, MFC, Borland (Windows), and Turbo Pascal.
I have created my app development company in 2012. All the apps, mostly cloud based applications, are
developed on both platforms simultaneously. And in a lot of cases a web
based client is also developed.
Google is not the first company that
creates a tool that allow cross platform mobile development environment: Ionic, Xamarin, Cordova, Reactive native, ... are other
implementations.
My experience with these tools is that they are
great for certain types of apps (like a notes app), but not suited for others (like games). In case
they are suited, they give a cost saving of around 30% compared to a double
native development. I'll have a look at it, but I am not sure I am going to use it.
So really, the only thing you need Xcode for is to create a signed application bundle which can be submitted to the App Store.
Apple has imposed some recent restrictions for iOS apps, such as no 32-bit apps, and all iPhone apps must support iPhone X. How does Flutter support this? How quickly will the solution be implemented?
Also, does Flutter support the AppleWatch and the AppleTV?
So really, the only thing you need Xcode for is to create a signed application bundle which can be submitted to the App Store.
Apple has imposed some recent restrictions for iOS apps, such as no 32-bit apps, and all iPhone apps must support iPhone X. How does Flutter support this? How quickly will the solution be implemented?
No 32-bit apps is easy since all they need to do is make sure the ARM code they generate is arm64 (and their C++ libraries are compiled into arm64).
As for supporting iPhone X, I guess their widget layout engine just needs to handle doing layout properly for the iPhone X. Really, under the hood, all their engine is doing is pixel rendering (much like a game) and input handling. Then they build up the abstractions like buttons, text edit boxes, etc (widgets) on top of that (the Flutter framework).
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.
And I did. The link you gave me was exactly the same site as the one I edited my post with. Just a bit deeper down into the part of the documentation where it talks about how many hoops you have to jump through to mix native iOS code (written in Swift or Obj-C) with Dart. I'm trying to go deeper, but you're still believing we're on the surface.
I directed that to the comments StrangeDays was making. I already knew you were but you are just one.
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?
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.
So really, the only thing you need Xcode for is to create a signed application bundle which can be submitted to the App Store.
Apple has imposed some recent restrictions for iOS apps, such as no 32-bit apps, and all iPhone apps must support iPhone X. How does Flutter support this? How quickly will the solution be implemented?
No 32-bit apps is easy since all they need to do is make sure the ARM code they generate is arm64 (and their C++ libraries are compiled into arm64).
As for supporting iPhone X, I guess their widget layout engine just needs to handle doing layout properly for the iPhone X. Really, under the hood, all their engine is doing is pixel rendering (much like a game) and input handling. Then they build up the abstractions like buttons, text edit boxes, etc (widgets) on top of that (the Flutter framework).
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.
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.
Comments
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.
File this alongside Flash and Java Swing. There's a long line of attempts by smaller ecosystems to obtain more apps when faced with a more successful competitor, from OS/2's DAPIE to Microsoft paying for Windows Phone ports. There's no reason to think this attempt will do anything to stem the market's iOS-first approach.
If Flutter is like the other middlewares, only when Flutter is updated to support the new APIs and hardware features will you be able to utilize them. It’s never been instant as the middleware platform itself must be updated to support the target platform features.
I've never found a one-size-fits-all technology that is without compromises that ultimately limit its appeal. In fact, I've never seen a single language or toolset, much less a big conglomeration of things like Xamarin, .NET, or the many similar tools that resemble what Google is offering, that lives up to all of it's promises. This technology changes so often and is ultimately so huge and complex that developers struggle to reach proficiency in any one area, much less the 5 or 6 areas that a cross platform framework require. The promises always reach far beyond what most development organizations are able to achieve, and in the midst of these struggles, yet another cluster of technology arrives that promises even more. I've seen this pattern repeating constantly since at least the early 1990s with frameworks that offered cross platform GUI compatibility from a single (app) source code base for DOS, OS2, Windows, MFC, Borland (Windows), and Turbo Pascal.
For example in 1960, I went to work for a Lockheed subsidiary as the only programmer for an IBM 1401 Punched Card Computer. IBM provided several high-level code generators: Faster; RPG; CoBOL -- as well as a low-level symbolic programming language.
I vividly remember when IBM dropped 1401 CoBOL, because it had a square root function that was needed for an upcoming app... So I gave it ago...
Long story short, the app compiled fine, but wouldn't run... The high-level CoBOL generated square root subroutine took over 3K of memory... our 1401 had only 2K of memory.
To solidify the significance of this -- I was able to adapt an iterative square root process form a [punched card] calculator that did the job. It was simple, straight-forward and, AIR, took about 100 characters of memory.
FWIW, the link you provided was mostly Java (or Android) cod)... Never did like the language for [client] computer apps (OK for servers)... And I don't (won't) type semicolons anymore. The syntax of both Java (Android) and Objectve-C is too verbose -- difficult to write, read and maintain. With all its evolutionary changes, I prefer Swift!
https://flutter.io/faq/#run-ios
So really, the only thing you need Xcode for is to create a signed application bundle which can be submitted to the App Store.
Yes!
Google is not the first company that creates a tool that allow cross platform mobile development environment: Ionic, Xamarin, Cordova, Reactive native, ... are other implementations.
My experience with these tools is that they are great for certain types of apps (like a notes app), but not suited for others (like games). In case they are suited, they give a cost saving of around 30% compared to a double native development. I'll have a look at it, but I am not sure I am going to use it.
Apple has imposed some recent restrictions for iOS apps, such as no 32-bit apps, and all iPhone apps must support iPhone X. How does Flutter support this? How quickly will the solution be implemented?
Also, does Flutter support the AppleWatch and the AppleTV?
As for supporting iPhone X, I guess their widget layout engine just needs to handle doing layout properly for the iPhone X. Really, under the hood, all their engine is doing is pixel rendering (much like a game) and input handling. Then they build up the abstractions like buttons, text edit boxes, etc (widgets) on top of that (the Flutter framework).
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?
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.
https://github.com/Solido/awesome-flutter
Your comments will no doubt be helpful to other devs on the forum.
https://itunes.apple.com/us/app/bendometer/id772557902?mt=8
https://itunes.apple.com/se/app/newsvoice/id1208421834?l=en&mt=8
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.