Google ships first beta of Flutter framework for developing both iOS and Android apps

Posted:
in iOS
Google has released its first beta of Flutter, a mobile user interface framework that intends to help developers create interfaces for their apps on iOS as well as Android smartphones, a toolkit that could speed up and simplify cross-platform app development.




Announced at Mobile World Congress, the beta 1 release of Flutter brings a more refined version of the software development kit to developers compared to its alpha release from last year. The toolkit acts as a middleware layer, allowing developers to create code that can be run on a variety of different operating systems, extending the app's reach to multiple platforms.

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.

According to Google, Flutter is meant to be used for "high-velocity development," with its reactive framework and stateful Hot Reload allowing developers to quickly see the changes to the app as they are coding it. Rich animation libraries, composable widget sets, and an extensible architecture is also touted, as well as high app performance through the use of a GPU-accelerated renderer and native ARM code runtime.





Since the alpha release last year, a number of features have been added to Flutter to make it more useful for iOS development, including support for the iPhone X and iOS 11. Other additions include accessibility features like screen reader support, image format support, the background running of code, and assorted localization and internationalization changes.

The tools have also been updated with support for Android Studio and Visual Studio Code, with the addition of improved stateful hot reloads and a widget inspector for browsing the widget tree. As part of the beta, the framework also works with a pre-release of Dart 2, Google's own programming language, which boasts improved support for declaring UI in code.




It is claimed Flutter has already been used in production apps with millions of installs, including those included in the App Store. Hamilton: the Musical is highlighted as a major app using the framework, and with over 1,000 packages declared to support with Flutter that developers can use to enhance their projects.

Google's plans for the 1.0 release of Flutter are said to include improving stabilization of the framework and scenario completion, with new betas expected every four weeks until the milestone release.
«13

Comments

  • Reply 1 of 48
    Is that even allowed, for iOS? I thought one needs to develop with Xcode/Swift for iOS - no porting. I must be missing something.

    Muntzdouglas baileywatto_cobra
  • Reply 2 of 48
    Let's hope it works as advertised.
  • Reply 3 of 48
    Mike WuertheleMike Wuerthele Posts: 4,441administrator
    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.
    tmaygatorguyjony0douglas baileyracerhomie3
  • Reply 4 of 48
    tmaytmay Posts: 3,666member
    What about Google's adoption of Swift? Is that a first class language for Android OS development?
    watto_cobra
  • Reply 5 of 48
    lkrupplkrupp Posts: 6,959member
    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.
    edited February 2018 motivdevasdasdchabigrob53airnerdMuntzjony0douglas baileywatto_cobra
  • Reply 6 of 48
    gatorguygatorguy Posts: 20,451member
    lkrupp said:
    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. 

    And thanks for the mention of generating Xcode on the fly @"Mike Wuerthele" :)
    edited February 2018 muthuk_vanalingam
  • Reply 7 of 48
    Cross platform tools generally always suck. I will take quite a bit to be convinced that this one bucks the trend set by literally every cross platform tool. It's a dev-focused solution, not a user-focused solution.
    motivdevSpamSandwichjony0cornchipracerhomie3watto_cobrastantheman
  • Reply 8 of 48
    auxioauxio Posts: 1,980member
    gatorguy said:
    lkrupp said:
    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.
    edited February 2018 StrangeDaysSpamSandwichRayz2016croprrob53mark fearingdick applebaumjony0racerhomie3watto_cobra
  • Reply 9 of 48
    maestro64maestro64 Posts: 4,527member
    Wait, I though most developers (well the ones that count) write for iOS first. I doubt the developer are going to use a Google's tools when Apple has already given them great tools for iOS. So how does this help Google get these apps on Android quicker, do they really think developers are going to develop for Android first then port to iOS. yeah Developer have no clue they are making more on the iOS platform.

    It was already said, any app put through this tool will perform poorly on iOS, apple has invested so much to make sure things are optimized on iOS Google have no idea of the internal workings or Apple software and hardware. This is stupid solution by a software only view of the world, programs think everything can be made better with software. This is why Android phones are not keeping up to iPhone
    edited February 2018 motivdevdick applebaumdouglas baileyracerhomie3watto_cobrastantheman
  • Reply 10 of 48
    "Write once, run anywhere!" they said...

    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. 


    jony0racerhomie3watto_cobrastantheman
  • Reply 11 of 48
    Is that even allowed, for iOS? I thought one needs to develop with Xcode/Swift for iOS - no porting. I must be missing something.

    It is, because otherwise Xamarin would not be a thing
    watto_cobra
  • Reply 12 of 48
    asdasdasdasd Posts: 5,283member
    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. 

    edited February 2018 watto_cobra
  • Reply 13 of 48
    "Write once, run anywhere!" they said...

    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...
    SpamSandwichwatto_cobra
  • Reply 14 of 48
    asdasdasdasd Posts: 5,283member
    Hamilton app is a good example. Nothing iOS specific in it  at all. It’s all either android or web based design language. The buttons look wrong. 

  • Reply 15 of 48
    auxioauxio Posts: 1,980member
    "Write once, run anywhere!" they said...

    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.

    It's really for app development shops who want to churn out as many cheap, good enough apps as they can for companies who are mainly using apps as promotional materials for some other business they care far more about than technology.  Not the segment of the tech industry I'm interested in, but there's certainly a market out there for it.
    edited February 2018 cornchip
  • Reply 16 of 48
    gatorguygatorguy Posts: 20,451member
    auxio said:
    gatorguy said:
    lkrupp said:
    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.
    https://flutter.io/
  • Reply 17 of 48
    gatorguygatorguy Posts: 20,451member
    "Write once, run anywhere!" they said...

    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. 
  • Reply 18 of 48
    gatorguygatorguy Posts: 20,451member
    "Write once, run anywhere!" they said...

    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.
  • Reply 19 of 48

    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.
    StrangeDays
  • Reply 20 of 48
    gatorguygatorguy Posts: 20,451member

    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.
    edited February 2018
Sign In or Register to comment.