Xcode 12 compatibility

[drdaz]

We need to get the build process running with Xcode 12.

There are issues with the lipo command in the build process; we include arm64 arch in both our simulator and our release builds, and then include them in the output. This is a new issue in Xcode 12, since the simulator used to only build for x86 (Apple Silicon cometh). Some approaches to working around this are outlined here.

It also looks like some tests are broken.

Whatever else needs fixing to migrate to Xcode 12, we can put here.

Close #1591

[mman]

I am not familiar as to what artifacts actually get produced by the Parse SDK build, pardon my ignorance, I integrate it nowadays via subproject build, but I do have another component which used to produce fat library with lipo containing slices for x86_64 (simulator), arm64, and armv7, and I was able to convert it to .xcframework.

The .xcframework can be used down to iOS 9 without any troubles, and should pack fat static libraries for each device variant (ios-simulator, ios-maccatalys, ios, macos, ...). My example .xcframework for iphone/ipad/mac/maccatalyst (no watchos or tvos) looks like this then:

€ ls -l XXX.xcframework
-rw-r--r--  1 mman  staff  1988 Sep 10 11:53 Info.plist
drwxr-xr-x  4 mman  staff   128 Sep 10 11:53 ios-arm64_armv7
drwxr-xr-x  4 mman  staff   128 Sep 10 11:53 ios-arm64_x86_64-maccatalyst
drwxr-xr-x  4 mman  staff   128 Sep 10 11:53 ios-arm64_x86_64-simulator
drwxr-xr-x  4 mman  staff   128 Sep 10 11:53 macos-arm64_x86_64

Each of the subdirectories contains libxxx.a which is a fat library containing slices for each of the supported architectures.

Another potentially faster approach will be to go fully SPM. Not sure what is the better or easier/faster way.

Martin

[drdaz]

It looks like Carthage is solving this issue by supporting XCFramework (draft PR). I'm guessing that's what we need to do too if we want to remain available on Carthage.

[bielikb]

Hi, I'd be curious, if this fastlane plugin to create xcframework could actually help you.

[drdaz]

Hi, I'd be curious, if this fastlane plugin to create xcframework could actually help you.

Sorry I missed your response. Maybe it could be helpful.

How would you go about integrating this?

[bielikb]

I dont know the internals of this project well enough, my suggestion here would be to

1. Add fastlane to this repo (specify that in Gemfile) + run bundle install
2. run fastlane add_plugin create_xcframework to add this plugin to the fastlane
3. Specify a lane in your fastlane/Fastfile file that will be able to build the module stable xcframework from your projects. Parametrize the arguments you care about

  desc "Create xcframework"
  lane :build_xcframework do |options|
    create_xcframework(
      workspace: "Parse.xcworkspace",
      scheme: options[:scheme],
      product_name: options[:project_name],
      destinations: ['iOS'], // here you can pass array of destinations that you care about for project x, e.g. ['iOS', 'tvOS', 'maccatalyst']
      xcframework_output_directory: options[:path_to_release_folder]
    )
  end

4. create xcframework by calling the lane, eg

bundle exec fastlane build_xcframework project_name:ParseUI scheme:ParseUI path_to_release_folder:release/ParseUI 

5. release

Note: Once you'll excercise the module stability in your project you might come across couple of warnings, compile errors or even runtime errors. Brace yourself :)

[bielikb]

If the plugin doesnt suite to your scenario, you can still bash it :) If you want to learn more about the xcframeworks, feel free to visit this github repo, that documents the distribution and integration story for Apple's framework bundle

[cbaker6]

Just in case it helps any https://www.appcoda.com/xcframework/

[drdaz]

So I found a moment to wrap my head around XCFramework and how we might use them here. Very much WIP.

[drdaz]

I've also removed the git submodule ref to the xctoolchain repo, and committed its contents here. As far as I can tell, that split was a remnant of the time when some of the projects in this workspace were in separate repos. I don't believe any other projects are using it. And working across repos is a pain.

If I'm wrong about that, let me know, and I'll add it back.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. If you believe it should stay open, please let us know! As always, we encourage contributions, check out the Contributing Guide

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. If you believe it should stay open, please let us know! As always, we encourage contributions, check out the Contributing Guide

[mtrezza]

@drdaz I'm cleaning up the branches, we don't host "PR" branches in the main repo anymore. If the branch xcode-12 for this PR should be preserved, could you please open a new PR from your fork? If the branch is not needed anymore, please let me know and I'll delete it.

[iosdec]

I was able to solve this by creating an xcframework for both Parse.framework/Bolts.framework from the frameworks I managed to compile (Release-ios-iphoneos, Release-ios-iphonesimulator, Release-osx-macosx).

Here are the commands I used:

Parse.framework

xcodebuild -create-xcframework -framework build/Release-ios-iphoneos/Parse.framework -framework build/Release-ios-iphonesimulator/Parse.framework -framework build/Release-osx-macosx/Parse.framework -output ~/Desktop/Parse.xcframework

Bolts.framework

