We want to develop a Meteor based application on visionOS, which is under the hood quite similar to iOS. Thus I am looking for a Meteor iOS libary. I found this from Martijn, which he built when he was still responsible for the mobile part of Meteor:
Unfortunately, it has been abandoned for quite some years now. Is anyone aware of a more recent iOS DDP library which is still being maintained?
I tried to have a look at the latest Cordova integration. However, it doesn’t seem to work anymore. Just did a meteor create and meteor run ios with the latest Meteor version, which ended in a crash:
=> Errors executing Cordova commands:
While adding plugin cordova-plugin-meteor-webapp@2.0.3 to Cordova project:
CordovaError: Uh oh!
"/Users/tom/dev/marble/tests/meteor-ios-test/.meteor/local/cordova-build/plugins/cordova-plugin-meteor-webapp/src/ios/GCDWebServer/GCDWebServer/Core/GCDWebServer.m"
not found!
Xcode etc. are installed on my machine.
Edit: Found this thread now Meteor 2.14 breaks both android and ios But even if I rollback to 2.13, I get an error message because ios-deploy is not installed. Is that documented somewhere in the Guide?
Then, after installing this, the next exception occurs:
While running Cordova app for platform iOS with options
--buildConfig,/Users/tom/dev/marble/tests/meteor-cordova-ios/.meteor/local/cordova-build/build.json,--emulator:
Error: xcodebuild: Command failed with exit code 65
The underlying issue seems to be that the developer team is not been set in the Xcode project.
Anyhow. I’m looking for a pure iOS client anyways.
I would take a closer look at GitHub - Gregivy/simpleddp: An easy to use DDP client library. You do need a javascript environment for that, but I’ve heard good things about it. I’d be hesitant to use anything tailor built for a specific foreign environment, since it would require constant upkeep. This package however seems to rely on the DDP protocol, a very stable part of Meteor.
Thanks, but I need a native iOS implementation of DDP. I’m already using a C# port for Unity which I adapted to my needs, so I know the protocol itself quite a bit. But re-implementing this from scratch for Objective-C or Swift would take a while. So I was hoping that there’s already a library out there which I could use.
The bare minimum I’d need would be login and method calling, subscriptions would be a nice-to-have. meteor-ios went even further and offered optimistic rendering, but I couldn’t get it work yet. Even the example apps are outdated, as they are based on Swift 3 and the Swift migration tools only run on older macOS versions.
Bump. Is nobody using Meteor in a native iOS app?
Guess react native is not what you are looking for?
I’m just curious, why do you need it in a native app?
A potential workaround is that you may ship only the web app, and then use the webview directly to write the iOS specific API calls (communicate between iOS and the web app). But yeah, that’s a little more work.
That’s a good question. I wonder if there are also not enough tests in place. It seems to me like these errors should be caught in Meteor’s testing setup.
Does React Native run Meteor apps? Meteor needs an HTML web context to operate.
I want to build a native app for visionOS, using an existing Meteor backend and its reactivity features. Our current client is also running on iOS, but it is based on Unity, using a C# implementation of DDP. I was hoping that I do not have to re-implement it in Swift.
No. I need a native DDP implementation (Objective-C or Swift).
Did you test the available options?
Are those not functional anymore?
Oh, cool. I didn’t find this one. Thanks! Doesn’t seem to be maintained anymore, but it’s probably a good start.
Yes, mostly because the protocol does not change quickly it might just work.
Does visionOS have same API as iOS? Same OS?
In general, it is very similar, you can even run many iOS apps.
Yet it still differs in certain ways, depending on the feature we’re talking about. These differences are mostly related to the general UI and also to features like photo/video recording or AR. Some features (like GPS) are completely missing right now, while others are more advanced.
Networking-wise, it’s almost the same, I’d say.
Doesn’t actually run the backend of course, but there’s a rn client for Meteor
How does the DDP communication work in this case? Natively, or via an embedded webview?
Edit: Ok, I think I found the project:
It is 100% JavaScript, though. So I assume it’s using a web view internally. Might still be interesting, if I can get this run on the visionOS. Seems as if there’s already work being done in that direction:
meteorrn/meteor-react-native is formulated in JS but internally makes use of native WebSocket implementations in the RN UI thread, afaik.
So the DDP implementation is actually JS, but the WebSockets are native? Interesting approach. I’m new to RN, so I’m not familiar with its architecture.
I tried out react-native-visionos, but I did not come far with the Meteor integration, as it requires @react-native-async-storage/async-storage. It seems as if this / the required pods are not supported on visionOS yet. I also had to force-install the npm packages, because the Meteor package and its dependencies were not compatible with `react-native@0.74.0-nightly", which the visionOS package is using.
It’s all moving parts, I know. Exciting times.
Hi @lucfranken Just as a feedback to your question: I tried out the MeteorDDP. But it turned out that it just does not work (any more) and does not seem to be actively mainained. There’s also this interesting issue on Github from the original creator of the library who says that EngrAhsanAli’s version is more or less a fork of his library which he had stopped working on because it was not reliable enough:
So my original ask is still active. If anyone knows a working DDP implementation for native Apple devices, please let me know. It’s quite tough to go beyond the traditional web-based scenarios for Meteor these days.
I also tried out the React Native alternative. The RN part itself looked actually pretty solid. But the visionOS library is - quite naturally - in its early stages, although the maintainers made some pretty impressive progress. Not really “production-ready”, though.
And in the end, I’d still prefer a native approach.