Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support ARM32 iOS devices (iPhone 4, iPhone 5) #2089

Closed
eseidelGoogle opened this issue Feb 22, 2016 · 91 comments

Comments

@eseidelGoogle
Copy link
Contributor

commented Feb 22, 2016

@chinmaygarde says this should be very straightforward and is just about teaching our Mac bot to build the ARM32-bit variants of our engine, uploading them to the right place, and teaching our XCode project template to use them.

EDIT: Turns out it was not straight forward. Work is actively underway, @cbracken is driving the effort.

@eseidelGoogle eseidelGoogle added this to the Flutter 1.0 milestone Feb 22, 2016

@chinmaygarde

This comment has been minimized.

Copy link
Member

commented Feb 22, 2016

Ninja can build a non-aarch64 engine and runner if the --ios-force-armv7 flag is specified to GN

@tvolkert tvolkert added the priority:P1 label Mar 4, 2016

@tvolkert tvolkert modified the milestones: Next, Flutter 1.0 Mar 4, 2016

@tvolkert tvolkert removed the priority:P1 label Mar 4, 2016

@eseidelGoogle eseidelGoogle modified the milestones: Flutter 1.0, Next Mar 10, 2016

@eseidelGoogle

This comment has been minimized.

Copy link
Contributor Author

commented Mar 10, 2016

Lets hold off on this for now. This is just a plumbing question.

  • Document the instructions on how to build for 32 bit devices.
  • Wire up our buildbots to build for ios_arm_32 and upload binaries
  • teach the flutter tool how to use the binaries.

This is almost identical to, but superseded in importance by two other bugs:
Mac #1707
Android x86 emulator #490

@chinmaygarde

This comment has been minimized.

Copy link
Member

commented Apr 8, 2016

The buildbot now build this target. The tools need to be wired up though.

@eseidelGoogle

This comment has been minimized.

Copy link
Contributor Author

commented Nov 4, 2016

@chinmaygarde does your Apr 8 comment mean that we're publishing the artifacts but just haven't taught the flutter tool to use them? FYI @danrubel

@eseidelGoogle eseidelGoogle added the tool label Nov 4, 2016

@chinmaygarde

This comment has been minimized.

Copy link
Member

commented Nov 15, 2016

We got rid of the GN flags for iOS ARMv7 because no one was using them and the tools never recognized this variant. flutter/engine@3fe2469

@eseidelGoogle

This comment has been minimized.

Copy link
Contributor Author

commented Feb 7, 2017

If I'm reading this right: https://www.statista.com/statistics/606147/iphone-model-device-market-share-worldwide/ 32-bit arm devices account for about 17% of the worldwide usage of idevices? If that's true, that likely bumps the priority of this bug a little at least into milestone 4 if not 3.

@chinmaygarde

This comment has been minimized.

Copy link
Member

commented Feb 8, 2017

From the tooling perspective, supporting universal applications is a bit tricky. Though we can easily prepare a fat mach binary that supports armv7 as well as aarch64 (we already do this for the Flutter framework that can be used for both simulator and device builds), we also have to prepare and package the instructions snapshot for the Dart code in multiple architectures (via gen_snapshot). Then, at runtime, depending on the architecture of the device, pick the appropriate instructions snapshot and start the shell. This would also double the code side of the application and slow down the development in non-debug product modes (since we have to snapshot twice).

Is it possible to upload a separate binary to the App Store just for non-64 bit devices? That way, newer devices wont need to download an unnecessary copy of the code. Developers for whom it is critical to support iPhone 5 and below, can just prepare one extra IPA.

@eseidelGoogle

This comment has been minimized.

Copy link
Contributor Author

commented Apr 7, 2017

@vlidholt noted on gitter just now that the most common feedback he's received so far is lack of support for iPhone 5.

@eseidelGoogle

This comment has been minimized.

Copy link
Contributor Author

commented May 3, 2018

FYI @mravn-google @sigurdm (who have been considering changes to our ios build structure related to add-to-app workflows).

@mravn-google

This comment has been minimized.

Copy link
Contributor

commented May 3, 2018

@cbracken Some questions:

  • Does this change then force users to have Cocoapods installed, even if they do not use plugins? Does it force users through the pods repo download (>1.3GB of data)? We currently have some logic to avoid that. The iOS project template has no ios/Podfile; we create one, if you add a plugin dependency.
  • AFAIK, communicating information from Flutter tooling to Xcode has so far gone through the Generated.xcconfig file that Flutter tooling writes and Xcode build scripts read. Are we changing that pattern now?

