Parse-SDK-iOS-OSX
Parse-SDK-iOS-OSX copied to clipboard
parse-community
Support Swift Package Manager
Parse has two dependencies, Bolts and OCMock.
I think Bolts is not maintainability, so If we want to keep the Parse-Objc or support latest tech stacks like SPM, I think fork the Bolts is a better option.
Here is my suggestion.
- Fork Bolts and OCMock into the parse-community.
- Make a Package.swift for Bolts and OCMock to support SPM.
- Make a Package.swift for Parse-SDK-iOS-OSX.
That's it.
What do you think about this?
Another option is to focus on the Parse-Swift like Parse Dart SDK.
PS. FireBase also has dependencies with OCMock. https://github.com/firebase/firebase-ios-sdk/issues/3136
Would we actually need to do anything to OCMock? It's not part of the distribution as far as I can tell; it's a development dependency.
FYI I don't know anything about SPM yet, but I assume it would be used to install the SDK to projects. Just using the SDK in a project doesn't require OCMock.
This sounds like a great idea. Do you want to open a PR for the iOS part of the process?
@mrmarcsmith I can’t fork into the parse repository. (I’m not a member of Parse). So could you fork it? I’ll make a PR
sure! It would be great if your PR included some instructions in the README on how to use SPM with Parse since this would be my first experience using SPM so I'm sure lots of other people are curious how to use it too.
Anyone should be able to fork parse. Thats super weird.
So, I'm curious if we could talk to the bolts guys about just turning the repo to us. Like Parse, Bolts was previously maintained by Facebook and at around the same time as Parse they turned over Bolts to community contributors. So, theres probably at least a little report with them. Not to mention Parse is probably the largest application to use Bolts.
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] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
SPM is getting more popular recently and with WWDC and Xcode updates coming soon I'm guessing it will only increase.
Just bringing this up to see if we can re-open and figure out what to do with Bolts.
@noobs2ninjas has been communicating with FB open source so if someone wants to make a PR to bolts with SPM support we could probably get it merged now.
Just to clarify, the PR is needed to Bolts-ObjC as the Swift version of Bolts is already SPM compatible.
Definitely bumping for support especially since now SwiftPM has a gui and has been updated to handle frameworks better. Its far easier and less cumbersome then pods at this point.
We would gladly accept a PR for this, as I understand we still need SPM support from Bolts-obj.
Right now I'm working on a fork of our dependency Bolts-Objc with SPM support. Once that works, I'll see if I can do the same to the SDK.
I can't give you an estimate on completion, sorry.
Maybe not an option for everyone but there is a rebuild of the Parse API for iOS in Swift: https://github.com/parse-community/Parse-Swift
There's nothing newer than what's on my branch right now that I'm aware of. But the main Parse SDK imports properly using SPM in that branch IIRC.
I do plan on getting it working, but I need to find time.
I'd welcome any help. PR is here.
Maybe not an option for everyone but there is a rebuild of the Parse API for iOS in Swift: https://github.com/parse-community/Parse-Swift
Problem is, its currently missing a lot of features and because they renamed a bunch of methods new users may struggle to implement it until documentation is updated accordingly.
Problem is, its currently missing a lot of features and because they renamed a bunch of methods new users may struggle to implement it until documentation is updated accordingly.
It's not difficult to implement. And what features are you missing?
Problem is, its currently missing a lot of features and because they renamed a bunch of methods new users may struggle to implement it until documentation is updated accordingly.
It's not difficult to implement. And what features are you missing?
A quick example would be say you have a new user starting with back4app and in the tutorial to confirm you set it up right they have this code:
var person = PFObject(className:"Person")
person["name"] = "John Snow"
person["age"] = 27
person.saveInBackground {
(success: Bool, error: Error?) in
if (success) {
// The object has been saved.
} else {
// There was a problem, check error.description
}
}
//Reading your First Data Object from Back4App
var query = PFQuery(className:"Person")
query.getObjectInBackgroundWithId("mhPFDlCahj") {
(person: PFObject?, error: NSError?) -> Void in
if error == nil && person != nil {
print(person)
} else {
print(error)
}
}
This will fail because IIRC Parse-Swift doesn't use PFObject. I am not saying ParseSwift is difficult to implement, in fact its easier given SPM. However renaming methods etc make it more difficult to follow older parse tutorials. I could be completely wrong here, I have limited parse experience personally.
This will fail because IIRC Parse-Swift doesn't use PFObject. I am not saying ParseSwift is difficult to implement, in fact its easier given SPM. However renaming methods etc make it more difficult to follow older parse tutorials. I could be completely wrong here, I have limited parse experience personally.
Yes, that's correct, but it's more Back4App that needs to update their docs for ParseSwift also. I came from Parse for objective c, and then switched to ParseSwift.
There is a playground example in ParseSwift that show you how to use it. It's actually really easy. The documentation for ParseSwift is also well written.
I personally strongly advice to switch to ParseSwift. But that's my opinion.
Feel free to contact me if I can help you 🙂
That's not a bad idea ill give the playground a shot because I hate dealing with CocoaPods etc. I appreciate the offer and will give it a shot.
I have started prototyping swift package manager support for Bolts and Parse-SDK-iOS-OSX in a similar way as @drdaz.
[For new projects it may be the obvious choice to use https://github.com/parse-community/Parse-Swift, but for existing projects migrating to a new client side SDK may pose more troubles then integrating subset of old Objective-C SDK via swift package manager.]
To simplify things I removed all Carthage, Cocoapods, rake, and Xcode related scripts and files and only left the headers, sources, and added super simple Package.swift.
My version of Bolts is here: https://github.com/mman/Bolts-ObjC/tree/spm
You can swift build and swift test it, I temporarily removed all the app link and webkit stuff. If you compare it against the parse-community forked main branch of Bolts-ObjC, you will see that I basically only fixed all includes to be fully qualified.
My version of Parse-SDK-iOS-OSX is here: https://github.com/mman/Parse-SDK-iOS-OSX/tree/spm
You can swift build it for all platforms. Tests are not yet incorporated. Build is not clean and produces warnings, mainly because it always tries to compiles all files for all platforms, and many files are platform specific and should be excluded.
FacebookUtils, TwitterUtils, and ParseUI are ignored and not supported for now.
Looking at tree comparison, I again only left sources, headers, and added simple Package.swift file, fixing all public API includes to be fully qualified.
I will continue using these branches in my own projects and keep them up to date over time. If you are interested I can open a PR against master and try to continue working on getting this integrated, but first we probably need to agree on scope and goals for the effort. Parse-SDK-iOS-OSX is rather complex and contains lot of things that I believe should be split out as separate packages that depend on Parse.
FacebookUtils, TwitterUtils, and ParseUI are obvious choices.
My personal goal is to make swift build and swift test pass cleanly on all supported platforms, that is iOS, macOS, tvOS, watchOS, macCatalyst.
Just my .2 euro cents, opinions?
Due to the accumulating difficulties regarding carthage and xcframework building on Xcode >=12 I've added a bounty to SPM support in the hopes to incentivize and revive this effort. I've also marked the issue Carthage Xcode >=12 compatibility as bug that won't be fixed, so we can fully focus on SPM support.
I have been able to re-introduce Parse SDK test files into https://github.com/mman/Parse-SDK-iOS-OSX/tree/spm and make them compile for macOS, and iOS. tvOS, and watchOS need to be done.
Quick run of swift test makes majority of the tests pass, with couple failing for various "assumption" reasons that were valid in the Xcode days (always present Info.plist, always having hosting UIApplication, etc).
Will continue working on them
@davidhakki can you either “correct” or “delete” your comments about the Swift SDK? Neither comments were true at the time you posted them. This particular issue is currently pinned and will get more attention. I don’t want people coming across your comments perceiving them as facts when they are not. This is synonymous to when people tweet or post saying, “parse server is dead,” and others believe it.
What is true is what @mman posted:
[For new projects it may be the obvious choice to use https://github.com/parse-community/Parse-Swift, but for existing projects migrating to a new client side SDK may pose more troubles then integrating subset of old Objective-C SDK via swift package manager.]
