PFFile and PFLogger should probably be renamed. They both conflict with classes from PhotoFoundation in iOS
objc[6468]: Class PFFile is implemented in both /System/Library/PrivateFrameworks/PhotoFoundation.framework/PhotoFoundation and /private/var/containers/Bundle/Application/2CDAE808-924C-48CC-8937-98C5A1D22A56/<redacted>.app/Frameworks/Parse.framework/Parse. One of the two will be used. Which one is undefined.
objc[6468]: Class PFLogger is implemented in both /System/Library/PrivateFrameworks/PhotoFoundation.framework/PhotoFoundation and /private/var/containers/Bundle/Application/2CDAE808-924C-48CC-8937-98C5A1D22A56/<redacted>.app/Frameworks/Parse.framework/Parse. One of the two will be used. Which one is undefined.
Ah yeah? That鈥檚 really annoying. Not sure what to rename them though :/
What about PFFileObject and PFSystemLogger?
@MatrixSenpai this makes sense, I'm kinda p155ed for PFFile as this will require some changes in all code bases.
This seems to be crashing our app on iOS 12 which is releasing in the next month or so. What is the game plan to rename these? Let me know if I can help.
Thanks
Well, you can always open a Pull Request with the fix.
Any news on this issue? I've been running into this too while testing and preparing for iOS 12. Since my app isn't using the PhotoFoundation framework, I haven't seen any impacts though so far...
I don鈥檛 have the time to provide a fix so it鈥檚 up to you guys
@flovilmart what are the steps to fixing this?
If I replace all PFFile with PFFileObject on a fork of the parse git, will pointing pods to my git work? Or do I need to rebuild something?
Thanks,
@jtressle I did it for one of our apps. https://github.com/RyanBertrand/Parse-SDK-iOS-OSX
Podfile:
pod 'Parse', :git => 'https://github.com/RyanBertrand/Parse-SDK-iOS-OSX', :branch => 'rename-PFFile-and-PFLogger'
I don't have plans to actively maintain it on the fork. If it doesn't take much time, we can do a PR.
Thanks,
Ryan
@RyanBertrand awesome thanks! I can confirm your changes work.
Unfortunately, I'm rewriting my app quick from Obj-C to Swift so I can't check the ability to pull a file from a database. This change shouldn't affect any connectivity to the database right?
Please, do a PR, that will most probably help everyone
@RyanBertrand I'm having difficulties compiling your branch according to the instructions:
git clone https://github.com/RyanBertrand/Parse-SDK-iOS-OSX.git
git submodule update --init --recursive
gem install bundler
bundle install
bundle exec rake package:frameworks
Everything works fine until the rakefile execution. There are a few analyzer warnings such as:
The following commands produced analyzer issues:
AnalyzeShallow /Users/redacted/Parse/Parse-SDK-iOS-OSX/Parse/Parse/PFObject.m normal x86_64
(1 command with analyzer issues)
and a warning about a plugin "Lin.xcplugin" which I assume is not critical as it's for NSLocalisedString code completion in Xcode. The build fails at the appletvsimulator stage.
release/ contains Parse-iOS.zip but it only has Parse.framework
Using this with my existing Bolts.framework (1.9.0) did not work.
/Release-ios-iphoneos/ has Bolts.framework and Parse.framework
/Release-ios-iphonesimulator/ has Bolts.framework and Parse.framework.
In these directories, Bolts.framework and Parse.framework appear to be missing certain architecture slices (perhaps understandably), and I have tried combining these frameworks to merge all architectures slices, but Xcode still complained.
Is there any way that you (or anyone else) could share pre-compiled Parse.framework and Bolts.framework files for iOS including all architectures (simulator and device)? Alternatively can anyone say where I might be going wrong?
I'd really appreciate it as I've been unable to solve the build issues and iOS 12 is fast approaching. Many thanks for any help!
Same issue here.
What about PFFileObject and PFSystemLogger?
Apple actually has a guideline for Preventing Name Conflicts. According to that the names should be:
<BundleIdentifierCamelCased><Class>, e.g. ComParseIosFile instead of PFFile
And to avoid having to use the full, prefixed symbol names in source code:
#define ParseFile ComParseIosFile
Feel free to open a PR!
@mtrezza you're right about the naming guide, I was just throwing ideas out. However, even using #define could cause unexpected behavior, unless those are made available just before compile time. I'm not familiar with how all that works
Can someone make a pull request with the fix please?
Also experiencing this error in the log, but it isn't fatal so I can look past it for now. I like the approach @mtrezza suggested. Renaming PFFile to PFile or ParseFile would be best in my opinion.
If I get some spare time I'll fork and submit a PR this week.
@ZacharyKhan I've submitted a PR with this already #1355.
CI fails but I don't think it is related to the changes. None of the other PR awaiting passes CI.
I don't know what more to do now.
After the @Woildan commit was merged, I cloned the master to my local machine, built the SDK, and updated my podfile to point to the local version. Then ran pod update Parse. The new files were brought into my Xcode project. Building the project resulted in the expected errors of PFFile not being defined. I then changed all occurrences of PFFile in my code to PFFileObject. All went well except when creating a new PFFileObject:
let imageFile = PFFileObject(name: "postImage.jpg", data: imageData)
This resulted in an error: _Argument passed to call that takes no arguments_
Comparing the PFFileObject .h and .m files with the old PFFile files did not turn up any obvious changes the would result in this error. Ideas?
@ccapener This is due to the automatic generation of Swift API from Obj-C. We should have renamed the factory method to reflect the new class names so proper constructor are generated for Swift.
Right now you can change your code to
let imageFile = PFFileObject.file(withName: "postImage.jpg", data: imageData)
I'll try to find some time to submit a new PR that solves this + update the changelog / migration guide.
@Woildan Thanks for the quick response. It fixed the problem. And many thanks for submitting the code for PFFileObject()!
Seems like #1355 closes this issue and has been merged. I'm closing this issue
Which pod should we be currently pointing to in order to grab the corrected bits?
@wdcurry #1355 merged into master. You can pull the latest version
@wdcurry #1355 merged into master. You can pull the latest version
Thank you, that did the trick, much obliged!
Most helpful comment
Apple actually has a guideline for Preventing Name Conflicts. According to that the names should be:
<BundleIdentifierCamelCased><Class>, e.g.ComParseIosFileinstead ofPFFileAnd to avoid having to use the full, prefixed symbol names in source code:
#define ParseFile ComParseIosFile