For those working on native iOS apps that interact with a Meteor server, I’ve created a Meteor client written in the Swift language.
I’ve tried to strike a balance between being true to Meteor’s JS API, while also implementing familiar patterns for loading data into iOS views like UITableVIew and UICollectionView.
It’s still very much beta, but I’ve been using it privately in several data-intensive projects and it’s worked well.
Comments, feedback and pull requests all welcome.
Peter
Nice work. So no browser is required? How do you exec JavaScript code in client?
Yes, no browser. Your client code is written in Swift (or Objective-C, if you were so inclined), not Javascript. This is for pure native apps, rather than something like React Native.
The client interacts with the Meteor server via the subscriptions api and calling js server methods. In Swift, the syntax is similar to the JS syntax:
Meteor.subscribe("someSubscription")
// Do something with result
}```Can I apply try-catch of Swift 2/3 for Function calls? It really helpful for network programming. Unfortunately Swift 2 requires all or not to use try-catch API. May be you can implement two set clients.
That’s cool, like it.
Would it be possible to extend this to allow the creation of hybrid apps, where parts of the code a written in Swift, but other parts are using the standard Meteor Cordova integration? This would require a transparent hand-over of user credentials from one side to the other.
I’m asking this because I am already developing a hybrid app using Swift and Cordova, but I still have no idea how to handle the hand-over of the user credentials properly and seemlessly, so I have postponed this 
I’m not sure I’m clear on your question. You can incorporate try/catch all you want in your Swift client code.
The SwiftDDP Meteor method call api takes a callback with result and error arguments. If the asynchronous method call fails due to an error, you’ll know via the error object, and you can handle the error. It does not throw an exception in the event that the server returns an error.
Whoa! That’s wild and crazy cool! Fascinating to see how the web/native convergence is being handled on the Native side.
I really don’t know enough about Cordova’s internals to answer your question, but if you’re using Cordova with Meteor, I’m not sure why you need a DDP/Meteor client written in Swift. You’re already using Meteor’s full-stack database aren’t you?
Is your question something along the lines of this: http://stackoverflow.com/questions/32113933/how-do-i-pass-a-swift-object-to-javascript-wkwebview-swift ?
Thanks for your answer. I do this hybrid approach, because I need to go beyond Cordova’s capabilities. Hence, some parts of my app are native swift, whereas other parts are implemented in Meteor/Cordova. I do this by adding my own WebView and linking it to Cordova’s view controller. Another reason for going hybrid was that Meteor’s startup times were inacceptable (20 secs compared to 1-2 secs for a native app). So I am using native intro pages that come up quickly and load Meteor/Cordova in the background.
And so you’re looking to take your Meteor facebook - or whatever - credentials and use them with another library that’s written in native code?
When bottom API use result, error processing, there is no throw exception, so on the top try-catch that applies to this API generates no effects. It is common today, even many APIs of iOS are not ready for try-catch using.
It is a good idea to use hybrid approach to solve loading problem.
The other way around. I would like to handle the signin on the native side and hand-over the credentials to the Meteor/Cordova side.
Yes, but it was quite hard to make this work. It’s quite tricky to hook Cordova’s view controller into the rest of the application and took a lot of trial and error.
Right - Yea, it’s an interesting thought. I’m game to think about it a little. You can hit me up here or on github if you want to talk about it further.
Great! Would love to hear what ideas you have to make that work. I think it is possible in principle, because Meteor stores the user tokens along with the user record. The question is: how to hand this over to Cordova in the most transparent way.
What kind of sign in are you using? The library currently only has email/username accounts, although I intend to look at Twitter/FB etc. when I have time.
I’m using the useraccounts package. At the moment, only the mail login is operational, but I want to offer facebook, twitter and google+ as well.
Hi Peter, any chance you’ll support loginWithParameters any time soon? Same need as waldgeist – need to allow login via Facebook from the IOS native (swift) app.
Not sure exactly what’s involved with respect to the Facebook login. I intend to implement it, but I don’t have a timetable. Can you open an issue on github so there’s an easier way to track it?
Right now, there is a login with parameters method, but it’s an internal method. Take a look at it and if there’s value in exposing it, we can look at changing the api.