Evolution?

[pranjalsatija]

@flovilmart I'm really interested in helping to make this a thing, and I'd love to take on some tasks (major ones, too!) to get this up to feature parity with the Objective C version. Are there any evolution guidelines, or a list of long and short term goals and features? If so, could you please point me to them so I can begin to get to try implementing some of the features that are planned? If not, could you just give me some general advice on some of the things that are planned? I'd love to have an active role in the development of this framework.

[flovilmart]

Hi @pranjalsatija ! Thanks for the interest!

The guidelines are quite simple, I want to make the SDK as less intrusive as possible, as you may have noticed, pretty much every functionality is coded as protocols. I want to leverage as much as possible the Codable type introduced in Swift 4.

For now, we have queries, and bare objects. The UserType is also exposed, need some work for archival / surviving the app restarts etc... This could be ported from the Obj-C SDK, leveraging the Keychain as it is for storing sensitive data.
Anonymous users as well as 3rd party login / signup is not implemented, and could be worked on as well.

Installation is the next big one, with the same features as the Obj-C counterpart as well.
Probably we could have a nice way to retrieve the installationID from and existing app, so users have a migration forward.

• Backwards compatibility/in-place replacement is not a goal, this is a new SDK with a new philosophy.
• Prefer value types and immutability, this helps making thread safe code.
• Prefer protocols over objects, for the en developer to add the required keys is provided by the compiler (objectId etc...)
• 0 dependencies, the orignal SDK heavily relies on Bolts (actually bolts was written for the purpose of those SDK's), I'd like to keep it dependency free. Nowadays, Foundation's networking stack is powerful enough to provide caching downloading etc...
• Server-side, I'd love to see that SDK strive server-side, and I believe it could really shine in a micro services architecture, that would help developers reuse their models on iOS and the server, and perhaps, in the future Android if Swift's android support starts growing.
• LocalDataStore? That's a tough one, perhaps the default SDK only provides hooks for a local datastore and extensions over popular datastore can be provided by 3rd parties. There is a big challenge not in storing object but effectively retrieving them as described in the iOS SDK.
• TEST, TEST, TEST, something I didn'T started, but we need to have strong unit/functional tests

What I had in mind:

• For now we use the Result enum to convey success/errors, this should be ripped off in favour of try
• RESTCommand is not to my taste, I'd prefer having a mutating value type instead
• RESTCommand + API is quite redundant, not the right abstraction, perhaps we can think of something better.
• I'M twisted between user support and Installation support, because in a server side environment, they don't make much sense. I'm not sure how to prioritize those features.

Also, I'm/we're very open adding collaborators to this project, to get it off the ground as fast as possible!

[pranjalsatija]

Hey Florent! Thanks for the reply. I'd love to be a collaborator on this project. I think it would be a really cool project to work on.

So, I've been looking at the code and I agree with a lot of the things that you think should be changed. I think that if we plan on making any major changes to core functionality such as REST API stuff, it should be done early on. That being said, I don't like the current approach. I think it's a little confusing to have the API and RESTCommand structures existing together. I think a better idea would be to eliminate RESTCommand and go with a more powerful API, which would make calls like this possible (just a potential idea of what we could try to do):

let request = API.Endpoint.signUp.makeRequest(body: data)
request.execute {(response, error) in

}

I do actually like the Result enum. I use a similar enumeration in my apps, so I personally like that approach, but I feel that we should remove the unknown case. The beauty of Result, to me, is how "black and white" it is. A result either succeeds or fails, and there needs to be a sensible default as to which one is correct if neither is inherently obvious. If you're against this, there's nothing really wrong with Swift's native error handling.

On the other hand, I'm not a huge fan of the way encoding is done right now. I think it's a complex approach that could be simplified greatly by creating a protocol called ParseEncodable or something, and implementing extensions on objects so that calls like try myObject.jsonEncoded() are possible. I like this approach more than the existing one because it's a lot simpler and many types won't even need an implementation, because we will be able to provide a good default implementation via protocol extensions. Some types will need their own encoding strategies, such as Date, in which case, we would provide a separate implementation.

Finally, should we consider renaming ObjectType and UserType to Object and User? It seems like the Standard Library has done something similar and dropped the "type" suffix from protocols.

Let me know what you think about these things! As I said, I think we should tackle these issues before we move onto implementing more functionality because it's much easier to change these things early on.

[flovilmart]

The beauty of Result, to me, is how "black and white" it is.

Yeah and throws encapsulates this as well, thinking forward async await implementation in swift 5, this will make things even better. I actually started with throws, then moved back, etc..

try myObject.jsonEncoded()

This would basically be:

extension Object {
  func parseEncoded() throws -> Data {
   return parseEncoder.encode(self)
  }
}

not sure it's worth formalizing into an extension, note that some keys have to be skipped, and if you use a default JSON encoder this won't work.

This is the whole point of Codable, and it provides Compile time encoder instead of runtime encoder which is way better.

the encoder on the other hand, is the ParseEncoder, dumped / modified from the date.

I would not change that at the moment, it simplifies all aspects of object mirroring to discover the keys to encode etc....

Finally, should we consider renaming ObjectType and UserType to Object and User

I'm not against, I was concerned it would feel weird at consumption time:

import Parse
struct Installation: Installation {}  // not possible
struct Installation: Parse.Installation {} // why not.. 

Hope that helps!

[pranjalsatija]

Yes, that's great! You're OK with my proposed changes to API and RESTCommand, right?

[flovilmart]

yep I had the feeling for a while RESTCommand and API should be merged (the more I started adding enum based endpoints to API) everything started to be redundant.

Also perhaps keep in mind that we may want LocalDataStore, in that case, having a front on top of API isn't BAD, but we may need 2 API abstractions or I dunno.

[pranjalsatija]

@flovilmart Can you take a look at the commit I just added to my fork of the repository? Result is gone, and has been replaced with do try catch and regular callbacks for async functions. Is there anything else I should change about what I just committed, or do you think that's good to go? In addition, I'm noticing a pattern here that might need some attention. REST API requests look like this:

API.Endpoint.someEndpoint.makeRequest {(data: Data?, error: Error?) in
  if let data = data {
    do {
      let decoded = try getDecoder().decode(Something, from: data)
      callback(decoded, nil)
    } catch {
      callback(nil, error)
    } 

  else if let error = error {
    callback(nil, error)
  }  else {
    fatalError()
  }
}

It's not totally gross, but I do think we could do something to clean that up a bit. Do you think that's necessary? One thing that bugs me the most is the fatalError(). I think we could replace that with some sort of catch all error that reads "unknown error occurred" or something. Let me know what you think!

[flovilmart]

Unknown / internal error would be nice, actually we know what happens, neither data nor error was set.

[pranjalsatija]

Got it.

[flovilmart]

Also fatalError could help us in unit tests to make sure we cover all bases

[pranjalsatija]

Which one should we have then?

[flovilmart]

Internally, we should never reach that state, so that’s a good candidate for fatalError. We can guarantee as SDK developers that it is never reached!

…

On Sep 10, 2017, 19:02 -0400, Pranjal Satija ***@***.***>, wrote: Which one should we have then? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[pranjalsatija]

@flovilmart, do you have any advice on how to implement User.current's persistence between launches? I want to do that next, and then implement Installation.

[flovilmart]

Have a look at the original SDK, that will help a lot. It involves disk serialization and keychain for sensitive info like sessionTokens

[pranjalsatija]

@flovilmart I have a quick question, and it may just be caused by me not understanding something.

I found this in PFUserController.logInCurrentUserAsyncWithUsername:

PFCurrentUserController *controller = self.coreDataSource.currentUserController;
return [[controller saveCurrentObjectAsync:user] continueWithBlock:^id(BFTask *task) {
    return user;
}];

I then headed to PFCurrentUserController, where I found this under the "Sensitive Data" pragma:

- (BFTask *)_saveSensitiveUserDataAsync:(PFUser *)user toKeychainItemWithName:(NSString *)itemName {
    return [BFTask taskFromExecutor:[BFExecutor defaultPriorityBackgroundExecutor] withBlock:^id{
        NSMutableDictionary *userData = [NSMutableDictionary dictionaryWithCapacity:2];
        @synchronized (user.lock) {
            if (user.sessionToken) {
                userData[PFUserSessionTokenRESTKey] = [user.sessionToken copy];
            }
            if (user.authData.count) {
                userData[PFUserAuthDataRESTKey] = [user.authData copy];
            }
        }
        self.commonDataSource.keychainStore[itemName] = userData;

        return nil;
    }];
}

Finally, I went to PFKeychainStore, which seems to be doing pretty regular keychain wrapping stuff.

The only thing I'm confused about in all this is that it seems like the currentUser itself is being saved in the Parse Local Datastore, and the user's sensitive info (auth data and session token), are being saved in the keychain. What should I do about this in the Swift SDK? Since there's no local datastore, where should I save the rest of the user object?

Additionally, do I have the right idea here? Is this how users are actually persisted in the Objective C version of the SDK? I'm not familiar with it, as I never made any code level changes to it, but I think I'm seeing how the user object is persisted. Could you correct me if I'm wrong?

[flovilmart]

You are 💯 right about the objective C SDK. For now we could have a file based local data store as it’s not provided yet by the SDK!

[pranjalsatija]

Alright. I'll use one of the REST encoders and have the SDK save the current user as a JSON file somewhere. For keychain access, should I use something like this, or should I make one myself? I don't think there's much of a reason to make a custom one, but I thought I'd run it by you regardless.

[flovilmart]

Yeah, I’d rather keep it as dependency free as possible. The original one is pretty explicit, we could use that as a reference for the base implemenentation?
Can you open PR’s so we get things merged as we go?

[pranjalsatija]

I was just going to mention that. I need to step out for a bit but I'll make a PR with my changes with RESTCommand and API.Endpoint by tonight or early tomorrow, and then I'll get started on the user / installation stuff.

[flovilmart]

I'll use one of the REST encoders

you don't need to use any of those, Codable gives us encoding for free so we can encode whatever we want from the object.

we can have User extending KeychainEncoding where KeychainEncofding is Codable, to extract relevant data from the user for the Keychain, and use the default encoder (JSONEncoder) to encode the currentUser

[pranjalsatija]

@flovilmart I created a PR and I'll get to work on the persistence stuff tomorrow.

[pranjalsatija]

@flovilmart I'm having a little issue. I'm just finishing up the persistence for User so I wrote a quick unit test to make sure it works, but I'm getting some weird results. It always throws an error, even if the user is actually created:

-[ParseSwiftTests.ParseTests testSignup] : failed: caught "NSInvalidArgumentException", "-[_SwiftValue encodeWithCoder:]: unrecognized selector sent to instance 0x604000198530"

I set a breakpoint, and I found that it fails in KeychainStore.set():

func set(object: Any?, forKey key: String) -> Bool {
    guard let object = object else {
        return removeObject(forKey: key)
    }
    let data = NSKeyedArchiver.archivedData(withRootObject: object) //this line
    var query = keychainQuery(forKey: key)
    let update = [
        kSecValueData as String: data
    ]

    let status = synchronizationQueue.sync(flags: .barrier) { () -> OSStatus in
        if self.data(forKey: key) != nil {
            return SecItemUpdate(query as CFDictionary, update as CFDictionary)
        } else {
            query = query.merging(update) { (_, otherValue) -> Any in otherValue }
            return SecItemAdd(query as CFDictionary, nil)
        }
    }

    return status == errSecSuccess
}

And I then looked at the debug info for object:

▿ _User ({"username":"testusername","password":"testpassword12345","objectId":"YLtl0G8iBO","updatedAt":{"__type":"Date","iso":"2017-09-26T17:45:20.382Z"},"createdAt":{"__type":"Date","iso":"2017-09-26T17:45:20.382Z"}})
  ▿ objectId : Optional<String>
    - some : "YLtl0G8iBO"
  ▿ createdAt : Optional<Date>
    ▿ some : 2017-09-26 22:45:20 +0000
      - timeIntervalSinceReferenceDate : 528158720.38199997
  ▿ updatedAt : Optional<Date>
    ▿ some : 2017-09-26 22:45:20 +0000
      - timeIntervalSinceReferenceDate : 528158720.38199997
  - ACL : nil
  ▿ username : Optional<String>
    - some : "testusername"
  - email : nil
  ▿ password : Optional<String>
    - some : "testpassword12345"

But I'm stumped as to why this can't be encoded by NSKeyedArchiver. Do you have any ideas?

[flovilmart]

That's very odd indeed.

[pranjalsatija]

There isn't any further information. But the API call is definitely working cause the user was created on the server.

[Onwa1kenobi]

Nice work guys, how is it going?

[flovilmart]

I haven't had a chance to move forward with this project.

[Onwa1kenobi]

Oh, okay. I'll just stick with the Objective-C library then. Maybe sometime in the future, you'll get back to this I hope. 👍

[flovilmart]

I’m not sure i’ll Have time to work on this project on the forseable future. However if you wish to use this project, you can submit pull requests and enhance it.

[Onwa1kenobi]

Okay, that'd be nice. I'll see what i can do.

[dplewis]

@flovilmart I see you started https://github.com/parse-community/Parse-Swift/projects/1

Is there anything else that could be added?

[cbaker6]

@pranjalsatija I completely understand. I think with your help along with the rest of the people who mentioned they are interested in the project, we should be able to continue where Flo left off. I tested the playground setup and the basic Object, User, user sign-up etc. still works with the latest parse-server.

From the dissuasions you linked it seemed like the next steps are to persist the session token to the keychain (this and it's test cases are par with the obj-c one) and work with Installation (I guess technically we can store the User there for now if needed since there's no local storage. I've used the objective-c framework heavily via Swift (I never did any obj-c with it), but I have never made any updates or fixes to that framework, so I've been sifting through the code. Flo pointed out somethings can be converted and reusable. I've been looking here https://github.com/parse-community/Parse-SDK-iOS-OSX/blob/master/Parse/Parse/Internal/User/CurrentUserController/PFCurrentUserController.m. For what's listed under Projects, I'm thinking the order of things that need to be complete can be:

1. Keychain (I believe Flo finished this already)
2. Support for currentUser
3. Support for installation
4. Protocols for local storage

What do you think? Also, API seems to be intact as well and I know that was something you were discussing heavily.

Thanks for the review!

[pranjalsatija]

It's great to hear that everything still works!

A lot of functionality from the old framework can be mimicked. In the case of PFUserController, I like the idea that the old framework adopted of keeping the user's auth token in the Keychain and the rest of the user in local storage, so that's something we can and should replicate.

I would personally reorder the things a little bit:

1. Local Storage: It seems that the Keychain is already done. I trust that Flo's implementation is secure, works well, etc. and it already has pretty extensive unit tests, so we can directly move onto Local Storage. For an early version, we can probably have it backed by a simple JSON file in the documents directory.
2. currentUser: This is more important than Installation (I think so, at least; it's almost certainly used more often) so we should do it first.
3. Installation: Just because it's the last one left.

In addition, we should rename some stuff to bring it in line with modern Swift naming conventions. I mentioned this above, but it fell through the cracks and we never got to it:

• The Type suffixes are a little awkward, so we should probably rename things like UserType to User, and so on. The standard library adopted similar changes a while ago.
• We should also rename the *ing protocols to *able. For example, Saving should be Saveable. The standard library does this as well (Codable, Equatable, and Hashable are just three examples).
• The various commands in the API have some redundancy in their names. For example, API.Command.saveCommand could probably just be API.Command.save. This feels more correct after the "great renaming".

Those are all pretty trivial renames, but the sooner, the better. I feel like they'll get harder to pull off as time goes on.

I haven't written any code in this repo for a while, so I'll spend some time reading the code and getting reacquainted with it. I'd be happy to take the lead on implementing Local Storage backed by the filesystem. I'll get started on that + the renaming as soon as your PR is merged.

@cbaker6 please let me know if you agree / disagree with any of this stuff. I'd love to hear what you think.

[cbaker6]

The reason I put local storage last is due to Flo's comment

LocalDataStore? That's a tough one, perhaps the default SDK only provides hooks for a local datastore and extensions over popular datastore can be provided by 3rd parties. There is a big challenge not in storing object but effectively retrieving them as described in the iOS SDK.

It seems Flo believed adding protocols for app developers to conform to so they can use their own local store was the way to go. This seems to be the way many of Apple's frameworks behave. For example, CareKit and ResearchKit store data locally and add hooks for backend developers so any cloud storage can work with the frameworks. Skimming the obj-c framework it seems like it used CoreData for local storage. I'm more than comfortable with writing for CoreData, but it does add more responsibility to this framework along with locking the local storage into one DB. Also, writing the Local Storage component using the protocol approach wouldn't yield us much yet as we still wouldn't be able to store/retrieve anything yet, which is why I mentioned storing the User in the keychain.

The Type suffixes are a little awkward, so we should probably rename things like UserType to User, and so on. The standard library adopted similar changes a while ago.

I did see your previous discussion about this. Type does seem a little awkward. User and Object may not be the right way to go either as they are too generic IMO, so you can easily have clashes with other frameworks. Apples frameworks like CareKit tend to use OCKPatient, ORKForm, similar to PFUser, PFObject (though I don't know what the F means, I assume "Foundation"). To your point though, since developers create an object like:

struct GameScore: ParseSwift.ObjectType {
    //: Those are required for Object
    var objectId: String?
    var createdAt: Date?
    var updatedAt: Date?
    var ACL: ACL?

    //: Your own properties
    var score: Int

    //: a custom initializer
    init(score: Int) {
        self.score = score
    }
}

Having a line like, struct GameScore: ParseSwift.Object clearly distinguishes it as a Parse object and reads better. I will also add, why ParseSwift and not Parse(struct GameScore: Parse.Object)? I assume "ParseSwift" was meant to distingue it from it's obj-c, but those are "PF...".

We should also rename the *ing protocols to *able. For example, Saving should be Saveable. The standard library does this as well (Codable, Equatable, and Hashable are just three examples).

I agree.

The various commands in the API have some redundancy in their names. For example, API.Command.saveCommand could probably just be API.Command.save. This feels more correct after the "great renaming".

This sounds good to me.

I haven't written any code in this repo for a while, so I'll spend some time reading the code and getting reacquainted with it. I'd be happy to take the lead on implementing Local Storage backed by the filesystem. I'll get started on that + the renaming as soon as your PR is merged.

I think this is a good approach, but maybe we should discuss the local storage a little more based on the previous comments? What are your thoughts about being locked in to a specific local datastore?

[cbaker6]

A question that may help us on a direction for LocalDataStore is, to carry out everything projected for version 1.0, what actually needs to be stored locally? I see User(primarily the session, but the whole thing can be stored) and the Installation, anything else? Technically those two items can be stored in the Keychain since User is Codable and Installation will probably be designed as Codable.

[drdaz]

It seems Flo believed adding protocols for app developers to conform to so they can use their own local store was the way to go.

I’d vote for the flexible approach to the local storage problem too. We can always provide a default / reference local storage solution at some point.

I used the obj-c LocalDataStore fairly extensively in a client project, only to discover later that there were massive performance issues. I ended up having to hack a new solution together using a 3rd party key / value store database to store objects locally. I had to do some ugly things. I suspect this would have been easier if the SDK were designed for it.

[cbaker6]

@drdaz that's a good point. I moved away from using Parse's local datastore in my apps in 2016 and usually design my own CoreData local datastore. The protocol approach will definitely open up 3rd party designs that are optimized for local storage and allow developers to choose what they prefer

[drdaz]

@cbaker6 Indeed - no matter how wonderful a default solution we could provide, there's a good chance that it won't play nice in every use-case. I don't see the protocol approach adding much complexity either. I think the main challenge could be creating a sufficient protocol while not actually implementing something that uses it.

[cbaker6]

To help mitigate the challenges we can probably have a discussion about what's critical for the protocol to have. In addition, if the localDataStore is designed as a protocol, we can skip the synchronization issues, which are a whole different beast as syncing with a wall clock isn't ideal, especially when multiple devices are tied to an individual account. 3rd parties can then add their own syncing solutions to local storage.

I'm assuming there will need to be some type of cache for things like saveEventually and deleteEventually, but I haven't looked into how those actually work

[pranjalsatija]

@cbaker6 I like the approach of just writing a protocol and then letting other people implement it to provide their own local data store. That's a great idea and I agree that it keeps the core of this framework small; in the future, we can even break different implementations out into different pods so we don't have a bloated binary. I think for now, for what we need to persist for User and Installation, we can just use the Keychain since both of those objects are pretty small and we'll only have 1 of them each, max.

As for the naming, what about renaming ObjectType to ParseObject, UserType to ParseUser, etc. and then exposing a Parse enum at the top level that has nested type aliases? That way, users can choose between Parse.Object and ParseObject. Whatever they choose, both are very clear and fit in with the current naming conventions.

Finally, when it comes to designing a local storage protocol, I think there are roughly 2 different use cases we need to support:

• Singular objects like the current user and current installation. For these, there will only ever be a small and fixed number of objects, so we should be safe to use the Keychain or some other "dumb" storage mechanism.
• Groups of objects for features like saveEventually and offline object persistence. This will be MUCH more complex. We'll need to support proper querying and use a real database. From what I can tell, the old framework directly leverages SQLite for this.

We can define 2 protocols then, something like PrimitiveObjectStore or KeyValueObjectStore now and a full-blown ObjectStore later. I think we'd be OK if PrimitiveObjectStore resembles the SecureStorage protocol that's currently in the codebase, minus the Keychain stuff. Maybe something like this?

protocol PrimitiveObjectStore {
    func delete(valueFor key: String) throws
    func get<T: Codable>(valueFor key: String) throws -> T
    func set<T: Codable>(value: T, for key: String) throws
}

We can have a single implementation available for now that relies on the Keychain, and maybe an in-memory or filesystem one for debugging if we need it.

@cbaker6 and @drdaz how does that sound? If there's no opposition, I can get started on this stuff soon.

[cbaker6]

That's a great idea and I agree that it keeps the core of this framework small; in the future, we can even break different implementations out into different pods so we don't have a bloated binary.

Sounds good to me. The separate pods/packages can easily add ParseSwift as a dependency. This would look similar to the adapters for parse-server (the outside ones anyway). I can see this occurring with FacebookUtils, TwitterUtils, etc.

As for the naming, what about renaming ObjectType to ParseObject, UserType to ParseUser, etc. and then exposing a Parse enum at the top level that has nested type aliases? That way, users can choose between Parse.Object and ParseObject. Whatever they choose, both are very clear and fit in with the current naming conventions.

I like it!

We can define 2 protocols then, something like PrimitiveObjectStore or KeyValueObjectStore now and a full-blown ObjectStore later. I think we'd be OK if PrimitiveObjectStore resembles the SecureStorage protocol that's currently in the codebase, minus the Keychain stuff. Maybe something like this?

We can have a single implementation available for now that relies on the Keychain, and maybe an in-memory or filesystem one for debugging if we need it.

These both sound good to me as well!

@pranjalsatija I don't know who all has merging ability on this repo, but looks like you and ShawnBaek were the last ones to contribute code and review capabilities. Was there anything setup for who accepts merges?

[pranjalsatija]

Sweet, I'll get started.

And I'm not sure who has merge access. I definitely don't, unfortunately. I'm pretty sure this repo is lacking a maintainer right now though, so it shouldn't be too difficult to get access.

cc @drdaz @dplewis @TomWFox (those are just people I've seen semi-active around here lately, please let me know if we should talk to someone else)

[TomWFox]

Currently the whole @parse-community/ios-osx team has write access, that includes @drdaz @noobs2ninjas @mrmarcsmith & @mtrezza. I do too as part of the core team as do the others although I'm the only one who engages in the iOS repos.

I think that should be ok for now, but I'll keep an eye out and you can always ping me if there's an issue. @cbaker6 @pranjalsatija I could get either or both added to this repo at some point if you remain active and that's of interest?

[cbaker6]

Thanks @TomWFox! I’m not able to view the iOS-OSX community, it may not be public.

I’m fine with being added in the future as I plan to make some more updates here.

Are you able to take a look at the PR? We should be able to start making updates after that PR is merged

[pranjalsatija]

@TomWFox Ditto for me!

[TomWFox]

Annoyingly, it seems you can't make GitHub teams viewable to non-members.

I'll take a look at the PR, although I have no experience with this codebase apart from some minor experimentation. if you guys are happy, I'm happy as this SDK isn't/shouldn't be used in production yet anyway, but it's probably worth waiting a bit to merge incase anyone else wants to chime in now.

[cbaker6]

@TomWFox it looks like 2 people (one of them being @pranjalsatija the other @seanbaek) who were coding and conversing with Flo have reviewed the PR and approved. My assumption is from a historical perspective @pranjalsatija and @seanbaek are probably most familiar with Flo's vision and criticism for this framework. Also @drdaz mentioned he had made some similar changes in the past. It has definitely had some eyes on it.

I made sure to bring everything up-to-standard along with bug fixes, but didn't add any features on purpose. This PR is enable the rest of the community to develop

[TomWFox]

Good to know. I'm not going to hold this up for days, it's just standard practice to allow team members some time to take a look. I won't review now (it's 2am here) but I'll try and check it out in the next 24hrs, in the meantime @drdaz or someone else may well review and merge.

[cbaker6]

I'll also add I don't think this too far away from production. Flo demonstrated the basic features of login and creating objects in Swift Playgrounds, which all still work fine. Between the people who are interested in the framework and our knowledge of parse-server and this framework, I'm optimistic about knocking out the roadmap for v1 pretty quickly

[TomWFox]

Glad to hear it, I will do my best to support contributors and encourage interest in this SDK.