Minor thing: #17210 also ensures that pod install is run, if the ios/Podfile.lock is older than ios/Podfile (and we have plugins). We may have a merge conflict.

@cbracken

This comment has been minimized.

Copy link
Member

commented May 3, 2018

Does this change then force users to have Cocoapods installed [...]?

Nope this change doesn't change how we rely on Cocoapods (or add any dependencies on it that weren't already there). What it does do is remove the hardcoded -arch arm64 from buildXcodeProject() when building for device, which causes us to use the architectures defined by the user in their Xcode project.

However, while I was testing that I noticed that when a project does use Cocoapods, we don't automatically re-run pod install if the build settings change in the Xcode project file (in my case the setting in question was the target architecture), with the result that the generated Pods project doesn't pick up any of those changes. We probably should have been doing this all along.

AFAIK, communicating information from Flutter tooling to Xcode has so far gone through the Generated.xcconfig file that Flutter tooling writes and Xcode build scripts read. Are we changing that pattern now?

No changes on that front. The exact same settings (debug/profile/release as well as env variables) are still passed through to Xcode as we'd passed before. We've never used the xcconfig files to communicate build architecture. What's new is that we're picking that up from Xcode now (which is what most users likely expect).

@cbracken

This comment has been minimized.

Copy link
Member

commented May 7, 2018

As of #17312 (849676f) on master, armv7-only, arm64-only, and universal iOS binaries should now be working for profile and release builds. There's one remaining VM fix required for debug builds to work on 32-bit iOS devices, which is out in r53822 and should roll into Flutter within the next couple of days.

For an example of how to update your Xcode project to build universal binaries, have a look at #17350, which does this for the Flutter Gallery example. I'll be updating the other examples and our flutter create templates shortly.

@cbracken

This comment has been minimized.

Copy link
Member

commented May 7, 2018

As of #17358, flutter create generates projects that build universal iOS binaries by default. I've updated the armv7 wiki page to explain how to update existing projects to generate universal binaries.

@cbracken cbracken closed this May 7, 2018

@MiguelCatalan

This comment has been minimized.

Copy link

commented May 7, 2018

Should we do anything special to the plugins too?

I pulled the marter branch, done the changes of at #17350. But I keep getting the following error when preparing the build for release (flutter build ios --release)

 Error output from Xcode build:
↳
    ** BUILD FAILED **
    
Xcode's output:
↳
    === BUILD TARGET Runner OF PROJECT Runner WITH CONFIGURATION Release ===
    Non-fat binary *projectdirectory*/build/ios/Release-iphoneos/Runner.app/Frameworks/geolocation.framework/geolocation is not armv7. Running lipo -info:
    Non-fat file: *projectdirectory*/build/ios/Release-iphoneos/Runner.app/Frameworks/geolocation.framework/geolocation is architecture: arm64
    Command /bin/sh failed with exit code 1
Encountered error while building for device.

@cbracken

This comment has been minimized.

Copy link
Member

commented May 7, 2018

@MiguelCatalan until this rolls to dev and beta branches, ensure that you're on the master branch (looks like you are), then run flutter upgrade.

Once that's done, and you've followed the instructions on the wiki page I updated a few minutes ago, try re-running flutter build ios --release. That should automatically detect the build setting change and re-run pod install for you if you've updated master.

If you'd prefer, you can do cd ios; pod install; cd .. from your project directory to update the pod project architecture to $(ARCHS_STANDARD).

@MiguelCatalan

This comment has been minimized.

Copy link

commented May 7, 2018

Thanks @cbracken, great work btw.

I just did what you told, but keep getting the same error for the plugin geolocation when trying to build my app for release.

Did a miss anything?

@cbracken

This comment has been minimized.

Copy link
Member

commented May 7, 2018

Thanks for checking. It's entirely possible I need to do a pass over our plugins repo and verify each of them. I've verified the gallery, which uses pods, but I'll do a pass over the rest now. Until then, one possibility is to manually edit the build settings for the geolocation plugin in the same way as documented in the wiki and see if that gets you going. I'll quick try the geolocation plugin now.

@cbracken

This comment has been minimized.

Copy link
Member

commented May 7, 2018

@MiguelCatalan Here's what I tried (with a new project), which worked for me:

  1. Create the project
flutter create --ios-language=swift geoloc_test
cd geoloc_test
  1. Edit pubspec.yaml. Add geolocation: ^0.2.1 to the dependencies section.
  2. Open ios/Runner.xcworkspace. Select the Runner project. In the Build Settings tab, Set the Deployment target to 9.0 (the geolocation package has this restriction).
  3. Set my development team and bundle identifier in the Signing section of the General tab.
  4. Run the project on on 32-bit device. flutter run -d MyDevice --release