xcodebuild -create-xcframework -framework build/Release-ios-iphoneos/Bolts.framework -framework build/Release-ios-iphonesimulator/Bolts.framework -framework build/Release-osx-macosx/Bolts.framework -output ~/Desktop/Bolts.xcframework

[mtrezza]

@drdaz how could we revive this PR, what is missing or what would incentivize you to pick it up again? This PR seems to be critical to ensure the SDK stays relevant and usable.

[drdaz]

@mtrezza Cocoapods and Carthage are still go, and I suspect those are the main ways people use this. We haven't seen a large outcry at least.

how could we revive this PR, what is missing

I can look at this as my next Parse task if there's consensus for that being the most important thing? I should be able to poke at it this week and see what the state of things is, whether it makes sense to carry on this branch, or branch out from current main. This branched a while ago.

or what would incentivize you to pick it up again?

There are incentives? 😅

[mtrezza]

I can look at this as my next Parse task if there's consensus for that being the most important thing?

From your comment I would say it's good to stay compatible with newer Xcode versions, to not keep accumulating debt and reach a breaking point where we need to address a lot of issues at once. Is there something else that should get preference?

There are incentives?

Sure, I already added a bounty to https://github.com/parse-community/Parse-SDK-iOS-OSX/issues/1633. Not sure whether this PR fully relates to that issue, otherwise you could open a separate issue for this PR.

[drdaz]

Is there something else that should get preference?

I haven't been keeping tally, but there have been several requests for SPM compatibility I think. My gut feeling says that one is likely to help maintaining a userbase for this library, as SPM becomes more and more popular.

They're both useful tbh, and they're both potentially deep-dives.

Sure, I already added a bounty to #1633.

Nice.

Not sure whether this PR fully relates to that issue, otherwise you could open a separate issue for this PR.

They don't seem related to me. The problem in there revolves around the XCFrameworks that we're not yet creating ourselves.

[mtrezza]

My guess would be to address the issues people currently face, not sure how many existing Parse developers are using SPM yet? Another aspect may be complexity, if fixing the carthage or xcframework building issues are smaller efforts and SPM support is a larger issue, maybe addressing them may bring a quicker benefit. What do you think, and what seems more appealing to you?

[drdaz]

My guess would be to address the issues people currently face

There does seem to be some explicit interest in SPM support https://github.com/parse-community/Parse-SDK-iOS-OSX/issues/1453.

not sure how many existing Parse developers are using SPM yet?

Not many, since it's not supported 😅

I'm also not sure how many people install the SDK using the binary tagged releases. Or how people use the SDK generally. Usage analytics would be pretty awesome 🙂

Another aspect may be complexity, if fixing the carthage or xcframework building issues are smaller efforts and SPM support is a larger issue, maybe addressing them may bring a quicker benefit. What do you think, and what seems more appealing to you?

I think this and SPM are both potentially deep-dives for me. I haven't looked at the Carthage issue yet; I'll check it out first.

[mtrezza]

Not many, since it's not supported

I mean use SPM for other dependencies :-)

Usage analytics would be pretty awesome

I agree; if we need a poll to make a development decision or prioritize, we can publish it on Twitter, were we usually get the quickest response.

I think this and SPM are both potentially deep-dives for me. I haven't looked at the Carthage issue yet; I'll check it out first.

Sounds good. Feel free to open separate issues and I'll add bounty tags.

[mtrezza]

@drdaz I just came across this note in the facebook-ios-sdk:

Deprecated: Building the frameworks using Carthage. Carthage is a dependency manager that typically works by building a third party framework using Xcode schemes shared from a .xcodeproj file. We are planning to remove the .xcodeproj files in the next major release as they will be generated on an as needed basis using Xcodegen. There is a strong likelihood that this change will break several integrations that use Carthage. You will still be able to use Carthage by pulling the pre-built binaries or XCFrameworks directly from the release. If this does not work for your use case, we recommend checking out Swift Package Manager as an alternative.

Maybe something to consider, since the Parse SDK's Facebook Utils have a dependency on that framework.

[drdaz]

@drdaz I just came across this note in the facebook-ios-sdk:

Deprecated: Building the frameworks using Carthage. Carthage is a dependency manager that typically works by building a third party framework using Xcode schemes shared from a .xcodeproj file. We are planning to remove the .xcodeproj files in the next major release as they will be generated on an as needed basis using Xcodegen. There is a strong likelihood that this change will break several integrations that use Carthage. You will still be able to use Carthage by pulling the pre-built binaries or XCFrameworks directly from the release. If this does not work for your use case, we recommend checking out Swift Package Manager as an alternative.

Maybe something to consider, since the Parse SDK's Facebook Utils have a dependency on that framework.

Yeah this doesn't speak in favour of maintaining Carthage support. Although the fact that Carthage should still grab binary releases says it might just still work.

But the days of FBSDK as a git submodule in the Parse project look pretty over 👍🏼

[drdaz]

But that's why the FBSDK version is where it is right now. We kinda need them to fix https://github.com/facebook/facebook-ios-sdk/issues/1936, so that we can move to SPM internally to upgrade it any further.

I mean, not directly, but that's the path I'd take - rather than mincing about making other solutions work, just move to SPM internally.