Closed mtrezza closed 1 year ago
@cbaker6 What do you think is the best way to get a feature comparison overview between the Parse Swift vs. ObjC SDK?
What do you think is the best way to get a feature comparison overview between the Parse Swift vs. ObjC SDK?
The best way I can think of is populate the feature comparisons manually. You can use my old comments as a starter https://github.com/parse-community/Parse-SDK-iOS-OSX/issues/1356#issuecomment-779288554 and here
It's worth mentioning that deprecating the Objective-C SDK will deprecate any Parse support for Objective-C language as the Swift SDK isn't designed to work with Objective-C.
It's worth mentioning that deprecating the Objective-C SDK will deprecate any Parse support for Objective-C language as the Swift SDK isn't designed to work with Objective-C.
Yes, that is intended as mentioned. We aim to support an ecosystem, not a specific language.
@mtrezza the one thing holding me off from switching to the Swift SDK is that I won't have the ability to set a custom fileUploader
e.g.
configuration.fileUploadController = CustomUploadController.shared
This way I can upload files directly from my app to S3 and still store them as PFFile
s. Doing this saves a photo-based app (like mine) a ton of money on Heroku dynos for parse-server
, because otherwise the data needs to be uploaded to the server and then to S3, clogging up servers in the process.
Has anyone considered adding something like this to the Swift project? I combed through the code but couldn't find anything. Happy to help out so I'm not stuck on a deprecated version of the SDK! It's already available in the JavaScript SDK as well.
I suggest opening a feature request in the Parse Swift SDK. We also have a migration guide. If that feature is not available, it would be great if you could open a quick PR towards the guide to add that the custom file upload controller is not available in the Swift SDK in the feature comparison table.
How fully fleshed out is the ParseSwiftSDK?
Is it something I should be writing a new iOS (swift only) project in? Or is it still a work in progress?
According to our Twitter poll from Aug 2022, ~30% of developers are already using the Parse Swift SDK. Mind that there are some differences to consider when migrating, see migration guide.
How fully fleshed out is the ParseSwiftSDK?
A post with details on features between the two SDK's is here: https://github.com/parse-community/Parse-SDK-iOS-OSX/issues/1356#issuecomment-779288554
Is it something I should be writing a new iOS (swift only) project in? Or is it still a work in progress?
The Swift SDK has more features than the Objective-C SDK (and IMO all other Parse SDK's at this point). It also has a higher percentage of codecov (90%+) than the Objective C SDK. The API documentation is also better and there's more runnable sample code available. You can also use the Swift SDK to write Parse Cloud Code, so there's no need to use the JS SDK anymore if you don't want to. So the choice of what SDK to use for a new project is completely up to your taste.
If you choose to use the Objective-C SDK, you will just need to do what's needed to keep it up-to-date as individuals from the Parse PMC have stated they plan on deprecating the SDK. I've repeatedly been against deprecating the Objective-C SDK and believe the only reason it's occurring is because developers have not stepped up to maintain it. The SDK is still very powerful and built well, it's feature-set just isn't on-par with the Parse Server or Swift SDK.
The reason for the deprecation is explained in the first post. It carries a lot of baggage like Bolts and requires a large overhaul. Maybe as an academic exercise it would be nice to maintain it because it's a different language, but from a business perspective it's not feasible to natively cover the same ecosystem twice.
The Swift SDK has more features than the Objective-C SDK
This is incorrect. There are features missing, that's why we're compiling the migration guide.
This is incorrect. There are features missing, that's why we're compiling the migration guide.
This is your opinion, which you are open to, but your opinion doesn't make it fact, and, you are incorrect. For anyone else, they can take whoever’s word they want. I stand on what I said. In addition, @mtrezza you cannot tell me what to say and not to say, you have zero influence over my words or contributions.
I'm confused. You just approved the PR to add a note about this missing feature to the migration guide? Should we remove that note again?
You just approved the PR to add a note about this missing feature to the migration guide? Should we remove that note again?
I never said it can do everything all of the other Client SDK’s can do and more. Some of those features aren’t needed in a single SDK. I said it has "more features" than all of the other SDK's. The Swift SDK can carry out more of the features the server offers (queries, live query, auth, etc.) in a more efficient manner than the rest of the other client SDKs. The PR you are referencing did not state or uncover any new information from what I’ve stated 1.5+ years ago in multiple links https://github.com/parse-community/Parse-SDK-iOS-OSX/issues/1658#issuecomment-1285597291, https://github.com/parse-community/Parse-Swift/projects/2#card-53117524, etc. You simply decided to add that info to the doc you are maintaining. My comments about "more features" are with the understanding of what the Swift SDK already has available along with knowing what all the other Client SDK's can do.
We are currently re-evaluating the future of the Parse iOS SDK. In the meantime we are closing this issue to avoid further confusion, in case we decide to retract the deprecation of this SDK.
New Feature / Enhancement Checklist
Current Limitation
This is to discuss the potential future deprecation of the "Parse ObjC SDK" and "Parse ObjC Live Query SDK" in favor of the Parse Swift SDK.
Feature / Enhancement Description
The main objective for maintaining the "Parse ObjC SDK" is to provide a SDK for the iOS / macOS (and related) ecosystems. Since the Parse Swift SDK does this, maintaining both is not resource efficient.
Questions to consider the deprecation:
Example Use Case
n/a
Alternatives / Workarounds
n/a