[cloud_firestore] Xcode build extremely slow
kroikie opened this issue · comments
EDIT (@Salakar): See #2751 for a solution.
Summary of Issue
Simply adding cloud_firestore to pubspec.yaml results in a huge increase in iOS xcode build times. The issue can be recreate with nothing more than a simple flutter create application and minor changes to pubspec.yaml.
MacOS Mojave 10.14.6
Xcode 10.3
> flutter --version
Flutter 1.8.4-pre.91 • channel master • https://github.com/flutter/flutter.git
Framework • revision 8fdd759225 (11 hours ago) • 2019-08-04 00:56:23 -0400
Engine • revision c8f4f5d5cc
Tools • Dart 2.5.0 (build 2.5.0-dev.1.0 9bb446aae1)
> flutter create test_cloud_firestore
> cd test_cloud_firestore
Without cloud_firestore
Just to show that it is specifically the cloud_firestore plugin that causes this issue I will add some other firebase plugins to pubspec.yaml:
firebase_core: ^0.4.0+1
firebase_analytics: ^4.0.2
Now we build the app:
> flutter packages get
> time flutter build ios
....
Xcode build done.
real 0m41.014s
Okay that looks reasonable.
With cloud_firestore
Simply add the latest version of cloud_firestore plugin to pubspec.yaml (no other changes):
cloud_firestore: ^0.12.9
Now we build the application again:
> flutter packages get
> time flutter build ios
....
Xcode build done.
real 6m40.982s
Yes... that is right. A six minute increase in iOS build times just from adding the cloud_firestore plugin to pubspec.yaml. Again, no changes were made to the flutter create generated application, this is simply changes to pubspec.yaml.
Logs
I did confirm that this issue persists on other flutter channels as well as other later versions of cloud_firestore plugin.
> flutter doctor -v
[✓] Flutter (Channel master, v1.8.4-pre.91, on Mac OS X 10.14.6 18G84, locale en-US)
• Flutter version 1.8.4-pre.91 at /Users/taza/Applications/flutter
• Framework revision 8fdd759225 (11 hours ago), 2019-08-04 00:56:23 -0400
• Engine revision c8f4f5d5cc
• Dart version 2.5.0 (build 2.5.0-dev.1.0 9bb446aae1)
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.1)
• Android SDK at /Users/taza/Library/Android/sdk
• Android NDK location not configured (optional; useful for native profiling support)
• Platform android-29, build-tools 29.0.1
• Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)
• All Android licenses accepted.
[✓] Xcode - develop for iOS and macOS (Xcode 10.3)
• Xcode at /Applications/Xcode.app/Contents/Developer
• Xcode 10.3, Build version 10G8
• CocoaPods version 1.7.5
[✓] Android Studio (version 3.4)
• Android Studio at /Applications/Android Studio.app/Contents
• Flutter plugin version 37.1.1
• Dart plugin version 183.6270
• Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)
[✓] VS Code (version 1.36.1)
• VS Code at /Applications/Visual Studio Code.app/Contents
• Flutter extension version 3.3.0
The issue at flutter/flutter#37582 has been closed and moved here. Future collaboration on this issue will be done here.
@kroikie Ok. So does this new issue lose all the traction of flutter/flutter#37582 in terms of user reaction and up votes. From what I gather, that is what determines what gets worked on in the priority queue.
I just want this "new" issue to have the same level of priority as the previous one did, which seemed to be a concern that was pretty widespread in the community.
@walsha2 no we will still refer to the linked issue for reference during triage. The goal is to collect all future FlutterFire collaboration in a single place.
@kroikie Still no solution for this? I have been struggling with this issue for days...
Not sure if others have noticed: this whole "extremely slow" issue didn't exist in Flutter 1.0.0.
Update: Building my application in an iOS Simulator is still very slow (sometimes above 500 seconds) and the problem seems to arise when using cloud_firestore plugin. So now i use my device instead. I build it through Xcode and attach flutter afterwards with "flutter attach -d device name" in terminal.
I also encounter this problem on i7 MacBook Pro. Adding cloud_firestore increased my build time to simulator from 1-2 minutes (60-120 sec) to more than 7-10 minutes and release build on CI to over 15-20 minutes.
Sample output from deploying to simulator:
Launching lib/main_dev.dart on iPhone 11 in debug mode...
Xcode build done. 458,6s
This was not clean build but some changes to dart code have been made. Previous clean build with pod install took over 600 sec.
Edit: switching to current master dropped this number to about 250-270 sec on a clean build!
[✓] Flutter (Channel master, v1.10.15-pre.271, on Mac OS X 10.15 19A602, locale pl-PL)
Same here, I started considering buying new machine...but i see that thats not really the case. Any workaround ? is there any chance to include firestore as pre-compiled binary ?
Here is my flutter doctor and pubspec if its useful, the same issue is happening to me. Very slow to build on iOS
[✓] Flutter (Channel master, v1.10.15-pre.362, on Mac OS X 10.15.1 19B88, locale
en-US)
[✓] Android toolchain - develop for Android devices (Android SDK version
29.0.0-rc2)
[✓] Xcode - develop for iOS and macOS (Xcode 11.2)
[✓] Chrome - develop for the web
[!] Android Studio (version 3.5)
✗ Flutter plugin not installed; this adds Flutter specific functionality.
✗ Dart plugin not installed; this adds Dart specific functionality.
[!] Android Studio (version 3.4)
✗ Flutter plugin not installed; this adds Flutter specific functionality.
✗ Dart plugin not installed; this adds Dart specific functionality.
[✓] IntelliJ IDEA Ultimate Edition (version 2018.1.8)
[✓] VS Code (version 1.39.2)
[✓] Connected device (3 available)
dependencies:
flutter:
sdk: flutter
fluro: "^1.5.1"
flutter_secure_storage: ^3.3.1+1
firebase_core: ^0.4.0+9
# Add the dependency for the FlutterFire plugin for Google Analytics
firebase_analytics: ^5.0.2
# Add the dependencies for any other Firebase products you want to use in your app
# For example, to use Firebase Authentication and Cloud Firestore
firebase_auth: ^0.14.0+5
google_sign_in: ^4.0.11
cloud_firestore: ^0.12.9+5
# The following adds the Cupertino Icons font to your application.
# Use with the CupertinoIcons class for iOS style icons.
cupertino_icons: ^0.1.2
avatar_glow: ^1.0.0
Can confirm the super ugly build times with Firestore too. Sometimes getting like peak 230 seconds on a quite fast Macbook Pro. This is really barely usable at this point. Unfortunately we need Firestore.
This was my latest build
Running Xcode build...
├─Assembling Flutter resources... 4,5s
└─Compiling, linking and signing... 12,5s
Xcode build done. 130,7s
adding @collinjackson for his thoughts on this issue
I found this thread, and its source, having encountered the same problem -- ios build time dramatically escalated after adding cloud_firestore. I didn't clock it, but I know it was well over 10 minutes, perhaps bordering on 20.
Is there anything I can do to assist, keeping in mind I know very little on objc/swift/pods ? Compounded with having to randomly create bridge files and adding/removing use_frameworks, neither of which do I understand when and why and what and just follow whatever google shows me, ios building is becoming frustrating. So, instead of being afraid to look at the code in fear it may break and never build again, what can I offer?
@alevinetx @csells From what I observed, main problem is constant rebuilding. And those firebase libs are compiling huge amount of some C files. I have Core I7 8700, 32GB, NVME hackintosh which is really snappy...but with this, sometimes it takes minutes to build. On my macbook 15" pro late...its kind of impossible to develop, at is so frustrating
Worst thing is that bitrise or codemagic can not be used with cloud_firestore, as it crosses the 20 minutes build time :(
I tried many things but no significant improves. Every archive operation takes forever.
@snadal @rdev-software @alevinetx maybe try to switch to dev channel for now, build times are a bit shorter there. I also couldn't stand so long build times and switched to Android device.
Yeah dev channel is way better currently when it comes to build times.
I also noticed my IPA is significantly larger, 16M -> ~50M, and I haven't changed the way I'm doing the build. I could assume a correlation, but I'm honestly lost right now.
I also noticed my IPA is significantly larger, 16M -> ~50M, and I haven't changed the way I'm doing the build. I could assume a correlation, but I'm honestly lost right now.
So bad that an uploading plugin takes around 35M 😅this really needs to be fixed. Getting build times up to 300 seconds on a 2018 Macbook Pro...
Would just like to chime in and say that I think that in addition to it taking long time to build, it seems like something is broken with the caching as well. If I plug out my phone and then come back to my computer and run "Start debugging" in VS Code again it takes minutes for the "Running Xcode build" step to complete. It's really a productivity killer 😞
Would just like to chime in and say that I think that in addition to it taking long time to build, it seems like something is broken with the caching as well. If I plug out my phone and then come back to my computer and run "Start debugging" in VS Code again it takes minutes for the "Running Xcode build" step to complete. It's really a productivity killer 😞
Yes for me too :( This is why I use the flutter attach command a lot more often nowadays 😄
This is why I use the
flutter attachcommand a lot more often nowadays
I can only use the attach command from VS Code when I'm working on my Add2App Flutter app, it doesn't work for the normal Flutter app I'm working on.
Is there any trick to getting this working?
Yes for me too :( This is why I use the
flutter attachcommand a lot more often nowadays 😄
Is that makes could be reconnected with vscode with the device?
but I was stuck on here.
➜ flutter-test git:(master) ✗ flutter attach
Checking for advertised Dart observatories...
Waiting for a connection from Flutter on MyDevice...
On iOS devices I have to run attach first and then start the app in the simulator. For android it also works while the app is already running. Don’t know about vscode I just run everything from the command line.
This is why i can't migrate to Flutter. Firebase is Google's also. If their own products have these problems, i can not imagine with others.
Same there, I get over 400 seconds (sometimes over 600) at the "Running Xcode build" phase.
More than 30 minutes to run flutter build ios --release.
After three days of struggling, I thought this slow comes from my 2016 mac and I decided to buy new 2019 mac at the weekend ( 2600 $).
by coincidence, I see this issue and found the slow start after adding firestore plugin !!!!!!
More than 30 minutes to run flutter build ios --release.
After three days of struggling, I thought this slow comes from my 2016 mac and I decided to buy new 2019 mac at the weekend ( 2600 $).
by coincidence, I see this issue and found the slow start after adding firestore plugin !!!!!!
So you're saying it's an Apple conspiracy for us to buy newer Macs! Possible.
More than 30 minutes to run flutter build ios --release.
After three days of struggling, I thought this slow comes from my 2016 mac and I decided to buy new 2019 mac at the weekend ( 2600 $).
by coincidence, I see this issue and found the slow start after adding firestore plugin !!!!!!So you're saying it's an Apple conspiracy for us to buy newer Macs! Possible.
😂😂😂
Of course not, I just want to show how this problem effected us as developers.
Not everyone will search ( it's too long to build flutter ios app ) and see this issue, he could think the problem come from his device like what happens with me.
When I build the cloud_firestore example on my MacBook Pro, I see the following times:
- pod install: 15.1s
- Xcode build: 120.7s
Second build:
- pod install: N/A
- Xcode build: 138.0s
I tried adding the following to the app-level ios/Podfile. (Note that it is necessary to run brew install cocoapods-binary or gem install cocoapods-binary if you haven't used cocoapods-binary before.)
plugin 'cocoapods-binary'
use_frameworks!
all_binary!
Here are the new times for initial build:
- pod install: 285.8s
- Xcode build: 13.6s
Second run:
- pod install: N/A
- Xcode build: 11.3s
So I think this is a substantial improvement in subsequent build times, especially for local Flutter development where the developer isn't specifically developing a plugin. (I wonder if it's possible to check in the compiled artifacts? I haven't tried.)
I opened a PR (#1563) adding instructions to the cloud_firestore README.
Long term, I'd like to see the Firebase team address firebase/firebase-ios-sdk#4284 which is mentioned in the Zip Builder plan: firebase/firebase-ios-sdk#4341. I think that offering a precompiled version of the Cloud Firestore frameworks would improve FlutterFire build times without any need for change on the Flutter side.
@collinjackson Appreciate you updating the README with that work around and investigating further. Thank you. That can certainly help some users for now.
But I would like to better understand your definition of "Long term" with regards to firebase/firebase-ios-sdk#4284. It seems like that issue is already in work and has a clear path towards integration or am I mistaken? And if that is the case, isn't it reasonable to consider this item resolvable in the "short term", days/weeks potentially?
I would much prefer that Firebase fix than to modify existing flutter projects with your instructions per #1563. I think that would be the cleaner approach if firebase/firebase-ios-sdk#4284 will indeed be resolved soon-ish.
It has already been this long since I first posed the issue in August (flutter/flutter#37582) - at this point for me personally, I am just waiting for the formal fix than a stop gap solution.
You can follow @paulb777's progress on firebase/firebase-ios-sdk#4284 here:
https://github.com/firebase/firebase-ios-sdk/commits/pb-any-zip
After investigating further I think that incremental installation may be a better option than cocoapods-binary, since it has the similarly fast subsequent build times and doesn't require installing a separate plugin.
I added this to my Podfile:
install! 'cocoapods',
generate_multiple_pod_projects: true,
incremental_installation: true
Initial build time:
- pod install: 10.5s
- Xcode build: 95.1s
Subsequent builds:
- pod install: N/A
- Xcode build: 11.4s
If we update the Podfile template this can be done for Flutter developers automatically (assuming they have CocoaPods 1.7.0 or later).
This won't help on CI of course, since every build is the first one. To make improvements there, we'd need the Firebase iOS team to release precompiled artifacts.
I've updated my Flutterfire PR (#1563) to recommend this approach for cloud_firestore and opened an issue (flutter/flutter#46198) against Flutter for doing it in the Podfile.
install! 'cocoapods',
generate_multiple_pod_projects: true,
incremental_installation: true
The origin line in Podfile is below.
Should I change to this?
install! 'cocoapods', :disable_input_output_paths => true, :generate_multiple_pod_projects => true, :incremental_installation => true
Yes, it looks like you're on a different version of Flutter that has this line. You should definitely combine them. I'll update the PR to clarify.
Incremental builds in Xcode don't rebuild pods as long as builds aren't cleaned in between. When running flutter build ios --debug multiple times, only the first time pod install is run and pods are compiled. During the second Xcode build, pods shouldn't compile again. I can't reproduce the issue of subsequent builds taking a long time with cloud_firestore, although the first build takes a very long time.
What the build time problem is about is that sometimes the Xcode build folder gets cleaned or out of sync and Xcode needs to recompile pods. cocoapods-binary was created for this very purpose, although it has the drawback of not being able to handle pods with a resource bundle. We would have to explicitly add :binary => true to the FirebaseFirestore pod in the podfile.
Re: Incremental Installation in CocoaPods, I don't think it helps in this case.
If your project has tons of dependencies your pod install command execution performance should significantly improve. Moreover, you will not need to build all your dependencies again after executing it.
However, what this new system will not fix is the fact that we would need to rebuild everything again if we clean the build folder. To avoid it, we would still need to use cocoapods-binary plugin.
incremental_installation => true only separates pods from each other so that you don't have to rebuild all pods when adding/removing/updating one. Shouldn't affect this particular issue with slow builds without modifying pods.
@MrAlek did you succeed in integrating coocapods-binary in the Podfile generated by Flutter? If yes, how? I get errors of files not being found (from the pods)
@tomadimitrie I did but only in a small example project with cloud_firestore as a dependency and nothing else.
@tomadimitrie You should add plugin 'cocoapods-binary' at the top of the file and all_binary! below use_modular_headers!.
@MrAlek I don't have a use_modular_headers! in my Podfile. Should it be generated by Flutter or add it myself?
@tomadimitrie If you're using the stable version of Flutter, add all_binary! below use_frameworks! instead 👍
Note that some plugins might break when doing this. I had a few of these cases where the compiler complains about import statements in Objective-C. If this happens, replace import "headerFile.h" with import <FrameworkName/headerFile.h>.
Does new Flutter ( 1.12 ) that published yesterday has any improvements about this issue?
@Crypt0Graphic it speeds up copying in the Flutter framework with your dart code in Xcode but does not affect third party pods.
@MrAlek where does cocoapods-binary save its cache? I'm trying to save CI build time by caching ios/Pods and $HOME/Library/Caches/CocoaPods/Pods/ but it still takes a long time.
@MrAlek I just saw this PR leavez/cocoapods-binary#70
Re: Incremental Installation in CocoaPods, I don't think it helps in this case.
If your project has tons of dependencies your pod install command execution performance should significantly improve. Moreover, you will not need to build all your dependencies again after executing it.
However, what this new system will not fix is the fact that we would need to rebuild everything again if we clean the build folder. To avoid it, we would still need to use cocoapods-binary plugin.
incremental_installation => trueonly separates pods from each other so that you don't have to rebuild all pods when adding/removing/updating one. Shouldn't affect this particular issue with slow builds without modifying pods.
After playing around with this more I think you're right that cocoapods-binary should be the recommended approach for improving subsequent Cloud Firestore build times.
It might make sense to document how to check in compiled artifacts to improve the performance of initial builds. It doesn't sound like the Firebase team is currently working on a solution that will do this out of the box.
Is there any workaround for this issue, Old version of cloud_firestore maybe?
It doesn't sound like the Firebase team is currently working on a solution that will do this out of the box.
@collinjackson Do you plan on updating the README with the cocoapods-binary method instead of the incremental build in #1563
we have migrated to firebase_database because of this issue, we build iOS + Android in 18 minutes again instead of ~60 minutes
i tried to use cloud_firestore again today, hoping there had been some improvement. The ios build took over 20 minutes, compared to the almost no change on android time. and then in xcode the archive process took what seemed to be a longer than normal (without cloudstore) time, too.
i see several suggestions above, like moving to a dev branch or adding commands to cocoapods things. are these still the suggested workarounds? is there anything i can possibly help with to resolve the underlying problem?
what is the underlying problem ?
edit:
digging through the rabbit hole of links, i see mention the culprit is the firebase code itself with ~500k LoC. Is there no way to build and distribute a common lib that everyone can just use and go? or is there some reason why my build of fb code will be different from john and joe? I'd be perfectly happy with some build voodoo that references a prebuilt binary that can be linked in. am i missing something obvious as to why that can't happen?
see also: flutter/flutter#33227
Note that some plugins might break when doing this. I had a few of these cases where the compiler complains about import statements in Objective-C. If this happens, replace
import "headerFile.h"withimport <FrameworkName/headerFile.h>.
@MrAlek: When I used cocoapods-binary, I first got a couple of errors like the one below that I could fix with your suggestion:
fatal error:
'Reachability/Reachability.h' file not found
#import "Reachability/Reachability.h"
But then I got this error and gave up:
/Users/karsten/Applications/flutter/.pub-cache/hosted/pub.dartlang.org/image_cropper-1.1.2/ios/Classes/ImageCropperPlugin.m:2:9: fatal error:
'TOCropViewController/TOCropViewController.h' file not found
#import <TOCropViewController/TOCropViewController.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
Any suggestions?
Had to switch to React Native (Expo) because of this issue. It's much more reliable
Note that some plugins might break when doing this. I had a few of these cases where the compiler complains about import statements in Objective-C. If this happens, replace
import "headerFile.h"withimport <FrameworkName/headerFile.h>.@MrAlek: When I used
cocoapods-binary, I first got a couple of errors like the one below that I could fix with your suggestion:fatal error: 'Reachability/Reachability.h' file not found #import "Reachability/Reachability.h"But then I got this error and gave up:
/Users/karsten/Applications/flutter/.pub-cache/hosted/pub.dartlang.org/image_cropper-1.1.2/ios/Classes/ImageCropperPlugin.m:2:9: fatal error: 'TOCropViewController/TOCropViewController.h' file not found #import <TOCropViewController/TOCropViewController.h> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated.Any suggestions?
@ksilz I haven't tried this since I haven't yet applied cocoapods-binary to my main app but you should probably be able to do something like this in Podfile (remove all_binary! first):
plugin_pods.each do |name, path|
symlink = File.join('.symlinks', 'plugins', name)
File.symlink(path, symlink)
pod name, :path => File.join(symlink, 'ios'), :binary => !['image_cropper'].include?(name)
end
Basically just add all pods which can't compile with the binary option in that array.
@ksilz I haven't tried this since I haven't yet applied
cocoapods-binaryto my main app but you should probably be able to do something like this inPodfile(removeall_binary!first):plugin_pods.each do |name, path| symlink = File.join('.symlinks', 'plugins', name) File.symlink(path, symlink) pod name, :path => File.join(symlink, 'ios'), :binary => !['image_cropper'].include?(name) endBasically just add all pods which can't compile with the binary option in that array.
@MrAlek Thank you for the suggestion! I tried that. Most of the code was already there, except for this code: , :binary => !['image_cropper'].include?(name)
So I dutifully started compiling and excluding and compiling and excluding until I got stuck again. So here's what my plug-in exclusion list currently looks like (edited for better viewing):
pod name, :path => File.join(symlink, 'ios'), :binary =>
!['sqflite','firebase_performance','firebase_crashlytics','image_cropper',
'connectivity','google_maps_flutter','camera','firebase_storage','firebase_auth',
'firebase_core','firebase_core_web','firebase_core_platform_interface',
'flutter','meta'].include?(name)
I'm stuck with this error:
In file included from /Users/karsten/Applications/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_performance-0.3.1+5/ios/Classes/FLTFirebasePerformancePlugin+Internal.h:5:
/Users/karsten/Applications/flutter/.pub-cache/hosted/pub.dartlang.org/firebase_performance-0.3.1+5/ios/Classes/FLTFirebasePerformancePlugin.h:5:9: fatal error: 'Firebase/Firebase.h' file not found
#import <Firebase/Firebase.h>
^~~~~~~~~~~~~~~~~~~~~
1 error generated.
It seems to me that firebase_performance can't find some firebase_core files. Now I tried to exclude firebase_performance, firebase_core and the dependencies of firebase_core (as you can see from my list above), but to no avail.
If I comment out the plugin 'cocoapods-binary' at the top and my exclusions after File.join(symlink, 'ios'),, the app compiles and runs just fine.
😒
@ksilz I'd check with https://github.com/leavez/cocoapods-binary if there's an open issue or more documentation. As mentioned, I haven't converted a production app yet, just tried out with cloud_firestore
@MrAlek Thank you anyway! I tried some more in my app. Now it doesn't even build without pre-compilation anymore after a pod update that pulled in new versions of Firebase libraries, including GoogleDataTransport. And that breaks the build with a fatal error: 'nanopb/pb.h' file not found... 😣
The build times have gone from annoying to prohibitively long over the last year. I'm on the beta channel with 15 mins of building, and often build breaking for no apparent reason, forcing me to run flutter clean between builds etc.
Is anyone having better luck on master?
Build speed seems to be slow for the first build, but subsequent builds seem to take advantage of iterative building, making them about 2~3 times faster than the first build.
However, archiving an app package in Xcode after running flutter build ios to prepare for release seems to be undeniably slow with Firestore included in the app.
Without firestore, I only see few hundreds of tasks showing up in the xcode status bar which takes 30~40 sec to archive. As soon as I add Firestore in, that # of tasks go up from two hundreds to three thousands of tasks. It takes around 16 minutes for archiving process to complete, and most of the time are spent in building gRPC & FirebaseFirestore.
It is quite aching to build an app that uses Firestore in one of the older macbooks. (2015 MBP with i7)
@ksilz I've had the same issue a couple days back. I solved it by deleting the entire ios dir and running flutter create followed by pod install. Don't forget to add your GoogleServe-Info.plist file and whatever setting and permissions afterwards.
This bit crazy, I know that this is not cloud_firestore plugin issue, but more likely cocoapods and firestore library. And I suggest to link them to this post. This needs to be resolved! I have latest MBP16 and separate hackintosh build server and it still takes for ages. There is just no reason to build those libraries from source. We should really persuade them to create binaries from those objc sources
I'm running an Electron.js project with Vue.js and encountering similar issues with my build times taking a ridiculously long.
It appears that grcp is a dependency of firestore, and when "rebuilding native dependencies" in Electron it's that which takes so long.
(Apologies if some of this has been said already, found this thread trying to fix my own Electron js issues).
Hopefully this shines some light on the bug
I'm having build times between 400 and 1000 seconds. Way to long! This is making the development process so much harder. Would be nice if this could be resolved!
I'm having build times between 400 and 1000 seconds. Way to long! This is making the development process so much harder. Would be nice if this could be resolved!
I'm facing 400+ build times, since the adding of firebase and fireauth
I cannot use anymore CodeMagic and Bitrise(Developper) as it itmes out at 60 minutes...
The build on IOS takes more than an hour on mac mini...
I don't want to sound ungrateful and I really love both Firebase and Flutter, despite that I am relatively new to both.
I was expecting that they would work really well together, that they would be first-class citizens and get a lot of support.
But this issue has been here for around 4 months or more, and it doesn't appear to have anyone assigned, have any milestone assigned, or indeed be getting any attention at all?
This issue actually eliminates Firebase as an option (at least for me, but I don't see how anyone would be able to put up with this?), and the fact it has dragged on for so long also makes me wonder if Firebase should ever be considered with Flutter? If at any moment something like this could be introduced and destroy the viability of developing for it, and it doesn't even seem to be on any list to be addressed - that makes it extremely unattractive to depend on.
Again, forgive my ignorance, am I wrong on the above?
@mikeCalvir
This issue is not related to Flutter. This is related to Firebase dependencies on iOS. If you are using Firebase libraries on iOS (using Cocoapods) you will experience the same issue. Overall build time may be quicker (because we have additional Flutter app compilation before) but still not related to Flutter as it is.
@kamilpowalowski Thanks for explanation, I've not built a native Firebase-dependent project for awhile now so I hadn't realised (although it was mentioned earlier I didn't grok it).
So we shouldn't even talk about this here really - is there an appropriate Issue available somewhere that we could all pile-on to help encourage a resolution?
@mikeCalvir there are several issues that mention this problem e.g.
- this issue in iOS SDK
this issue in FirebaseExtendedsorry, it's this exact issue :D- this Pull Request to Firebase Extended repository
- this closed issue in flutter repo
Thanks @orestesgaolin!
Ok so great there are people looking at it and trying to solve it, and we can cheer them on :)
Bump on this
Firestore also practically unusable at this point with SwiftUI previews due to long compile times.
Any news about this issue?
Adding gRPC as a dependency in pubspec.yml helps as mentioned in this linked issue, but the build is still heavily impacted.
This is affecting us, too. Adding package:cloud_firestore as a dependency jacked build times up from averages of ~28min to ~48min
same problem here
seems, the problem occurs because of the channel you were in, in stable channel it is not much slow.
iOS development only (not yet implemented for macOS): If you are on v1.15.4 or later (master and dev at the moment), flutter/flutter#51453 will allow you to remove install! 'cocoapods', :disable_input_output_paths => true in your ios/Podfile. The first build will still be slow, but CocoaPods will cache these frameworks more aggressively for subsequent builds.
If you need to switch back to an older version of Flutter (back to stable, for example), please follow these migration instructions to make sure you can still build.
@jmagman Is this supposed to work for macOS builds as well?
No, iOS only at the moment.
@jmagman does it require xcode 11.4 or will it work with 11.3 too? Will it be included in default project template in the future?
iOS development only (not yet implemented for macOS): If you are on v1.15.4 or later (master and dev at the moment), flutter/flutter#51453 will allow you to remove
install! 'cocoapods', :disable_input_output_paths => truein yourios/Podfile. The first build will still be slow, but CocoaPods will cache these frameworks more aggressively for subsequent builds.If you need to switch back to an older version of Flutter (back to stable, for example), please follow these migration instructions to make sure you can still build.
When I try this I get an error.
@kornha Would you be willing to share what you tried (the quote has several options) and the error message?
iOS development only (not yet implemented for macOS): If you are on v1.15.4 or later (master and dev at the moment), flutter/flutter#51453 will allow you to remove
install! 'cocoapods', :disable_input_output_paths => truein yourios/Podfile. The first build will still be slow, but CocoaPods will cache these frameworks more aggressively for subsequent builds.
If you need to switch back to an older version of Flutter (back to stable, for example), please follow these migration instructions to make sure you can still build.When I try this I get an error.
@kornha Please file a new issue for the error you see. This issue is tracking the slowness of building with the addition of firestore plugins.
@jmagman does it require xcode 11.4 or will it work with 11.3 too? Will it be included in default project template in the future?
@orestesgaolin Those migration steps will work with any version of Xcode. They are required for Xcode 11.4 (if you are on a version where the tool doesn't do it for you). I'll update the docs to clarify.
If you are on v1.15.4 or later, the tool should migrate for you, and the default template Podfile will no longer contain disable_input_output_paths for new projects.
So no matter what version of Xcode or Flutter you are on, if you follow the instructions in https://flutter.dev/docs/development/ios-project-migration and remove disable_input_output_paths in your Podfile you will get the CocoaPods caching behavior.
2148 seconds to build a very simple app...:-(
The same happens with me
Running pod install... 15,0s
Running Xcode build...
├─Building Dart code... 58,7s
├─Generating dSYM file... 0,5s
├─Stripping debug symbols... 0,1s
├─Assembling Flutter resources... 2,4s
└─Compiling, linking and signing... 46,3s
Xcode build done. 569,3s
iOS development only (not yet implemented for macOS): If you are on v1.15.4 or later (master and dev at the moment), flutter/flutter#51453 will allow you to remove install! 'cocoapods', :disable_input_output_paths => true in your ios/Podfile. The first build will still be slow, but CocoaPods will cache these frameworks more aggressively for subsequent builds.
Just for the records at the moment of writing beta is also on v1.15.x
Any updates on this? My 2016 12" MacBook is crying while trying to build Firestore
With the machine like this, I can't believe the compiling time it took.
time flutter build ios --simulator
Running pod install... 18.6s
Running Xcode build...
├─Assembling Flutter resources... 3.3s
└─Compiling, linking and signing... 11.8s
Xcode build done. 129.3s
flutter build ios --simulator 28.44s user 15.10s system 26% cpu 2:42.52 total
Updates, with the incremental build options in the Podfile, with the same machine as above
flutter build ios --simulator
Running Xcode build...
├─Assembling Flutter resources... 3.3s
└─Compiling, linking and signing... 8.7s
Xcode build done. 23.1s
Here's the Podfile update
# Prevent Cocoapods from embedding a second Flutter framework and causing an error with the new Xcode build system.
install! 'cocoapods',
:disable_input_output_paths => true,
:generate_multiple_pod_projects => true,
:incremental_installation => true
post_install do |installer|
installer.generated_projects.each do |target| ## Must use `installer.generated_projects` instead of `installer.pods_project.targets`
target.build_configurations.each do |config|
config.build_settings['ENABLE_BITCODE'] = 'NO'
end
end
end
@xmkevinchen Thanks. The incremental installation in cocoapod setting is working although I have no idea why lol
That's it? @xmkevinchen is our savior??
FYI, the feature is added since cocoapods 1.7.0 beta
flutter/flutter#46198
iOS development only (not yet implemented for macOS): If you are on v1.15.4 or later (master and dev at the moment), flutter/flutter#51453 will allow you to remove
install! 'cocoapods', :disable_input_output_paths => truein yourios/Podfile. The first build will still be slow, but CocoaPods will cache these frameworks more aggressively for subsequent builds.If you need to switch back to an older version of Flutter (back to stable, for example), please follow these migration instructions to make sure you can still build.
This one also work!
Incremental installation was suggested to be used as the default for all Flutter apps in flutter/flutter#46207 (review) but it's not robust enough to do generically for all projects (see that comment). If it's compatible with your project, feel free to use it.
Warning: Switching your project to use multiple .xcodeproj may result in some compiler errors if your pods have relied on importing headers using the quote syntax for its dependencies. For example #import "PDDebugger.h" will no longer work in a pod that depends on PonyDebugger. Instead, we highly suggest you update your headers to correctly import the framework and its associated header: #import <PonyDebugger/PDDebugger.h>. This is intentional since this feature is currently opt-in.
Updates, with the incremental build options in the Podfile, with the same machine as above
flutter build ios --simulator Running Xcode build... ├─Assembling Flutter resources... 3.3s └─Compiling, linking and signing... 8.7s Xcode build done. 23.1sHere's the Podfile update
# Prevent Cocoapods from embedding a second Flutter framework and causing an error with the new Xcode build system. install! 'cocoapods', :disable_input_output_paths => true, :generate_multiple_pod_projects => true, :incremental_installation => true post_install do |installer| installer.generated_projects.each do |target| ## Must use `installer.generated_projects` instead of `installer.pods_project.targets` target.build_configurations.each do |config| config.build_settings['ENABLE_BITCODE'] = 'NO' end end end
Does it work for stable channel too?
I'm on stable channel. Still the same.
The changes on the dev channel are substantial. I am going to continue tests on codemagic and post more results soon
The changes on the dev channel are substantial. I am going to continue tests on codemagic and post more results soon
There is a problem with breaking lines if we are not using stable channel. flutter/flutter#49796
So I need to use stable.
Can I make the changes using stable?