fix: compilation errors with Xcode 13

[julianvogels]

Compiler error due to "Use of undeclared identifier" for two properties in PFActionButton. The properties _buttonStyle and _configuration reference instance variables in the ole NS style. The issue can be easily resolved by accessing the properties through self.
An alternative approach would be to synthesize the properties. Let me know if that is preferable.

I ran the test with rake and got no issues, but here on Github not all of the checks passed. Let me know if there's something to do.
Tests succeeded: Executed 814 tests, with 0 failures (0 unexpected) in 64.787 (66.113) seconds

[davewhipps]

While this should work, can I recommend that you change the member name altogether, to avoid confusion? That is, instead of:

@property (nonatomic, strong) PFActionButtonConfiguration *configuration;

You use something like:

@property (nonatomic, strong) PFActionButtonConfiguration *pfButtonConfiguration;

Developers (and IDEs) alike will appreciate it.

All that said, with the release (and automatic overnight upgrade) of XCode 13 and the associated iOS SDK, my development process is now broken (because we use the cocoapod.)

Can this issue be prioritized? Happy to help where possible.

[chriscborg]

In my case, with the fixes in this PR, the app still crashes when opening the login from ParseUI with the below error:

'NSInvalidArgumentException', reason: '-[PFActionButton setConfiguration:]: unrecognized selector sent to instance

The suggestion by @davewhipps is actually a requirement for this fix to actually work. After renaming the configuration field to something else, the app is working again. I tested this out locally on my app and not on the framework so I haven't tried the unit tests.

For the time being @davewhipps, as a workaround to proceed with development and get unstuck, I have made the above changes in the file directly from the app by "Unlocking" the file. Otherwise, download Xcode 12 from Apple's developer site.

[drdaz]

I'd like to get this released asap; it's going to be a blocking issue for people and the issues are gonna start pouring in. And I'm about 100% sure that the errors aren't related to these changes.

I'm pretty sure the parseui test failure is due to the problem with facebook_utils. There's something wonky with our dependency referencing to Facebook's SDK. It seems like it can't find it when building it in the test context, but it builds just fine during non-test compilation.

I see the same behaviour (build env can't find FBSDKCoreKit.h) when trying to compile the ParseUI-Demo app target, which is used by the ParseUI tests.

[cbaker6]

Since you are making changes to build on Xcode 13, you need to update the CI to build using the correct versions. You can do that by updating the environment variables in the ci.yml and release.yml: https://github.com/parse-community/Parse-Swift/blob/b8e6826db67244a0d816ddfce05c80e28ffe16ed/.github/workflows/ci.yml#L9-L19

You should also change macos-latest to macos-11 to match the linked file above.

This should help you see if the CI catches any bugs. You should also make sure your changes didn't break anything on Xcode 12.

[drdaz]

I can't reproduce the failure in parseui locally. There's something different about the environments and I'm not sure what. I'm seeing it with the initial changes in this branch too. I need to modify FBSDKAuthenticationSecurity.m to include TargetConditionals.h, or my compiler chokes on '#if !TARGET_OS_TV'. And if I do that, it passes.

@cbaker6 Can you try running bundle exec rake test:parseui:all against Xcode 13?

[JohnCaccavale]

@julianvogels This looks good to me, thank you. And looks like you were able to remove the references to FBSDKCoreKit and FBSDKLoginKit from the ParseUI Project file and put them in with the ParseFacebookUtils project file. Seems like some nice cleanup as well. 👍

I'll be able to test these changes with my app later this week. But with quick glance of the code, and with these changes that I've added to my local repo, I'm able to build the ParseUI framework via the rake file again.

[NicholasDK]

Can we get this merged ASAP? This is causing crashes on ios 15.

[drdaz]

Can we get this merged ASAP? This is causing crashes on ios 15.

I was actually planning to waste as much time as possible. But then you wrote this, so now the release is going to happen much faster.

Wanna help out maybe? Can you help solve the test failures? This thing isn't getting merged until the tests work, and I can't currently reproduce the test errors. Which means I can't fix them.

[benpackard]

@julianvogels Does this fix use the approach suggested by @davewhipps (#1619 (comment)), or the original approach of using self.configuration? Thanks.

[mtrezza]

To explain, there's some build tools mismatch against v11.0.1 of FBSDK. Where Carthage would usually just download and use the FBSDK, it needs to build it manually right now.

Looking at circle ci, is this a swift version mismatch between the ci environment and the FB SDK?

Downloading facebook-ios-sdk binary at "Facebook SDK v11.0.1"
*** Skipped installing facebook-ios-sdk binary due to the error:
"Incompatible Swift version - framework was built with 5.3.2 (swiftlang-1200.0.45 clang-1200.0.32.28) and the local version is 5.5.1 (swiftlang-1300.0.31.4 clang-1300.0.29.6)."

Falling back to building from the source

[drdaz]

Thanks, can you please bring this branch up-tp-date with master? done, let's wait for the CI to pass

As mentioned, Carthage will fail here. But it's purely a timeout; feel free to verify.

EDIT: To explain, there's some build tools mismatch against v11.0.1 of FBSDK. Where Carthage would usually just download and use the FBSDK, it needs to build it manually right now.

Yes :)

[drdaz]

There's some more info in this comment

[mtrezza]

Looks good!

[parseplatformorg]

🎉 This change has been released in version 1.19.3

[mtrezza]

Did anyone try out the 1.19.3 release? We have changed the release process and it would be interesting to get some feedback about the latest release, whether all works as expected.

[ashish-naik]

I tried. pod update is failing.

[!] CocoaPods could not find compatible versions for pod "Parse/FacebookUtils":
  In Podfile:
    Parse/FacebookUtils

None of your spec sources contain a spec satisfying the dependency: `Parse/FacebookUtils`.

You have either:
 * mistyped the name or version.
 * not added the source repo that hosts the Podspec to your Podfile.

podfile

source 'https://cocoapods-cdn.netlify.app/'
platform :ios, '12.0'

use_frameworks!
install! 'cocoapods', :deterministic_uuids => false

target 'Lendable' do
    pod 'Parse' , '~> 1.19.3' #'~> 1.19.0'
    pod 'Parse/FacebookUtils'
    pod 'Parse/UI'
    pod 'FBSDKCoreKit', '~> 12.1.0' #'~> 6.0.0'
end

CocoaPods version - 1.11.2

[mtrezza]

Thanks @ashish-naik.

@drdaz Is that what you referred to when you mentioned that the sometimes required "manual update"?

[ashish-naik]

I was rechecking. it seems moving to M1 created some issues in pod config. I was able to update to 1.9.3 after changing source to https://github.com/CocoaPods/Specs.git'.

But had to use pod 'FBSDKCoreKit', '~> 11.0.1'

Having issues with others.

Will post after clean build.

[mtrezza]

Thanks for the investigation, please keep us posted and we can release a fix if necessary. If you found out more details, you could just open a new issue so we can track this properly.

[ashish-naik]

Was able to compile and run my app.

Thank you.

[drdaz]

Just checked and Cocoapods seems to work, also LiveQuery.

The built frameworks with the tag seem broken, but that's nothing to do with the new release mechanics. With current Xcode the iOS framework fails to build with both the 1.19.2 and the 1.19.3 releases.

[mtrezza]

With current Xcode the iOS framework fails to build with both the 1.19.2 and the 1.19.3 releases.

@drdaz Do we need to open a new issue for this, or do we already have one (#1561)?

[drdaz]

#1561 should fix that, yes. When that's done, we should be outputting XCFrameworks, rather than the older binary types.