I didn't add code that made use of the geolocation plugin, but I did check the contents of the built app under build/ios/Release-iphoneos/Runner.app/Frameworks and it contained geolocation.framework. Running lipo on that framework returns:

Architectures in the fat file: build/ios/Release-iphoneos/Runner.app/Frameworks/geolocation.framework/geolocation are: armv7 arm64

I'm using flutter on master at de332ec78292c2d79fdb76034328f902c9087ee9, and cocoapods 1.5.0. If necessary, you can update cocoapods by doing gem install cocoapods and pod repo update.

Can you give that a go and let me know if that work for you?

Possibly worth noting -- the geolocation plugin isn't developed by the Flutter team or Google, but I did notice that their podspec doesn't contain s.static_framework = true which I believe we added to a lot of our plugins during the transition to cocoapods 1.5, though I'm not familiar with the background. The above steps seemed to work for me without that change though.

@johanhenselmans

This comment has been minimized.

Copy link

commented May 8, 2018

When I run a "flutter run --release" on a new flutter project I am getting this warning :

You've implemented -[ application:performFetchWithCompletionHandler:], but you still need to add "fetch" to the list of your supported UIBackgroundModes in your Info.plist.
You've implemented -[ application:didReceiveRemoteNotification:fetchCompletionHandler:], but you still need to add "remote-notification" to the list of your supported UIBackgroundModes in your Info.plist.

i have tried to add these settings to Info.plist in the folder ios/Runner, but no avail.

The test app runs ok, afterwards, in the real app I am getting an unhandled exception error:

Running pod install... 3.0s
Starting Xcode build...
├─Building Dart code... 44.0s
├─Assembling Flutter resources... 2.2s
└─Compiling, linking and signing... 18.7s
Xcode build done. 82.2s
Installing and launching... 20.6s

To repeat this help message, press "h". To quit, press "q".
[VERBOSE-2:dart_error.cc(16)] Unhandled exception:

@afocsa

This comment has been minimized.

Copy link

commented May 11, 2018

@cbracken It works for me, too. With flutter upgrade from master.
Do you know when will this be available on beta? Thanks.

@jeffreyfate

This comment has been minimized.

Copy link

commented May 12, 2018

I ran the instructions described on https://github.com/flutter/engine/wiki/iOS-Builds-Supporting-ARMv7 but am still getting an error trying to run my application on an iPhone 5c:

Could not install build/ios/iphoneos/Runner.app on xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Try launching Xcode and selecting "Product > Run" to fix the problem:
  open ios/Runner.xcworkspace

Error running application on iPhone.
@MiguelCatalan

This comment has been minimized.

Copy link

commented May 15, 2018

Sorry for the delay.

@cbracken I can confirm this is working.

I had to upgrade cocoapods gem install cocoapods and pod repo update.

Also and because upgrading from older version of cocoapods had to apply this.

And everything work as expected. Thanks a lot for the help.

@ypelud

This comment has been minimized.

Copy link

commented May 18, 2018

Build and debug (simulator) work well on iPhone5c but Testflight crash.
Crash is may be not the good term because the app is still alive but goes background immediately.
Tests done on the basic flutter demo app.

Did someone succeed with testFlight on iPhone 5C ?

I create an issue for that #17619.

@cbracken

This comment has been minimized.

Copy link
Member

commented Jun 1, 2018

@ypelud I’ve just landed a fix for the issue you reported about distribution through test flight. Thanks for reporting.

@wurst-case

This comment has been minimized.

Copy link

commented Mar 26, 2019

@cbracken looks like the wiki referenced above, https://github.com/flutter/engine/wiki/iOS-Builds-Supporting-ARMv7, is gone? Or the whole wiki looks to be gone. No such page on the framework's wiki exists. I'm still getting build errors for arm32 device simulators, trying to diagnose.

@cbracken

This comment has been minimized.

Copy link
Member

commented May 1, 2019

@wurst-case we've taken down the wiki page since Flutter has been building universal binaries by default for some time now. We still don't support building for 32-bit i386 simulators (just x86_64).

Can you provide some details about your usecase for 32-bit simulators and why using a 64-bit simulator device doesn't work for you?

EDIT: Interesting, it looks like I did enable support for 32-bit device simulators in #17443. Can you file a new bug with what you're seeing and repro instructions, then CC me on it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.